W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2001

Poorly researched observations on <xsd:key>, <xsd:keyref> and <xs d:unique>

From: Arnold, Curt <Curt.Arnold@hyprotech.com>
Date: Thu, 8 Feb 2001 09:51:12 -0700
Message-ID: <B2C1451A181BD411B88A00E018C1C19C08AA6E@THOR>
To: "'xmlschema-dev@w3.org'" <xmlschema-dev@w3.org>
Cc: "'www-xml-schema-comments@w3.org'" <www-xml-schema-comments@w3.org>
I've been consumed by other things recently but I had a little time to attempt to do some small experimentation of the implementation of <xsd:key>, <xsd:keyref> and <xsd:unique> and I wanted to pass
on observations.

First, the description of the <xsd:selector xpath=""/> is fairly roundabout.  It says that it is an xpath expression whose result has this property and that property property.  Of all the types of
XPath expressions, it would seem to me that the only types that can fulfill the requirement would be a PathExpr or a UnionExpr (which also includes PathExpr).  So if you started saying that {selector}
was:

An UnionExpr, as defined in XPath

instead of:

A XPath expression, as defined in XPath

You wouldn't need as much text disallowing all the other types of XPath expressions and would only need to describe the disallowed axis, etc.

Since the selector attribute appears to be only a restricted subset of an XPath UnionExpr, instead of using a simple type XPathApprox in the schema for schemas, I'd use distinct simple types for
selector's xpath and field's xpath, calling them, for example, selectorXPath and fieldXPath and eliminate the temptation to make XPathApprox a generic XPath type.

XSV didn't like <xsd:selector xpath="text()"/>.  It seemed to be within the spirit of the XML Schema description of the allowable values for the xpath, however I don't think it fulfills the
XPathExprApprox's pattern.  It definitely would appear to be a desirable capability to use the text content of an element as a key or unique constraint.

The restriction on the field returning a one element node set would appear to eliminate field that returned a string like:

<xsd:field xpath="translate(@name,'ABCDEFGHIJKLMNOPQRSTUVWXYZ','abcdefghijklmnopqrstuvwxyz')"/>

I do not think that prohibiting the use of functions in the field xpath simplifies implementation since I do not see a prohibition on using expressions in predicates so translate() et all would have
to be supported for:

<xsd:selector xpath="*[translate(@yesno,'YESNO','yesno')='yes']"/>
Received on Thursday, 8 February 2001 11:56:04 GMT

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