
Here's excerpts from the latest XML Schema 1.1 draft (http://www.w3.org/TR/xmlschema11-1/) XML Representation Summary: all Element Information Item et al. <all id = ID maxOccurs = 1 : 1 minOccurs = (0 | 1) : 1 {any attributes with non-schema namespace . . .}> Content: (annotation?, (element | any)*) </all> <choice id = ID maxOccurs = (nonNegativeInteger | unbounded) : 1 minOccurs = nonNegativeInteger : 1 {any attributes with non-schema namespace . . .}> Content: (annotation?, (element | group | choice | sequence | any)*) </choice> <sequence id = ID maxOccurs = (nonNegativeInteger | unbounded) : 1 minOccurs = nonNegativeInteger : 1 {any attributes with non-schema namespace . . .}> Content: (annotation?, (element | group | choice | sequence | any)*) </sequence> Schema Component Constraint: All Group Limited When a model group has {compositor} all, then all of the following must be true: 1 It appears only as the value of one or both of the following properties: 1.1 the {model group} property of a model group definition. 1.2 the {term} property of a Particle with {max occurs}=1which is the {particle} of the {content type} of a complex type definition. So xs:all: - can contain elements as content (as 1.0) - can contain wildcards as content (new) - can't contain model groups as content (as 1.0) - content can repeat (new) - can be the content of a model group definition - can be the content of a complex type - can't be the content of a model group ** These rules prevent: a) xs:choice or xs:sequence directly inside xs:all b) xs:all directly inside xs:sequence or xs:choice Clearly wrappering in an element solves this but b) can also be solved by using an xs:group reference. On input: I agree that the infoset items emitted for xs:all content will appear in the order of the physical data On output: I think that the order of infoset items preented for xs:all content should appear in the order presented Sandy also made the point that because we are choosing an XML Schema subset for DFDL, we are at liberty to choose which of the 1.1 enhancements we adopt. Regards Steve Hanson Programming Model Architect WebSphere Message Brokers Hursley, UK Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 "Mike Beckerle" <mbeckerle.dfdl@gmail.com> 29/10/2008 13:13 Please respond to <mbeckerle.dfdl@gmail.com> To Steve Hanson/UK/IBM@IBMGB, <dfdl-wg@ogf.org> cc Subject RE: [DFDL-WG] DFDL & support for XML Schema 1.1 Very good. If these are the primary things in Schema 1.1, then this is a big help. Question: if we drop unordered property so that we have xsd:sequence groups and xsd:all groups, will we retain restrictions on nesting, i.e., can't nest xsd:all inside an xsd:all, etc. To me there's little or no downside to these restrictions because you can always put an element "wrapper" around an xsd:all group which changes the logical model, but in DFDL doesn't imply anything about the physical representation, so it's not really a problem. I assume xsd:all will have the semantics of preserving the arrival order, so it is much like an array of choice semantically. That is, the DFDL infoset will have the items within the xsd:all group in the order they appear in the physical data. Mike Beckerle | OGF DFDL WG Co-Chair | CTO | Oco, Inc. Tel: 781-810-2100 | 504 Totten Pond Road, Waltham MA 02451 | mbeckerle.dfdl@gmail.com From: dfdl-wg-bounces@ogf.org [mailto:dfdl-wg-bounces@ogf.org] On Behalf Of Steve Hanson Sent: Wednesday, October 29, 2008 7:54 AM To: dfdl-wg@ogf.org Subject: [DFDL-WG] DFDL & support for XML Schema 1.1 Sandy Gao at IBM has looked at the reasons for moving to schema 1.1 and concluded that DFDL should move. Grounds: - Weakened wildcard support - there is less ambiguity in 1.1 because an optional element x followed by a wildcard will match x, instead of giving a UPA error - this will enable DFDL to model more formats - Relaxation of <xs:all> means that it is suitable for DFDL use - this will allow us to drop the dfdl:unordered property - In Schema 1.0, annotations are lost on particles, but they are needed by DFDL. Schema 1.1 captures all annotations. 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