DSSSL macros experiment

Subject: DSSSL macros experiment
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Mon, 8 Feb 1999 10:21:46 -0500
Hi,

I create an intermediary dsssl file for HTML macros so that people can use
it for macro experiment with HTML formatting objects as output. There is
actually a bug in Jade and in the Talva DSSSL engine (based on Jade). The
bug occurs when there is a certain number of macros defined. The HTMLFOM.dsl
file which contains HTML formatting object macro definition is below the
threshold limit and will work OK. I added the style property to the BODY,
DIV and SPAN HTML FOs. This way, the output can be HTML+CSS. The result is
incredible more readable than with the GI construct as you will see in the
example. You can download the zip file containing all elements from:

ftp://www.netfolder.com/DSSSL2Test.zip

It contains:

- The HTMLFom file containing HTML formatting objects
- the simple-test.dsl file which is the DSSSL script using HTML formatting
objects macros
- The simple-sgml.xml file which is the XML file using simple-test.dsl file
for formatting. I used the old construct "format" for output, a future
sgmlKit (in progress) version will include the new "media" construct.

To run it with Jade, you know how.
To run it with the SGMLKit:
a) Place the HTMLFom.dsl and simple-test.dsl files in the same directory as
the simple-sgml.xml file.
b) The simple-sgml.xml file contains a processing instruction that tells the
sgmlKit to render directly in the browser (actually only IE 4.x or IE 5.x).
c) If you are using the document explorer, you just have to point and click
on the xml file and get its output renderered in the document view. If you
use the browser stand alone without the document explorer bar, type the XML
document location as a file URL, and see it rendered in the browser. If you
select "show source" in the browser, you'll be able to see the generated
HTML.

Note:
I had to modify the "style" property to "css-style" because we have a name
conflict with a the dsssl engine reserved keyword. It becomes more obvious
that with macros usage, potential name conflict may occur and that name
space provision would be necessary. I tried the CSS:style construct but this
construct is in conflict again with a similar DSSSL construct. So it seems
that a construct "in tune" with the overall dsssl notation like "css-style"
fits better. I then suggest that a best pratice would be to create macros
element with a name space tag like for instance define a macro element like
"css-style" instead of "style" or html-body" instead of "body". This way, we
reduce the probability of name collision between the new macro and a
reserved keyword.

Of course, in the case of XML name spaces are already defined as "id:name",
so, for instance, the example above would be: "css:style". With dsssl, with
the actual parser we can't use that construct so the name space convention
would be more like "id-name" ("css-style"). It seems that XSL has the same
problem with the HTML formatting objects. You can't, in actual XSL engines,
use the construct html:body, the browser won't understand this. So, the
problem, even showing different facet in both languages, is about the same:
how do we manage name spaces and what is the resultant file (do we extract
any name space ID from entities before giving that to the end renderer? - a
certain kind of post process)

In the example file I didn't use the html name space for all other elements
like body, div or span but I'll try that in the next experiment.

If you have comments, let's think together on this issue and work toward an
improved dsssl. As you probably noticed, the usage of macros and HTML+CSS
formatting objects resolve in a certain way the dsssl-o issue. And now, as
soon as the other protocols are icluded (not only the file protocol) you can
download and render with style sheet either a SGML or a XML document.

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


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


Current Thread