Re: Alternative approach for key/keyref

[James Clark <jjc@jclark.com>]

--On 12 July 2001 09:14 +0900 Murata Makoto <mura034@attglobal.net> wrote:

> James Clark wrote:
>
>> It's certainly much weaker and in my view much more ad-hoc.
>
> I think yours is already very weak and ad-hoc.

It's the strongest and least ad-hoc restriction on <key> and <keyRef> that 
we have been able to find so far. If you have a stronger and less add-hoc 
one, I would be delighted to hear it.  If you perceive it to be weak and 
ad-hoc, then I would suggest that a constructive response is to try to make 
it stronger not weaker.

>  Rather than pretending
> to have a generalized solution, I think that we should honestly admit
> that our mechanism in RELAX NG is very weak and ad-hoc and is only
> slightly better than ID/IDREF.

I am all in favour of clear statement that this is not intended to be a 
generalized solution. However, I see no incompatibility between such a 
statement and our current approach.

From a practical perspective, I believe what we have is a considerable 
improvement over ID/IDREF.

> I don't think inference rules are
> absolutely  required.  7.2 does not have any inference rules and this is
> just fine.

I agree that inference rules are not absolutely required.  However a fair 
comparison of the relative complexity of two approaches requires that they 
be expressed with similar levels of formality.

I just don't believe that your approach really is significantly simpler.

As I understand it, you propose that for determing key-ambiguity we should 
only consider

1. The name of the attribute or element containing the key, and

2. The name of its parent element

in other words the last 2 segments on the ancestry path.  Why consider 2 
segments only? Why not 1? Why not 3? Why not 42?  It's just so arbitrary. 
Once you have more than one, you have almost all the implementation 
complexity of the current approach, because you have to consider 
intersection of name classes. But clearly just considering the name of the 
attribute itself is not sufficient (and is incompatible with XML 1.0).

Your approach would yield an ambiguity in the following case:

<ns1:foo>
  <bar>
    <baz>key</baz>
  </bar>
</ns1:foo>

<ns2:foo>
  <bar>
    <baz>not key</baz>
  </bar>
</ns2:foo>

where ns1 and ns2 are separate namespaces and baz in ns1 is a key but baz 
in ns2 is not.  I think that's quite wrong. Personally, I don't much care 
for this style of using namespaces, but there are plenty of people who do.

James