It also occurred to me that, if we follow through with our 'variable markup' piece of work, we could remove these properties altogether and use variable markup instead. Eg: Use dfdl:initiatorType property which referred to a simple type by name that carried DFDL properties that described how to extract the initiator. Not as convenient, but xsd:any is unlikely to be used that frequently. One thing we have not defined is how the element name for the infoset is deduced from the initiator. This is very straightforward with variable markup. It's just the value returned by the dfdl:initiatorType. If using separate properties we have to say what happens to white space etc. Neither have we explicitly said what types of DFDL representations are allowed for xsd:any. I think we had been assuming xsd:string only, but I don't see why it can't be any simple type? Regards Steve Hanson Programming Model Architect WebSphere Message Brokers Hursley, UK Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 18/03/2009 12:01 ----- Steve Hanson/UK/IBM 16/03/2009 10:45 To DFDL Working Group cc Subject xsd:any support - propose dfdl:initiatorLength property Here's what we say about xsd:any (wildcard support) in DFDL spec. Any Element Wildcard The "any" element wildcard provides support for initiator-tagged data formats. The dfdl:initiatorSeparator property must be defined or it is a schema definition error. The 'processContents' attribute is not allowed in DFDL 1.0 and it's use is a schema definition error. This kind of wildcard is used to absorb content which while syntactically compatible is not logically modeled as elements of the sequence group. These declarations match a triplet of strings. The first is a variable-length string that matches any initiator tag. The second is a fixed value string which must match the initiator-separator property value. The third is a variable-length string that matches any content up until the end of the "element" being matched. The length of data matching an any-element wildcard is specified by the usual length properties: dfdl:lengthKind, dfdl:lengthUnits, dfdl:length, dfdl:terminator. dfdl:initiator is not used by Any Element wildcards and is ignored if specified in scope. We insist on the presence of a known initiator separator to separate initiator from data. We should also allow initiator length, to support models where there is no separator. Exactly one of initiator separator and initiator length must be specified. Initiator length is not a valid DFDL property on any other xsd object. This is supported today by IBM's MRM parser. Regards Steve Hanson Programming Model Architect WebSphere Message Brokers Hursley, UK Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU