general comments to SOAP Version 1.2 (parts 0-2)

Dear XML Protocol WG,

please receive the following general comments on your
last call versions of soap 1.2 parts 0-2.
Editorial comments are marked with ed.; other comments
are substantial.

Please copy me on any discussion about these issues;
I'm not subscribed to the soap discussion list.

General:

Acknowledgements: I assume that the 'member of the WG'
"Noah Mendelson (IBM)" and the the 'previous member of
the WG' "Noah Mendelson (Lotus Development)" are one and
the same person. This would appropriately be reflected
by saying 'member of the WG': "Noah Mendelson (IBM,
formerly Lotus Development)". There are other cases
like this (apologies to Noah for picking him as an
example).

Part 0:

My impression is that this is not really a primer. Even the
first example is already very long. In various places, issues
such as GET vs. POST,... are discussed. Although such issues are
very important, their discussion in the Primer seems to be more
a reflection of the fact that tehy were disucssed extensively
in the WG, rather than being written with careful consideration
for beginners.

1.1, 'pure information retrieval': GET requests can be used
very appropriately for many more things than 'pure information
retrieval'. Assume a web service that accepts XML Schema dates
and returns dates formatted e.g. for Japanese cheques. While
the service would do calculations, it would have a very high
cachability.

2.2.2, "Part 2 Section 4.1.1provides": ed.: space missing.
There are other places where a space before or after a link
got lost.

2.4, last table (unnumbered): having two columns, one for intermediary
and another for ultimate receiver, seems completely unnecessary.

3., paragraph starting with 'However, a soap message may travel':
This and other places show how 'weak' soap currently is. Rather
than being a well-defined, complete protocol layer that can
easily be used from higher layers and mapped to lower layers,
it seems to be a collection of options, and even for the simplest
uses, a large number of things have to be selected/specified again
by each application. This currently doesn't look very inviting.

3.1.1, "RDF format for the itinerary might have been choosen":
There are too many might, could,... in the spec overall. This is
a typical example.

3.1.2, before example 13: ed: that the all the -> that all the

3.2, just before example 14: Why does the sender need soap
capabilities? Somebody could just send a soap message in an
email with a simple mua, couldn't they?

3.2, example 14: Content-Type missing.


Part 1

General: The use of URIs in some places and qnames in other places
is arbitrary and very confusing. Except for element/attribute names,
URIs should always be used. This would also simplify mapping to
description languages,...

General: Compared to other W3C specs, soap uses a very large number
of namespaces. Many of these namespaces in turn are used for very
few things. This creates an unnecessary overhead in particular
for small messages (as they may e.g. be used on small devices),
and overall seems quite unnecessary.

Example 1 (nit): The message should probably expire a bit later,
to avoid that it's never seen because the receiver didn't have
time at the right moment.

2.6: "at-most one fault" -> "at most one fault"

2.7.1: Re-inserting ... emphasizes the need to process them at
each soap node ...: weird wording. Maybe: Processing is defined
here in terms of reinserting (rather than leaving things in place)
to emphasize the need ....

2.7.2 Active Intermediaries: Are these part of the processing
model, or is this a way to 'cheat' around the processing model?
It sounds as if they can do just about anything, which looks
highly suspicious.

3.2, point 2: Is it allowed to just change the soap processing
model? In arbitrary ways? or are there restrictions?

4.2, multiple features: 'MUST provide any info necessary for
their successful use in combination': Is it okay to say
'feature A and B cannot be used together', or is this not allowed?

5.2.3: "MAY be omitted if its value would have been ...": another
example of 'would'.

5.3.1: Please add: "* May have any number of element or attribute
children." It would be strange if body child elements had to be
CDATA only.

7.1 ed: side affects -> side effects

7.3.1 ed: 'associated that protoco': 'with' missing.

[18]: This should move to note when the last call drafts move on.


Part 2:

Intro: ed) The list of points (1.-7.) mixes full sentences and
nominal phrases, which is very awquard to read.

2.2.1, title (ed): looks strange. I suggest something like
'single-reference and multi-reference nodes'.

3.: A simple example showing a model graph and one or two
possible encodings is urgently needed because it will make
reading and understanding this section a lot easier for a
lot of people.

3.1.6: ed
[2]   nextConcreteSize   ::=   " " concreteSize: The notation for
space is confusing. Better use something explicit
(such as <a href='http://www.w3.org/TR/REC-xml#NT-S'>S</a>

3.2: enc:MissingID: this sounds right only in some cases. In others,
'DuplicateID' or so seems better, or change to 'IDProblem' or so
if you want just one subcode.

4. 'binding-specific address of the target soap node': My understanding
up to here was that soap nodes were identified by an (any)URI, without
this being binding-specific. Please clarify here or earlier.

4.1.2: "the 6.4 Web Method Specification Feature feature": 'feature feature'
sounds weird. (ed)

4.2.2, 3rd bullet point: It is unclear here if a return value
has to be present for a procedure that can return various values,
one of which being 'void', in the case where the actual return
value is 'void'. (yes seems the correct answer to me, to avoid
counting wrong, but then how exactly will this be represented)

4.2.3, 1st para:
'<body> MUST contain only a single child element' and 'is constrained
to produce a single tree' are not the same. The former can lead
to a graph e.g. with cycles as long as all nodes in the graph
can be reached by following edges starting from a single node.
(such a thing is probably called a 'single-rooted graph', but
maybe it's called something else).

4.4, item 4:
'or when there is a mismatch ...': This mismatch has to be
clarified/restricted, otherwise everything can be a env:Sender
fault.

4.4, Note: 'if the receiver does support' ???
'if the receiver does NOT support' seems to make more sense.

5.1.2 The figure should be numbered and labeled, and should be
redone to look sharper. (ed)

6.2.2 This should make clear that there are no soap intermediaries.
(I hope I got this right)

7.1, first note: Is a soap intermediary a http intermediary?

7.1, ed: performingsimilar: add space

7.5.1.2, 415: support Content-type: add 'the'
ed       500: an SOAP fault->a SOAP fault

table 21, ed: 'has generating': fix grammar

B: 'validation ... MUST NOT be required by conforming processors':
Does this mean: 'conforming processors are not required to validate'
or 'it is forbidden that a conforming processor validates' or what?

B: Could there be a feature/module requiring validation in a certain
way (rather than this being purely application-level)?

B2: 'Validation against the minimum schema will not succeed': WHY?
This seems wrong.

B3: '...schemas could be constructed ... certain graphs': Why
only graphs? Couldn't it be just about any kind of data?



Regards,    Martin.

Received on Saturday, 13 July 2002 08:11:22 UTC