RE: [ws-caf] Mt Everest and WS-CF

["Jim Webber" <Jim.Webber@newcastle.ac.uk>]

Peter:

> What ?  You mean the receiving soap implementation's insists 
> that the namespace of any header is defined in a standard ?  

I don't think I said that.

> This is the general purpose SOAP extensibility mechanism 
> right ? That has an attribute mustUnderstand that allows a 
> receiver to safely ignore things it doesn't understand 
> provided the sender is happy that it doesn't understand. Do 
> you mean the supported headers have to be set at compile time 
> from some constrained set ?

The point is, I want it to be understood and a standard helps that. Not
at the SOAP level where the mechanics of mustUnderstand help, but by the
_people_ building the service. I can get them to support a standard
(hey, they can reuse the work with their other partners) but I can't get
them to use my own ad-hoc structure.

> That seems to be a perverse understanding of what SOAP 
> headers let you do.

SOAP headers let me put elements into an infoset, according to a certain
structure. Any additional semantics are of your own making. 

> But in that case, why should WS-Context implementations be 
> any better ?
> You have a context type that is http://jim.webber.name/.... 
> That's not in a standard, don't' support it!

I want it to be supported. That's why I'm using a standard piece of XML
(the WS-Context context) in my infoset.

> Or do you mean it only wants to do schema validation on 
> things in standards.
> But the xsd:any inside the Context (I know you said you 
> didn't have one, but many uses will) surely deserves to be 
> validated. And it must be in a non-standard namespace.

The services will validate and use the aspects of the infoset that they
understand (which is the bit I am interested in). What they do with
other content is out of scope.
 
> This seems to be the "WS-Context-by-value is a crutch for 
> broken SOAP implementations"
> argument again.

I disagree.

Jim
--
http://jim.webber.name