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

[John Cowan <jcowan@reutershealth.com>]

(Note:  I've added relaxng-user@relaxng.org, which is the most appropriate
mailing list for this.)

Sean McGrath scripsit:

> I am creating a whole bunch of Relax NG schemas and seeking to
> maximize re-use of schema fragments.
> 
> I am having trouble with multiple includes and seeking advise on how
> best to deal with the one-include-per-file restriction.
> 
> Here is my setup/wishlist:
>     All schema fragments stored in RNC and tranged via ANT to RNG/XSD/DTD.
> 
>     All schema fragments are usable standalone as well as modules of 
>     bigger schemas.
> 
>     All schema fragments have their own namespace with a simple naming 
>     convention that mirrors the file naming convention.
> 
> All schemas take the same basic shape. Here is the basic shape (for
> any schema S):
> 
>    -- file S.rnc --
>     namespace S = "http://example.com/S";
> 
>     # One of these for each schema fragment this schema uses.
>     # Replace XXX with schema basefilename.
>     include "XXX.rnc" { start |= notAllowed }
> 
>     start = _S.ROOT_
> 
>     _S.ROOT_ = element S:root {
>              ...
>        }
>    -- end file S.rnc --

If all your schema fragments are really Russian-doll style like this, then
you'd do better to get rid of the definitions, store a single element
pattern in each file, and use external references to embed them in
one another as needed.

But I'll assume that your needs are more complex than that.

> In an ideal world, a schema writer wishing to use another schema X as
> a component, should not have to know anything about what other schema
> fragments get included by schema X.
> 
> As I understand Relax NG, this is not the case. In the ASCII art below
> I have tried to illustrate a situation in which schema M includes M1
> and M2. M1 in turn, also includes M2.
> 
> M --|
>    |-- M1 --|
>    |        |                
>    |        |-- M2
>    |  
>    |  
>    |-- M2
> 
> 
> The resultant schema (as I understand it) is illegal because M2 is
> included twice.

Correct.  That's because inclusion is flat (it does not introduce a name
scope); when you include rules, you throw away the enclosing grammar pattern
(implicit in the case of rnc format).

> Back in my C programming youth, I would use use "#ifndef" :-) How best
> to handle in Relax NG?

NRL is probably your friend in this case.

> Illustrative schemas below.
> 
> Error message:
>    java -jar d:\data\utils\trang.jar m.rnc m.xsd
> 
>    m2.rnc:5:1: error: multiple definitions of "_M2.ROOT_" without 
> "combine" attribute
> 
> Interestingly, tranging to RNGs does not produce multiple include
> errors. Subsequent jing's complain about the duplicates
> however. Tranging to XSD's does produce errors about the duplicates.

Translation between rnc and rng is very "surfacey" and doesn't always
catch errors.  Translation to xsd has to understand the semantics,
so it does fairly complete error checking on the input.

> -- m.rnc --
> namespace M = "http://example.com/M";
> 
> start = _M.ROOT_
> 
> include "m1.rnc" { start |= notAllowed }
> include "m2.rnc" { start |= notAllowed }
> 
> _M.ROOT_ = element M:root {
>    # content model here
>    text
> }
> 
> -- m1.rnc --
> namespace M1 = "http://example.com/M1";
> 
> start = _M1.ROOT_
> 
> include "M2.rnc" { start |= notAllowed }
> 
> _M1.ROOT_ = element M1:root {
>    # model goes here
>    text
> }
> -- m2.rnc --
> namespace M2 = "http://example.com/M2";
> 
> start = _M2.ROOT_
> 
> _M2.ROOT_ = element M2:root {
>    text
> }
> -- end --
> 
> I can see a couple of routes forward involving munging the locations of 
> includes with scripts but I do not want to launch into anything until I 
> have sanity checked that I have not missed the simple one line solution.
> 
> regards,
> Sean
> 
> -- 
> http://seanmcgrath.blogspot.com

-- 
Evolutionary psychology is the theory           John Cowan
that men are nothing but horn-dogs,             http://www.ccil.org/~cowan
and that women only want them for their money.  http://www.reutershealth.com
        --Susan McCarthy (adapted)              jcowan@reutershealth.com