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

Henry,

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

Thanks for the clarification.

>> But they have different types and it's unclear which type
>> should be used for the value space comparison. How can you
>> [...]
>
> One implementation strategy would be to simply collect pairs of
> [string,type], and to compare equal iff

Okay, I can see how this could work but it seems counter-
intuitive to me to have a collection of field values whose
types can change. It's like getting a result set from a
database query and having the columns in each row change
their types willy nilly (to use a technical term).

To ensure the types, though, we'd have to eliminate the
use of //, *, and ancestor::x/@. Which, BTW, I would be
in favor of. :)

>> 5) Did the subset intentionally leave out "." as a valid
>>    selector expression?
>
> Yes -- no plausible use case came to mind.

This rules out the possibility of ever having attributes on
the declaring element be considered as a unique, key, or
keyref value.

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

Good.

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

This decision seems a little bit extreme and limits the
types of selectors and fields that can be constructed.

In general, the restricted path length, the choice to
disallow the verbose form (except for ancestor::x/@),
and the restriction of only allowing predicates at the
end of selectors seems unnecessary since they do not
impact the performance of validating documents or
cause undue implementation difficulties. Can you shed
some light on these particular decisions?

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

Great. I'll be looking forward to reading the new draft.

-AndyC

P.S. What was the use case for ancestor::x/@?

Received on Wednesday, 21 February 2001 01:45:10 UTC