RE: key/keyref problem

Hi Priscilla ,
 
Please forgive my ignorant. I didn't know that you are a W3c board
member. I thought you are, just like me, a frustrated XSD-spec reader,
voicing your point of view. I only know Henry Thompson as the person who
clarify the spec issues. I was wishing he will say something here..... 
 
I wish I can write things shorter, in case you have no time to read the
whole mail,  please see my last conclusion understanding at the end.
~~~~~~~~~~~~ BEGIN skipable
OK, simply put, we agree with 2 easy cases, lets put it here ...
case 1. if key and keyref are declared on the same level under the same
scope it should work
<r>
    key=1
    keyref=1
    <a/>
    <b/>
</r>
 
case 2. if key and keyref are declared in different scope it, should
fail.
<r>
    <a>
        key=1
    </a>
    <b>
        keyref=1    
    </b>
</r>
 
>> 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'.
 
1. If scope of the key 'B' is the element 'b', then how can the <keyref
refer="B">, which is outside of scope of element 'b', see the <key
name="B"> ? 
2. Assume that we follow your logic... then you are are saying ... 
            if keyref=1, then validation fail.
            if keyref=2, then validation success.
    <root>
        keyref= (1 | 2)
        <b>
            key=1
            key=2
        </b>
        <b>
            key=1
            key=3
        </b>
    </root> 
 
However, since the <key> inside element <b> is scopped to <b>, you will
need to maintain EITHER the key-set (pairs of key-value) of <b>s, match
the keyref to each table and fail if there is a duplicated key-set, OR
put all key-set of <b>s' into a global table in additional to the
individual local key-set tables, and fail the validation if a keyref
point to a duplicate key-set in the global table ( if so, then the
senario 2. above will also work?). 
~~~~~~~~~~~~END skipable
 
CONCLUSION of my understanding:
1. What I see is happenning:
It seems as one cannot point to the spec where it explain such
requirement and the steps it takes to attack such implementation
(un-expensively) without ambiguity for all implementors.
 
2. What I am thinking:
In W3c point of view, should people implement IDConstraint, in a manner
as do at your own risk, at this time? Or, should W3c call for a hault on
this particular section of the spec until further notice and
clarification? Please understand that, I am worry about the conformance
issues, I don't want our or other implementations fighting over
something that is not clear defined in the near future.
 
3. What I understand your interpretation:
In short, we need following 2 rules.... with them the confusion above
will be clarified. (do I have it correctly)?
    A <key A> is referable by all the <keyref A>s from only
ancestor-or-self of the element that host the <key A>. 
    A <keyref A> can only refer to one of the <key>s defined in the
decendent-or-self of the element that host the <keyref A>. 
 
Thank you,
-Aung