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=").  Unless I'm missing something, this is
a serious problem, and we should open an issue.   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'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?


------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Thursday, 28 February 2002 20:59:26 UTC