RE: Issue with soap-rpc:result

I agree with Don. It doesn't make sense to rely on XSD simple types and
mechanisms like xsi:type and xsi:nil while eschewing complexTypes in
favor of structs expressed in some other language. There is no reason to
invent a language to describe XML trees that represent graphs when XSD
can already define those XML trees.

The need to support the serialization of graphs into XML is a general
problem that is not
unique to RPC call stacks. The problem should be addressed using some
standard schema types
for representing typed references. Clearly such types are definable,
because the SOAP encoding rules represent graphs as trees whose
structures are definable with XSD. If we had a library of types, the
encoding rules could explain how to map the call-stack of a method
invocation in a traditional programming language into schemas that use
these types.

I look at the SOAP encoding rules as a stopgap measure that SOAP 1.1 had
to use because XSD was not yet complete. Now that XSD is complete - and
since the SOAP data model relies on it anyway - why not define the SOAP
data model in terms of XSD types so we can have the best of both worlds?

Thanks,
Tim-


> -----Original Message-----
> From: Don Box [mailto:dbox@microsoft.com] 
> Sent: Wednesday, February 06, 2002 9:47 PM
> To: Noah Mendelsohn
> Cc: Jacek Kopecky; Tim Ewald; XMLDISTAPP
> Subject: RE: Issue with soap-rpc:result
> 
> 
> > -----Original Message-----
> > From: Noah Mendelsohn [mailto:noah_mendelsohn@us.ibm.com]
> > Sent: Wednesday, February 06, 2002 5:43 PM
> > To: Don Box
> > Cc: Jacek Kopecky; Tim Ewald; XMLDISTAPP
> > Subject: RE: Issue with soap-rpc:result
> > 
> > Don Box sez:
> > 
> > >> The reality is, SOAP mandates XML Schema-awareness.
> > 
> > Awarenes of built in simple types? yes.  Validation or 
> availability of 
> > some application- or header-specific schema?  Not in SOAP 
> 1.1 and not
> in
> > SOAP 1.2 as at stands.
> 
> Agreed. However, section 5 certainly depended on xsi:type and 
> xsi:nil, the former of which placed a very broad dependency 
> on the XML Schema type system.
> 
> > >> I don't think adding yet another way to define data 
> representations 
> > >> is the answer.
> > 
> > I think the real question is, do we want graphs or trees?  SOAP 1.1
> says
> > that for RPC, we need graphs.
> 
> It's not just RPC that needs this, btw. It's a more general 
> problem related to using XML as a serialization format. RPC 
> is just one application of serialization.
> 
> That stated, since the underlying data model is a tree-based 
> Infoset (or PSVI), everything gets reduced to a tree. If XML 
> Schema had supported typed references, then graphs could have 
> been a first-class construct in PSVI. 
> 
> In retrospect, Section 5 should have been expressed as an XML 
> Schema type library that canonicalized how to represent typed 
> references and arrays. I strongly believe that would have 
> eliminated all of the confusion over encodings.
> 
> > We want to express the difference between:
> > Object o1 = new Thing();
> > Object o2 = new Thing();
> > Object o3 = new Thing();
> > x=method(o1, o2, o3);
> > 
> > and
> > 
> > Object o1 = new Thing();
> > Object o2 = new Thing();
> > Object o3 = o1;
> > x=method(o1, o2, o1);
> 
> Totally agreed. If only the Schema WG would have done it for us...
>  
> > Either a simple XML tree (modeled by XML Schema) or soap 
> 1.1 chapter 5 
> > graph model can represent the first call with fidelity.  Only the
> graph
> > model can easily capture the identity of arguments #1 and #3 in the
> second
> > call.
> > 
> > For better or worse, SOAP 1.1 went to some trouble to solve that
> hairier
> > problem.  Along the way, it got the ability to send cyclic data 
> > structures, DAGs, and some other things you might find in 
> programs.  I 
> > think the question should be "do we need that expressive 
> power in SOAP
> 1.2
> > to do RPC?"
> 
> We need that expressive power in XML Schema in general.
> 
> That stated, they didn't give it to us. 
> 
> However, I believe the right approach is to do a 
> schema-oriented solution.
> 
> I'm not arguing for a loss of expressive power.
> 
> I'm simply advocating that we add the 10% we need to XML 
> Schemas than build a parallel universe that we will need to 
> carry with us in addition to the XML Schema world we cannot ignore.
> 
> DB
> 
>

Received on Thursday, 7 February 2002 12:40:04 UTC