RE: [xri] XRD element order

[Eran Hammer-Lahav <eran@hueniverse.com>]

I feel pretty strongly about this.

There should be no required element order and <Expire> should remain an element. We are dealing with such a simple schema that human readability isn't going to be an issue. I also want to make sure element order isn't going to break things because so far most people using XRD are not aware of any specific required order.

As for Expire, I think the proposed optimization doesn't gain much and at this point there should be a higher threshold for changing the schema.

EHL

> -----Original Message-----
> From: Will Norris [mailto:will@willnorris.com]
> Sent: Monday, June 22, 2009 3:44 PM
> To: OASIS XRI TC
> Subject: [xri] XRD element order
> 
> 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
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php