Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Associating DSSSL style sheets with documents
 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@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
