Re: Repost: Re: `High-level' format specifications with XSL?

[Paul Prescod <papresco@xxxxxxxxxxxxxxxx>]

Sean Mc Grath wrote:
> 
> I think the SGML/XML world could do with a whole bunch of standard
> DTDs for Scientific Publishing, Contracts, Memoranda etc. etc. that
> unashamedly specify their display sematics. Then users of SGML/XML
> could piggy-back on these back-ends by doing SGML-SGML transformations.

I do not like this solution for reasons described in
http://www.cgl.uwaterloo.ca/Projects/meta/sgml97/papresco/

"Our first reuse strategy was to unify the documents through
transformation to a common document type, like TEILite. This
document type would have known semantics and could be handled by
one stylesheet for print and another for online. In essence, the TEILite
constructs would be used as pseudo flow objects in that the stylesheet
author would transform into them purely in order to inherit the
formatting specified in a stylesheet. The important feature of the
intermediate format is that it would express higher level constructs
that would be common to the formatting of many similar DTDs and to
both of their online and print expressions. We would expect pseudo
flow objects to be about at the semantic level of the popular LaTeX
macro package for TeX. [FN 1]

The most convenient way to specify these transformations is the
HyTime architectural form facility. Architectural forms are a
powerful facility of HyTime that offer interesting ways to treat
documents as if they conformed to more than one DTD and to
validate them against more than one DTD. They are a powerful and
useful tool for reusing code of all kinds. For example, a HyTime
engine is a reusable software component that depends entirely on
HyTime architectural forms for its reusability. You get this
reusability by specifying that a particular element in a document is
“equivalent to” an element type in an architectural
DTD. You declare this equivalence using special attributes. For
example an element like <p gcapaper="para"> would be
equivalent to a para element in the gcapaper architecture. If the root
element of your document is declared to be equivalent to the root
element of the architectural document type, and recursively every
sub-element is equivalent to an element type in the other document
type then you have defined a mapping. The result of transforming your
document according to that mapping is called an architectural
instance.

Despite the fact that they can do simple transformations, architectural
forms are not intended to be a generalized transformation language
and their transformational power is limited. Architectural forms have
at least two weaknesses in this context. First, they are strictly
declarative and thus do not have the full power of a programming
language to allow sophisticated queries and mappings. Second, they
cannot add elements. For every element in the architectural instance,
there must be at most one element in the source document. Both of
these limitations make sense if you think of architectural forms as
expressing a mapping from elements to (architectural) element types,
rather than as a full transformation language. 

Our document types were not so similar that architectural forms were
flexible enough to unify them without throwing away important
information. We could correct the problem with a more general
transformational technology. We could, for instance, use Jade's
SGML transformation back-end to transform everything. The initial
transformation would be fully programmable and thus flexible. 

Our primary concerns about this approach involved the user interface
and extensibility. If we think about the TEILite constructs as pseudo
flow objects then it seems reasonable to want to use idiomatic
DSSSL constructs to create them and to have access to built-in
DSSSL flow objects when necessary to augment them. This is
analogous to the way that TeX code can be interspersed with LaTeX
code where necessary. If we transformed into an actual TEILite
instance then there would be no place to put these non-TEILite flow
objects. 

There was also the question of complexity. While SGML to SGML
transformations are not brain surgery, they are also not trivial.
Stylesheet authors of moderate skill might get frustrated trying to
coerce their intermediate output into conformance with the common
DTD. In addition, performance is also a concern. The two-pass
conversion would generally take twice as long as a single pass.
This would be totally inappropriate in a WYSIWYG XML authoring 
environment."

As that paper argues, XSL and DSSSL should really allow inspection and
manipulation of flow objects in order to create higher level flow objects,
as LaTeX macros are built on top of TeX.

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

Three things trust above all else: Your knowledge of your craft
That someone turns a profit, and that you will get the shaft
http://www.geezjan.org/humor/computers/threes.html


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list