xsi:type for multiref targets.

> One issue with the current definitions of enc:integer is that
> they don't allow for anything other than id/href from the 
> encoding namespace, so you can run into issues with root & 
> arrayType etc.

There is also likely to be a problem with more derived types. For
instance, if I want to define an integer restricted to the range 0 to
100, should I derive it from xsd:integer or the SOAP encoding array
version, e.g., enc:integer? Or am I not supposed to do that if I'm using
the SOAP data model? If I do have a simple type derived from
xsd:integer, am I responsible for making an equivalent complexType with
an id and href attribute? If I do, and a SOAP processor checks
explicitly for types defined in the SOAP encoding namespace (which my
type would not be), how will it know what I'm doing? I see a strong
argument for Noah's wrapper style simply to avoid these problems.

> I really wish that soapencoding would either fully adopt XSD,
> or completely drop it, and not continue its current parts of 
> XSD approach, and the resulting confusion it brings. 

Amen, brother.

Tim-

Received on Sunday, 3 March 2002 13:02:09 UTC