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.



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



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

And prohibiting <list> of <key>s will complicate the spec.

So I think the current symmetry between <key> and <keyref> is nice. 



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


regards,
--
Kohsuke KAWAGUCHI                          +1 650 786 0721
Sun Microsystems                   kohsuke.kawaguchi@sun.com



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


Powered by eList eXpress LLC