W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2011

Re: Classroom critique of XML Schema 1.1

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Sat, 19 Mar 2011 15:21:11 -0400
Message-ID: <4D850227.6070005@arcanedomain.com>
To: "Costello, Roger L." <costello@mitre.org>
CC: "xmlschema-dev@w3.org" <xmlschema-dev@w3.org>
I think Michael Kay has answered more clearly than I could. The other point 
I'd make is: if what you want is Schematron, then by all means use it. 
Schematron is exactly at the design point you seem to be looking for. 
Unlike DTDs and XSD, it is not particularly focused on context-free 
definitions of reusable elements, but rather on allowing one to express 
what one might call relatively arbitrary (not intended in a pejorative 
sense) constraints, in whatever terms are convenient.

My view is that what we tried to do in XSD 1.1 was not to provide a full 
replacement for Schematron, but rather to augment the 
element/attribute-oriented type system we have with Schematron-like 
constraints that would meet many needs that arise when using xsd types. For 
example, for an element like:

<width min="3" max="4" />
<height min="6" max="8"/>

You might want a measurement type

<xs:element name="width" type="measurement"/>
<xs:element name="height" type="measurement"/>

where there measurement type requires min and max to be integers, and max 
to be >= min. That's just the sort of thing xsd 1.1 assertions are intended 
for, and it's quite intentional that the constraints on measurements are 
independent of either element names (width, height) or of their position in 
some container tree.

Yes, you could allow the full flexibility of Schematron for XSD 1.1 
assertions.  As MSM has indicated, we considered that, and we were well 
aware that it would bring you, well, all the convenience and power of 
schematron. MK has outlined some of what you would lose.

Bottom line: if Schematron is what you want, by all means use it, either 
alone, or in conjunction with XSD.

Noah

On 3/19/2011 12:45 PM, Costello, Roger L. wrote:
> Hi Noah,
>
> You wrote:
>
>> If someone wrote in XQuery a function that required an argument of type
>> "xs:string:", then static type checking could be used to prove that
>> passing the (value of) a Publisher element would be ok.
>
> Isn't static type checking done on the<Publisher>  element in the XML instance document? Consider this XML instance:
>
>      <Publisher>Wrox Press</Publisher>
>
> Static type checking determines whether the value in the<Publisher>  element (Wrox Press) falls within its set of allowable values as specified by the associated XML Schema.
>
> In XML Schema 1.1 the determination of the set of allowable values for<Publisher>  may require looking in multiple places, e.g.,
>
>      <element name="Publisher" type="string" />
>
>      <assert test="string-length(.//Publisher) le 140" />
>
> Thus, static type checking involves checking that the value of<Publisher>  is not longer that 140 characters.
>
> In other words, the data type of<Publisher>  is not a string; it is a string that is constrained to less than or equal to 140 characters in length.
>
> Yes?
>
> /Roger
>
>
Received on Saturday, 19 March 2011 19:21:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 19 March 2011 19:21:43 GMT