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

"Andy Clark" <andyclar@us.ibm.com> writes:

> I guess the real problem is the terseness of the XPath subset
> description. It's unclear from the text whether the following
> would be allowed:
> 
>   x//y/z
>   x//y//z
> 
> In other words, is the descendant axis only allowed to be
> used before the last element step? If so, then I agree that
> the implementation is simplified.

SOrry for the confusion -- yes, the _only_ proposed allowed use is .//x

> >> 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:
> >> [...]
> >
> > 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.
> 
> But they have different types and it's unclear which type
> should be used for the value space comparison. How can you
> keep a collection of values of different types and still
> perform the correct comparison to ensure uniqueness? I'm
> sorry to keep belaboring this point but it doesn't seem to
> make sense to me.

One implementation strategy would be to simply collect pairs of
[string,type], and to compare equal iff

 1) type1=type2 or one is derived from the other;
and
 2) the strings compare equal using type-appropriate comparison.

This approach intentionally avoids converting to values, which would
be a perfectly good alternative.

> And I have other questions regarding the subset...
> 
> Regarding field examples:
> 
> 1) Why is there a sample field specified as "ancestor::x/@"
>    when text at the bottom of the subset states directly
>    that the verbose form is not allowed and no reverse
>    axes are allowed? Does the subset intend to allow
>    people to specify fields outside of the element scope
>    by using the ancestor axis?
> 2) If ancestor is allowed, why not ".." as long as it is
>    followed only by "@" or "x/@"?
> 3) If ancestor is allowed, then we have another ambiguity
>    because there may be multiple elements on the ancestor
>    axis that match the path. Are all accepted (even if
>    they have different types)? Is only the first matched
>    value selected?
> 4) Why aren't predicates allowed for fields?

Same answer in virtually all cases -- the only use cases we had or
could envisage were restricted to the cases supported.

> Regarding selector examples:
> 
> 5) Did the subset intentionally leave out "." as a valid
>    selector expression?

Yes -- no plausible use case came to mind.

> 6) Why the explicit comment to "note only 1 level" for
>    the "x/y" example?
> 7) Is there a good reason that "[y]" is allowed? The
>    implementation is required to buffer the document in
>    order to support this. Take the following example:

Yes, I think we should give that one up.

> 9) Is there any plan to expand the allowed predicates
>    to include things like "[4]", "[position()<4]",
>    "[@a='hello']", etc?

No -- use cases again.

> In general:
> 
> 10) Is there any explicit limit to the length of XPath
>     expression used for selectors and fields? It seems
>     no but there are places where an explicit length is
>     mentioned (e.g. "note only 1 level" comment).

Yes -- in all cases what you see is what you get -- no longer paths
are allowed.

> Is there a newer subset description available? If so, please
> send that to me so that I can direct my questions to the most
> recent document.

Will do.

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 Tuesday, 20 February 2001 12:43:56 UTC