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

Re: xsi:type for multiref targets.

From: Simon Fell <soap@zaks.demon.co.uk>
Date: Fri, 01 Mar 2002 20:53:18 -0800
To: "Martin Gudgin" <marting@develop.com>
Cc: xml-dist-app@w3.org
Message-ID: <vam08uo0vh1bralifgklpu70n6bs88plnb@4ax.com>
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.

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. 


On Fri, 1 Mar 2002 09:21:08 -0000, in soap you wrote:

>----- Original Message -----
>From: <noah_mendelsohn@us.ibm.com>
>To: <xml-dist-app@w3.org>
>Sent: Thursday, February 28, 2002 4:16 PM
>Subject: xsi:type for multiref targets.
>> In the course of preparing to fulfill the action item that Gudge and I
>> to write up the clarification of xsi:type, the following possible issue
>> occurred to me.
>> If I remember correctly, our idiom for multirefs is:
>>       <target id="x">somevalue</target>
>>       <edgename href="x"/>
>>       <edgename2 href="x"/>
>> This gives you one node, of indeterminate type, with edges named
>> "edgename1" and "edgename2'.
>> Now, let's say you want  to type the node as an integer:
>>       <target id="x" xsi:type="xsd:integer">25</target>
>>       <edgename href="x"/>
>>       <edgename2 href="x"/>
>> Well, that doesn't work!  The element named target is not of type integer,
>> because it has an attribute (id=").
>That's why in the encoding schema[1] we define types with id and ref attrs.
>So the correct serialization would be ( playing fast and loose with
>namespaces... );
>       <target id="x" xsi:type="enc:integer">25</target>
>       <edgename href="x"/>
>       <edgename2 href="x"/>
>> Unless I'm missing something, this is
>> a serious problem, and we should open an issue.
>I don't think we need to. But maybe we should call this out in the text and
>refer to the encoding schema[1]
>> This also provents
>> explicitly supplying xsi:type="xsd:string" on a multiref node, which I
>> think is a common case.
>> Proposed Solution
>> ----------------------
>> Introduce a new wrapper element (name TBD) along the following lines:
>>       <soapenv:graphnode id="x">
>>             <target xsi:type="xsd:integer">25</target>
>>       </soapenv:graphnode>
>>       <edgename href="x"/>
>>       <edgename2 href="x"/>
>> The soapenv:graphnode element would serve only to carry the id.  It would
>> not create a node separate from its child (it's not a one element
>> structure);  it and its child form one node.  So, in the example, the
>> is identical to the first one in this note, except that it has type
>> xsd:integer and a value of 3.
>I quite like this approach although I'm not sure it's necessary. If people
>*really* want to use xsd:integer and can't face using enc:integer then this
>is a sensible direction to explore. I do realise that the enc:xxx approach
>messes up our minimal schema approach.
>> I'm on the fence as to whether use of the
>> graphnode wrapper would be required on all multiref targets, or just
>> available as an option for use when xsi:type is an issue.  Comments?
>If we do it this way, I would prefer to mandate it for multiref targets.
Received on Friday, 1 March 2002 23:54:26 UTC

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