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

Martin,

>> Is this inconsistency intentional? In other words, when the grammar
>> has a target namespace, should we assume that unqualified steps in
>> the XPaths are in the target namespace? What about when the content
>> models are a mix of target namespaces?
>
> [MJG]
> My understanding is that this is an error in the Primer example. XPath
> clearly states that unqualified names in an XPath expression *always*
refer
> to elements ( and/or attributes ) which are unqualified ( in no
namespace,
> have a namespace name of '' ). They do *not* refer to elements in the
> default namespace ( if any )

Finally someone stands up and gives an explanation for the
inconsistency between the primer example and general usage
of qualified names for XPaths in Schema. Thank you!

> The selector in the above example should be a:bar

This was my interpretation but it was inconsistent with
the primer. Fixing this in the primer will help.

> Either make one of the bar elements ( I'd go for the outer one )
qualified
> or give it a different name or make sure it is of the same type as the
inner
> bar element.

I disagree. I don't think that the XPath syntax used for
specifying selectors and fields should determine how
people create their content models; instead, the syntax
used should be able to express all of the content models
possible in XML Schema without ambiguity.

> I don't think that just because .//x allows people to build 'bad'
selectors
> means it should be removed. It also allows people to build 'good'
selectors.

I'm still concerned about the ambiguity in determining
the datatype for field value comparison.

> I don't understand this statement. What is an 'anonymous element'? Do you
> mean an uqualified element ( one in no namespace )? XPath can easily
> distinguish between qualified foo and unqualified foo. To match qualified
> foo requires a prefix mapping to the namespace name for foo and for that
> prefix to be used in the XPath expression. To match unqualified foo
*don't*
> specify a prefix in the XPath expression.

You are right but my comment was based on the previous
inconsistency in the use of XPath in the primer. Now
that it is cleared up, the problem disappears.

-AndyC

Received on Sunday, 18 February 2001 22:15:35 UTC