- From: Micah Dubinko <MDubinko@cardiff.com>
- Date: Mon, 16 Jul 2001 16:34:51 -0700
- To: "'www-forms@w3.org'" <www-forms@w3.org>
- Cc: "'XForms@yahoogroups.com'" <XForms@yahoogroups.com>
XForms authors, enthusiasts and implementers: We'd like to gather your opinions on the topic of content models in XForms. The question is Which is preferable, a simple, fixed order content model, or a more flexible but very difficult to specify content model, or something else? An example: In the June XForms spec, the content model of <xform>, ignoring for now one small detail (the ##all allowance in the published version) is like this: OPTION 1: <xsd:sequence> <xsd:element ref="xform:submitInfo" minOccurs="0"/> <xsd:element ref="xform:model" minOccurs="0"/> <xsd:element ref="xform:instance" minOccurs="0"/> <xsd:element ref="xform:bind" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> This means authors MUST write the elements in exactly the specified sequence. Changing the order of the sequence in any way results in an invalid form. This is easy to do--even the examples in our spec fell down in the June WD! (Thanks to Andrew Watt for spotting this and sparking the discussion.) What we would really like to say is something like: 'one element x, one element y, multiple elements z, in any order'. Unfortunately XML Schema, with which we are mainly concerned, doesn't support this. Schema only supports <sequence>, as above, or <choice>. So one approach would be to offer several <choice>s of every possible ordering of the elements--an ugly and non-scalable solution. Something like this: OPTION 2: <!-- untested. great danger of ambiguous content models... --> <xsd:choice> <xsd:sequence> <xsd:element ref="xform:submitInfo" minOccurs="0"/> <xsd:element ref="xform:model" minOccurs="0"/> <xsd:element ref="xform:instance" minOccurs="0"/> <xsd:element ref="xform:bind" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:sequence> <xsd:element ref="xform:model" minOccurs="0"/> <xsd:element ref="xform:submitInfo" minOccurs="0"/> <xsd:element ref="xform:instance" minOccurs="0"/> <xsd:element ref="xform:bind" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> <xsd:sequence> <xsd:element ref="xform:instance" minOccurs="0"/> <xsd:element ref="xform:submitInfo" minOccurs="0"/> <xsd:element ref="xform:model" minOccurs="0"/> <xsd:element ref="xform:bind" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> ... and so on, until every permutation is covered... </xsd:choice> Another option in Schema, <all>, works only with single elements. If we restrict ourselves to maxOccurs=1 on every element, then we could use the <xsd:all> connector. This would require that XForms be constructed like this: OPTION 3: <xform> <submitInfo>... <instance>... <bindGroup> <bind>... <bind>... <bind>... </bindGroup> <model>... ... </xform> Where the order doesn't matter, but we are restricted to ONE element of each name as direct children of <xform>, forcing the multiple <bind> elements one level deeper. Any other element that allowed maxOccurs of >1, say <submitInfo>, would need to do the same. What is the best trade-off here? Is there another solution not even mentioned? Please direct your replies to www-forms@w3.org. Thanks! Micah J. Dubinko Chief XML Architect Senior Engineer (W) 760-936-4639 P.S. This exact discussion also applies to the content model of the form controls, where we currently have <xsd:sequence> <xsd:element ref="xform:caption"/> <xsd:element ref="xform:help" minOccurs="0"/> <xsd:element ref="xform:hint" minOccurs="0"/> <xsd:element ref="xform:onevent" minOccurs="0"/> </xsd:sequence>
Received on Monday, 16 July 2001 19:41:27 UTC