[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Alternative approach for key/keyref
--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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC