Re: General concern about inter-grammar references

[James Clark <jjc@jclark.com>]

I don't think W3C XML Schema has any concept of multiple grammars.  Thus, I 
do not think RELAX NG is lacking anything in respect of inter-grammar 
references as compared to W3C XML Schema.  The thing that W3C XML Schema 
has that RELAX NG does not is the ability to identify definitions in the 
grammar using a namespace URI/local name pair rather than merely a local 
name.  The easy way to facilitate translation from W3C XML Schema to RELAX 
NG is to allow define/ref to use QNames or an ns attribute just as 
element/attribute/key/keyRef can.

> Another problem is how to assemble necessary files. Say the "schema" A
> references a definition in B. The problem is, we cannot write
> <include href="B.rng"/> in A.rng because C.rng might have a reference to
> B, too.
>
> If both A and C has references to B and we write <include href="B.rng"/>
> to both A.rng and C.rng, then it causes a collision because B.rng is
> included twice.
>
> So converted RELAX NG files cannot contain <include> statements. Instead,
> you have to create a hub file by yourself and includes all necessary
> files, which is a very tiresome labor.

This is a fair point but I don't think it's got much to do with 
inter-grammar references.  This problem crops up with many different 
programming languages.

One possible simple solution is to allow a <grammar> to <include> the same 
URI any number of times without error.  Since we have order independence 
this is safe.  We would need to require that the inherited value of the ns 
attribute was the same for all inclusions of a particular URI.  This does 
add some complexity to the spec and gets us into comparing URIs which is 
usually a bad idea.

Another possible solution is to use a provide/require mechanism.  You allow 
a grammar to contain <provide> elements

<provide feature="foo" href="foo.rng"/>

It is an error to have multiple provides of the same feature.  You also 
allow a grammar to contain any number of <require> elements.

<require feature="foo"/>

You can have any number of requires of the same feature.  In a modular 
schema, you would typically have a module definitions file modules.rng

<grammar>

<provide feature="foo" href="foo.rng"/>
<provide feature="bar" href="bar.rng"/>

</grammar>

Each module <require>s the modules it depends on. The semantics of 
<provide> is that it is equivalent to an <include> if the same grammar 
contains a <require> of that feature.

You still need a hub, but it's much easier to create

<grammar>

<include href="modules.rng"/>

<require feature="baz"/>

</grammar>

All the dependencies of the baz module included automatically.  Instead of 
a new <provide> element you could add an optional ifRequired attribute to 
<include>.  An implementation could even allow a user to specify a required 
feature externally (perhaps on the command line) so that you don't have to 
manually create the hub file.

This is reminiscent of conditional sections in DTDs. SP allows a -i option 
to define a parameter entity as INCLUDE.

Is this on the right side of the 80/20 line for 1.0? I'm doubtful.

> If there are multiple <grammarRef> with the same name, then only the
> first one is loaded and the rest is ignored.

That would lose order independence and be highly unsafe.  If you are going 
to do that, then you might as well just allow multiple definitions of the 
same name and use only the first one.

James