W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2000

xsd:prohibit to prevent stupid tricks using xsd:unique

From: Arnold, Curt <Curt.Arnold@hyprotech.com>
Date: Thu, 13 Jul 2000 14:08:48 -0600
Message-ID: <B2C1451A181BD411B88A00E018C1C19C08A6F5@THOR>
To: "'www-xml-schema-comments@w3.org'" <www-xml-schema-comments@w3.org>
Stupid tricks involving xsd:unique could be used to prohibit
a particular pattern from appearing in an instance document.  
Since prohibiting a pattern would seem to be of general use,
it would be beneficial if a specific constraint were added
instead of allowing the stupid tricks to become widespread.

For example, the prohibition that  an "element" element with a ref attribute
cannot appear as an immediate child of schema could be enforced using a
unique stupid trick like:

<xsd:unique>
	<xsd:selector>/|//xsc:schema/xsc:element[@ref]</xsd:selector>
	<xsd:field>Can't have ref at top level</xsd:field>
</xsd:unique>

Since the selector matches the document root, the constant value is added
to the table of field values.  If any element matches the other pattern,
then a constraint violation would be triggered.

I'd suggest that adding an explicit <xsd:prohibit> be added (unless xsd:unique is
removed in a simplification push) with a content model like xsd:unique but without the
fields (which would require moving field from keybase to local complex types for unique, key and keyref).  xsd:prohibit would be used like:

<xsd:prohibit>
	<xsd:selector>//xsc:schema/xsc:element[@ref]</xsd:selector>
</xsd:prohibit>

This would have the requires no additional facilities than <xsd:unique>,
would result in clearer schemas and more efficient validation.
Received on Thursday, 13 July 2000 16:21:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:12:47 GMT