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: Fri, 1 Mar 2002 09:21:08 -0000
Message-ID: <004501c1c102$6d5a3bd0$b47ba8c0@zerogravitas>
To: <noah_mendelsohn@us.ibm.com>, <xml-dist-app@w3.org>

----- 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 04:21:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:59:09 GMT