- From: Pete Cordell <petexmldev@tech-know-ware.com>
- Date: Fri, 18 May 2007 10:42:18 +0100
- 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 UTC