About DSSSL 2 Specifications

Subject: About DSSSL 2 Specifications
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Sat, 14 Aug 1999 09:48:25 -0400
Hi,

Actually the DSSSL-1 specifications allows a feature not implemented in
OpenJade. This is part of the declaration element and named The
literal-described-char. In a certain way, this could show a very limited
template based processing in DSSSSL. For DSSSL-2, a more elaborate template
based construct could be proposed.

A) extract from the DSSSL-1 specifications:
-------------------------------------------
Literal Described Character
The literal-described-char element type form specifies that bit combinations
in an
SGML document whose meaning was declared in the SGML declaration using a
minimum literal
equal to the value of the desc attribute are to be converted to the
character whose name is
specified in the content of the element.
EXAMPLE 3
<literal-described-char desc="SGML User’s Group logo">
logoSGML
</literal-described-char>

B) expand from this construct for template based processing
------------------------------------------------------------
The above construct allows to substitute a string by an other. So each time
the parser encounters a "logoSGML" it is substituted to "SGML User’s Group
logo" in the source document grove elements. This is a kind of find and
replace feature.

C) how a template based construct may work?
-------------------------------------------
As seen in the previous construct, substitution could be a useful tool. The
above construct has been thought for source input data substitution. We can
also, imagine constructs for output substitution. Thus, the simple following
rule may creates a content substitution but this time for the output
document.

<style-specification>
<style-specification-body>
(root
	(make template
		id: "html_doc"
		(process-children)
	)
)
</style-specification-body>
<style-specification>

<template-specification>
<template-specification-body id="html_doc">
<HTML>
<BODY>
.. put your stuff here ....
</BODY>
</HTML>
</template-specification-body>
</template-specification>

The template is then inserted or substituted to the root FO (i.e. the output
document) in the target output. We would have as output:
<HTML>
<BODY>
.. put your stuff here ....
</BODY>
</HTML>

>From there on, we have different possible constructs:
a) based on a pull model
b) based on a push model
c) based on a mix of both model

The pull model implies that certain construct are included in the template
an "pull" content from the grove.
The push model implies that constructs are "pushed" into the template
The mix model is obviously a combination of both models.

D) The pull model:
------------------
If we unify the query-expression as already suggested by James Clark in
(http://www.netfolder.com/OPenJade/dsssl2.htm#ExtendedPatterns) (Note: this
items implemented in the OpenJade and accessible through the -2 command line
option where also suggestions made by James and some other members of the
DSSSL community like, for instance, Paul Prescod as items to be included in
the next DSSSL-2 specifications). Thus, with a unified query-expression
based on grove elements, we can more easily add pull based data extraction
from the grove. For instance the following template show data extraction
from the source document grove:

<style-specification>
<style-specification-body>
(root
	(make template
		id: "html_doc"
		(process-children)
	)
)
</style-specification-body>
<style-specification>

<template-specification>
<template-specification-body id="html_doc">
<HTML>
<BODY>
<dsssl-select-node match="legal:child:text(header)"/>
</BODY>
</HTML>
</template-specification-body>
</template-specification>

If a particular implementation would support XPAth based query-expression
and if all element are declared as omit tags, then a DSSSL template could be
identical to a XSLT template like below

<?xml version="1.0"?>
<HTML>
<BODY>
<xsl:select-from match="/legal/child::text("header")"/>
</BODY>
</HTML>

or, again with omit tags and the rule that the fault operator is set to
(root (process-children)), (root (process-template)) (note: if one fail then
the other is triggered). We could also have (with omit tags)

<?xml version="1.0"?>
<HTML>
<BODY>
<dsssl-select-node match="legal:child:text(header)"/>
</BODY>
</HTML>

For complete integration with the XML world we would also need to support
name space basd notations like: dsssl:select-node instead of
dsssl-select-node.

In this case (and still with more work to do) we could say that XSL could be
a subset of DSSSL.


E) the push model:
------------------
If the template contains the following construct:

<style-specification>
<style-specification-body>
(root
	(make template
		id: "html_doc"
		(process-children)
	)
)
(element tag2
	(make paragraph
		font-family-name: "arial"
	)
)

</style-specification-body>
<style-specification>

<template-specification>
<template-specification-body id="html_doc">
<HTML>
<BODY>
<dsssl-process-children />
</BODY>
</HTML>
</template-specification-body>
</template-specification>

The template is substituted to the root FO, then inside the template, the
"dsssl-process-children" construct or a similar construct would trigger
construction rules processing. In the example the output is HTML and then if
the DSSSL engine able to generate HTML construct form DSSSL flow object
would generate the following output:

<HTML>
<BODY>
<DIV style="font-family="arial">This is the text</DIV>
</BODY>
</HTML>

or even better:
<HTML>
<BODY>
<DIV class="tag2"> This is the text</DIV>
</BODY>
</HTML>

And provide a CSS companion to the HTML document.

This is only a suggested DSSSL-2 specification item. The above text is only
to collect comments and do not represent an official ISO document.

regards
Didier PH Martin
mailto:martind@xxxxxxxxxxxxx
http://www.netfolder.com



 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist


Current Thread