W3C home > Mailing lists > Public > www-forms@w3.org > July 2001

Request for Feedback: Content Models in XForms

From: Micah Dubinko <MDubinko@cardiff.com>
Date: Mon, 16 Jul 2001 16:34:51 -0700
Message-ID: <E840F0B7E6189547BDB91DA8BF2228AB28BBD4@csmail.cardiff.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:49 GMT