[i47]: XML Protocol WG Issues list discussion

At the face to face meeting in Cambridge (February 26 - 27) I agreed
to begin the discussion of Issue 47 in [1], raised in an email to 
xml-dist-app [2].

<quote>
R201

    "The RPC conventions within the XML Protocol should use the Data
     Representation model discussed in section 4.5 to represent
     parameters to a call in the request message and results of
     the call in the reply message."

A method invocation is modeled as a struct. Parameters and results are 
modeled as accessors on the struct. The concepts of "struct" and 
"accessor" are loosely described in Section 5 [3] of the specification.

Issue RPC7: SOAP 1.1 describes its notion of a "data model" in a section 
describing an encoding system. The notion of a data model should 
probably be separated from the actual physical representation.

    "It must be convenient to create straightforward mappings of
     the data types to a wide variety of widely deployed
     programming languages and object systems."

The Schema types [4] have been shown to map to a reasonable set of 
native data types in commonly used programming languages and object 
systems. The additional types described in SOAP 1.1 - structs, arrays - 
also map to commonly used programming constructs.

SOAP defines in section 5 a datamodel that contains constructs like 
"struct", "array", "multi-struct", and simple types. The RPC 
convention in section 7 is cast in terms of the data model and not 
in terms of a specific representation within the SOAP message. That 
is, it is possible in SOAP to use another actual representation while 
still using the SOAP data model as well as using some other data model 
entirely. We (the WG) makes a note that we should ensure the 
destinction is made in the XML Protocol spec. We leave it to later to 
actually decide how we might best tackle this in the design phase. 
Discussion will take place in email.
</quote>

Based on similar arguments in [5], I would urge that we not define SOAP 
encoding rules directly in the XML Protocol specification.

The first phrase of 201 "The RPC conventions within the XML Protocol 
should use the Data Representation model discussed in section 4.5..." is 
misleading in that it implies a model that could be used, which (I believe) 
is actually not there.

I suggest the following small change, referring to "Data Representation 
guidelines" instead of a model, and adding a reference to SOAP:

201
"The RPC conventions within the XML Protocol should *follow* the Data
     Representation guidelines discussed in section 4.5 to represent
     parameters to a call in the request message and results of
     the call in the reply message.  A possible realization of 
     these guidelines can be found in the SOAP/1.1 specification [4]."
 
Rationale
=========
The rationale for leaving the requirements decoupled from encoding is the 
same as that given in the email concerning Issue 48 [5].  Specifically, 
the SOAP encoding rules allow for arrays (there may be a separate issue 
now concerning R404), and simply referencing the SOAP specification on 
this point is as far as I think we should go.

As mentioned for Issue 48, staying out of the application semantics
helps assure "composability" with other W3C specifications, and also
with outside specifications which may define metadata. 

One final reason for the decoupling is as follows:  if we really intend
as a working group to improve upon the encoding rules, then regurgitating
them in the specification *might* make sense.  However, that prospect
seems doubtful, and the encoding is, in any case, an app issue. 

Best regards,
David Ezell

[1] http://www.w3.org/2000/xp/Group/xmlp-issues.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jan/0193.html
[3] http://www.w3.org/TR/SOAP/#_Toc478383512 <http://www.w3.org/TR/SOAP/ 
[4] http://www.w3.org/TR/xmlschema-2/
[5] http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2001Mar/0010.html

Received on Tuesday, 20 March 2001 18:04:59 UTC