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

Re: CR-49: XPath subset: Use subset not full XPath for Key and KeyRef

From: Henry S. Thompson <ht@cogsci.ed.ac.uk>
Date: 19 Feb 2001 13:36:51 +0000
To: "Andy Clark" <andyclar@us.ibm.com>
Cc: Jim Trezzo <jim.trezzo@oracle.com>, www-xml-schema-comments@w3.org, "Trezzo,Jim" <JTREZZO@US.ORACLE.COM>
Message-ID: <f5b3ddakd58.fsf@cogsci.ed.ac.uk>
"Andy Clark" <andyclar@us.ibm.com> writes:

> The subset of XPath proposed for XML Schema by the working group does not
> go far enough in limiting the allowed expressions. In fact, further
> thoughts on the problem make me wonder whether using XPath at all for
> identity constraints in Schema is a good idea. The following problems
> highlight some of my concerns.
> Problem 1: Qualifying Elements and Attributes
> I asked for a clarification on this issue from the general XML Schema
> community on the xmlschema-dev mailing list with no response. Perhaps I can
> get a response from the www-xml-schema-comments readers.
> The problem involves an inconsistency between how element names are
> referenced when the grammar specifies a target namespace. In this case, all
> references to elements must be fully qualified. For example:
>   <schema xmlns='...' targetNamespace='NS' xmlns:a='NS'>
>     <element name='foo'>
>       <...>
>         <element ref='a:bar'/>
>       </...>
>     </element>
>     <element name='bar'>
>       <.../>
>     </element>
>   </schema>
> However, an example of using identity constraints in the primer (report.xsd
> in section 5) does *not* qualify the XPaths used when defining selectors
> and fields. For example:
>   <schema xmlns='...' targetNamespace='NS' xmlns:a='NS'>
>     <element name='foo'>
>       <.../>
>       <unique>
>         <selector xpath='bar'/>
>         <field xpath='@baz'/>
>       </unique>
>     </element>
>     <.../>
>   </schema>

As Martin correctly pointed out, this is a primer bug and has been
fixed.  Sorry for the confusion.  XPath expressions in
fields/selectors are interpreted as per XPath 1.0, so to match
qualified names in the document, prefixes are required in the XPath

> Problem 2: Ambiguous Element Step
> Allowing the use of the descendant:: axis in XPaths used for selectors and
> fields has several problems. The first relates to the ability of
> implementations to support identity constraints in an efficient manner.
> Without this axis, implementation of identity constraints is both
> straightforward and efficient (even for streaming XML such as SAX).
> However, allowing the descendant axis complicates the implementation for
> serial processors.

I don't understand this point.  Implementing the .//name is trivial in 
streaming mode, and corresponds exactly to what you already have to do
to implement ID/IDREF.

> The second problem relates to the fact that field values must be compared
> in the value space based on the attribute/element's datatype. However, the
> descendant axis introduces ambiguity. For example:
>   <element name='foo'>
>     <...>
>       <element name='bar'>
>          <...>
>            <element name='bar'/>
>          </...>
>       </element>
>     </...>
>     <unique>
>       <selector xpath='.//bar'/>
>       <field xpath='@baz'/>
>     </unique>
>   </element>
> Which bar element does the selector match? Both bar elements could declare
> a baz attribute with different types.

It matches both, that's the whole point of having a scoped selector.
And what's the problem, anyway?  You've asserted by the above that
'bar' elements are unique wrt their 'baz' attribute's value.  So you
keep a table of bar attribute's 'baz' attribute's values, and throw an 
error if you hit one twice.  Seems straightforward to me.

  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/
Received on Monday, 19 February 2001 08:36:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:54 UTC