Re: SOAP Encoding Schema broken

 Gudge,
 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 
reference. 
 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)
                   http://www.systinet.com/



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