ACTION REQUIRED: implementation features comments

WG members should evaluate these comments to help finalise the contents of
Table 2.
(The Table will shortly be updated with ID numbers that correspond to those
Jacek uses. Features that "go away" will retain their ID numbers.)

............................................
David C. Fallside, IBM
Ext Ph: 530.477.7169
Int  Ph: 544.9665
fallside@us.ibm.com

----- Forwarded by David Fallside/Santa Teresa/IBM on 07/18/2002 05:05 PM
-----
|---------+---------------------------->
|         |           Jacek Kopecky    |
|         |           <jacek@systinet.c|
|         |           om>              |
|         |           Sent by:         |
|         |           xml-dist-app-requ|
|         |           est@w3.org       |
|         |                            |
|         |                            |
|         |           07/18/2002 03:55 |
|         |           AM               |
|         |                            |
|---------+---------------------------->
  >-----------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                             |
  |       To:       xml-dist-app@w3.org                                                                                         |
  |       cc:                                                                                                                   |
  |       Subject:  implementation features comments                                                                            |
  |                                                                                                                             |
  |                                                                                                                             |
  >-----------------------------------------------------------------------------------------------------------------------------|




 Hi all, 8-)
 I have comments here on the implementation features listed in
table 2 in [1].
 I refer to the features by their ordinal position in the table
(at the moment the table contains 60 features) and I presume that
the features will be numbered from 1 to 60 in the next update to
the document.
 My comments are from the position of a SOAP implementor - what I
envision I could say I implement or not. From this POV arise some
properties of implementation features:
 1) a feature should be atomic - it can be implemented or not,
nothing in between. This is an ideal state; usually there is some
fuzziness and the following is my personal approach to drawing
the line.
 2) a feature must affect implementation - for example
requirements on transport bindings affect binding specs, not
implementations.
 3) a feature must be specified by SOAP 1.2 specification, part 1
or 2.
 My comments are at the end of this message. They are in the form
of "feature_number) my comments". Features I don't comment on are
OK with me.
 Proposed features are in the form of "feature_number) feature
text"; the feature text presumes a context of "an implementation
supports ...".
 If I suggest splitting a feature, this suggestion also implies
removing the original feature.

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/


[1] http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html



 1) split into three features:
 1.1) generating and transmiting SOAP messages - initial sender,
intermediary
 1.2) receiving and processing SOAP messages - intermediary,
ultimate receiver
 1.3) relaying SOAP messages - intermediary

 2) add the text "supports env:role attribute II" obsoleting
feature 18

 3) remove, routing is not in SOAP 1.2 spec and relaying is in
1.3

 4) dupe of 2

 5) rephrase: "supports SOAP-specified role names"

 7) rephrase: "supports active intermediaries" to remove
commonality with 1.3

 8) does this mean at one endpoint URI? Just a clarification
question, otherwise the feature is OK.

 9) rephrase to include all soap-envelope elements (envelope,
fault, header, body) because I don't see why an implementation
should validate Envelope and not the others

 10) don't see what it means: "does it support XML with some
content?" Suggestion: remove

 11) rephrase: "allows insignificant whitespace in SOAP Envelope,
between headers etc."

 12) obsoleted by 9

 13) and 14) I suggest merging these two

 15) obsoleted by 9

 16) obsoleted by 9

 17) duplicating 9 and 2

 18) obsoleted by 2

 20) obsoleted by 9

 21) obsoleted by 9

 22) split into
 22.1) Supports multiple application data models and their
serializations into XML
 22.2) Supports SOAP Data Model

 23) obsoleted by 22.1

 24) rephrase: "supports SOAP Encoding"

 26) rephrase: "supports globally and locally scoped names"

 27) split into:
 27.1) supports simple data types
 27.2) supports structs
 27.3) supports arrays
 27.4) supports generics

 28) obsoleted by 27.3

 29) dupe of 22.1

 30) remove

 34) rephrase to: "supports application/soap+xml content type
with XML 1.0 serialization",

 35) dupe of 31 and 32

 36) dupe of 33

 37) not specified by SOAP, remove

 38) and 39) implementation supports state description? merge
into "supports all specified HTTP status codes"

 40) merged into 34

 41) through 46) merge into "supports SOAP Faults"

 50) remove, covered by others

 53) split into
 53.1) supports RPC as structs
 53.2) supports RPC as arrays

 55) dupe of 53

 57) SOAP doesn't specify other encoding styles, remove

 58) covered by 53

 59) remove or rephrase to "supports SOAP headers with RPC"

 60) rephrase to "supports RPC faults"

Received on Friday, 19 July 2002 00:51:02 UTC