More thoughts on multiple style specifications (was Re: SGML to HTML with jade?)

[Norman Walsh <norm@xxxxxxxxxxxxx>]

Paul Prescod wrote:
> Norman Walsh wrote:
> > That's definitely an issue.  I needed modularity so that I could redefine
> > some definitions for specific projects without having to copy the whole
> > stylesheet.  However, it's pretty clear that I don't fully grok the
> > ramifications of multiple style-specifications, and perhaps I went to
> > far in my zeal for modularity.  I could merge things back together into
> > fewer pieces, certainly.
> 
> You grok the semantics of standard SGML entities. Why don't you use
> those?

Well, to be perfectly honest, because a) I wanted to experiment
with multiple style specifications (like the mountain, because
they were there ;-) and b) I didn't know what I was getting into.

I also thought that driver files for customized versions of the
stylesheet would be simpler because they'd only have to point to
dbmain, not to all the modules (I could use a parameter entity
to make a similar simplification without multiple style
specifications, though).

Now let me turn the question around.  When *is* it better to use
multiple style specifications?  

I was going to argue that it allowed better modularity.  The
table model, for example, can stand on its own and I can plug it
into different style sheets.  But when would I need a module
without some extra wrapping?  And if I'm going to have extra
wrapping anyway, then the table model might just as well be an
unwrapped fragment that I include with an entity.

My current thinking is that I ought to use just entities for the
docbook stylesheet or a combination of entities and style specifications.
I could, for example, make the elements of dbmain entities, but leave
dbmain as a style specification.  A rule of thumb is forming in my head,
"if it's big enough to stand alone---if it's complete without additional
stuff---make it a separate style specification, otherwise make it an
entity".

Comments?  Please.

--norm


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist