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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:19 UTC