Lists Home |
Date Index |
- From: Len Bullard <email@example.com>
- To: Gavin Nicol <firstname.lastname@example.org>
- Date: Thu, 06 Mar 1997 09:10:05 -0600
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
xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to email@example.com the following message;
List coordinator, Henry Rzepa (firstname.lastname@example.org)