- From: Arnold, Curt <Curt.Arnold@hyprotech.com>
- Date: Thu, 8 Feb 2001 09:51:12 -0700
- 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 UTC