XRD element order

[Will Norris <will@willnorris.com>]

I've been thinking and talking with folks a bit about the order of  
elements in XRD, and whether it makes sense to enforce a particular  
order.  There are only a few examples I can think of that it would  
matter.  Well, one really... that is a SAX parser.  I remember Markus  
mentioned at one point that the iPhone SDK (simply as an example)  
doesn't expose a DOM parser, only SAX.  When dealing with a SAX  
parser, there are a few optimizations you can make with regards to  
document order:

   - expose XRD expiration early on.  As soon as the parser can  
determine that the XRD is no longer valid, it can bail out

   - expose Type elements early on.  Different Type values may give  
the parser a hint at what additional extended elements in the <XRD />  
may be of interest.

   - expose Rel elements early on.  Like Type, different Rel values  
may give the parser a hint at what additional extended elements in the  
<Link /> may be of interest.

None of these matter with a DOM parser, because the entire document  
gets parsed regardless.


The downside of requiring element order:

   - What is the "right" order?  If we're going to enforce element  
order, we need to decide which makes the most sense.  Of course, that  
is entirely subject.

   - Since different people think about this data in different ways,  
they'll naturally tend to order the elements differently.  If XRD  
specifies a strict order of the elements, we're bound to have some  
implementations that respect that, and some that don't.  Some will be  
ultra strict, refusing to parse documents that aren't in order, and  
others won't care at all.  We're bound to see at least a moderate  
amount of confusion from the community wondering why they are getting  
parsing errors.


So the trade-off is a slight optimization for SAX parsers (which will  
likely be the minority) for a pretty decent potential for at least  
some amount of parsing confusion.  I propose a little of both:

   - since Expires is single-valued, move it to be an attribute of  
<XRD />.  This still allows SAX parsers to bail out on expired XRDs  
very early

   - remove the ordering requirement of all other elements, by  
wrapping them in a "choice".  This makes the schema a tiny bit more  
complicated, but not much.

Thoughts?

-will