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

I think if we continue to discuss this the merits of the current design by 
email we are going to generate more heat than light.  Let's discuss it at 
the telcon.

But in advance of the telcon let me offer this thought.  Maybe the way out 
of this hole is to move the cross-reference feature out of RELAX NG itself 
into a separate spec.

Thus if you want ID/IDREF style cross-references you would have to use an 

<attribute name="foo" rnga:refType="IDREF">
  <data type="NCName"/>

If you want to have path-based cross-references, then you don't have to 
support ID/IDREF style cross-references if you don't want to.  If you want 
to support something like what we have now, you could do that as well (via 
key/keyRef attributes on any pattern).

We could put something like rnga:refType into our common annotations spec.

I think there are many reasons for separating out cross-reference checking 
and layering it on top of RELAX NG.

a) For some applications of RELAX NG, the cross-reference feature doesn't 
make a whole lot of sense: for example, using RELAX NG for type-checking 
XML processing applications, or computing subset relationships between 

b) As a general design principle, it's better for a spec to do one thing 
and do it well, and be able to combine in a modular fashion with other 
specs to do other things.

c) The technology for cross-reference checking is clearly at a different 
level of maturity from that of regular tree grammars.  Whereas regular tree 
grammars are mature and ripe for standardization, cross-reference checking 
is not at the same stage.

I would claim that Murata-san's various proposals are really a 
compatibility hack, something that we believe is not really the right 
solution but that we include for compatibility with XML practice.  I 
suspect he would not disagree, but would argue that what we already have is 
a compatibility hack.  Compatibility hacks are useful, but I believe, just 
like default attributes, they should be kept out of the RELAX NG spec 


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

Powered by eList eXpress LLC