W3C home > Mailing lists > Public > xml-dist-app@w3.org > April 2002

Re: SOAP Encoding Schema broken

From: Jacek Kopecky <jacek@systinet.com>
Date: Fri, 26 Apr 2002 15:48:47 +0200 (CEST)
To: Martin Gudgin <martin.gudgin@btconnect.com>
cc: XML Protocol Discussion <xml-dist-app@w3.org>, Yves Lafon <ylafon@w3.org>
Message-ID: <Pine.LNX.4.44.0204261541320.29102-100000@mail.idoox.com>
 Gudge,
 as said in [1], the type name assignment is xsi:type or itemType 
or unspecified. 
 The element QNames that encoding schema provides were meant to
serve as possible replacement for xsi:type, a shortcut, really. 
So if the rules are understood that "if there is no xsi:type and 
there is itemType above, the type is that of itemType, never 
other" we'll have an issue.
 Possible solutions:
 a) remove the elements (they are only a shortcut anyway) in
favor or xsi:type, or
 b) phrase the relevant parts so that the elements in encoding 
namespace are really that shortcut equivalent to specifying the 
appropriate xsi:type.
 What do you think?

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)
                   http://www.systinet.com/



On Fri, 26 Apr 2002, Martin Gudgin wrote:

 > I've been thinking about this a bit more. In the array case, we're already
 > covered by[1], assuming people actually use itemType attributes. If they
 > don't use itemType then we're back to needing specific element QNames in
 > order for type assignment to work.
 > 
 > So what will people do in the real world? Use itemType? Use specific element
 > QNames? Both? Neither?
 > 
 > I'm not sure that validation against the encoding schema is all that useful,
 > even if I change it to remove the current ref problem. It will only provide
 > type info nodes in arrays or generics accessed by position. And it will only
 > do it for arrays if people haven't already used itemType. So that really
 > just leaves generics. Is it worth the effort to get the encoding schema
 > right and write rules for type assignment when the utility is so limited?
 > 
 > Gudge
 > 
 > [1] http://www.w3.org/2000/xp/Group/1/10/11/soap12-part2.xml#enctypename
 > 
 > ----- Original Message -----
 > From: "Martin Gudgin" <martin.gudgin@btconnect.com>
 > To: "Jacek Kopecky" <jacek@systinet.com>
 > Cc: "XML Protocol Discussion" <xml-dist-app@w3.org>; "Yves Lafon"
 > <ylafon@w3.org>
 > Sent: Friday, April 26, 2002 9:49 AM
 > Subject: Re: SOAP Encoding Schema broken
 > 
 > 
 > >
 > > ----- Original Message -----
 > > From: "Jacek Kopecky" <jacek@systinet.com>
 > > To: "Martin Gudgin" <mgudgin@hotmail.com>
 > > Cc: "XML Protocol Discussion" <xml-dist-app@w3.org>; "Yves Lafon"
 > > <ylafon@w3.org>
 > > Sent: Friday, April 26, 2002 9:18 AM
 > > Subject: Re: SOAP Encoding Schema broken
 > >
 > >
 > > > Gudge,
 > > >  these elements are only used where the edge label doesn't
 > > > matter,
 > >
 > > Oh, I agree entirely.
 > >
 > > > and they are used so that xsi:type becomes unnecessary.
 > >
 > > xsi:type is *never* necessary, although it is sometimes useful.
 > >
 > > >  There are two scenarios - the edge is a reference or is not a
 > > > reference.
 > >
 > > Agreed.
 > >
 > > >  In case the edge is a reference its element information item
 > > > carries no relevant type information.
 > >
 > > Right, it's an edge and only an edge.
 > >
 > > > In case the edge is not a
 > > > reference there is no problem with the current schema.
 > >
 > > Agreed.
 > >
 > > >  Since the type information has no meaning on the reference, I
 > > > prefer your middle solution, element named "reference" which has
 > > > an attribute "ref" and that's all.
 > >
 > > OK, presumably we'd need to frame this so that such elements are only used
 > > in arrays and generics accessed by position.
 > >
 > > Gudge
 > >
 > >
 > 
Received on Friday, 26 April 2002 09:48:50 GMT

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