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

"Andy Clark" <> writes:

> > How change?  Each result of a field query has whatever type it has.
> > Note this is a very marginal case, in that using a path expr to define
> > a field that actually may resolve to two different elements/attribute
> > with the same name is pretty unlikely.
> But if we disallow the use of // then we can guarantee
> the types of the field values for an identity constraint.
> I think that this is a "good" thing. :)

Not so.  The _selector_ pattern may have identified elements with
different types, so the same, trivial, field path may pick up
e.g. attributes with different types.

> >> P.S. What was the use case for ancestor::x/@?
> >
> > See the example in the spec. itself -- when you actually want
> > reference into multiple scopes, you'll need a property of the scoping
> > element to distinguish one scope from another.
> The example in the current dot-release of the spec does
> not follow the XPath subset and can not be implemented
> without buffering the document. This can be fixed, though,
> by changing the grammar such that the stateCode element
> is an attribute of the containing state, instead. (I
> still don't like its use, though.)

Indeed.  Exactly how to treat this case is under discussion in a joint 
XSL/Schema WG task force.

> What is the current opinion regarding the question
> posted to the xmlschema-dev mailing list regarding the
> use of substitution groups and/or xsi:type? Following the
> example, I think that people would actually define the
> sample grammar such that each person can have vehicles of
> all types (cars, motorcycles, trucks, etc) w/o requiring
> each element to be part of the content model *and* w/o
> requiring the duplication of keyRef information for each
> of these elements.

I've answered those questions directly.  In brief, until we have XML
Schema so that we can have a type-aware XPath, key/keyref will have to 
use element/attribute XPath expressions, which will always be
interpreted _as per XPath_, so no funny business with xsi:type or
substitution groups has any impact -- either the pattern matches the
source document's infoset, or it doesn't.  End of story.  Only slight
wiggle is that default values are available.

  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:

Received on Thursday, 22 February 2001 06:41:28 UTC