>> (1) paths of arbitrary lengths (e.g., paragarphs in
>> chapters/sections/subsections are identified by numbers,
>> but paragaraphs in column articles are not).
>
>As you said, it is beyond XML DTD's ID/IDREF capability, but still a
>nice-to-have feature. The cost of this feature is the concepts of [n]e, [n]a,
>and \sim. By removing this feature, as you did in your rewrite, will
>need a simpler \sim only.
>
>So I guess this is really just a matter of cost-effectiveness. Is this
>feature deserves three additional concepts in the spec? Apparently, you
>don't think it's worth the cost. I guess I can live without this
>feature. RELAX Core didn't have this, but nobody complains.
Since I believe path expressions provide the right solution eventually, I
don't think this is a matter of cost-effectiveness. To me, the approach in
the spec is just wrong.
>> (2) key/keyRef declarations can be combined with <choice> (see the
>> production rule for the non-terminal "value")
>
>It looks like <choice>ing keys/keyrefs are unnecessary as you said. But
>I don't know how it complicates the spec. Isn't it just a matter of
>changing the 7.1 BNF?
I agree that prohibition of this feature does not make the spec very simple. Moreover,
one could use this feature so as to use integers from 1 to 100 and those from
200 to 300 as key values. This is done by writing a <choice> containing two
<key>s. But we do not need this to mimick ID/IDREF/IDREFS of XML DTDs.
>> (3) key/keyRef declarations can be combined with <list> (again, see the
>> production rule for the non-terminal "value")
>
>I think there is no such thing as "one-to-one correspondence between
>identifiers and elements/attributes" from the very beginning. RELAX NG
>doesn't introduce the concept of "identifiable elements/attributes". So
>adding list of IDs will break nothing.
Let's revisit DTDs of XML 1.0. If an element type has an attribute declared as
ID, elements of that element type are identifiable elements. Two elements of
this element type never specify identical values for the ID attribute. In other words,
for each value of this attribute, there exists one element of that element type.
But this attribute might be #IMPLIED. Thus, some elements of that element type do
not have this ID attribute. Therefore, for each element of the element type,
there exists at most one value of the ID attribute. Thus, we have one-to-one
correspondence (or zero/one-to-one).
The same thing applies to the relational database. No tuples have more than
one keys. In this case, we have exactly one-to-one correspondence. This fact has
been used to create and modify index files.
I do not want to destroy this correspondence without understanding its impacts on
index files and future extensions such as multi-part keys. How do you generalizes
this feature for multi-part keys?
>And prohibiting <list> of <key>s will complicate the spec.
$B!)(B I don't think you have any supporting evidence here. See my mail at:
http://lists.oasis-open.org/archives/relax-ng/200107/msg00246.html
>> (4) key/keyRef declarations within <list> can be freely combined
>> with <oneOrMore>, <interleave>, <group>, and <choice> (see the
>> production rule for the non-terminal "tokens")
>
>But this one is actually contributing to simplify the current spec.
I don't think so. I have already proposed another BNF, which allows
<list><oneOrMore><keyRef>...</keyRef></oneOrMore></list> only. I would
like to know how you feel about it.
Cheers,
Makoto
----
Murata Makoto
