Re: [xri] XRD element order

[Markus Sabadello <markus.sabadello@xdi.org>]

+1 on everything (i.e. no required element order and <Expire> should remain an element)

- 99% of the XRDs you get are NOT expired, so being able to check that early doesn't normally buy you much.

- Expired XRDs are just one of several error conditions an XRD processor needs to check, so most of the time it will want to read the entire XRD anyway.

- A typical client application will only want a small piece of information out of an XRD, not keep the whole XRD around for a long time. So whatever resources the "XRD processing step" on your platform needs, it needs them only temporarily for a very short time.

- If I were to write an XRD processor on the iPhone (yes that is SAX based), then yes I agree that theoretically having <Rel>s and <Type>s first CAN help you optimize your XRD processor a bit (i.e. when the SAX parser hands you an extension element, you can throw it away immediately instead of keeping it around, because you already know that you don't want the current <Link>). Maybe one idea would be to not REQUIRE anything, but to RECOMMEND that <Link>s with a lot of extension elements SHOULD place their <Rel>s and <Type>s first to make resource-conscious parsers happy?

Markus

On Thu, Jun 25, 2009 at 10:42 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

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


---------------------------------------------------------------------
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