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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: More thoughts on multiple style, Norbert Mikula | Thread | Re: SGML to HTML with jade?, Paul Prescod |
Re: Order of matching in multiple s, Paul Prescod | Date | DTD for customizable stylesheets, Matthias Clasen |
Month |