Re: xsi:type for multiref targets.

Thanks for reminding me of this.  As you say, it provides a useful middle 
ground solution.  The case that it seems not to hit completely is one 
where there is a derived simple type is to be referenced.  I suppose the 
direction should be that those wishing to use derived simple types in SOAP 
do the same thing we did:  create wrapper complex types.  That kind of 
muddles things like type identity, and I don't think it's a first-class 
approach, but it's probably a reasonable compromise.  Either that, or the 
"graphnode" element that I proposed.  I think graphnode is a bit 
architecturally stronger, the status quo is a bit easier to encode, and 
represents minimal disruption to the existing SOAP design.    Either way 
is OK with me.  Thanks.

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







"Martin Gudgin" <marting@develop.com>
Sent by: xml-dist-app-request@w3.org
03/01/2002 04:21 AM

 
        To:     <noah_mendelsohn@us.ibm.com>, <xml-dist-app@w3.org>
        cc: 
        Subject:        Re: xsi:type for multiref targets.



----- 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 Sunday, 3 March 2002 10:53:26 UTC