Re: New issue: Default values of SOAP header block attributes

+1 to both (friendly) amendments.

Jean-Jacques.


noah_mendelsohn@us.ibm.com wrote:

> I think this is very good overall.  Suggestion:  let's line this up with
> Mark's proposed rewrite of section 2 to introduce the "ultimateReceiver"
> attribute.
>
> ==============================
> <insteadOf>
> Omitting the SOAP actor attribute information item implicitly targets
> the SOAP header block at the ultimate SOAP receiver. An empty value for
> this attribute is equivalent to omitting the attribute completely, i.e.
> targeting the block at the ultimate SOAP recipient.
> </insteadOf>
>
> <suggestedAlternative>
> Omitting the SOAP role attribute information item is equivalent to
> supplying that attribute with a value of
> "http://www.w3.org/2001/12/soap-envelope/role/ultimatereceiver".
> An empty value for this attribute is equivalent to omitting the
> attribute completely, i.e. targeting the block at the ultimate
> SOAP recipient.
> </suggestedAlternative>
>
> If you prefer, this could be integrated in chapter 4, which would be
> symmetric with mU.  In this particular case, I think we should at least
> provide a mention in chapter 2, as targeting the endpoint with a missing
> role attribute will be a very common idiom.  Perhaps chapter would say:
> NOTE that section 4.x mandates a default value of i"http://www.w3.org/2001/12/soap-envelope/role/ultimatereceiver" if the role attribute is missing.
> ==============================
> I think the warning on schema validation can be interpreted as ruling out
> the need to validate even application level structures.  That presumably
> was not your intent.  Also, with the infoset formation, we shouldn't be
> saying what's serialized, as that's at the discretion of the binding.
> Indeed, if a binding wants to optimize out defaults on the wire, we can't
> see that, as long as it's recreated in the received infoset.  So, I've
> changed "serialized" to "transmitted".
>
> <insteadOf>
> A SOAP message MUST NOT impose any XML schema processing (assessment and
> validation) requirement on the part of any receiving SOAP node in order
> to correctly process a SOAP message according to the processing rules
> defined in section 2. Unless explicitly stated otherwise, SOAP REQUIRES
> that all information items that affect the SOAP processing model,
> whether specified in this specification or whether they belong to a
> foreign namespace be carried in the serialized SOAP envelope.
> </insteadOf>
>
> <suggestedAlternative>
> A SOAP message MUST NOT require any W3C XML schema processing
> (assessment or validation) in order to establish the values or
> correctness of element and attribute information items explicitly
> used in this specification.  These information items, which
> include mustUnderstand, role, the qualified names of header
> blocks, etc. must be carried explicitly in the transmitted SOAP
> envelope.
>
> Specifications for the processing of particular SOAP header
> blocks or body entries MAY but NEED NOT call for additional
> validation of the SOAP message in conjunction with application
> level processing.  In such cases, the choice of schema language
> and/or validation technology is at the discretion of the
> application. discretion of the application.
> </suggestedAlternative>
>
> Do these suggestions make sense?
>
> ------------------------------------------------------------------
> Noah Mendelsohn                              Voice: 1-617-693-4036
> IBM Corporation                                Fax: 1-617-693-8676
> One Rogers Street
> Cambridge, MA 02142
> ------------------------------------------------------------------
>
> "Henrik Frystyk Nielsen" <henrikn@microsoft.com>
> Sent by: xml-dist-app-request@w3.org
> 02/10/2002 06:21 PM
>
>
>         To:     <xml-dist-app@w3.org>
>         cc:
>         Subject:        New issue: Default values of SOAP header block attributes
>
> Last week I took an action item to describe the issue of dealing with
> default values for the SOAP envelope attributes "mustUnderstand" and
> "actor/role". This mail contains first a discussion of the issue and
> then proposes a resolution to be considered.
>
> Discussion
> ----------
>
> Section 4 defines the semantics of omitting both the actor/role
> attribute and the mustUnderstand attribute:
>
> 1) Section 4.2.2 says: "Omitting the SOAP actor attribute information
> item implicitly targets the SOAP header block at the ultimate SOAP
> receiver. An empty value for this attribute is equivalent to omitting
> the attribute completely, i.e. targeting the block at the ultimate SOAP
> recipient."
>
> 2) Section 4.2.3 says: "Omitting this attribute information item is
> defined as being semantically equivalent to including it with a value of
> "false"."
>
> However, neither of the statements above provides any guidance as
> whether the attributes should lexically appear in the SOAP message when
> they have their default values. Later in the section, we find the
> following statement:
>
> 3) Section 4.2.1 says: "SOAP header block attribute information items
> 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 3.1 XML Schema)."
>
> While it might seem that these statements are contradictory, the
> intention of the 3) is not to disallow omitting the SOAP header block
> attributes but to state that SOAP modules can not default their values.
> For example, a SOAP security module can not set the default mU value to
> true in the schema definition for the header blocks that it defines.
> Currently, the vast majority (if not all?) of existing SOAP
> implementations do not generate SOAP header block attributes with their
> default values.
>
> In addition,
>
> 4) Section 3.1 says: "A SOAP message MUST NOT impose any XML schema
> processing (assessment and validation) requirement on the part of any
> receiving SOAP node. Therefore, SOAP REQUIRES that all attribute
> information items, whether specified in this specification or whether
> they belong to a foreign namespace be caried in the serialized SOAP
> envelope."
>
> Section 3.1 seems to go too far in the requirement of not requiring
> schema processing. The only piece that we can possible talk about is
> that schema processing MUST NOT be required in order to correctly
> process a SOAP message according to the SOAP processing model in section
> 2. I don't think we have anything to say about whether
> application-defined data relies on schema processing or not.
>
> Proposal Outline
> ----------------
>
> Whenever we have a choice in what can be generated by a sender and what
> must be accepted by a receiver, it seems useful to invoke the general
> Robustness Principle "Be liberal in what you accept, and conservative in
> what you send" [2][3].
>
> The proposal consists of three main parts and a minor part:
>
> A) Clarify the paragraph in section 4.2.1 to remove the apparent
> contradiction.
>
> B) Add a sentence to the two paragraphs mentioned the semantics of
> omitted SOAP header block attributes that indicated the guidelines for
> handling default attribute values.
>
> C) Clarify section 3.1 to say that it only applies to SOAP processing as
> defined by section 2.
>
> D) In addition, I would suggest that we add a paragraph in the
> introduction of part 1 (for example as part of section 3 explicitly
> calling out the Robustness Principle as a general principle for SOAP
> processors.
>
> Specific Text Modifications
> ---------------------------
>
> A. Modified section 4.2.1 paragraph (clarification):
>
> SOAP header block attribute information items whose value differs from
> their default value as defined in section 4.2.2 and 4.2.3 MUST appear in
> the SOAP message itself in order to be effective; any other value that
> does not appear directly in the SOAP message MUST NOT affect the SOAP
> processing as defined by section 2.
>
> B.1 Modified section 4.2.2 (added paragraph):
>
> Omitting the SOAP actor attribute information item implicitly targets
> the SOAP header block at the ultimate SOAP receiver. An empty value for
> this attribute is equivalent to omitting the attribute completely, i.e.
> targeting the block at the ultimate SOAP recipient.
>
> SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the
> SOAP actor attribute information item for SOAP header blocks targeted at
> the ultimate SOAP receiver (see section 3.2 Robustness Principle).
>
> B.2 Modified section 4.2.3 (added paragraph):
>
> Omitting this attribute information item is defined as being
> semantically equivalent to including it with a value of "false" or "0".
>
> SOAP senders SHOULD NOT generate, but SOAP receivers MUST accept the
> SOAP mustUnderstand attribute information item with a value of "false"
> or "0" (see section 3.2 Robustness Principle).
>
> C. Modified section 3.1 (clarification):
>
> A SOAP message MUST NOT impose any XML schema processing (assessment and
> validation) requirement on the part of any receiving SOAP node in order
> to correctly process a SOAP message according to the processing rules
> defined in section 2. Unless explicitly stated otherwise, SOAP REQUIRES
> that all information items that affect the SOAP processing model,
> whether specified in this specification or whether they belong to a
> foreign namespace be carried in the serialized SOAP envelope.
>
> D. Added subsection 3.2 about Robustness Principle
>
> 3.2 Robustness Principle
>
> The use of XML as the fundamental description framework leaves in many
> cases a great deal of flexibility for expressing semantically equivalent
> statements in a variety of different ways. In order to obtain robust and
> interoperable implementations it is essential that SOAP implementations
> take into account the Robustness Principle as expressed by [2][3]: "Be
> liberal in what you accept, and conservative in what you send".
>
> Throughout this specification, guidelines will be provided as to what
> constitutes "conservative". However, it is important that implementers
> realize that this often represents only a subset of the set of
> acceptable values.
>
> Comments?
>
> Henrik Frystyk Nielsen
> mailto:henrikn@microsoft.com
>
> [1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part1.html#N60D
> [2] http://rfc.net/rfc1123.html
> [3] http://rfc.net/rfc793.html

Received on Tuesday, 12 February 2002 05:44:14 UTC