[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Improving 7.3 (was Re: Alternative approach for key/keyref)
In my opinion, unnecessary generalizations have made 7.3 very complicated. In the case of key/keyref, the spec already imposes severe restrictions (e.g., lack of multi-part keys and string-only keys rather than complex-element-keys) and nevertheless introduces unnecessary generalization. For example, a single grammar can have two patterns as below: <element name="foo"> <list> <keyRef name="k"><data type="short"/></key> </list> </element> and <element name="foo"> <list> <keyRef name="k"><data type="short"/></keyRef> <keyRef name="k"><data type="short"/></keyRef> </list> </element> In my understanding, they do *not* make this schema key-ambiguous. But do we really need this? We can even have <choice> or <group> between <list> and <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. Right. Since I do not think that current syntax for key/keyRef is mature, I did not touch that part. I think that a better approach is to incorporate severe restrictions. > However, I find it rather unsatisfactory to formalize only the notion of > key type and leave key ambiguity defined only informally. OK. Let's define both 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? This is true. Here is an improved rewrite. A schema is key-ambiguous if (1) it contains two element patterns <element> nc1 top1 </element> and <element> nc2 top2 </element>; some name matches both nc1 and nc2, and; top1 and top2 have different key-types. or (2) it contains two attribute patterns <attribute> nc1 pattern1 </attribute> and <attribute> nc2 pattern2 </attribute>; some name matches both nc1 and nc2; pattern1 and pattern2 have different key-types. > 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. Here is my counter proposal. This BNF is much more restricted than that in section 6. This proposal makes it very easy to introduce key-types. 1) Get rid of non-terminal "token" and its production rule 2) Revise the production rule for "value" value ::= dataValue | <key ns="anyURI" name="NCName"> dataValueChoice </key> | <keyRef ns="anyURI" name="NCName"> dataValueChoice </keyRef> | <text/> | <list> (<empty/> | tokens) </list> | <list><oneOrMore><keyRef ns="anyURI" name="NCName"> dataValueChoice </keyRef></oneOrMore></list> @ | <list><oneOrMore><key ns="anyURI" name="NCName"> dataValueChoice @ </key></oneOrMore></list> | <choice> (<empty/> | value) value </choice> 3) Revise the production rule for "tokens tokens ::= dataValue | <oneOrMore> tokens </oneOrMore> | <group> tokens tokens </group> | <interleave> tokens tokens </interleave> | <choice> (<empty/> | tokens) tokens </choice> Cheers, Makoto
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC