Re: repeating and recursive inclusion

[Jeni Tennison <mail@jenitennison.com>]

Hi Pankaj,

> James (Clark) has implemented in RELAX NG the XHTML abstract
> modules defined by the XHTML Modularization:
>
> http://www.thaiopensource.com/relaxng/xhtml/ ,
>
> that you may want to look at. The implementation closely follows the
> DTD implementation structure-by-structure (though not in principle),
> and leverages on the previous TREX implementation. This makes
> transition and comparison quite convenient.

Cool, I'd seen the TREX one, should've thought that there was a RELAX
NG one as well.

> The RELAX NG implementation for a member markup language of the
> XHTML "Family" is just a matter of aggregating relevant modules (and
> no more) as creating a model module (like the DTD implementation) is
> not required by the RELAX NG implementation. This possibility is
> certainly time saving and convenient.

Uh-huh, I see it - very neat approach, good illustration of the power
of the combine attribute.

> "The first problem is that if you include something twice then you
> run into problems with having multiple defines of the same name."
>
> That would be a problem in DTDs too.

'Only' for element and notation declarations, but I don't think that
because something is a problem in DTDs it should remain a problem in
schemas. What I'm struggling with is how to manage 'black box' schemas
- what you do when you're given a RELAX NG schema for a vocabulary
that you want to incorporate into your own, but you don't know, don't
want to know, and certainly don't want to change that schema design.

I guess what's bugging me is that each of the XHTML modules implicitly
relies on at least a couple of other modules - one module where all
the data types are defined, and another where the common attributes
are defined. If you tried to design a schema that didn't include those
basic modules then you would get errors all over the place.

That's exactly how it's done in DTDs, because it has to be, but to my
mind it's bad design. If you have a module that relies on some pattern
definitions, then that reliance should be explicit. You should still
have those separate utility modules, but they should be included into
the ones that use them, not added at the top level of the schema. But
adopting that method leads to the problems of multiple definitions
that I raised.

I get the feeling that I'm just thinking about it in the wrong way.

> "The second problem is to do with recursive inclusions in nested
> grammars. I'm coming across this with client-side image maps - the
> map element can have any block content (a Block.mix pattern), and
> within it any a elements can have two extra attributes (shape and
> coords) to indicate areas on the image that they correspond to."
>
> The RELAX NG implementation of the Client-Side Image Maps 
> module
>
> http://thaiopensource.com/relaxng/xhtml/modules/csismap.rng
>
> does make use of nesting grammar patterns. It does not make use of
> Block.mix based on the reasoning that "loose.dtd doesn't use %Flow;"
> although I do not see why a reference to loose.dtd should be there
> at all.

I think you mean that it *doesn't* make use of nesting grammar
patterns.  That schema module adds the shape/coords attributes to a
elements wherever they occur.  I was attempting to constrain it so
that they were only permitted on a elements that occurred within a map
element, and that was where I was having the problems that I
described.  If that kind of constraint is one that's out of RELAX NG's
scope, then fine.  I just thought it would be nice if it could handle
it neatly.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/