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.

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. 

Cheers
Simon
www.pocketsoap.com

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
>took
>> 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
>graph
>> 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.
>
>Gudge
>

Received on Friday, 1 March 2002 23:54:26 UTC