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

"Andy Clark" <andyclar@us.ibm.com> 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.

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 Thursday, 22 February 2001 06:41:28 UTC