Re: [xri] XRD element order

[Will Norris <will@willnorris.com>]

I generally subscribe to Postel's Law of "being conservative in what  
you send, and liberal in what you receive".  The only way to be  
liberal in what we receive, is to be liberal in what the schema  
allows.  Different people think about the information in an XRD in  
different ways, placing more or less importance on different  
elements.  Consequently, people are naturally going to publish  
documents with elements ordered in a way that makes sense to them.   
Now, one option is to say that they're wrong, and that they must  
follow the prescribed element order.  But what's the real benefit?   
Regarding the benefit to SAX parsers, see my note below.  But aside  
from that, there really is no benefit in being strict here, yet  
carries a fair potential for deployment problems.


## SAX Parsers

As I mentioned earlier, there are some optimizations that can be made  
for SAX parsers with regards to extended elements.  Because of the XRD  
extensibility model, there could be an infinite number of extension  
elements added to the document.  If a SAX parser is able to get the  
<Rel /> and <Type /> values early enough, then the parser should be  
able to know which extension elements are of interest, and skip over  
the rest.  The only requirement for this to be possible is that <Rel / 
 > and <Type /> appear before any extension elements.  With regard to  
extension attributes, there's only so much optimization you can really  
do... it's likely that the parser will have to parse all attributes  
regardless.

So one compromise would be to specify that elements in the XRD  
namespace can appear in any order, but that they must appear before  
any elements in other namespaces.  This is really straightforward to  
do in the schema.  I still question how much optimization we need to  
worry about even with this though.  Theoretically yes, an XRD could  
have a ridiculous number of additional elements from other namespaces  
that could choke a SAX parser.  But really, do we think this is going  
to be a real problem?  How large of a document can even the most  
constrained SAX parsers handle?  Several KB easily, if not several  
MB.  And how much good will the above optimizations actually do?  I  
suspect that most parsers will just parse all elements regardless.

I think its worth noting that SAML, as an example, provides a pretty  
healthy amount of flexibility with regards to element order in cases  
where order really doesn't matter.

With XML DSig, I fought pretty hard for it, despite the real world  
deployment challenges we're certainly going to face, because using  
DSig brought real value.  With element ordering though, I don't know  
that there is enough value to justify the deployment challenges it's  
likely to create.  (And of course, this entire discussion is moot if  
XRD libraries don't actually enforce whatever schema we have)

-will


On Jun 24, 2009, at 11:48 AM, <njones@ouno.com> <njones@ouno.com> wrote:

> 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