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

"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
expression.

> 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.

ht
-- 
  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