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

RE: key/keyref problem

From: Priscilla Walmsley <priscilla@walmsley.com>
Date: Fri, 17 Aug 2001 14:24:33 -0400
To: "'Aung Aung'" <aaung@microsoft.com>, <xmlschema-dev@w3.org>
Message-ID: <007101c12749$e19f1680$1ab0153f@xmls>
Hi Aung,

> A:   (this is what I think the spec says how it should work, here the
scope of the key 'A' is element a, and all keyref
> under the scope will see key A)
> <root>
> <element name="a">
>    <key  name="A">
>    <element name="b">
>         <keyref    refer="A">
>    </element>
> </element>
> </root>

No, this is not how the spec works, despite the erroneous example in the

> B:  (this is what you and Eric come agreeement on how it should work, if
that is the case, how do you defind the scopeof
> the key 'B'? it cannot be all the way to the root element, can it? )
> <root>
> <element name="a">
>    <keyref   refer="B">
>    <element name="b">
>         <key   name="B">
>    </element>
> </element>
> </root>

The scope of the key 'B' is the element 'b'.  All values of the field(s)
have to be unique within an instance of 'b'.

> How about this: should this work? (  how/why?)
> C:
> <root>
> <element name="a">
>         <key   name="A">
> </element>
> <element name="b">
>         <keyref   refer="A">
> </element>
> </root>

No, because the key and keyref have to be defined in the same element, or
the key has to be defined in a child element.  Neither is the case here.

> The fact that two of you come to an agreement that is quite differ from
what the spec said

The only place the spec disagrees is the erroneous example in the Primer.
The prose of the Primer does not talk about the scope of identity
constraints at all, and the prose of Structures confirms our interpretation.

> and no one from the standard
> come out to (approve/disapprove) it is bad.

I am a member of the W3C XML Schema Working Group, if that's what you mean
by someone "from the standard".

> The standard should give out clear examples, not all possible cases, but
at least several cases that will clarify these
> confusion, so that all implementors will not have different implemetation
and not have to fight in the future.

I agree that the specification should be more clear on this subject, and
provide correct examples. Certainly the invalid example will be an item for
the errata list.

Priscilla Walmsley
Vitria Technology
Received on Friday, 17 August 2001 14:22:31 UTC

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