Re: How to Version XML Applications

Norm Walsh writes:

>> Certainly other strategies exist and SOAP
>> must have one.

This note is only to clarify what SOAP 1.2 does and does not do, for those 
who may be interested.

If we're talking about header entries, SOAP names them with QNames, which 
means they're heavily based on namespaces.  There is no notion at all of 
one header being similar to another modulo some notion of "version". There 
are no version attributes or the like.  A header is sent with a QName, and 
the receiver either recognizes it, or knows that it does not.  What you do 
have is the 'mustUnderstand' tool which basically says:  "it is/isn't safe 
for you to proceed if you don't recognize and understand the spec for this 
qname?".   A trick you can do to have messages that work across versions 
is do have specifications that reference each other.  So you could do 
something like this:

*  write a spec for QName nsv1:n1 (I.e. making the obvious assumption that 
nsv1 maps to a namespace for the first version).  Maybe it tells you how 
to do some caching.

* when you want changed function, write a spec for v2 that says: "if 
nsv2:n1 appears by itself in a SOAP message, here is the interpretation; 
if nsv2:n1 appears in the same message as a header with nsv1:n1 (I.e. the 
original) then here is how it modifies the semantics of ht nsv1:n1 header. 
 Maybe this changed function provides finer control over the caching and 
partially overrides conventions in the V1 specification. 

So, you can use the headers separately and they work.  You can put them in 
a message together, potentially mark the nsv1:n1 header 
"mustUnderstand="true" if you like, but leave the nsv2:n1 header as 
mustUnderstand="false", which is the default.  If the message arrives at a 
node that understands the new version, it will do the right thing with the 
two headers (implementing the smarter caching rules, and not being 
confused that the V2 header partially changes the interpretation of the 
V1).  If it arrives at a node that only understands v1, it will correctly 
ignore the v2 header (because you said it was not mustUnderstand...if the 
v2 header is mustUnderstand, you probably don't need to send the v1 at 
all, but nothing prevents you from marking them both mU) and will do 
caching according to the V1 spec.

BTW:  there's no signficance to the fact that the local names of the two 
headers in this example are both n1, I chose that arbitrarily.  All header 
QNames are treated symmetrically and are viewed as opaque (though SOAP 
does predefine a few, such as those that represent SOAP faults.)

So, SOAP is really solving a problem primarily in a messaging environment. 
 It also has some conventions for how to respond if all of SOAP is the 
wrong version (SOAP 1.2 vs a future SOAP 1.3):  there's basically a trick 
that says "here's a response that all future versions of SOAP recognize, 
that will give you a hint for a version of SOAP that I do support if you 
want to try again."  This only works if you are willing to do more than 
one round trip and have a basically request/response environment. Versions 
of SOAP itself are identified by the expanded name of the root element, 
which in SOAP 1.2 is SoapEnv:Envelope, where SoapEnv is bound to the SOAP 
1.2 envelope namespace.

Hope this is useful background for the discussion.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Friday, 13 September 2002 17:01:05 UTC