[Standards-JIG] Re: JEP-0091: Delayed Delivery
Tony Yat-Tung Cheung
tony.cheung at asiayeah.com
Tue Feb 21 14:45:45 UTC 2006
Thanks all for clearing up. So the conclusion is all XML attributes'
order do not matter, including the xmlns attribute.
It's true that most DOM/SAX parsers only process the start/end element
when all its attributes are received. For my proprietary implements, my
parser actually parses and processes an attribute as soon as it arrives.
My design philosophy is a fully streaming parsing, and is tailor made
for running on a mobile device (which has limited memory for buffering
and slower network connections).
In this example, it doesn't hurt to buffer up the attributes, since
there are only two of them. But in cases where there are lots of
attributes, the ordering may improve efficiencies. Because some of the
attributes could be ignored (without buffering) and it could be possible
to process an attribute as soon as it arrives. Since XMPP is designed to
be fully streaming, it may makes sense to suggest to have the xmlns
Actually I think it should be better to put the timestamp in a separate
xml element, not as an attibute here. But since this JEP is historical,
I don't think we are going to make any change here.
On Feb 19, 2006, Joe Hildebrand wrote:
> There is no requirement for XMPP XML to be in canonical form that I
> know of.
> As well, http://www.w3.org/TR/REC-xml/#sec-starttags says:
> "Note that the order of attribute specifications in a start-tag or
> empty-element tag is not significant."
> RFC 3920 calls out http://www.w3.org/TR/REC-xml-names/, not http://
> www.w3.org/TR/xml-names11/. At http://www.w3.org/TR/REC-xml-names/
> #ns-decl we see this:
> "A namespace is declared using a family of reserved attributes. Such
> an attribute's name must either be xmlns or have xmlns: as a prefix.
> These attributes, like any other XML attributes..."
> Therefore, xmlns= and xmlns:foo= are just attributes, and attribute
> order is not significant.
> In particular, many DOM implementations do not surface the order that
> attributes came in.
> In practice, almost ALL XMPP processors that I've run into don't care
> about the order that their attributes are serialized, so you're going
> to get them out of order no matter what you think is correct. :)
> Conclusion: you must parse the entire start-tag or empty-element
> before you know what namespace it, or any of it's attributes are in.
> Corollary: stpeter, if you want to reorder attributes in examples to
> make them easier to read, cool, but there's no need, it's just busy-
> On Feb 18, 2006, at 9:25 AM, Ian Paterson wrote:
> >>>/ Is it a requirement that xmlns must be the 1st attribute
> />>>/ following the <x> element?
> />>/ Next we look at "Canonical XML":
> />/ [snip]
> />>/ Therefore Tony is right and the xmlns "attribute"
> />>/ (in fact it is a "reserved attribute", in Xpath
> />>/ called a "namespace node") does belong first.
> />>/ I'll have to go through the existing JEPs to
> />>/ clean that up.
> />/ Is this necessary? (I thought there was no requirement for XMPP XML to
> />/ be in Canonical form.)
> />/ - Ian
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards