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

Subject: Re: More thoughts on multiple style specifications (was Re: SGML to HTML with jade?)
From: Norman Walsh <norm@xxxxxxxxxxxxx>
Date: Wed, 25 Jun 1997 13:50:02 -0400
Norbert Mikula <nmikula@xxxxxxxxxxxxxxxxx> writes:
> On Wed, 25 Jun 1997, Norman Walsh wrote:
> > Comments?  Please.
> 
> My idea to use multiple stylespecs was  :
> a.) re-use
> You have a core module with the more general specifications,
> and then you two or more specific ones. For instance
> core : HTML
> specific a : HTML for printout
> specific b : HTML for online display

Right, but do you ever use HTML by itself?  If not, why is it
better to have a stylespec for it?  Why not just &html.dsl; it
into htmlprint.dsl and htmlonline.dsl?

> Furthermore, if you look for instance at Jon Bosak HTML stylesheet,
> you could take the different parameters for 
> visual appearance and create a seperate module
> for the major different settings. This you could
> then present to the user via a menu.

Yes, this is what I had in mind when I wrote

 ] 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.

I could make dbmain.dsl modular by including the chunks
(dblists, dbmsgset, dbrfntry, etc.) in it via entities, avoiding
the precedence specificity problems, and then have specific
drivers that incorporate it by style specification.  In this
case, I think it would be more intuitive, the things you put in
the driver would override the things in dbmain.  (But not always
in the most intuitive way, e.g., if you started to stick
(element ...)  declarations in the driver).

> b.) maintainabiltity
> 
> You could have certain core functions/modules outside
> the DTD specific stylespecs. This core module you could
> include via an external-spec. reference

Another good reason for modularity, but I don't see why it
matters if they are style specs on their own or just fragments
included via entity.

In fact, I'm starting to think that style specifications for
fragments is just the wrong way to go.  Imagine a table fragment
that includes (element TABLE ROW CELL PARA), which seems
reasonable.

If you make the table module a style specification, it would
only work if you included the table module before any module
that defines (element PARA) and that's an odd dependency to keep
in your head, IMHO.

> c.) reduce network load
> 
> If I refer to a base module via external-spec. reference,
> the application might be able to keep in the cache
> and wouldn't need to reload and reparse the spec. 

True.  Not a problem just yet, but definitely a possibility.

                                        Cheers,
                                          norm
-- 
Norman Walsh <nwalsh@xxxxxxxxxxxxx> | The First Amendment is often
Senior Application Analyst          | inconvenient. But that is besides
ArborText, Inc. (www.arbortext.com) | the point. Inconvenience does not
413.549.3868 Voice/FAX              | absolve the government of its
                                    | obligation to tolerate speech. --
                                    | Justice Anthony Kennedy, in 91-155


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


Current Thread