[standards-jig] software version
jabber.org at ralphm.ik.nu
Mon Jul 28 09:11:01 UTC 2003
On Sun, Jul 27, 2003 at 06:14:40PM -0600, Jeremy Nickurak wrote:
> On Sun, 2003-07-27 at 13:57, Julian K. Missig wrote:
> > Except this is not a traditional network protocol. This is XML. Any
> > Jabber client must be able to properly parse XML--which means that
> > additional elements will hurt no one. If a Jabber client doesn't
> > properly parse XML, it's not a proper Jabber client. That's *by
> > design*, not just some mishap.
> We're talking about entirely different levels of "parse" here.
> The fact that we're using XML as the basis for the protocol means that
> any client will be able to parse the fundamental infrastructure of the
> streams, that is, the syntax. The semantics (the specific rules of
> relationships between different tags) meanwhile, are just as important.
> That's what the namespace is *for*.
> The namespace serves as a *unique identifier* for what rules and
> relationships govern the stream's organized XML. If those rules change
> (with the addition of new non-fully-namespaced tags, for example), then
> it is really no longer in that namespace, since the new set of rules is
> fundamentally backwards-incompatible (and potentialy vice-versa with the
> older data potentially not making sense or meaning the same thing).
A namespace is for grouping elements and attributes that belong together.
Adding a new element, while not changing the others, in general doesn't
break backwards compatibility at all.
If you change something to the namespace so that semantics change in a
fundamental way or documents that used to conform are now illegal, /that/
would be a reason to use another namespace.
As was said in this thread, be liberal in what you receive, conservative
in what you send. I agree totally. But I actually *do* expect other developers
to do that too. This is XML. Version 1.0 didn't even have namespaces!!
> That's why, as a general rule of thumb, many XML developers make their
> namespace definition a URL that points at the dtd/xml-schema for their
> semantics. It's an instant, free method of defining what's the data in
> question really means.
> It also means that, based on that unique identifier, and the probability
> that it will point at a dtd/schema, validation will always work
> consistently. (You can't change the version without changing the
> schema/dtd, and that means pointing at a new URL, which means a new
The jury is not out on this and there has been a lot of discussion. See
for example this document:
Although it proposes using namespaces for versioning, it also mentions some
of the drawbacks and what you could do about them.
More information about the Standards