[standards-jig] XML Conformance

David Waite mass at akuma.org
Wed Jan 16 23:13:48 UTC 2002

----- Original Message -----
>From: "Julian Missig" <julian at jabber.org>
> First off, the id attribute: the id *MUST* start with an alphabetic
> character, but can contain numbers after that.
<snip definition>
> So therefore, ids may start with a letter, an underscore, or a colon,
> and then have all the numbers your pretty little heart desires. However,
> '2' is not a valid id.

I do not believe the 'id' attribute has been declared to be of type ID. If
it has, it is a mistake. See below.

> It is also important to remember that there are *two* XML documents
> being created, one going to the server, one coming from the server,
> which is why you can receive a packet with the same id as one you sent.

id stamps on packets are supposed to be unique per user, not unique
globally. So I can get two messages from two different users with an id
attribute value of JCOM_12, for instance. If 'id' is declared to be of type
ID, this is not valid.

> Second, namespaces. Contrary to what some people believe, Jabber's usage
> of namespaces conforms with the specification. <x> and <query> are
> actually a parent element of everything within in the same namespace.
> Schemas will conform with this statement. The "problem" is that current
> Jabber implementations do not fully support namespaces via Qualified
> Names. (Such as <last:query xmlns:last="jabber:iq:last"> and then being
> able to use last: thereafter) - However, there is NOTHING WRONG with
> Jabber being even more restrictive than the XML Namespaces
> Recommendation. I feel that we should continue to enforce the fact that
> jabber:x: and jabber:iq: namespaces within jabber:client are only
> allowed in certain places (<x> within <message> and <presence>, <query>
> within <iq> and so on). If the protocol remains strict here, Jabber
> implementations will not have as much to compensate for and can be much
> better optimized. It's also much easier to program when you expect
> namespaces to always use certain element names in certain places. Again
> I stress that this does not break the XML Namespaces Recommendation in
> any fashion, we are simply adding additional restrictions to Jabber.

There are already a few places where prefixed namespaces are used (first
which comes to mind is dialback, but also stream:stream) - in these cases
the prefix has to be identical to the prefix within the definition or else
no existing implementation can handle them. Is this more restrictive than
the XML-names spec, or does it conflict?

Another problem is that the interserver and intraserver protocols
(jabber:server and jabber:component:accept) include message, presence and iq
elements in their namespaces. This basically makes it so that you _cannot_
use namespaces appropriately for any component which bridges between these,
such as scm or ccm. For example, with CCM you will be sending users messages
which look like:
<message xmlns='jabber:component:accept' to='foo' from='bar'>...</message>

If the server component does not correct for this, the clients cannot even
support namespaces correctly.

-David Waite

More information about the Standards mailing list