W3C home > Mailing lists > Public > xml-dist-app@w3.org > March 2002

Re: xsi:type for multiref targets.

From: Martin Gudgin <marting@develop.com>
Date: Sat, 2 Mar 2002 16:38:19 -0000
Message-ID: <001a01c1c208$aa827d90$b47ba8c0@zerogravitas>
To: "Simon Fell" <soap@zaks.demon.co.uk>
Cc: <xml-dist-app@w3.org>
> ----- Original Message -----
> From: "Simon Fell" <soap@zaks.demon.co.uk>
> To: "Martin Gudgin" <marting@develop.com>
> Cc: <xml-dist-app@w3.org>
> Sent: Saturday, March 02, 2002 4:53 AM
> Subject: Re: 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.

That we can fix by putting an anyAttribute into the attribute group.

> 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.

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...

Received on Saturday, 2 March 2002 11:38:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:11:47 UTC