Hi,

Jim Stanley wrote:
> Just when I think I understand all this key/keyref stuff, another
> conundrum arises:
> 
> I have "categories" under my root, each with one or more "property
> definitions" consisting of name-value pairs.   Several of my categories
> have duplicate property definitions, something like below:
> 
> <root>
>   <category>
>     <name>Foo</name>
>     <propDef>
>         <name>Color</name>
>         <type>integer</type>
>     </propDef>
>     <propDef>
>       <name>Flavor</name>
>       <type>String</type>
>     </propDef>
>   <category>
>   <category>
>     <name>Bar</name>
>     <propDef>
>       <name>Color</name>
>       <type>integer</type>
>     </propDef
>     <propDef>
>       <name>Odor</name>
>       <type>String</type>
>     </propDef>
>   </category>
> </root>
> 
> If I define a primary key as follows:
> 
> <xs:key name="catElem.PK">
>   <xs:selector xpath="category/propDef"/>
>   <xs:field xpath="name"/>
> </xs:key>
> 
> XMLSpy tells me that the duplicate value "Color" has been already
> matched by the identity constraint.  If I configure it like so:

Here the target node is 'propDef'. The node-table being build on the
<root> element looks like this:

    Node       | Key-sequence
----------------------------
1. <propDef> | 'Color'
2. <propDef> | 'Flavor'
3. <propDef> | 'Color'
4. <propDef> | 'Odor'

The spec says:
"4.2.2 No two members of the ·qualified node set· have ·key-sequences· 
whose members are pairwise equal, as defined by Equal in [XML Schemas: 
Datatypes]."

... this is not satisfied, since the key sequences of 1. and 3. are
equal.


> <xs:key name="catElem.PK">
>   <xs:selector xpath="category"/>
>   <xs:field xpath="propDef/name"/>
> </xs:key>
> 
> it tells me that the field "propDef/name" matches twice within the
> scope of element 'category'.

Here the target node is 'category', this element as the context node
for the XPath of the field, resolves _two_ times to a node. This is
ruled out by:

"3 For each node in the ·target node set· all of the {fields}, with that 
node as the context node, evaluate to either an empty node-set or a 
node-set with exactly _one_ member, which must have a simple type... "

> I don't get this.  I thought after the last go-round that using just
> 'category' as the field selector created an automatic unique constraint
> per category.  I need to make sure that the combination of category name
> *plus* propDef/name (Foo + Color) is unique.  Can someone shed some
> light (again?)

I don't see a way to do this, since you want only the _first_ 'propDef'
child element of the 'category' element to be used as a field. This is
not expressible by the reduced XPath syntax of the indentity-constraint
mechanism. In your example the XPath 'propDef/name' resolves to multiple
nodes, which is not allowed. What you would need, would be
'propDef/name[1]' - unfortunately not supported.
If there was only one 'profDef' child, the following would create a key,
consisting of both 'name' values.

<xs:key name="catElem.PK">
   <xs:selector xpath="category"/>
   <xs:field xpath="name"/>	
   <xs:field xpath="propDef/name"/>
</xs:key>

Cheers,

Kasimier


From K.Buchcik@4... Tue Dec 14 16:20:51 2004
Received: from bart.w3.org ([128.30.52.40])
	by frink.w3.org with esmtp (Exim 4.34)
	id 1CeFPv-00