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
