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

Trejkaz trejkaz at trypticon.org
Wed Aug 17 05:32:31 UTC 2005


Quoting David Waite <dwaite at gmail.com>:
>> A loose/strict scheme would work like this:
>>   * Implementations MUST conform to the loose schema.
>>   * Implementations SHOULD conform to the tight schema.
>>
>> In other words, you can use the loose schema to determine what other
>> implementations might send to you, so that you can prepare for it.
>
> How would you prepare for that different than the random xml they
> might send you?

For one, you would be able to validate their data as conforming to the loose
schema, and therefore "valid enough" to handle.  You might have an XML binding
library which does a lot of this work under the covers, where you just feed it
the loose schema.

Completely random XML, which validates to neither, could be rejected 
completely.
In this fashion you can handle some data which doesn't comply to the strict
schema, which would otherwise be rejected as well.

>> As far as I can tell, we really do mean <xs:all> in almost all cases.
>
> <xs:all> is very limited in terms of what you can do with it. For
> example, you cannot use xs:all if you want to allow more than one
> child element with a particular name.

Sure.  But when was the last time you saw two usernames in 
jabber:iq:register or
jabber:iq:auth?  This would only become a problem for more interesting schemas
like data forms, where you actually do want a mix of single and 
multiple items.

But of course, RELAX NG solved that limitation years ago.

  element x {
    (
      element instructions { xs:string }* &
      element title { xs:string }? &
      field* &
      reported? &
      item*
    ),
    attribute type { "cancel" | "form" | "result" | "submit" }
  }

With this you can have 0 or more instructions, 0 or 1 title, 0 or more 
field, 0
or 1 reported and 0 or more item... in any order you want.

TX


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




More information about the Standards mailing list