Improving 7.3 (was Re: Alternative approach for key/keyref)

[Murata Makoto <mura034@attglobal.net>]

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