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 10:18:07 +0200 (CEST)
To: Martin Gudgin <mgudgin@hotmail.com>
cc: XML Protocol Discussion <xml-dist-app@w3.org>, Yves Lafon <ylafon@w3.org>
Message-ID: <Pine.LNX.4.44.0204260957300.29102-100000@mail.idoox.com>
 these elements are only used where the edge label doesn't 
matter, and they are used so that xsi:type becomes unnecessary.
 There are two scenarios - the edge is a reference or is not a 
 In case the edge is a reference its element information item 
carries no relevant type information. In case the edge is not a 
reference there is no problem with the current schema.
 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.
 Best regards,

                   Jacek Kopecky

                   Senior Architect, Systinet (formerly Idoox)

On Thu, 25 Apr 2002, Martin Gudgin wrote:

 > I was working on the appendices regarding annotation of the graph with
 > respect to schema validation events this morning and while doing so realised
 > that the encoding schema has a serious problem.
 > We define complex types and global element decls for most of the built-in
 > schema types, adding optional id and ref attributes ( and allowing
 > attributes from other namespaces ). The problem with this approach is that
 > while it works fine for id ( the element which has the id still has
 > content ), it doesn't work for ref. Here's why; When an element has a ref
 > attribute, it's content should be empty. Unfortunately only a few of the
 > built-in schema types will validate this way ( string, normalizedString and
 > token ). All other types require that the content of the element be a valid
 > lexical form of the specified type, which will not be the case when ref is
 > present :-(
 > One solution to this problem is to define two types for each built-in. e.g.
 >   <xs:element name="double" type="tns:double" />
 >   <xs:complexType name="double" >
 >     <xs:simpleContent>
 >       <xs:extension base="xs:double" >
 >         <xs:attribute name='id' type='xs:ID' />
 >       </xs:extension>
 >     </xs:simpleContent>
 >   </xs:complexType>
 >   <xs:element name='doubleRef' type='tns:doubleRef' />
 >   <xs:complexType name='doubleRef' >
 >     <xs:attribute name='ref' type='xs:IDREF' />
 >   </xs:complexType>
 > But this means that outbound edge labels depend on whether the node is
 > serialized in line or is referenced using the 'ref' attribute or xsi:type is
 > needed.
 > Another approach is to define a reference type and global element decl;
 >   <xs:element name='Reference' type='tns:Reference' />
 >   <xs:complexType name='Reference' >
 >     <xs:attribute name='ref' type='xs:IDREF' />
 >   </xs:complexType>
 > and say that all inbound edges for multi-refs are encoded as 'Reference'
 > elements. But again this forces particular edge names or xsi:type usage.
 > It's only a small stretch to then do this;
 >   <xs:element name='TypedReference' type='tns:TypedReference' />
 >   <xs:complexType name='TypedReference' >
 >     <xs:attribute name='ref' type='xs:IDREF' />
 >     <xs:attribute name='type' type='xs:QName' />
 >   </xs:complexType>
 > which has the advantage of carrying type info ( albeit app level ) with the
 > reference. Still has the same problems as the previous two regarding edge
 > names/xsi:type.
 > My inclination right now is to take the first approach and describe what
 > happens if the specified edge labels are used and what happens if the
 > specified edge labels are not used.
 > Thoughts, comments and other input to the usual address
 > Gudge
Received on Friday, 26 April 2002 04:18:14 UTC

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