Key and keyref ambiguity

[James Clark <jjc@jclark.com>]

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