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

Henry,

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

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

Keys and key references can be declared in different
element decls, as allowed by the spec and shown in the
example. Can this be removed simply by defining the key
and its reference in the most outer-scoped element
declaration? And if so, then do we need to allow cross
declaration references for key and keyRef?

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.

What kind of feedback are you receiving from other people
that are trying to implement identity constraints within
a serial parser?

-AndyC

Received on Thursday, 22 February 2001 01:43:53 UTC