Re: [ws-caf] Context - XML technical

[Kevin Conner <Kevin.Conner@arjuna.com>]

Hiya Tony.

Tony Fletcher wrote:
> 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.

I hope to cover this with a later email (not necessarily today) so will leave this for now, I'm not ignoring the issue.

> 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.

I agree and this is the situation we had prior to the recent change, the exception being the mechanics (the type was indicated within the type element and not the xsi:type attribute).

> 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.

This is correct.

> 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.

This is where we disagree and, coincidentally, the reason behind this change in the first place.

The SOAP 1.2 specification (http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#muprocessing) states that "A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics specified for the XML expanded name of the outer-most element information item of that header block".  There is no mention of type, only that the qualified name be recognised and that it can be processed (I'll come back to processing later).

The structure of the SOAP mustUnderstand fault (http://www.w3.org/TR/2003/REC-soap12-part1-20030624/#mufault) enforces this as the only information it can return in the associated NotUnderstood header is the qualified name of the header element.

If we use your interpretation and allow the type information of our header element to be specified using xsi:type then the following message would be possible.

 <ctx:context xsi:type="a:contextType" env:mustUnderstand="1">
   ...
 </ctx:context>
 <ctx:context xsi:type="b:contextType" env:mustUnderstand="1">
   ...
 </ctx:context>

If the receiver was only aware of one of the types, for example a:contextType, then a must understand fault would be generated.  This fault would have a code of env:MustUnderstand and would include a NotUnderstood header specifying the qualified name of the header.

 <env:NotUnderstood qname="ctx:context"/>

The sender, upon receiving this reply, will not be able to tell which header was not understood.  In fact the sender will be unable to tell whether it is the type of the header that is at fault or that the receiver does not understand ctx:context (regardless of type).

The soap:mustUnderstand attribute is a simple mechanism, its sole purpose is to mandate the processing of a header.  How the header is processed, whether it generates a fault or not, is defined in the semantics associated with the header's qualified name.

Receiving a MustUnderstand fault informs the sender that the receiver does not recognise the element name and is therefore unable to process it.  If the receiver recognises the element name, and the processing fails, then a fault defined by the semantics of the header will be raised.

The other issue you raised was the processing of headers that include extendable elements (Any) from another namespace, stating that the mustUnderstand attribute  must apply to the 'complete structure' otherwise it is not possible to use these elements.  If an header element is extendable then the semantics of that header element must specify how these extensions are to be processed.  Part of this specification will include what happens should the extension be unrecognised.

The following example shows a header which has an extension mechanism supported by the base type element.
 <a:header env:mustUnderstand="1">
   ...
   <a:type>http://aaa.bbb.ccc/ddd/eee/fff</a:type>
   ...
   <ext:el1>
     ...
   </ext:el1>
   <ext:el2>
     ...
   </ext:el2>
 </a:header>

The mustUnderstand attribute therefore asks the receiver if it understands the semantics of the header represented by the qualified name a:header.  The receiver, recognising the name, begins to process it by examining the type element.  It discovers that the type is unknown to it and therefore returns a fault to the sender.  The fault in this case is not a MustUnderstand fault but is a:InvalidType, a fault which is specific to the processing of a:header.

If the processor were to recognise the type and perform the type specific processing it may discover that there was another reason for failure.  It may be that the extension allows the specification of an addressing mechanism and the receiver doesn't recognise it.  In this case it could generate another fault, e.g. ext:UnknownAddressingMechanism.

In both these cases the sender knows that the receiver understands the semantics implied by the a:header element but that it is not aware of the specific type (or addressing mechanism) being requested.  The sender could therefore choose to resend the request using a different type/addressing mechanism if appropriate.

    Kev

-- 
Kevin Conner
Arjuna Technologies Ltd.