OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[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 

If we were to adopt the approach to key ambiguity that you suggest, I think 
the mods in


are a better approach.

In any case, there is as yet no issue on changing the key/keyRef ambiguity 

--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