W3C home > Mailing lists > Public > xml-dist-app@w3.org > October 2001

Re: Comments/Issues on Part 1

From: Doug Davis <dug@us.ibm.com>
Date: Wed, 10 Oct 2001 07:54:55 -0400
To: xml-dist-app@w3c.org
Message-ID: <OF540D0DB1.7696D508-ON85256AE1.00413A3A@raleigh.ibm.com >
Hugo wrote:
>Hi Doug.
>* Doug Davis <dug@us.ibm.com> [2001-09-21 15:10-0400]
>> I was asked to raise my comments on part 1 as issues:
>Your email lists 21 issues. Were any of those dealt with? Should they
>all go on the issues list?
>If so, could you please send your email to xml-dist-app and I will add
>them to the issues list?

ok - I went through my issue list and removed the ones that
I believe have been resolved.  I've also labeled the ones
that I believe are strictly editorial (vs. requiring a change
in meaning behind the text) with "issue - editorial".


[issue - editorial]
In part 1 we talk about what's in part 2 with very specific
details - by that I mean we list the current set of items in
there.  It seems like it would be better to just say that
there's a part 2 with additional/optional things - much like
we just used the term "adjunts" instead of listing all of 'em.

[issue - editorial]
The last sentence of the intro states:
  These four parts are functionally orthogonal. In recognition
  of this, the envelope and the encoding rules are defined in
  different namespaces.
This seems out of place since we haven't talked about the
role of namespaces yet so the reader will probably not get the
point of it.

[issue - editorial]
1.1 Design goals, IMHO, need a sentence stating that while these
four items listed are not part of the spec, it is not because
they can not be done, but rather are just outside the scope
of the spec at this time.  (maybe leave off "at this time"??)

[issue - editorial]
Section 1.3:  The header block contains the parameters...
We can't call them 'parameters' that implies we know how they
are used and we don't - perhaps "subelements" or "xml blocks"
would be better.

Section 1.4.2: SOAP Block
Do we want to limit this to just SOAP blocks?  By that I mean
just env, header and body and their immediate children or can
any xml chunk (i.e.   <foo> <bar/> </foo>  = 2 SOAP blocks)
be called "SOAP blocks" ?  The definition of "SOAP Block" isn't
clear to me.

[issue - editorial]
Section 2.1 - 2nd paragraph
  A SOAP node receiving a SOAP message MUST perform processing
  [according to the SOAP processing model], generate SOAP faults,
  SOAP responses, and if appropriate send additional SOAP messages,
  as provided by the remainder of this specification.
1 - please add the text in []
2 - Does it really have to be able to generate SOAP responses?
    What if all it does it is log the soap message - that's still a
    valid SOAP node.  I believe the key is the processing model not
    whether it generates a repsonse or not.  Perhaps just move the
    "if appropriate" so we have instead:
  A SOAP node receiving a SOAP message MUST perform processing
  according to the SOAP processing model and if appropriate generate
  SOAP faults,  SOAP responses, and send additional SOAP messages,
  as provided by the remainder of this specification.

[issue - editorial]
Section 2.2 SOAP Actors and SOAP Nodes
This section seems to be repeated in section 4 - do we really need
both?  I would be in favor of removing this section and leaving
section 4.

Section 2.2 SOAP Actors and SOAP Node
  The roles assumed MUST be invariant during the processing of an
  individual SOAP message; because this specification deals only
  with the processing of individual SOAP messages, no statement is
  made regarding the possibility that a given piece of software
  might or might not act in varying roles when processing more than
  one SOAP message.
"invariant" - so if during the processing of a message a SOAP node
determines that it should also assume additional "roles", this would
be illegal?  I think this should be allowed.  We've been talking
about an issue very much along these lines on the mailing list
but I can't remember what it's resolution was - so this might have
already been resolved.

[issue - editorial]
Section 2.3 - 1st paragraph
  We refer to the (implicit or explicit) value of the SOAP actor
  attribute as the SOAP actor for the corresponding SOAP block
  (either a SOAP header block or a SOAP body block).
"a" body block should be "the" body block - isn't the entire body

Section 2.3 - 2nd paragraph
  We say that a SOAP block is targeted to a SOAP node if the SOAP
  actor (if present) on the block matches (see [10]) a role played
  by the SOAP node, or in the case of a SOAP block with no actor
  attribute information item (including SOAP body blocks), if the
  SOAP node has assumed the role of the anonymous SOAP actor.
This is quite a change from 1.1 - to me this says that the "actor"
attribute is the *only* way to target blocks - in 1.1 we said
"The XMLP/SOAP actor global attribute can be used to indicate the
XMLP/SOAP node at which a particular XMLP/SOAP header block is
targeted" - notice the "can be used" - I read that to say that
there may be other means of deciding which blocks are targeted
for a node.  Also, in section 4 (when we repeat actors and nodes!)
we say "can".  I think we should remove this section in favor of
section 4.

[issue - editorial]
Section 2.4 - 2nd paragraph
  ...local name and namespace name of the outer-most element
  information item of that block; or not process the SOAP message
  at all, and fail (see 4.4 SOAP Fault).
"and fail" - shouldn't it be "and generate a fault".

[issue - editorial]
Section 2.4 - 1st paragraph
  ...increased flexibility in processing order as long as all SOAP
  messages, SOAP faults and application-level side effects are
  equivalent to those that would be obtained by direct implementation
  of the following rules [in order].
Please add the "in order".

[issue - editorial]
Section 2.5 - bullet #1
  Generate a single SOAP MustUnderstand fault (see
  4.4.2 MustUnderstand Faults) if one or more SOAP blocks
  targeted at the SOAP node are mandatory and are not understood
  by that node. If such a fault is generated, any further processing
  MUST NOT be done.
Should we make it clear that we mean "understood" and not necessarily
"succefully processed" ? For example, what if the body contains an
RPC and that service isn't deployed - in this case the block was
understood but not able to be successfully processed.  This might
just be getting a bit picky so if none of the editors see a problem
with the current text, I'm ok with dropping the issue.

[issue - editorial]
Section 2.5 - bullet #2
  ...Process SOAP blocks targeted at the SOAP node, generating
  SOAP faults (see 4.4 SOAP Fault) if necessary. A SOAP node
  MUST process SOAP blocks [targeted for this node that
  are] identified as mandatory.
Please add the "targeted for this node that are". Also, the
")" is missing from the "see 4.4 SOAP Fault".

[issue - editorial]
Section 2.5 - last paragraph
  Additional SOAP header blocks MAY be inserted at any point in
  the SOAP message, and such inserted SOAP header blocks MAY be
  indistinguishable from one or more just removed (effectively
  leaving them in place, but emphasizing the need to reinterpret
  at each SOAP node along the SOAP message path.)
We need to say where they are placed since we went out of our
way to say that the order of "untouched" blocks MUST NOT change
or we could just say it doesn't matter - but we should probably
say something.

Section 4.1.1
  ...Each item in the list identifies a set of serialization
  rules that can be used to deserialize the SOAP message.
  The sets of rules should be listed in the order most specific
  to least specific.
"can be used" or "MUST be used"?
Also, we have lists of serialization rules, does it mean that
a value on an element overrides any previously mentioned value
or that it just extends the list?  It sounds like it replaces
it - we should be prefectly clear on this.

[issue - editorial]
Section 4.1.2
  SOAP does not define a traditional versioning model based on
  major and minor version numbers. If a SOAP message is received
  by a SOAP node in which the document element information item
 does NOT have a local name of Envelope and a namespace name of
  http://www.w3.org/2001/06/soap-envelope the SOAP node MUST
  treat this as a version error and generate a VersionMismatch
  SOAP fault (see 4.4 SOAP Fault). A SOAP VersionMismatch fault
  message MUST use the SOAP/1.1 envelope namespace
  (see A Version Transition From SOAP/1.1 to SOAP Version 1.2).

This is wrong - this says that if you also support v1.1 you're
not SOAP compliant.

[issue - editorial]
Section 4.2.1 - Example: Example header with a single header block
We use: mustUnderstand="1" but in the text(sec 2.4) we say it
should be "true".

Secton 4.3.1
  While both SOAP Header and SOAP Body are defined as independent
  element information items, they are in fact related. The
  relationship between a SOAP body block and a SOAP header block
  is as follows: a SOAP body block is semantically equivalent to a
  SOAP header block targeted at the default actor and with a SOAP
  mustUnderstand attribute information item with a value of "true".
  The default actor is indicated by omitting the actor attribute
  information item (see 4.2.2 SOAP actor Attribute).

This last sentence implies that people "should" omit the actor
attribute when in fact they MUST omit it, right?  I think this last
sentence should be removed it could lead to some confusion.  Oh wait,
is the last sentence talking about headers or the body - I thought
it meant the body - but now that I reread it perhaps we're talking
about headers.  If we're talk about headers then we should change
it to something like:
  On headers, the default actor is indicated by...
Received on Wednesday, 10 October 2001 07:55:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:04 GMT