Re: meaning of dot in xpath expressions in keys?

Hi Gary,

> I need to make sure that an attribute in a particular element has
> the same value as an attribute in its child element. In the
> following example the fact that the names of the processes have been
> accidentally swapped over should be queried by the schema.

Hey, that's really cunning! I hadn't thought of using identity
constraints like that.

> The following schema works in XML Spy but not the Microsoft XML component
> MSXML4 beta 2 (July).
[snip]
> <xs:key name="ContextNameSingleNodeKey">
>     <xs:selector xpath="."/> <!--     What's the meaning of the dot -->
>     <xs:field xpath="@name"/>
> </xs:key>
> <xs:keyref name="ProcessNameMustBeSameAsContextName"
> refer="ContextNameSingleNodeKey">
>     <xs:selector xpath="Process"/>
>     <xs:field xpath="@name"/>
> </xs:keyref>
>
> I think XML Spy has got it right on this occasion. It looks like
> MSXML4 thinks that the dot in ContextNameSingleNodeKey means "this
> node and all sibling nodes of the same type.

It should mean 'this node'. If you wanted to do all sibling nodes,
you'd have put the identity constraint in the element declaration for
the Repository element. So I think MSXML4 has got it wrong.

By the way, in:

>         <xs:unique name="ContextNamesUnique">
>             <xs:selector xpath="./Context"/>
>             <xs:field xpath="@name"/>
>         </xs:unique>
>         <xs:unique name="ProcessNamesUnique">
>             <xs:selector xpath=".//Process"/>
>             <xs:field xpath="@name"/>
>         </xs:unique>

you'd probably be better off (a) going down step by step to the
Process elements rather than searching all descendants [it's more
efficient] and (b) removing the ./ at the beginning of the paths [it's
superfluous when you're selecting children] i.e.:

  <xs:selector xpath="Context" />
  <xs:selector xpath="Context/Process" />

> On another, related note: is anybody else finding that many of the
> relationship/ constraints/rules in their data are not expressible
> using XML schema? Does anybody know if the key/keyref mechanism is
> going to be improved or supplemented in any way so that XML schema
> can describe any document/database rather than just a subset?

The kind of constraint that you're expressing here is what some people
refer to as 'co-constraints' where the value/presence of a particular
element/attribute relies on the value/presence of another
element/attribute. It's recognised that XML Schema isn't very good at
co-constraints; in general you're better off using RELAX NG or
Schematron in conjunction with XML Schema if you want to validate
them.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

Received on Tuesday, 16 October 2001 17:21:31 UTC