[standards-jig] software version

Jeremy Nickurak atrus at rifetech.com
Mon Jul 28 22:28:26 UTC 2003


On Mon, 2003-07-28 at 03:11, Ralph Meijer wrote:
> 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.

Who decides what change constitutes a "fundamental" change?

You never know what kinds of implementations are going to be based
around an old protocol. The addition of a new element definately can
break that xml's ability to be parsed by older software.

Consider a hypothetical jabber client that, for purposes of (admitidly
short-sighted) optimization, sorts incoming packets into groups based on
the unique keys 'p' 'm' and 'i', derived from the first character of the
packet's root tag, "message", "iq" or "presence". The introduction of
another tag, say, "peer2peer", would throw these older implementations
for a loop.

Is it a slightly contrived example? Sure. All i'm saying is that
limiting yourself to only adding new elements *does not* save you from
breaking older implementations.

> The jury is not out on this and there has been a lot of discussion. See
> for example this document:
> http://www-106.ibm.com/developerworks/xml/library/x-tipnamsp.html.

I'll have to read through this later, as i'm getting late for work.
Thanks for the pointer.

-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030728/26d00235/attachment.sig>


More information about the Standards mailing list