[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Key and keyref ambiguity
I think a more restrictive constraint is a little bit more natural than the one that Murata-san proposed. Specifically, - for an attribute, the key-type can depend on the attribute name and the element name (this is the same as Murata-san's proposal) - for an element, the key-type can depend on the element name only (in Murata-san's proposal, if I understood correctly, it could also depend on the parent element's name) This consistently reflects an XML 1.0 world-view in which the content of attributes can be dependent on both the attribute name and the element name whereas the content of an element can depend only on the element name. This also avoids the need to have special treatment of the document element. With the reformulation of key ambiguity in the draft I just posted, this more restrictive constraint can be expressed with just a few changes. Instead of p_1 [n]_e p_2 (meaning p_1 has p_2 has a child element pattern for name n) we have [n}_e p (meaning p is a possible element pattern for name n) Then change the (element) rule from p_1 contains <ref name="ln"/> deref(ln) = <element> nc p_2 </element> n in nc ---------------------------------------------------------------------------- ---- p_1 [n]_e p_2 to deref(ln) = <element> nc p </element> n in nc ----------------------------------------------- [n]_e p and change (element compete 2) from p_1 ~_e p_2 p_1 [n]_e p_3 p_2 [n]_e p_4 -------------------------------------------- p_3 ~_e p_4 to [n]_e p_1 [n]_e p_2 ---------------------- p_1 ~_e p_2 That's it. Same number of inference rules. Two inference rules each have one fewer antecedent. I still prefer the current constraint. James
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC