- From: Tim Ewald <tjewald@develop.com>
- Date: Sun, 3 Mar 2002 13:00:58 -0500
- To: "'XMLDISTAPP'" <xml-dist-app@w3.org>
> The soap encoding is an encoding for graphs. XSD describes > trees. With XSD today you can't *accurately* describe graphs > as per soap encoding partly because of the lack of > co-constraints and partly because there is no support in XSD > for typed references. We could add extensions to XSD into the > encoding to deal with those things. However, I'm increasingly > of the opinion that type assignment belongs in a layer above > SOAP. That certainly seems to be where it lives today. I'm > not convinced that adding schema extensions to the SOAP spec > is really where we want to go. Of course, if we got rid of > graphs all together then everyone could just use XSD... I think one of the problems here is that, as far as I can tell, the SOAP data model is just a data model and not a type system. Like the Infoset, the SOAP data model deals with generic types. Where the Infoset has nodes of type element, text, attribute, the SOAP data model has nodes, arrays and typed references. XSD adds problem-domain specific type information to XSD. The SOAP spec doesn't address how to do the same thing for the SOAP data model, it is left up to higher-level technologies to decide. So how can we define a type mapping from the SOAP data model to schema in a way that makes sense if one of the things we are mapping doesn't actually specify types? Do all SOAP data model graph nodes get represented by a single, open XSD node type? Or do most people intend to use more specific complexTypes for this, despite the fact that the SOAP encoding explicitly does not rely on them? It seems that the further we go down this path, the harder things become... Tim-
Received on Sunday, 3 March 2002 13:01:55 UTC