[Standards-JIG] sequence vs. choice in Jabber/XMPP schemas

David Waite dwaite at gmail.com
Tue Aug 16 00:40:00 UTC 2005


I vote for #1. Be strict in what you produce and liberal in what you
accept, right?

On 8/15/05, Trejkaz <trejkaz at trypticon.org> wrote:
> Quoting Peter Saint-Andre <stpeter at jabber.org>:
> > 1. Keep using xs:sequence and require existing implementations to pay
> > attention to the order of child elements.
> 
> Ouch.  That's going to be hell for people working with DOM-like APIs
> where it's
> not so easy to insert new elements into them in the expected order.  On the
> other hand, it's really easy for people generating their XML by string
> concatenation.
> 
> > 2. Switch to xs:choice and care less about the number of allowable
> > child elements.
> 
> If anything, <xs:all> is probably a closer fit in most of these cases.
> 
> e.g. JEP-0077 (In-Band Registration) currently has:
> 
>     <xs:sequence minOccurs='0'>
>       <xs:element name='username' type='xs:string' minOccurs='0'/>
>       <xs:element name='password' type='xs:string' minOccurs='0'/>
>       ...
>     </xs:sequence>
> 
> It could be...
> 
>     <xs:all minOccurs='0' maxOccurs='1'>
>       <xs:element name='username' type='xs:string' minOccurs='0'/>
>       <xs:element name='password' type='xs:string' minOccurs='0'/>
>       ...
>     </xs:all>
> 
> That way it still allows them in any order, but doesn't allow people to
> use more
> than one of each.  This is better than both <xs:sequence> and <xs:choice> for
> the majority of situations you can find in the JEPs.
> 
> > 3. Define two different sets of schemas: a strict one following (1)
> > and a loose one following (2).
> 
> XHTML did this in version 1.0, and practically nobody used the Strict
> version as
> there was no incentive given to use it.  They ended up making 1.1 effectively
> strict, removing the non-strict version.
> 
> > 4. Switch from W3C XML Schema to a different schema language, such as
> > RELAX NG, Schematron, or Examplotron.
> 
> RELAX NG is certainly much more powerful than W3C's XML schema.  They
> even seem
> to have acknowledged this themselves, as the drafts for XHTML 2.0 are entirely
> written in RELAX NG schema. :-)
> 
> It allows situations which we have that we can't currently represent.  For
> instance, we could specify that <status> and <show> elements don't
> occur inside
> <presence> when type="subscribe"... and that's just the tip of the iceberg, of
> course.
> 
> In addition to this, RELAX NG has a "Compact Syntax" which is just as flexible
> as the normal syntax, but much easier to read and write.  It's easier to read
> than DTDs, which were already a great deal easier to read than W3C XML
> schemas.
> :-)
> 
> And of course, because RELAX NG is a superset of all other schema
> functionality,
> there exist tools to transform it into other formats (approximating where
> necessary, of course.)
> 
> My main choice then, is (4).  And (2) is a reasonable fallback as long as
> <xs:all> is used in places where it makes more sense than <xs:choice>.
> 
> TX
> 
> 
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
> 
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mail.jabber.org/mailman/listinfo/standards-jig
>



More information about the Standards mailing list