Re: [xri] XRD element order

[<njones@ouno.com>]

I mostly agree with Peter on this:

I don't think that we would gain much by *explicitly* saying that node
order doesn't matter --when it actually does from an XML point of view,
even though we don't interact with it like it does. I do like the thought
of thinking through the node order from a SAX perspective though. As
mentioned that could help with parsing XRD documents on devices with
constrained memory requirements. 

+1 on the expires information move to an attribute.

Nika

On Tue, 23 Jun 2009 09:47:06 -0400, Peter Davis <peter.davis@neustar.biz>
wrote:
> 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.
> 
> 
> 
> ---------------------------------------------------------------------
> 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