[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: General concern about inter-grammar references
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC