[Standards] About stream namespaces
elmex at x-paste.de
Fri Mar 16 18:22:38 UTC 2007
On Fri, Mar 16, 2007 at 10:58:59AM -0700, Rachel Blackman wrote:
> >>>Enforcing this kind of backward compatibility for new client
> >>>implementations does not make much sense for me. It would make more
> >>>sense if servers would would be told that they MAY not generate
> >>>such prefixes to take care of old clients.
> >>>At least with that SHOULD NOT in place this issue will never be
> >>>resolved because server implementors might say: "Well, RFC says you
> >>>SHOULD NOT do that. I won't fix it.". And client developers will
> >>>have to obey :-)
> >>One of our rules in writing the RFCs was not to break things since we
> >>already had such a large installed base at that time. Sorry.
> >Does this mean that these issues will never be resolved, because there
> >are already so many people who do it wrong?
> If it is defined as 'right' in the specification, people are not
> doing it 'wrong' to do it that way.
> But the argument I hear is that more liberal XML should be allowed
> through because it's 'easier' for people. But keep in mind, not
> everyone out there had the option of embedding a huge full XML/DOM/
> XSLT/whatever-else library for XMPP.
Sorry for being blunt:
If XML is too hard, then don't use it. ;-)
> supporting looking for things via 'xmlns:caps' or 'xmlns:event' or
> 'xmlns:status' or whatever else is rather more difficult.
> Now, I personally already added support for that because we already
> have some clients which do send things like that in the stream, so
> whatever happens, I'll cope. But since all I had for the
> circumstances in Astra was a really scaled-down EXPAT variant, it was
> a huge headache for me and required making my XMPP stream parser
> about four times more complicated than it would otherwise be. I'm
> reasonably sure the same is true for folks on at least some mobile
> devices, who may have fairly scaled-down XML parsers as well.
Right, for those there is section '11. XML Usage within XMPP' in
> Just as a data point that, no, changing the protocol to your method,
> to allow/want qualified elements and xmlns everywhere does not make
> implementation universally easier. :)
Right, it just makes the spec and the fixed implementations correct.
And if XML is too slow for this kind problem, then maybe it's not the right
If the stuff that is called 'XML Namespaces' in the RFCs is actually not
supposed to be 'XML Namespaces' then maybe it should be made _very_
clear that those are not 'XML Namespaces'. And that regular and
completly valid usage of XML Namespaces is not supported in the stuff
that XMPP calls "XML".
More information about the Standards