comments on WS Desc Requirements draft of 29 April 2002

Dear colleagues:

I have just read the working draft of the Web Service Description
Requirements of 29 April 2002 (http://www.w3.org/TR/ws-desc-reqs/),
and hope that these comments may be useful in revising and improving
the document.  They are offered solely on my own behalf and do not
necessarily represent the views of any organization or individual
other than myself.

Sec. 2.2 Normative definitions

Operation is defined as "A set of Messages related to a single Web
Service action ..." -- on this, three observations:

   1 "action" is undefined (I realize one can't define every term in
     every definition -- perhaps specs should provide both definitions
     and explicit lists of important primitive concepts), and the result
     is that I don't know what is actually meant here.

   2 I would have expected an operation to involve a "sequence"
     rather than a "set" of messages -- if you really do mean that
     operations are unordered collections of messages without
     duplicates, then "set" is the right word, but in that case I hope
     you'll add a note explaining why sequence can usefully be left out
     of the concept of operation.

   3 the phrase "... is called Operation" may be a typo for "... is
     called an Operation"

Sec. 4.2 Simplicity

R014 seems vague.  It would be helpful to the reader if it were
possible to indicate in a sketchy manner which parts of the existing
Web infrastructure are meant here: existing deployed WSDL 1.1
software?  REST-ful software and ideas? HTML 3.2?  I realize that this
is likely to be a difficult point to reach perfect consensus on;
perhaps a note indicating the degree of consensus and the points of
contention would be useful.

Sec. 4.3 Interface Description

R054 is opaque to me: as a reader, I don't know what is meant here, or
how I would tell the difference between a Web Services Description
spec that met this requirement and one which didn't.

R041 again uses the word "set" where I think "sequence" must be what
is actually expected.  (From which I infer that you either need to say
"sequence" or explain why "set" is right.)

R116 sounds good, but I don't know what it means.  An example of an
abstract policy, as opposed to a concrete policy, would be helpful, as
would an example clarifying what it means to "offer" a policy.

Sec. 4.5 Messages and Types

R046 leaves the term "wire format" undefined.  I have heard this term
often before, but never before in a context where the details of what
is meant matter quite so much.  A definition or at least an example
would be useful.  (Big-endian vs. little-endian? HTTP vs. SMTP?  ASCII
vs UTF-7 vs UTF-8 vs Shift-JIS vs EBCDIC vs UTF-16?  All of the above?
None of the above?)

R085 uses the term "strongly typed", which I have heard applied to
widely different and contradictory type diciplines.  I assume you mean
statically typed, typed at design time, as opposed to dynamically
typed, manifestly typed, or typed at run time.  Since the obvious
antonym of "strong" typing is "weak" typing, and since "weak" so
easily carries a pejorative connotation, I think it would be good to
revise this requirement to eliminate the phrase "strongly typed".

Sec. 4.6 Service Types

This would be easier to read and follow if R118 preceded R058.

Sec. 4.8 Reusability

R071 puzzles me slightly.  If the description is in XML, as is implied
by your definition of Web Service, then this is already given by the
existence of the external-entity mechanism in XML.  If the
external-entity mechanism of XML does not meet this requirement, then
it is not clear what the requirement is, and this item needs revision.

Sec. 4.9 Extensibility

R012 uses but does not define the term "support", which means the
statement of the requirement is not really very informative.

R067 uses the term "points of extension", which should perhaps be
defined (I don't know what it means).

Sec. 4.11 Security

R115 appeals to a notion of equivalence, but the meaning of
"equivalence" is not clear here.  Do you mean that the WG
specification(s) SHOULD define an equivalence relation on Service
descriptions?  Or are you appealing to an existing notion of such an
equivalence relation, and saying that the spec(s) should be sure to do
something (what?) about it?

In either case, it's not clear to this reader what this has to do with
security; would it be possible to add a note explaining?

References

I think your references should include a reference to the XML spec.

I hope these help.

-C. M. Sperberg-McQueen
  World Wide Web Consortium

Received on Thursday, 5 September 2002 10:05:36 UTC