Subject: RE: DocBook and Jade for Literate Programming From: "W. Eliot Kimber" <eliot@xxxxxxxxxxxxxx> Date: Tue, 03 Nov 1998 11:13:47 -0600 |
At 08:31 AM 11/3/98 -0800, Wroth, Mark wrote: >and going on to provide an example of how one might approach such an >implementation. While I confess I still don't really understand the >underlying process, the example is causing light to shine dimly through >the fog. If that vague understanding is close, then this >"architectural" approach would appear to make extending and customizing >a literate programming system much easier than a straight DTD approach >would. That's the idea. You can specialize your own documents however you want as long as the specializations are consistent with or completely separate from the base architecture. Tools that only understand the base architecture (e.g., a DSSSL spec written to the architecture) will still be able to process your documents. Tools that understand your document direction need not be aware that it also conforms to an architecture. You can interchange your documents with others directly if they also use architecture-aware processors. You can interchange with others at the architectural level by generating a version of your document that only reflects the architecture (e.g., spam -ALitProgArch -p mycodefile.sgm > interchangefile.sgm). The architecture becomes an agreement among a community of interest over what the common things to interchange will be *without* constraining each member's ability to meet their own local requirements by creating specialized documents. The community must also define interchange policies that say how people are intended to use the architecture for interchange. For example, within an enterprise that has defined an architecture that defines the general rules for all documents created by that enterprise, the policy might be "every element type in a document must be derived from something in the corporate architecture". This type of policy ensures that nobody colors too far outside the lines. It can be validated by simple inspection and enforced by refusing to admit non-conforming documents to corporate-provided production processes, for example. Another policy might be "do whatever you want", we'll figure it out. This is essentially the RDF policy, where RDF provides some basic tools but doesn't proscribe how you use them. Note that any existing DTD can be used as an architecture (because the declaration syntax for architectures and DTDs is the same). However, if you are trying to enable smooth and productive interchange within a community of interest, you need to design the architecture explicitly to be an architecture as you will make different design choices for architectures designed for general use than you will for DTDs designed for specific use (similar to the common authoring vs. production distinction). You can even use HTML as an architecture if you really want to (at least the versions that include Div). Note that architectures are similar to XML name spaces but not the same. In particular, the formal architecture mechanism enables syntactic validation of documents against the architecture. In other words, like name spaces, architectures define a vocabulary of names, but also define, using existing syntactic mechanisms and processors, rules for how those names can be combined. The complete architecture mechanism also provides various markup minimization features that name spaces do not provide. [Markup minimization is not always an advantage--it complicates the implementation of architectural processing while making it generally easier to use for authors and DTD designers. However, you are not required to use or depend on architectural markup minimization ("automapping").] Cheers, E. -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 75202. 214.953.0004 www.isogen.com </Address> DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: DocBook and Jade for Literate P, Wroth, Mark | Thread | Re: DocBook and Jade for Literate P, Mitch C. Amiano |
Re: DocBook and Jade for Literate P, Mitch C. Amiano | Date | ANN: CSLDSSSL (was: DocBook and Jad, G. Ken Holman |
Month |