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: key/keyRef: generalization, ad-hocness,and generalization of ad-hocness



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

? 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  mura034@attglobal.net


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC