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

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Jim,

> > "tie together operations" - I think you mean you want an
> > identifier to propagated on each operation. Ok, you can do 
> > that in a header. The far-end won't understand it any more or 
> > any less for being in a WS-Context with your context-type URI 
> > or your header namespace.
> 
> Actually it will. The far end will probably refuse to "sign 
> off" on elements in the namespace http://jim.webber.name but 
> they are much more likely to sign off on something from a 
> proper standard's namespace.

What ?  You mean the receiving soap implementation's insists that the
namespace
of any header is defined in a standard ?  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 ?

That seems to be a perverse understanding of what SOAP headers let you
do.
Of course, if the received wisdom of the SOAP world is that headers
can't be
used for application-specific purposes, then the application-specific
requirement
will indeed have to be readdressed by exactly the same mechanism nested
within it.

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!

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.

This seems to be the "WS-Context-by-value is a crutch for broken SOAP
implementations"
argument again.

Peter