[standards-jig] software version
atrus at jabber.spam.rifetech.com
Mon Jul 28 00:14:40 UTC 2003
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).
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
Jeremy Nickurak -= Email/Jabber: atrus at rifetech.com =-
"I do not know how World War III will be fought, but World War IV
will be fought with sticks and stones." -- Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Standards