Re: [relax-ng-comment] An RNC modularisation strategy question

[Sean McGrath <sean.mcgrath@propylon.com>]

John Cowan wrote:

>One possible way forward for Sean's particular case, though not for the
>general case, would be to relax (:-)) RNG validity such that it is valid
>to have two definitions of the same name without a combination specified,
>provided the definitions are identical -- in which case, one of them is
>simply discarded.
>
>This seems like a reasonable extension to me.
>
>  
>
That would work perfectly for my scenario. I am looking into the other 
options mentioned but this would be by far the cleanest for my setup.

Some more details of the (possibly unconventional) way I lay out my schemas:

I use name definitions a lot. I use one for each element type in fact 
(no russian dolls and no nested grammers). I lay out my RNC's lile BNF 
grammers with  names playing the part of  "non-terminals". I use rigid 
naming conventions for filenames, namespaces, element types and the 
non-terminals to help me stay sane. e.g. the element type "foo" in 
namespace "R1234" will look like this:

    -- file R1234.rnc --
    namespace R1234 = "http://www.example.com/R1234";

    _R1234.FOO_ = element R1234:foo {
    }
    ...

So, If I know there is an element type "foo" in namespace R1234 and I 
want to import the schema into another schema, I immediately know 
(without having to look anything up) where it is stored, what name to 
refer to in order re-use that element type. e.g.

    -- file R5678.rnc --
    # include the schema for namespace R1234
    include "R1234.rnc"

    namespace R5678 = "http://www.example.com/R5678";

    _R5678:BAR_ = element R5689:bar {
       ...
       # re-use element foo from namespace R1234
       _R1234.FOO_
      ...
    }

Multiple includes are pretty much inevitable in this sort of set-up. 
Overlapping includes naturally end up occuring because each schema is 
both standalone (and therefore must include all dependances) and a 
potential sub-schema.

Sean