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

[Rich Salz]

(Hi, I just joined; spurred by the JEP-0072)

Here's a few thoughts on the schema issues.

I'd really like to see a normative machine-readable description of every 
message; ideally that would be a JEP requirement, just as the various 
"consideration" sections are.  There are a couple of reasons for this:
      It allows generic tools (such as mine) to test validity
      It makes conformance testing feasible
      It avoids the current problem, where one of the first two items
      takes a non-normative description too seriously.

I prefer XSD over RelaxNG, since XSD has much more commercial uptake.  I 
agree that Relax is more powerful, and is generally "better" by any 
technical metric, and that spending too much time with XSD, is believed 
to be a carcinogen.  I think it's worth the trade-off, but I am clearly 
biased and realize many will think otherwise.  More on Relax/XSD below.

If the order of elements doesn't matter, then pick an arbitrary one and 
use xsd:sequence. It makes receivers easier to write (no rescans or 
collecting pieces as you find them), and increases interoperability. It 
might make some sender implementations harder (they'll have to do DOM 
appendChild in the right order?), but the number of receivers is at 
least equal to the number of senders.

The number of times an element can be repeated is very important; while 
there isn't much semantic difference between (element content omitted 
for brevity)
     <name/><password/>
and
     <password/><name/>
Unless the specs are written very carefully, however, messages like
     <name><name><password/>
and
     <password/><name/><password/>
are legitimate and guaranteed source of interop problems (if not 
security holes); which name or password element is used -- the first or 
the last?

Of the existing implementations that don't conform to the non-normative 
schema, are they willing to change at some point?  If so, then working 
to make the XSD files normative seems reasonable.  If not, then perhaps 
rev'ing the protocol (via a new namespace) and making the XSD files 
normative for the new namespace makes sense.  I expect most folks will 
not want to define a whole new namespace just to accomodate XSD. :)

A third option is to write normative schemas in Relax, and use its tools 
to generate XSD. For cases where XSD can't express what Relax can, 
annotate the schema with the constraints, ideally via XPath or similar
     <xsd:documentation>
       <jabber:vc>count(tns:name)==1)</jabber:vc>
       <jabber:vc>count(tns:password)==1</jabber:vc>
     <xsd:documentation>
     <xsd:choice maxOccurs="unbounded">
       ...
     </xsd:choice>
And then make *both* schema languages normative and use an errata (JEP 
update) to fix inconsistencies if/when they're found.

Hope this helps.
	/r$

-- 
Rich Salz, Chief Security Architect
DataPower Technology                           http://www.datapower.com
XS40 XML Security Gateway   http://www.datapower.com/products/xs40.html