RE: [ws-caf] Context - XML technical

["Tony Fletcher" <tony_fletcher@btopenworld.com>]

Dear Kevin,

My general principle is that if you can make it work and keep everyone happy
then generally I am happy for that solution to be adopted - though there are
caveats I should add to that statement and there are certainly times when
doing one thing properly is better than try to meet conflicting requirements
(and then there is compromise imposed for political reasons!)

Although it can make the instance document look a bit cumbersome (though I
suspect actually it has just moved the cumbersomeness - the namespace
declarations mainly - from one place to another) I would still like to
explore further the solution to the context element problem of making the
element 'concrete' (i.e. not abstract) but marking the type as abstract in
the context schema.

1) According to XMLSpy the current Context schema which has the context
element marked as abstract 'breaks the current WSDL description which shows
which context messages have a context structure as a header as the reference
chain leads from the WSDL back to the context element, which is abstract,
and the Context does not provide any substitution group members for that
abstract element.  Therefore I think we have to fix either the schema or the
WSDL description for context (or possibly both).  I am not sure if it should
but making the context element not abstract and the contextType abstract
seems to keep XMLSpy happy.

2) As I said on the call this approach means that you can tell this header
is a context from the element name (context) and its namespace prefix (which
is linked to the namespace URI for Context), and if that is all a system
needs to know, it need go no further.  Analysing the attributes of that
element yield immediately the actual type with its namespace prefix (which
is linked to the namespace URI for the referencing specification that
determined the details of the context structure.  Again if that is all a
system needs to know, it need go no further.

3)  My reading of the SOAP specifications indicates that the SOAP envelope
global mustUnderstand attribute is not a problem.  It can only be added to a
SOAP Header, that is an immediate child element of the SOAP envelope
element.  It can be optionally added to each such header element, so if you
have several context headers in a SOAP message, each has its own
mustUnderstand attribute (or it is absent which is the same as setting it to
'false').  Thus there is no confusion or problem there that I can see.  The
SOAP 1.2 primer and spec makes it clear that this attribute applies to the
whole header block.  That is, if it set to true the system must trawl
through the whole structure and make sure it understands everything in that
header including any embedded changes of namespace before it decides whether
it can process it or needs to raise a fault.  Although the SOAP 1.1 W3C Note
does talk about the structure as identified by the Qname of the element it
clearly needs to mean 'and hence the complete structure' otherwise not only
is this case of structure (the type) having a different namespace from the
element ruled out but also any structure that included an Any in its schema
such that an instance document can switch namespace at that point and
include a structure from a different namespace schema.  Thus according to
your very strict reading of the SOAP 1.1 spec even if both the context
element and contextType were made 'not abstract' then we would still fall
foul of SOAP1.1 as we have an Any embedded in the context structure.

Thus it seems to me that this approach meets Kevin's requirements / request,
but also really does not add anything that is not required anyway and gives
systems the option as to how much of the context header they attempt to
interpret (unless mustUnderstand is set to true and the system is the target
system, in which case it has to make sure it can process the complete
header, head to toe).

Best Regards     Tony
A M Fletcher
Tel: +44 (0) 1473 729537   Mobile: +44 (0) 7801 948219
 tony.fletcher@choreology.com    amfletcher@iee.org       (also
tony_fletcher@btopenworld.com)
 


-----Original Message-----
From: Kevin Conner [mailto:Kevin.Conner@arjuna.com] 
Sent: 20 June 2005 13:20
To: WS-CAF
Subject: Re: [ws-caf] Context - XML technical


I can think of two solutions to this issue.  Assuming it is agreed that I
have made a case for it :-), these are: -

 - use a standard name for a context, i.e. revert to wsctx:context and
reinstate the wsctx:type element.
 - add a compulsary attribute to the context type identifying appropriate
headers as a context.

The first solution would break the soap:mustUnderstand/context type
requirement whereas the second would not.

	Kev

-- 
Kevin Conner
Arjuna Technologies Ltd.