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.
--
ralphm
