I'm currently implementing XMPP core (client and server) in Python. It's meant to be a fun/educational thing. But also, as there aren't many compliant XMPP stacks out there, and there seems to be inertia within the Jabber community in getting momentum around a compliant stack, I want to make sure an open and plug extensible reference implementation is available. XMPP is a fascinating technology. Within, a rant about design decisions that are taking the fun out of things for the moment. Slump This is from the XMPP Core draft (draft-ietf-xmpp-core-24), section entitled XML Usage within XMPP: A default namespace declaration is REQUIRED and is used in all XML streams in order to define the allowable first-level children of the root stream element. This namespace declaration MUST be the same for the initial stream and the response stream so that both streams are qualified consistently. The default namespace declaration applies to the stream and all stanzas sent within a stream (unless explicitly qualified by another namespace, or by the prefix of the streams namespace or the dialback namespace). - 11.2.2 Default Namespace "A default namespace declaration is REQUIRED". Wow. I've never seen that before. It goes on to say: An implementation MUST NOT generate namespace prefixes for elements in the default namespace if the default namespace is 'jabber:client' or 'jabber:server'. An implementation SHOULD NOT generate namespace prefixes for elements qualified by content (as opposed to stream) namespaces other than 'jabber:client' and 'jabber:server'. - 11.2.2 Default Namespace So here's what I think the problem is. Any XML content going into an XMPP stream/stanza that is not namespace qualified will inherit either the jabber:client or jabber:server namespaces. That's exactly how default namespaces are expected to work. When the content is lifted out it will have to be pulled out of those namespaces, otherwise the markup will be trashed by merely having passed through the XMPP application layer. Most likely fixing up such content will require a design-conflicting hack to obliviate the default mechanism - off the shelf namespace aware tools will correctly preserve the namespace binding and leave the embedded markup borked. Granted what XMPP calls Stanzas and markup folks sometimes call fragments are coming in as discrete chunks and you could silently ignore the default namespaces, but as far as I can tell, you're supposed to treat the entire XML stream as a logical document so the normal rules appy (and it would be weird to spec the rules and then not apply the rules). There are layering problems here. Havign seen some costly weirdness in my time, frigging with namespaced markup is not something I think you want to be designing into Internet technologies. I'm surprised to see XML application envelope insisting on a default namespace on the document element. Choices I'm deeply conflicted on this. Entertaining non-compliance is a real option despite my design goals. Still, it's a just a draft and it may be possible to get this language turned around, assuming I can present a coherent argument and not a tirade - but my experience is that technical criticism or judgement on the merits of XML Namespaces is not wanted. It is much like the position of objecting to W3C Schema or WS or SOAP-RPC in the past - nobody wants to hear it - shut up, head down. I suspect the reason this hasn't come up as an issue yet is that as I said, compliant XMPP code is thin on the ground and XMPP doesn't seem to be used much yet to carry XML markup. And it in the past that Jabber code was fast and loose when it came to XML processing. Consider this outtake: The element names of the element and its and children MUST be qualified by the streams namespace prefix in all instances. An implementation SHOULD generate only the 'stream:' prefix for these elements, and for historical reasons MAY accept only the 'stream:' prefix. SHOULD in spec means "do it, unless you have a really good reason not to". I think the only reason you would specify the above is if you were worried about breaking legacy implementations that were doing dodgy things [My reason not to obey this would be it's broken to assign significance to namespace prefixes in this way. In some places it's acceptable to apply significance to a prefix (XPath comes to mind), but not here.] Maybe we'll get lucky and no non-namespaced markup will ever get sent over XMPP. Permathread Now, this has come up in Atom. There was a thread a while back with the premise, 'we need say something about xmlns="" for content', a thread I mostly instigated. So we talked about it and I got strong pushback on saying anything of the sort in the format spec - 'put in the in guide', 'implementation detail'', 'not core' - you get the idea. However, pushing Atom around using XMPP/Jabber is hot area at the moment and both technologies are receiving interest for application slightly outside their target domains (syndication and instant-messaging). A number of people think XMPP and Atom area good fit, myself included. But the jabber:client and jabber:server default namespaces by design ensure that XML content embedded within an XMPP stream will be polluted. Well behaved namespace aware tools will carry those two default namespaces through into the content after the markup has passed out of XMPP. There's nothing in either specification that would indicate a problem. As Tim Bray puts it - Broken As Designed. Who pays? The question then is: should Atom pick up the tab on this? Should XMPP? This is a great question, because it entertains any working group wiggle room to disavow responsibility for ensuring inteoperation and robustness between XML formats used at different layers. I'm not involved in specifying XMPP, but as a member of the Atom-WG I think Atom should do its utmost to enable its users' content to be robustly carried irrespective of the external packaging format. In terms of specification text, we are talking about a couple of sentences that do not impact on any other aspect of the format - in fact telling users they should shroud their content in xmlns="" before dropping it into an Atom feed doesn't impact on Atom at all. No wonder then people feel it's superfluous or unneccessary to specify this. And of course, if Atom was all the markup in the world, there is no point. You see, within the bounds of any given spec or layer, default namespaces are a non-problem; and this is perhaps why Atom folks are deeply reluctant to say anything. It's only as you try to get the various markups to play nice you get bitten, and you tend to get bitten with respect to an enclosing XML format. Usually this is an enveloping or packaging technology and usually this is happening very far away in time and space from any working groups. As such it's entirely contextual and by following a certain line of reasoning, the idea of adding such text to the Atom format spec was not accepted. It is precisely that ability to wiggle out of saying anything that lets you know default namespaces represent an architectural problem. Ziggurat We can explain the fundamental architectural issue using 3 pictures. The first one is what most technologists have in their heads when they are thinking about a stack or a layered architecture: The thing to remember here is that layering is an unquestionably good principle to hold; any interactions and couplings between layers are highly controlled or simply do not exist. Much of the problems in computing arise from not having sound first principles to base things on, but layering is about as close as it gets. This next one is what a stack or a layered architecture predicated on XML packaging looks like: The important point to remember here is that most technologists often have the first picture in their head even when they are dealing with this second structure. In itself, that's not a problem. When it comes to using default namespaces, this 3rd picture shows a line who's direction indicates the scope of a default namespace when applied to the outer layer: Now there is a problem. It should be clear that default namespaces trangress the layers. In turn this means they violate one of the few engineering principles we have in computing that could be considered a universal. Default namespaces offer no benefits that justify breaking with the layering principle. The rabbit's not like us. The default namespace is a bizarre construct. It's a like a macro and a lexical scope rule rolled up into one, but from an alternate universe. In modern protocol construction, it conspires to produce an architectural joke of the first order. As a result of the way a single XML document tree can operate at different application layers (picture 2 above), having a globally scoped namespace snatches defeat from the jaws of victory (picture 3). It's notable, but perhaps not widely realized, that with default namespaces in tow, XML Namespaces is a non-backwards compatible upgrade to XML. If there are only prefix namespaces, this entire problem evaporates. Everyone can play together up and down the stack as no enclosing envelope or XML packaging technology, one that you don't know about or perhaps one that hasn't even been invented yet, can come along and break your content (only versioning is allowed to break your data like this). As such, I have a problem accepting the use of default namespaces as a credible approach. The immediate solution is to wrap markup with an xmlns="" declaration before letting it loose on the world. If you don't you are commiting what might be termed a markup fallacy (in the Deutsch sense) - that the root element in front of you is always the root element. But it would help if we could get this bootstrapped into protocol and format specifications via non-invasive text, especially in formats such as Atom, SOAP and XMPP that are taking responsiblity for carrying arbitrary content. Ultimately however, the xmlns="" declaration is a hack - the proper solution is to deprecate and then eradicate the default namespace from acceptable XML usage. Finally, here's XMPP Core's rationale for using XML Namespaces: Namespaces are used within all XMPP-compliant XML to create strict boundaries of data ownership. The basic function of namespaces is to separate different vocabularies of XML elements that are structurally mixed together. Ensuring that XMPP-compliant XML is namespace-aware enables any allowable XML to be structurally mixed with any data element within XMPP. Rules for XML namespace names and prefixes are defined in the following subsections. - 11.2 XML Namespace Names and Prefixes "The basic function of namespaces is to separate different vocabularies of XML elements that are structurally mixed together". Well, jabber:client and jabber:server through their use of default namespaces subvert that rationale and ensure that that ownership can cross boundaries. I'm surprised this passes muster with the draft-hollenbeck recommendations on XML markup for use in IETF protocols tho' I haven't looked at it in a good while - if it does, that document is also in need of attention....
Previous Topic
