OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] XRD element order


one other (small and perhaps insignificant) reason to enforce element  
order is readability.  Especially during debugging and early adoption,  
humans will often parse the XML, and as such, preserving a consistent  
order helps identify omissions and other bugs.

most of the other XML specs i've worked on in recent history have  
actually argued opposite your direction, meaning that since DOM  
parsers do not care, and humans and SAX parses do care about ordering  
(programmers will to, as they implement handlers for the XML), that  
the XSD should require an order...

my .02

=peterd

On Jun 22, 2009, at 6:43 PM, Will Norris wrote:

> 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

Peter Davis: NeuStar, Inc.
Director & Distinguished Member of the Technical Staff
45980 Center Oak Plaza Sterling, VA 20166
[T] +1 571 434 5516 [E] peter.davis@neustar.biz [W] http://www.neustar.biz/ 
  [X] xri://@neustar*pdavis [X] xri://=peterd
The information contained in this e-mail message is intended only for  
the use of the recipient(s) named above and may contain confidential  
and/or privileged information. If you are not the intended recipient  
you have received this e-mail message in error and any review,  
dissemination, distribution, or copying of this message is strictly  
prohibited. If you have received this communication in error, please  
notify us immediately and delete the original message.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]