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

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 Monday, 11 February 2002 11:29:26 UTC