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

----- Original Message -----
From: "Andy Clark" <andyclar@us.ibm.com>
To: "Jim Trezzo" <jim.trezzo@oracle.com>
Cc: <www-xml-schema-comments@w3.org>; "Trezzo,Jim" <JTREZZO@US.ORACLE.COM>
Sent: Friday, February 16, 2001 5:44 AM
Subject: Re: CR-49: XPath subset: Use subset not full XPath for Key and
KeyRef


>
> Jim,
>
> The subset of XPath proposed for XML Schema by the working group does not
> go far enough in limiting the allowed expressions. In fact, further
> thoughts on the problem make me wonder whether using XPath at all for
> identity constraints in Schema is a good idea. The following problems
> highlight some of my concerns.
>
> Problem 1: Qualifying Elements and Attributes
>
> I asked for a clarification on this issue from the general XML Schema
> community on the xmlschema-dev mailing list with no response. Perhaps I
can
> get a response from the www-xml-schema-comments readers.
>
> The problem involves an inconsistency between how element names are
> referenced when the grammar specifies a target namespace. In this case,
all
> references to elements must be fully qualified. For example:
>
>   <schema xmlns='...' targetNamespace='NS' xmlns:a='NS'>
>     <element name='foo'>
>       <...>
>         <element ref='a:bar'/>
>       </...>
>     </element>
>     <element name='bar'>
>       <.../>
>     </element>
>   </schema>
>
> However, an example of using identity constraints in the primer
(report.xsd
> in section 5) does *not* qualify the XPaths used when defining selectors
> and fields. For example:
>
>   <schema xmlns='...' targetNamespace='NS' xmlns:a='NS'>
>     <element name='foo'>
>       <.../>
>       <unique>
>         <selector xpath='bar'/>
>         <field xpath='@baz'/>
>       </unique>
>     </element>
>     <.../>
>   </schema>
>
> 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 )

The selector in the above example should be a:bar

>
> Problem 2: Ambiguous Element Step
>
> Allowing the use of the descendant:: axis in XPaths used for selectors and
> fields has several problems. The first relates to the ability of
> implementations to support identity constraints in an efficient manner.
> Without this axis, implementation of identity constraints is both
> straightforward and efficient (even for streaming XML such as SAX).
> However, allowing the descendant axis complicates the implementation for
> serial processors.
>
> The second problem relates to the fact that field values must be compared
> in the value space based on the attribute/element's datatype. However, the
> descendant axis introduces ambiguity. For example:
>
>   <element name='foo'>
>     <...>
>       <element name='bar'>
>          <...>
>            <element name='bar'/>
>          </...>
>       </element>
>     </...>
>     <unique>
>       <selector xpath='.//bar'/>
>       <field xpath='@baz'/>
>     </unique>
>   </element>
>
> Which bar element does the selector match? Both bar elements could declare
> a baz attribute with different types.

[MJG]

Man goes to a doctor and says "Doctor it hurts when I do this". Doctor
replies "Don't do that"

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


>
> Problem 3: Anonymous Element Names
>
> This is perhaps the most troubling because XPath is not capable of
> distinquishing between globally declared elements and anonymous elements
in
> a target namespace where the form default is unqualified.

[MJG]
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.

Martin Gudgin
DevelopMentor

Received on Friday, 16 February 2001 04:02:50 UTC