LC Issues from Spec reviews

The following 15 issues are culled from WG reviews of the spec prior to 
the LC draft publication. Yves, please raise new LC issues for each one.

This completes the editors action item: "Redirect non editorial issues 
to last call issues list".

Regards,
Marc.

 From Noah Mendelsohn:

(i)
>>> Section 5, Section 5.2.1, Section 5.3.1:
>>> Clarify that whitespace IS (potentially) significant in Header and
>>> Body blocks.  Changes are needed at the very end of section 5.0.
>>> Also, 5.2.1 and 5.3.1 should be brought in line with the conventions
>>> established for 5.4.5.1, etc., which talk about character children and
>>> whitespace. 
>> > +1, but I think that this may need some discussion.
>> I think the last paragraph of 5.0 is OK as it says "Unless otherwise 
> indicated...". I've added a bullet to 5.2.1 and 5.3.1 noting that 
> whitespace is significant.
> 
> Question: Is whitespace within the Body significant or only within 
> children of the body ? At the moment we only state the latter.
> 

(ii)
>>> Section 5.1.1:
>>> The encodingStyle attribute SHOULD NOT appear on the SOAP
>>> Envelope [reference to 5.1], SOAP Body [reference to 5.3] or SOAP
>>> Header [reference to 5.2] element information items.
>>> </suggested>
>> Not sure whether this should be a MUST because of the scoping rules for encodingStyle ?
> 

(iii)
>>> Section 5.2.1 (and 5.3.1):
>>> (Don't we allow arbitrary attributes on header blocks?  This may
>>> need to be a last call issue.  Still, I'm curious whether we ever
>>> intended to rule these out?  The equivalent issue exists for Body
>>> child elements, IMO.)
>>> <original>
>>> Each SOAP header block element information item:
>>>
>>> * MUST have a [namespace name] property which has a value, that
>>>   is, be namespace qualified.
>>>
>>> * MAY have an encodingStyle attribute information item in its
>>>   [attributes] property.
>>>
>>> * MAY have an role attribute information item in its [attributes]
>>>   property.
>>>
>>> * MAY have a mustUnderstand attribute information item in its
>>>   [attributes] property.
>>> </original>
>>> <suggested>
>>> Each SOAP header block element information item:
>>>
>>> * MUST have a [namespace name] property which has a value, that
>>>   is, be namespace qualified.
>>>
>>> ** May have zero or more attribute information items.  Among
>>>    these MAY be any or all of the following, which have special    
>>> significance for SOAP processing:
>>>
>>>      - encodingStyle attribute information item
>>>
>>>      - role attribute information item
>>>
>>>      - mustUnderstand attribute information item
>>>
>>> </suggested>

(iv)
>>> Section 1.4 (and 3.1):
>>> "SOAP feature: An abstract piece of functionality..." (what is an 
>>> abstract piece of functionality?...same phrase appears in 3.1)

(v)
>>> Section 3.1:
>>> (AMBANT (the word "it") and generally a bit awkward.)
>>> <original>
>>> While the SOAP Protocol Binding Framework provides for the possibility
>>> that such features may be expressed outside the SOAP envelope, it does
>>> not define a specific architecture for the processing or error
>>> handling of these externally expressed features by a SOAP
>>> intermediary. </original>
>>> <suggested>
>>> Although the SOAP Protocol Binding Framework allows end-to-end
>>> features to be expressed outside the SOAP envelope, no standard
>>> mechanism is provided for the processing by intermediaries of the
>>> resulting messages.
>>> </suggested>
>> > Hmmm... not too sure we haven't lost the intent with the suggested
>> tweak.
>> 

(vi)
>>> Section 3.3: relationship to section 3.1.1 is awkward.  Both
>>> establish special rules for MEPs.  Suggest that all description
>>> of special rules for MEPs be in one place or the other.
>>>

(vii)
>>> Section 5.2.3:
>>> (the final reference to "false or 0" seems to violate our style
>>> guideline, I.e.  that we never talk about multiple lexical forms,
>>> unless it matters.  In the first sentence it does matter, in the
>>> 2nd it doesn't.  Still, I'm not sure I'd make that part of the
>>> change.)
>>> <original>
>>> If relaying the message, a SOAP intermediary MAY substitute
>>> "true" for the value "1", or "false" for "0". The SOAP
>>> mustUnderstand attribute information item may be omitted if its
>>> value would have been "false" or "0".
>>> </original>
>>> <suggested notSureWeShouldChange="true">
>>> If relaying the message, a SOAP intermediary MAY substitute
>>> "true" for the value "1", or "false" for "0". The SOAP
>>> mustUnderstand attribute information item may be omitted from the
>>> relayed message if its value would have been "false".
>>> </suggested>
>> 

(viii)
>>> Section 5.4.4:
>>> What do we mean "similar"?  They are as different as the
>>> definition of a variable and a reference to that variable.
>>> <original>
>>> The Role element information item is similar to the SOAP role
>>> attribute information item (see 5.2.2 SOAP role Attribute),
>>> except that the value of the Role element information item
>>> identifies the role the node was playing at the point the fault
>>> occurred. </original>
>>> <suggested>
>>> The Role element information identifies a role the node was
>>> playing at the point the fault occurred.  This MUST BE one of the
>>> roles assumed by the node during processing of the message [ref
>>> to section 2.6].
>>> </suggested>
>> > +1
>>
> 
> Partly done. I removed the "is similar to the SOAP role
> attribute information item (see 5.2.2 SOAP role Attribute),
> except that the value of the Role element information item". I did not 
> add the sentence "This MUST BE one of the roles assumed by the node 
> during processing of the message [ref to section 2.6]." as this seems to 
> go beyond the bounds of an editorial change.

(ix)
>>> Section 7:
>>> I find this section to generally be in need of editing to tighten
>>> the wording and to make the messages clearer.  I would still
>>> prefer to put it in an appendix, as almost none of the rules in
>>> it are testable or can be directly used to distinguish a conforming
>>> from a non-conforming implementation.
>>>

 From Stuart Williams

(x)
>>>>2.1 SOAP Nodes
>>>>--------------
>>>>
>>>>
>>>>>A SOAP node MUST be identified by a URI.
>>>>>Wonder if we should say "unambigously identified". eg.  http://.../next
>>>>>does
>>>>>not unambiguously identify a SOAP node (some context for interpretation
>>>>> is
>>>>>required in addition to a URI in order to identify a SOAP node from this
>>>>>URI).
>>>>>Can the  URI be relative? I think not! Should we say "absolute URI"?
>>>>
>>>Good points. Another question: why 'MUST' a SOAP node be identified by a 
>>>URI ? Roles are identified by a URI, but why must a SOAP node be ? 
>>>Should this be a 'MAY' ?
>>>

(xi)
>> 2.7.2 Active Intermediaries:
>> ----------------------------
>>
>>One mechanism by which an active intermediary can describe the 
>>>modifications performed on a message is by inserting header 
>>>blocks into the outbound SOAP message. These header blocks 
>>>can inform downstream SOAP nodes acting in roles whose correct 
>>>operation depends on receiving such notification. In this case, 
>>>the semantics of such inserted header blocks should also call 
>>>for either the same or other header blocks to be (re)inserted 
>>>at subsequent intermediaries as necessary to ensure that the 
>>>message can be safely processed by nodes yet further downstream. 
>>>For example, if a message with header blocks removed for encryption 
>>>passes through a second intermediary (without the original header 
>>>blocks being decrypted and reconstructed), then indication that 
>>>the encryption has occurred must be retained in the second 
>>>relayed message.
>>>
>> > Personnally I'd delete this paragraph... it feels a little arm-wavey. It
>> certainly specifies nothing and is largely tutorial.. if that.

(xii)
> 3.1 SOAP Features
> -----------------
> 3rd Paragraph - last sentence:
>> A feature expressed as SOAP headers is known as a SOAP module,
>> and each module should be specified according to the rules 
>> in 3.2 SOAP Modules.
> 
> Personnally, I would like a really strong model of features, properties,
> modules, bindings and expressions.  "A feature expressed as SOAP headers is
> known as a SOAP module..." just does not do it for me.
> 
> Features are abstract things (given the examples). Modules are specifcations
> of concrete behaviours and message components that realise the functionality
> of one (or more) features. In the case of modules the syntactic message
> components (feature related properties (state) ?) are expressed within SOAP
> headers. But... SOAP modules are not, not, not a kind of feature (that's
> what the quoted sentence says if you drop out the qualification).
> 
> On the whole I don't think we articulate the concepts of features,
> properties, modules and bindings with any rigourous clarity - we need to do
> that.

(xiii)
> 
> 3.1 SOAP Features
> -----------------
> Last paragraph:
>> A binding specification that expresses such features external to 
>> the SOAP envelope should define its own processing rules to which 
>> a SOAP node is expected to conform (for example, describing what 
>> information must be passed along with the SOAP message as it 
>> leaves the intermediary). 
> 
> seems contradictory with (from 4. SOAP protocol binding framework):
> 
>> A binding does not provide a separate processing model and does 
>> not constitute a SOAP node by itself. Rather a SOAP binding is 
>> an integral part of a SOAP node (see 2. SOAP Processing Model). 
> 
> The first says that a binding does provide a model for processing features
> external to the envelope. The second says more globally that a binding does
> not provide a separate processing model.
> 
> If there are subtle distinctions here then we MUST find ways to remove the
> subtelty from the language. IMO a spec has *no* buisness being subtle... it
> only leads to trouble later.

(xiv)
> 5 SOAP Message Construct
> ------------------------
> 3rd paragraph: We not clear about whether intermediaries MUST, SHOULD, MAY,
> SHOULD NOT or MUST NOT forward PIs - only that a message SHOULD NOT contain
> them.
> 

(xv)
> 5.1.1 SOAP encodingStyle Attribute
> ----------------------------------
> 1st para:
>> SOAP defines an optional encodingStyle attribute information item which
> indicates the encoding rules used to serialize a SOAP message.
> 
> This sentence suggest that a single instance of the attribute applies to the
> whole message... which I believe is not the case. I'm also not sure how we
> resolved whether the attribute can be carried on the envelope itself or not.



-- 
Marc Hadley <marc.hadley@sun.com>
XML Technology Centre, Sun Microsystems.

Received on Friday, 28 June 2002 07:13:57 UTC