Re: More Comments on MS V.941

[Prasad Yendluri <pyendluri@webmethods.com>]

Please see some follow up in <PY></PY> below..

Regards, Prasad

christopher ferris wrote:

> Prasad,
>
> Please see my responses inline below.
>
> Cheers,
>
> Chris
>
> Prasad Yendluri wrote:
> > Chris (et al),
> >
> > The spec needs to be explicit on the normative nature of the specification part or the
> > non-normative nature of the schema in the appendix. This is not stated.  Currently it states that
> > the schema is normative as well (see lines 38-..)
>
> The schema IS normative with regards to the ebXML SOAP extension element
> definitions. What the schema does NOT cover (presently) is where these MUST be
> included in the SOAP Envelope. The normative part of the specification
> covers that.

> The only thing that the current schema (appendix A1) does not address from
> a validation perspective is where the ebXML SOAP Header and Body extension elements
> belong.

<PY> This could remain a confusing aspect for people that may not have the benefit of this discussion /
clarification. Assuming we end up leaving the schema the way it is defined now, it would help if  this
is stated explicitly in the introductory text of the appendix, with a reference to the section in the
specification part that specifies where in the SOAP Envelope (Header/Body) the respective (top-level)
elements in the schema go. </PY>

> One thing that Henrik indicated to us in our discussions in the SOAP
> sub-team was that for all intents and purposes, the SOAP Body element is just
> a specialized SOAP Header as far as a compliant SOAP Processor is concerned.
> He uses the term "syntactic sugar" to characterize the distinction between
> the two.

> From a processing POV, an ebXML SOAP processor can either:
>         - respond with an Error if the message does NOT conform
>         to the ebXML Message Service specification (e.g. because
>         an element that is expected to be in the SOAP:Header is
>         somewhere else such as the SOAP:Body)
>
>         - Or, it can look around to see if the element (that otherwise
>         conforms to the ebXML SOAP extension element schema) is present and
>         process the message and its contents anyway.

<PY> Leaving room for the second option above would lead to interoperoperability issues, even though
semantically there isn't too much of a difference if the ebXML defined elements go in the SOAP Header or
Body. I think we should stick with our specification of where the ebXML SOAP-Extension elements belong
(Header/Body) and require adherence to it. </PY>

> >
> > 38: *Appendix A Schema- This normative appendix contains [XML Schema] for the ebXML Header
> > document.
> >
> > Additionally, I noticed at least  few places where the specification is not explicit on the
> > required/optional nature of elements and attributes (where as the schema captures is accurately).
> > This needed to be tightened up if the specification part (and not the schema) is the normative.
>
> If you are referring to the fact that in the specification, there are places
> where the word REQUIRED or MUST is used as regards an element or attribute
> definition and its cardinality, optional elements are expressed as MAY be present
> or without an explicit statement. This is because we have chosen to avoid
> use of the word OPTIONAL in the specification as it MAY be interpreted
> (incorrectly) by an implementor to mean "You need NOT implement" when in reality,
> it means "The element MAY be present, a compliant implementation MUST be prepared
> to handle the elements presence or absense and process accordingly".

<PY> No. I was referring to 'Required/Optional' from a *schema* perspective only (not from an
implementation perspective). Now that we are saying the schema (in the appendix) *does* provide a
normative definition of the elements in the ebXML Header, it is ok. We need to have a clear statement on
which one supersedes, when there is an inconsistency between the specification and the schema.

BTW, if we are reserving "OPTIONAL" to really mean "Optional to implement", we should perhaps state it
normatively as well (in 4.2?). I have found few places where we use "OPTIONAL" when we really mean MAY.
E.g. the ErrorList element (see line 335) is listed as OPTIONAL. Here we mean it from a schema
perspective and not "Optional to Implement", right?  </PY>

> There is very little in the specification that is OPTIONAL to implement.

<PY>Agree. I guess we do list one or two that are optional to *implement*.</PY>

> >
> > The wording in the appendix needs to be updated to reflect that this is the schema for both SOAP
> > Header and Body extensions (lines 2015-2017):
> >
> > 2015: A.1
> > 2016: The following is the definition of the ebXML SOAP Header extension elements as a schema that
> >
> > 2017: conforms to [XMLSchema].
>
> Yes, I had a similar comment in the emails I just sent out with my comments.
> I agree.
>
> >
> > Regards, Prasad
> >
> >