On Dec 9, 2011, at 03:55, Ralph Meijer wrote: > On 2011-08-12 11:33 , Mike Wacker wrote: > > [..] > > >> So the main takeaway, if I understand this correctly, would be that if >> even the schema implies an order, I shouldn't assume any particular >> order unless the RFC or XEP explicitly calls it out. > > Yeah, that sounds right. Expecting stuff in a particular order makes > processing unreasonably more difficult, especially since there is the > expectation that you can ignore everything you don't understand. > >> As another example, for RFC 6120, the client namespace in A.5 implies >> that while the "normal" content (<show>, <status>, and <priority>) can >> come in any order for presence stanzas, all extended content must come >> after all "normal" content. But unless RFC 6120 specifically calls out >> that ordering constraint (and it doesn't as far as I can tell), the >> server should be able to handle, for example: >> >> <show>xa</show><c >> xmlns='http://jabber.org/protocol/caps'...><status>Vacation!</status> > > Indeed, those elements could be in any order. > > From the top of my head, the only specification that I know to rely on a > specific order is Publish Subscribe (XEP-0060), for the create/configure and > subscribe/options combination. This is written out explicitly in the prose. I > didn't enjoy implementing that in Wokkel. In retrospect it would have been so > much easier to have those data forms be a child element of the create and > subscribe elements respectively.
I think XEP-0004 also says something about the order of elements (as in, maintain the order of <field/>s and <item/>s as they were received). I'd like to point out that all of our XML Schemas are non-normative. They're provided for informational use, and ought not be considered the absolute record of authority. - m&m <http://goo.gl/LK55L>
smime.p7s
Description: S/MIME cryptographic signature
