RE: implementation features comments

Jacek,

Reviewed your comments and suggests all comments be incorporated in Table 2.
Note also that item #62 appears to be a duplicate of #34.

-LT

-----Original Message-----
From: Jacek Kopecky [mailto:jacek@systinet.com]
Sent: Thursday, July 18, 2002 3:55 AM
To: xml-dist-app@w3.org
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 Wednesday, 24 July 2002 21:24:21 UTC