[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Alternative approach for key/keyref
Your "rewrite" is missing all the inference rules for the "contains" relation which you use in the (contains) rule. To define keyType properly you need another 6 inference rules. However, I find it rather unsatisfactory to formalize only the notion of key type and leave key ambiguity defined only informally. I don't see how that will help a reader. If a reader can understand the formalization of key type, then they can understand a formalization of key ambiguity. Your informality leaves things unspecified. For example, given competing patterns <attribute> nc1 p1 </attribute> <attribute> nc2 p2 </attribute> do you look at the key-type of the <attribute> patterns or the value patterns (p1, p2)? Why leave the formalism incomplete and open the door to ambiguities and misunderstandings when it's so easy to do the formalism completely? If we were to adopt the approach to key ambiguity that you suggest, I think the mods in http://lists.oasis-open.org/archives/relax-ng/200107/msg00147.html are a better approach. In any case, there is as yet no issue on changing the key/keyRef ambiguity rules. --On 23 July 2001 20:48 +0900 Murata Makoto <mura034@attglobal.net> wrote: > Murata Makoto wrote: > >> I will extend my rewrite, but I don't think inference rules are >> absolutely required. 7.2 does not have any inference rules and this is >> just fine. > > Here is my rewrite of 7.2. This is based on what James suggested. > > James Clark wrote: > >> 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) > > In my opinion, this rewrite is away easier to understand than the current > text. > > Since 7.2 becomes away simpler, we might even want to move 7.1 and 7.2 > before 6. > > Cheers, > > Makoto
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC