Re: key/keyref problem

Hi Priscilla,

Priscilla Walmsley wrote:

.../...
 
> The important word is "children."  In other words, the node table entries
> are propagated upward to the parent elements.

Yes, I had get it now!

This is so unusual in the XML world, that I must have skipped this as
impossible ;=) !

The scope of "declarations" or properties (xml:*, namespaces and to some
extent XSLT variables) is usually (or even always ?) going toward
children on the descendant-or-self axis and here we have definitions
(key or unique) which definition scope is ancestor-or-self. 

Thanks for pointing this out.

> > Furthermore, I would also think that allowing scoping element
> > of the key
> > or unique definition to be a child of the scoping element of
> > the keyref
> > still more confusing.
> >
> > If I understand what you mean correctly, it's allowing cases such as:
> >
> > <root>
> >  <sub>
> >    <key id="1"/>
> >    <key id="2"/>
> >  </sub>
> >  <sub>
> >    <key id="2"/>
> >    <key id="3"/>
> >  </sub>
> >  <keyref ref="2"/>
> > </root>
> >
> > .../...
> >
> > <xs:element name="root">
> >
> >   <xs:element name="sub">
> >    .../...
> >    <xs:key name="key">
> >     <xs:selector xpath="key"/>
> >     <xs:field xpath="@id"/>
> >    </xs:key>
> >   </xs:element>
> >
> >   <xs:keyref name="keyref" refer="key">
> >    <xs:selector xpath="keyref"/>
> >    <xs:field xpath="@ref"/>
> >   </xs:key>
> >
> > </xs:element>
> >
> > where one cannot determine which key is referred by a keyref.
> >
> 
> That schema is fine.  The instance is not valid because, as you point out,
> the keyref does not reference a single key sequence. If your instance had
> contained <keyref ref="1"/> it _would_ be valid. This is also described in
> section 3.11.5, where it describes conflict resolution for the node table:

Yes, I had carefully chosen my value ;) ...

This is something I find disturbing, but it's probably as subjective and
philosophical than objective.

I find kind of unnatural the fact that a keyref adds a constraint not
only to the references but also to the distribution of the values in the
key or unique that's being referenced.

If the designer that has been designing the "sub" element has decided
that the key should be unique at this level only, I think that it's
error prone to reference this key in one of the parents.

If the designer in charge of the "root" element wants to reference
sub/key/@id, I think that it would be cleaner if he had to define
another key for this. 

Otherwise, we have a situation were the key is constrained to be
globally unique when and only when it's referenced and, again, it's
adding constraints on the key based on the way it's used.
 
> "Potential conflicts are resolved by not including any conflicting entries
> which would have owed their inclusion to clause 1 above. Note that if all
> the conflicting entries arose under clause 1 above, this means no entry at
> all will appear for the offending ·key-sequence·. "
> 
> > This is also troubling to see that the scope of a key is
> > wider than the
> > element in which it is defined and I would have found it less
> > confusing
> > if it would have been the scoping element of the keyref that
> > could have
> > been a child of the scoping element of the key or unique.
> 
> It may help to think of a relational database analogy, where keys are
> primary keys and keyrefs are foreign keys.  A primary key is defined on a
> particular table.  Foreign keys can then reference that primary key from
> other tables in the database (a broader scope).

I did think of this analogy (one doesn't work during 6 years for a RDBMS
vendor without keeping some scars ;=) ) and that might be why I find the
above shocking.

When you define a key in a RDBMS, referencing this key doesn't add
constraints to the key.

> Does that make more sense?

It does help a lot, though... I have a new question!

What about the "reverse" ?

<root>
   <key id="1"/>
   <key id="2"/>
   <key id="3"/>
 <sub>
   <keyref ref="1"/>
   <keyref ref="2"/>
 </sub>
 <sub>
   <keyref ref="2"/>
   <keyref ref="3"/>
 </sub>
</root>

.../...

<xs:element name="root">

  <xs:element name="sub">
   .../...
   <xs:keyref name="keyref" refer="key">
   <xs:selector xpath="keyref"/>
   <xs:field xpath="@ref"/>
  </xs:key>
 </xs:element>

 <xs:key name="key">
  <xs:selector xpath="key"/>
  <xs:field xpath="@id"/>
 </xs:key>

</xs:element>

To me, this would seem less controversial and more "natural". 

Does I read the spec correctly if I say that there would not be any
"·node table· associated with the {referenced key} in the
[identity-constraint table] of the element information item" since the
tables get propagated to their parents and that this construct is
illegal per the rec?

Thanks

Eric 
 
> Priscilla Walmsley
> Vitria Technology

-- 
See you at XTech in San Diego.
             http://conferences.oreillynet.com/cs/os2001/view/e_spkr/790
------------------------------------------------------------------------
Eric van der Vlist       http://xmlfr.org            http://dyomedea.com
http://xsltunit.org      http://4xt.org           http://examplotron.org
------------------------------------------------------------------------

Received on Tuesday, 3 July 2001 02:52:47 UTC