Re: mustUnderstand reformulation

The WG agreed a couple of weeks ago that we would adopt Martin Gudgin's 
Infoset based rewrite [1] so I think it would be better if the proposed 
text were based on that rather that the WD and also adopted the same 
terminology, e.g. "attribute information item" instead of "attribute". 
In particular I would like to include some form of the following text in 
the new section 4.2.3:

"The mustUnderstand Attribute Information Item has the following Infoset 
properties:

      - A local name of mustUnderstand
      - A namespace name of http://www.w3.org/2001/06/soap-envelope
      - A specified property with a value of true.

The type of the Attribute Information Item is boolean in the namespace
http://www.w3.org/2001/XMLSchema. The default value is false."

I think the above means that we can lose the following sentence since 
this is implicit in the third bullet:

"This attribute MUST appear in the SOAP message itself in order to be 
effective; default values which may be specified in an XML Schema or 
other description language do not affect SOAP processing. (see section 3 
and 4.2.1)."

We might choose to combine something like the above with the text 
suggested in Chris's rewrite [2] (last paragraph in Section 3) to call 
out the significance of the specified property having a value of true. 
This would be better done in one place (Section 3 ?) that repeated for 
each of the global attributes IMO.

Regards,
Marc.

[1] http://www.w3.org/2000/xp/Group/1/06/01/soap-02-infoset.html
[2] Can't get a link becuase W3C list server is down, but "proposed 
wording to address attributes", Chris Ferris, 1 Aug 2001 sent to 
xml-dist-app@w3.org

Noah_Mendelsohn@lotus.com wrote:
> Glen Daniels and I were asked to propose a reformulation for
> "mustUnderstand".  What follows is a first cut for review and discussion by
> the workgroup.  The reformulation also attempts to remove overlap between
> section 4.2.3 and the processing model stuff.  We did this in parallel with
> Mark Hadley's work on eliminating overlap, so we probably unintentionally
> duplicated some of his effort.  Presumably, the two approaches can easily
> be reconciled if the workgroup believes that our overall direction is
> correct.
> 
> Also, in preparing this note, I noticed a potential issue which perhaps
> should be added to our list for tracking: not just in these sections, but
> in the specification overall, have we made the changes necessary to allow
> for Boolean attributes such as mustUnderstand to take the value of "true"
> as well as "1"?  I did not make that change below.
> 
> Thank you.
> 
> Section 4.2.3 (original:  unmodified from SOAP 1.2 July WD)
> -----------------------------------------------------------
> 
> [EdNote: This section partially overlaps with section 2. We expect this to
> be reconciled in a future revision of the specification.]
> 
> The SOAP mustUnderstand global attribute can be used to indicate whether
> the processing of a SOAP header block is mandatory or optional at the
> target SOAP node. The target SOAP node itself is defined by the SOAP actor
> attribute (see section 4.2.2). The value of the SOAP mustUnderstand
> attribute is either "1" or "0". The absence of this attribute is
> semantically equivalent to its presence with the value "0", which means
> processing the block is optional.
> 
> When a SOAP header block is tagged with a SOAP mustUnderstand attribute
> with a value of "1", the targeted SOAP node MUST: either process the SOAP
> block according to the semantics conveyed by the fully qualified name of
> the outer-most element of that block; or not process the SOAP message at
> all, and fail (see section 4.4).
> 
> The SOAP mustUnderstand attribute allows for robust evolution. Elements
> tagged with the SOAP mustUnderstand attribute with a value of "1" MUST be
> presumed to somehow modify the semantics of their parent or peer elements.
> Tagging elements in this manner assures that this change in semantics will
> not be silently (and, presumably, erroneously) ignored by those who may not
> fully understand it.
> 
> This attribute MUST appear in the SOAP message itself in order to be
> effective, and not in an eventual corresponding XML Schema (see section 3
> and 4.2.1).
> 
> Section 4.2.3 (proposed revision: removes overlap, deals with mustHappen)
> -------------------------------------------------------------------------
> 
> The SOAP mustUnderstand attribute allows for robust evolution of SOAP
> itself, of related services such as security mechanisms, and of
> applications using SOAP. Elements tagged with the SOAP mustUnderstand
> attribute with a value of "1" MUST be presumed to somehow modify the
> semantics of their parent or peer elements. Tagging elements in this manner
> assures that this change in semantics will not be silently (and,
> presumably, erroneously) ignored by those who may not fully understand it.
> Specific rules for processing header entries with mustUnderstand attributes
> are provided in sections 2.4 and 2.5 <<these should be links>>)  This
> attribute MUST appear in the SOAP message itself in order to be effective;
> default values which may be specified in an XML Schema or other description
> language do not affect SOAP processing. (see section 3 and 4.2.1).
> 
> The SOAP mustUnderstand attribute is useful for detecting situations in
> which required software is not available at a node which has been correctly
> targeted; it is not intended as a mechanism for detecting errors in
> routing, misidentification of nodes, failure of a node to serve in its
> intended role(s), etc.  any of which may result in a failure to even
> attempt processing of a given header entry.  For that reason reason, this
> specification does not by default provide for any fault to be generated
> based on the presence or value of the mustUnderstand attribute in a header
> not targeted to the processing node.   In general, processors SHOULD NOT
> generate such faults, and this specification includes no standard
> representation for such a fault.    This rule applies to the endpoint as
> well as to intermediaries;  it is not in general an error for a
> mustUnderstand header entry targeted to a node other than the endpoint to
> reach the endpoint without having been processed.
> 
> Note, however, that SOAP extensions can be defined for indicating the order
> in which processing is to occur, and for generating faults when a header
> entry is not processed in the appropriate order.  Specifically, it is
> possible to create SOAP header entries which are themselves targeted to the
> endpoint (or intermediaries) and labeled mustUnderstand="1", and which have
> as their semantic a requirement to generate some particular fault if other
> headers have  inadvertently survived past the intended point in the message
> path message (presumably due to a failure to reach the intended processing
> node earlier in the path).  Such extensions MAY depend on the presence or
> value of the mustUnderstand attribute in the surviving headers when
> determining whether an error has occurred.  In the absence of such explicit
> extensions, SOAP processors SHOULD NOT generate faults based on the
> presence or value of the mustUnderstand attribute in a header not targeted
> to the processing node.
> 
> Noah Mendelsohn &
> Glen Daniels
> 
> 
>

--
Marc Hadley <marc.hadley@sun.com>
Tel: +44 1252 423740
Int: x23740

Received on Thursday, 9 August 2001 07:45:37 UTC