RE: Issue with soap-rpc:result

Tim Ewald writes:

>> While I agree that XSD cannot describe the 
>> SOAP data model directly, it
>> *can* describe an encoded version of the 
>> data model that is representable as an XML infoset.

Sure, but if it's the graph that counts, you presumably want to establish 
a contract at that level.  Even for relatively simple graphs, there are 
many, many encodings that SOAP claims are completely equivalent.  When you 
write an XML schema to capture such a graph, you tend to validate at most 
one or a few of those serializations.  Now, I can understand the case for 
dropping the graph model entirely;  I'm less convinced about keeping 
graphs but modelling  as trees. 

Maybe an example will make my concern clearer.  Let's assume we are using 
graphs, and I have an RPC method that's documented to take three 
arguments.  SOAP basically says that's  a struct with three members, which 
is what I think I'd like to capture in an interface definition.  As far as 
I know, all of the following are legal XML documents to represent such a 
struct:

Example 1:

        <n:someMethod>
                <arg1>bob</arg1>
                <arg2>mary</arg2>
                <arg3>bob</arg3>
        </n:someMethod>

Example 2:
        <a:mref id="X">bob</a:nmref>
        <n:someMethod>
                <arg1 href="x"/>
                <arg2>mary</arg2>
                <arg3>bob</arg3>
        </n:someMethod>

...and so on in many variations.  The point is that it's very difficult, 
perhaps impossible in practice to write a schema that will accept all 
reasonable representations of the struct, and accepts only legal 
representations of the struct.   And that's a simple case.   It's a little 
like trying to document a C language API by describing an example of the 
assembler code that might be generated for it. 

BTW:  I'm not convinced that we need an extraordinarily deep or general 
graph modelling schema language.  I suspect that to effectively define 
SOAP graphs in enough detail to support applications such as WSDL 
interface descriptions, we do need something that models in terms of SOAP 
abstractions such as struct, multi-struct (if we keep it) and array, along 
with the SOAP simple types, and perhaps schema complex types (as opaque 
nodes in the graph). 

To reinterate:  if we don't want to go there I think the most coherent 
approach is to back off to true document literal, with perhaps a few 
conventions that can be used to facilitate bindings to common programming 
languages in cases where old SOAP 1.1 RPC is missed.  To keep graphs and 
model them as trees still doesn't make sense to me.  As noted earlier, 
this may well be an area where my personal opinion does not represent 
concensus for IBM.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Friday, 8 February 2002 18:19:57 UTC