W3C home > Mailing lists > Public > xmlschema-dev@w3.org > May 2007

Re: XML Schemas patterns (was: Re: Defining recursive elements?)

From: Pete Cordell <petexmldev@tech-know-ware.com>
Date: Fri, 18 May 2007 10:42:18 +0100
Message-ID: <004b01c79930$ed024f60$4200a8c0@Codalogic>
To: <noah_mendelsohn@us.ibm.com>
Cc: <xmlschema-dev@w3.org>

----- Original Message From: <noah_mendelsohn@us.ibm...>


>  <element name="thing">
>    <sequence>
>        <element ref="height"/>
>        <element ref="width"/>
>    </sequence>
>  </element>
>
>  <element name="height" type="measurementType"/>
>  <element name="width" type="measurementType"/>
>  <complexType name="measurementType">
>    <simpleContent>
>        <extension base="float">
>            <attribute name="units" type="string"/>
>        </extension>...
>
> I don't see a whole lot of duplication.  Like the type, the elements are
> declared in one place and used in another.

IMO - and this is admittedly a syntax issue - when I look at 'thing' I want 
to know what it's components are, and what the types of those components 
are.  The ref approach moves the type information (potentially) a long way 
from 'thing'.  This just makes it harder to read, and thus potentially more 
error prone.  As you say, the schema syntax could have been designed to 
yield the 'benefits' of both approaches, but it hasn't so that is what we 
have to work with.

Also, I think you have problems if you want things like:

  <element name="employee">
    <sequence>
        <element name="id" type="employeeID"/>
        ...
    </sequence>
  </element>

  <element name="vehicle">
    <sequence>
        <element name="id" type="vehicleID"/>
        ...
    </sequence>
  </element>

    <simpleType name="employeeID">
        <restriction base="ID">
            <pattern value="E[0-9]{2}-[0-9]{1,6}"/>
        </restriction>
    </simpleType>

    <simpleType name="vehicleID">
        <restriction base="ID">
            <pattern value="V[0-9]{1,4}"/>
        </restriction>
    </simpleType>

where the name of something (e.g. 'id') has a different interpretation in 
different contexts.

Or would you advocate putting the employee and vehicle types (or elements) 
in different namespaces?

> For the reasons Michael Kay's been giving, plus the one's I've been
> contributing, I think that the >semantics< of globals are usually
> preferable, and I don't think you've given any examples to indicate to the
> contrary.

IMO, in a number of cases (not all), the syntactic downside of the approach 
removes the semantic benefit.  Sure, if you're defining a schema that's 
going to be used with schema-aware queries and stylesheets, then you have to 
define the schema with those restrictions in mind.  But not all schemas are 
used in this way.

So, to summarize, I can see where you and Michael are coming from.  I'm just 
not totally convinced that it is the one and only way of doing things.

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML Schema to C++ data binding visit
 http://www.tech-know-ware.com/lmx/
 http://www.codalogic.com/lmx/
=============================================
Received on Friday, 18 May 2007 09:43:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:59 GMT