Lists Home |
Date Index |
- From: Michael Rossi <email@example.com>
- To: "'Bullard, Claude L (Len)'" <firstname.lastname@example.org>, email@example.com
- Date: Mon, 28 Aug 2000 11:28:49 -0400
Bullard, Claude L (Len) wrote:
> I need a bit of advice. It is suggested in a document
> that I am reading that the namespace be used for versioning.
> If in SOAP, for example, "the <envelope> element has a different
> amespace, you have to discard the message with a version
> error. As SOAP evolves, you'll probably be able to
> use different namespaces to indicate certain levels of
> specification conformance or message dialects." - VBPJ August 2000.
> Is this the understanding others have of the use of
> namespaces for versioning? I ask because a local
> is requesting a version attribute and I can't think
> of why not other than the namespace is then a
> continuum of definitions instead of a single, say, schema.
I noticed this in SOAP as well while reviewing it recently. I needed
to give the issue some quick thought while preparing a draft of a spec going
into its next release. Now, in this case we've already got a version
attribute (and a namespace). For compatability I have to keep the version
attribute, but the question arose as to what to do with the namespace.
I'd never claim to have a clear understanding of issues regarding
namespaces (would anyone?). But it strikes me that there are two ways of
interpreting a 'namespace'. One way is that this space is universally
defined somewhere and an application can go and reference things in it.
Another way is that this space is locally instantiated based on its
definition (in a schema or DTD) during processing, and it goes away when
this processing completes.
Given that the namespace spec only ever intended to "identify",
rather than "locate", I choose the latter interpretation. And based on this
interpretation, it seems to me that my namespace can remain constant across
versions of my spec (as a single instance can't contain more than one
version of it).
Michael A. Rossi
Computer Sciences Corporation