[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Schema?

• From: Rick JELLIFFE <ricko@g...>
• To: "Henry S. Thompson" <ht@c...>, XML-DEV@x...
• Date: Sat, 01 Jul 2000 20:59:13 +0800

"Henry S. Thompson" wrote:
> 
> Rick JELLIFFE <ricko@g...> writes:
> 
> > "Henry S. Thompson" wrote:
> > >
> > > Rick JELLIFFE <ricko@g...> writes:
> >
> > > >  2) type is directly keyed from the element name (or an xsi:type
> > > > attribute), which does not allow the user-friendly markup idiom of where
> > > > the element name gives the basic type of the element and an attribute
> > > > declares the subtype; instead, if one wants subtyping, one has to make
> > > > an explicit new element named for that--one must have <textInput> rather
> > > > than <input type="text">...
> > >
> > > This is misleading at best: This style of document is somewhat
> > > _better_ supported by XML Schema than it is by DTDs -- you can
> > > perfectly well write <input type="text">...</input> in a schema-valid
> > > document, and in some cases you can even organise things so that the
> > > content validated thereunder is validated differently to e.g. the
> > > content of <input type="hamAndEggs">...</input>.
> >
> > Henry, are you saying that in XML Schemas, a schema-defined attribute
> > specified by a user in an instance (apart from xsi:type) can ever select
> > the type or facet of the value of that element or of another
> > attribute?
> >
> > Can you give an example?  (Note, I am not talking about fixed or
> > defaulted values from a schema documenting the current type. That is
> > something quite different. I mean keying {i.e. selection} of type.)
> 
> <xs:schema xmlns:xs="http://www.w3.org/1999/XMLSchema">
>  <xs:complexType name="input" abstract="true">
>    <xs:choice>
>      <xs:element ref="source" minOccurs="0" maxOccurs="unbounded"/>
>      <xs:element ref="garnish" minOccurs="0" maxOccurs="unbounded"/>
>    </xs:choice>
>    <xs:attribute name="type" use="required" type="readOrEat"/>
>  </xs:complexType>
> 
>  <xs:simpleType name="readOrEat" base="xs:NMTOKEN">
>    <xs:enumeration value="text"/>
>    <xs:enumeration value="hamAndEggs"/>
>  </xs:simpleType>
> 
>  <xs:element name="source"/> <!-- these could of course be more different -->
>  <xs:element name="garnish"/>
> 
>  <xs:element name="lunch">
>    <xs:complexType>
>      <xs:sequence>
>       <xs:element ref='lunchMenu'/>
>       <xs:element ref='lunchReading'/>
>      </xs:sequence>
>    </xs:complexType>
>  </xs:element>
> 
>  <xs:element name='lunchMenu'>
>   <xs:complexType>
>   <xs:element name='input'>
>    <xs:complexType base='input' derivedBy='restriction'>
>     <xs:choice>
>       <xs:element ref="garnish" minOccurs="0" maxOccurs="unbounded"/>
>     </xs:choice>
>     <xs:attribute name="type" use="required">
>      <xs:simpleType base="readOrEat">
>       <xs:enumeration value="hamAndEggs"/>
>      </xs:simpleType>
>     </xs:attribute>
>    </xs:complexType>
>   </xs:element>
>   </xs:complexType>
>  </xs:element>
> 
>  <xs:element name='lunchReading'>
>   <xs:complexType>
>   <xs:element name='input'>
>    <xs:complexType base='input' derivedBy='restriction'>
>     <xs:choice>
>       <xs:element ref="source" minOccurs="0" maxOccurs="unbounded"/>
>     </xs:choice>
>     <xs:attribute name="type" use="required">
>      <xs:simpleType base="readOrEat">
>       <xs:enumeration value="text"/>
>      </xs:simpleType>
>     </xs:attribute>
>    </xs:complexType>
>   </xs:element>
>   </xs:complexType>
>  </xs:element>
> 
> </xs:schema>
> 
> The above schema-validates
> 
> <lunch>
>  <lunchMenu>
>    <input type='hamAndEggs'>
>      <garnish>onions</garnish>
>      <garnish>tomatoes</garnish>
>    </input>
>  </lunchMenu>
>  <lunchReading>
>    <input type='text'>
>      <source>The Scotsman</source>
>      <source>The Guardian</source>
>    </input>
>  </lunchReading>
> </lunch>
> 
> but not e.g.
> 
> <lunch>
>  <lunchMenu>
>    <input type='hamAndEggs'>
>      <source>The Scotsman</source>
>      <garnish>tomatoes</garnish>
>    </input>
>  </lunchMenu>
>  <lunchReading>
>    <input type='text'>
>      <source>The Guardian</source>
>      <garnish>onions</garnish>
>    </input>
>  </lunchReading>
> </lunch>
> 

> I wouldn't quite call this 'selecting' by use of attributes, because no
> single content model can contain two elements with the same name but
> different types, but this admittedly fanciful example is actually
> isomorphic to real examples where sub-cases of a general type are
> signalled by fixed attribute values.

In this example, the value of the type attribute is determined by the
grandparent
(i.e., by lunchReading or lunchMenu) restricting the allowed types of
its nested children.  It is exactly an example of the name of an element
being used to select the subtype.

This is clearly not  a case of where "a schema-defined attribute
specified by a user in an instance (apart from xsi:type) can ever select
the type or facet of the value of that element or of another attribute". 

It will not do users a service to pretend that XML Schema's excellent
design which are so good in some areas are universally good for
everything.

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

• Prev by Date: Major problems with string handling in expat
• Next by Date: XML-Schemas: purpose of elementFormDefault?
• Previous by thread: Major problems with string handling in expat
• Next by thread: XML-Schemas: purpose of elementFormDefault?
• Index(es):
  • Date
  • Thread