- From: Arnold, Curt <Curt.Arnold@hyprotech.com>
- Date: Thu, 13 Jul 2000 14:08:48 -0600
- 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 UTC