RE: xsi:type for multiref targets.

> 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