- From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
- Date: Wed, 22 Jul 2009 11:40:21 -0600
- To: "Costello, Roger L." <costello@mitre.org>
- Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, "xmlschema-dev@w3.org" <xmlschema-dev@w3.org>
On 21 Jul 2009, at 13:56 , Costello, Roger L. wrote: > > > Can you provide an example that illustrates the usefulness of > xs:error? > You might want to examine the work of Fabio Vitali, Paolo Marinelli, and Claudio Sacerdoti Coen on SchemaPath, which provided the initial impetus for the conditional type assignment construct of XSD 1.1; in a manner of speaking, XSD 1.1 acquired xsd:error from SchemaPath. Not all of their examples are possible with the conditional type assignment feature as it is now defined, because the conditions expressible in type XSD 1.1 alternatives are weaker than the tests of SchemaPath, in order to ensure that in XSD 1.1 types may be assigned to elements no later than the moment their start-tag has been fully read. But some examples are fairly nice. See, for example, "SchemaPath, a minimal extension to XML Schema for conditional constraints", WWW 2004. http://tesi.fabio.web.cs.unibo.it/twiki/pub/Tesi/SchemaPath/WWW04-SchemaPath.pdf A schema for XSLT, for example, might enforce a rule that XSLT templates must have either a name or a match attribute by declaring the xsd:template element thus: <element name="template"> <alternative test="@name" type="xslt:named-template"/> <alternative test="@match" type="xslt:template"/> <alternative type="xsd:error"/> </element> The XSLT spec does not, I think, in fact forbid template elements with neither name or match attributes, so this declaration goes beyond what that spec requires; you might write a schema like this in order to be more strict than the spec requires you to be. Another example: in schema documents, an 'element' element appearing in a content model must have either a 'name' attribute, or a 'ref' attribute, and not both. That constraint cannot be expressed in XSD 1.0, but it can be captured with conditional type assignment: <element name="element" type="element"> <alternative test="@name" type="localElement"/> <alternative test="@ref" type="elementRef"/> <alternative type="error"/> </element> The same effect cannot be achieved in XSD 1.0. In XSD 1.1, it could also be achieved by assertions; indeed, any type alternative which assigns xsd:error could be replaced by an assertion (attached, possibly to more than one type) negating the test. In both cases, the xsd:error fits more naturally (it seems to me) into the pattern of conditional type assignment. HTH Michael Sperberg-McQueen -- **************************************************************** * C. M. Sperberg-McQueen, Black Mesa Technologies LLC * http://www.blackmesatech.com * http://cmsmcq.com/mib * http://balisage.net ****************************************************************
Received on Wednesday, 22 July 2009 17:40:59 UTC