Lists Home |
Date Index |
- From: Henrik Frystyk Nielsen <email@example.com>
- To: "Bullard, Claude L (Len)" <firstname.lastname@example.org>, email@example.com
- Date: Tue, 29 Aug 2000 12:11:04 -0700
Traditionally major version numbers mean breaking changes while minor
version numbers mean backwards compatible changes. Apart from that,
version numbers are random in a decentralized environment.
The reason behind the SOAP "versioning model" is that we believe the
extensibility model built into SOAP is more flexible than having a random
version number which in particular has known problems in a multihop
message path model (seen in HTTP).
In other words, in SOAP, a party declares the features that is either a)
required or b) optional in the message and the receiving end can either
take it or leave it. This mechanism can of course also be used to
negotiate (via some "upgrade" mechanism) jumping to another envelope
namespace entirely which covers adding breaking features to the SOAP
We do therefore not need to have any other versioning model than: "look in
> 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.