- From: Thompson, Lynne R <Lynne.Thompson@unisys.com>
- Date: Wed, 24 Jul 2002 20:24:12 -0500
- To: Jacek Kopecky <jacek@systinet.com>, xml-dist-app@w3.org
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