RE: DocBook and Jade for Literate Programming

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

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").]


<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

 DSSSList info and archive:

Current Thread