Associating DSSSL style sheets with documents

[Len Bullard]

Gavin Nicol wrote:
> 
> >Yes and no.  The problem with the FOSI was that even though it
> >worked, it was hard to specify style on elements in context
> >when the contexts were complex.  We combine context and
> >local stylesheets.  So, a parentage can be used, but a local
> >stylesheet can introduce a new one, so the complexity is
> >localized as well.  Conservation of complexity:  we have
> >more stylesheets to manage per instance.
> 
> Ahh. Trading complexity in specification for complexity in management.

Yes.  Optional realities based on what requirement is most compelling 
in a given production management scenario.  One can write a stylesheet
for a complex 
DTD and get a complex stylesheet.  One can write a stylesheet for 
a set of related DTDs and only have to write some exceptions.
One can write multiple stylesheets that are called at 
different parts of the document as we do in IDE/AS and IADS 
and the styles are flexible.  The compromise is keeping and 
managing multiple stylesheets per document class if one is 
smart enough to use DTDs for systems that don't require them.
We've been through the "well-formed" approach down here.
Good for light stuff, but for classes of documents used 
over lifecycles, nyet.  But I'm content to let others bump 
their heads against that problem until they understand it.

Back to stylesheets, ss in any compound class (one stylesheet, 
several DTDs) that varies like this, if it is also dynamic 
(that is, some part of the DTD is always changing), then 
that complex/compound stylesheet can become a real bear.  This 
is particularly true in systems where one must share the stylesheet 
across organizational boundaries.  The longer one looks at this, 
the more one starts to favor delivery of encapsulated objects 
and view the separation of process and data as a weirdly religious 
approach favored by those who do not manage large dynamic document 
collections for distributed presentation.  This is why dual path, 
lobster-trap delivery systems are preferred by some organizations.
For example, SGML for archival, PDF for presentation.

So where we specify association of processing specifications to 
the document instance, if we make the programmer's job easy, we 
may make the information manager's job hard.  Guess who buys the system?
Encapulated objects give them both what they need on the 
front end.  The price is paid ten years later when one has to 
rehost, recover, or repurpose.  OTH, for information that 
does not live long, the encapsulated object is a good idea 
which is why I thought it strange that HTML is SGML.  Since 
this is a manageement production problem, it can be solved by 
a production approach (e.g, the lobster trap).

Look for the middle way.  Catalogs and menu selections look 
promising.

len

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)