W3C home > Mailing lists > Public > xmlschema-dev@w3.org > July 2001

RE: key/keyref problem

From: Priscilla Walmsley <priscilla@walmsley.com>
Date: Tue, 3 Jul 2001 07:49:51 -0400
To: <vdv@dyomedea.com>, <priscilla@walmsley.com>
Cc: <xmlschema-dev@w3.org>
Message-ID: <003b01c103b6$4974ff20$3182ce0a@xmls>
Hi Eric,

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

Yes, I can see your point.  Perhaps it should be a best practice to define
your keys and keyrefs in the same scoping element unless you have some
special reason not to.

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

Yes, that's correct.  The node table for the key would not make it down to
the sub element.  The instance is definitely invalid.  I'm not sure that it
is considered an error in the schema - there doesn't seem to be a specific
constraint on this.  But, you would never want to write a schema that way
because the ref attribute could never have a valid value.

> Thanks
> Eric

Je vous en prie!

Priscilla Walmsley
Vitria Technology
Received on Tuesday, 3 July 2001 07:49:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:55:52 UTC