Systinet Last Call comments

 Hi all, 8-)

 when replying please remove the XMLP Comments list from the 
recipients.

 Here are Systinet's comments on the Last Call working drafts of 
SOAP 1.2 specifications:
 

 1) RPC and Encoding fault combinations
 
 already described in [1]


 2) SOAP Data Model Schema language missing
 
 already described in [2]


 3) Generic compound types unnecessary

 It is Systinet's position that the 'generics' in the SOAP Data
Model are unnecessary and their handling is unclear. We don't see
any use for 'generics' in the known uses of SOAP Encoding.
 See also the posponed issue 185 [in 5].


 4) RPC array representation unnecessary

 It is Systinet's opinion that the array representation of RPC
invocation and results is unnecessary. The 'struct'
representation suffices because in most interface description
languages invocation parameters do have names. The situation is
similar to that of another W3C recommendation - RDF, where
properties are unordered and container membership properties are
named _1, _2 etc. to achieve ordering - [6].
 We are aware that adding array representation is the resolution
for issue 180 [in 5], but we are not planning to implement this
part of the SOAP RPC Representation.
 (The same comment can apply to arrays in the SOAP Data Model but
we'd call it "going too far". 8-) )


 5) RPC return value accessor too complex

 It is Systinet's opinion that the current way of identifying the
RPC return value in the RPC result struct (via a known parameter)
is too complex a solution for the problem and that it obscures
the representation.
 Nevertheless, our implementation does support this; the concern
is for ease of understanding for newcomers to SOAP.


 6) How is version transition handled in the HTTP binding?

 In Part 1, appendix A [3], the handling of SOAP 1.1 messages by
SOAP 1.2 nodes is specified. It says that a node can generate a
SOAP 1.1 version mismatch fault. In SOAP 1.1 messages travel via
the HTTP binding using the content-type text/xml, whereas in SOAP
1.2 the messages travel using the content-type
application/soap+xml.
 Is the version transition still practical if current SOAP 1.1
nodes only accept text/xml SOAP messages; so when they receive a
"known" SOAP fault, it has an "unknown" content-type and
therefore may not be recognized as a known fault?


 7) Missing universal transport binding

 The SOAP 1.2 HTTP binding defines a binding to an application
protocol; i.e. it only supports one application, and that is HTTP
itself (also known as REST).
 Shouldn't the SOAP specification also contain at least one
transport binding that can be used for all SOAP applications?  
We suggest a TCP binding.


 8) Data Model edges originating and not terminating

 In the SOAP Data Model it is said about graph edges that they
are said to originate at a graph node and terminate at a graph
node. In Encoding section 3.1.3 bullet 4 it says that "if a graph
edge does not terminate in a graph node then..."
 Is it possible (from the point of view of the Data Model) for an
edge not to terminate in a graph node? Isn't it contrary to the
common definition of a graph edge? The SOAP Data Model doesn't
define the term "edge" so the common definition has to be
accepted.
 Our understanding is that there are no such edges (not
terminating in a graph node); there may be "missing edges"
instead that can be described in bullet 4 section 3.1.3.


 9) Fault for broken array attributes?

 While SOAP Encoding specifies faults that are generated in cases
like missing ID and missing type; it does not specify faults that
should be generated in case of malformed encoding attributes
(like arraySize and itemType) and in case of inconsistency
between the array size and the actual number of members.


 10) No one-way MEP

 SOAP is a messaging protocol. Before MEPs are introduced, it is
inherently one-way. One-way MEP is a widely used one and one
that's exploited in WSDL 1.1; the basis for another W3C
specification-in-progress, WSDL 1.2. Moreover, SOAP Abstract
Model has a one-way operation as one of the two basic operations.
 Also, the resolution [7] to issue 38 says that "the SOAP 1.2
specification makes it easy to exchange one way and two-way
messages." Also, issue 179 deals with one-way messaging; the
resolution to this issue makes one-way messaging optional in
bindings.
 Altogether, we'd like to see the SOAP 1.2 specification not only
enable, but also provide a spec for one-way messaging.


 11) The SOAP Response MEP doesn't need sending+receiving states
(related to issue 239, maybe covered by it)

 It is unclear why this MEP needs the sending+receiving states in
the state machines when there is nothing really that is sent from
the requester to the responder. This also affects the states
figure.


 12) Is use of Appendix A optional?

 It is unclear in the RPC Representation whether the links to
Appendix A are a MUST (an identifier MUST be mapped to an XML
name using Appendix A's algorithm) or a MAY (for a possible
mapping algorithm see Appendix A).


 Lastly, the postponed issues in the former issue list [4] are
not mentioned in the LC issues list [5] so they may get
forgotten. It might be advisable to mention these postponed
issues in the LC issues list at least in the form of one issue
pointing to all of them.

 Best regards,

                   Jacek Kopecky

		   W3C Advisory Committee representative
                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/

[1] http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0041.html
[2] http://lists.w3.org/Archives/Public/xmlp-comments/2002Jul/0039.html
[3] http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#version
[4] http://www.w3.org/2000/xp/Group/xmlp-lc-issues.html
[5] http://www.w3.org/2000/xp/Group/xmlp-issues.html
[6] http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/#containers
[7] http://lists.w3.org/Archives/Public/xmlp-comments/2001Nov/0009.html

Received on Friday, 19 July 2002 13:30:33 UTC