RE: About Constructions rules

Hi Brandon,

Brandon said:
   Okay... I can begin to see where you're headed now, but I daresay
we're almost completely outside the realm of DSSSL if you want to use
a "push" approach for templates.
   I've actually been wanting to use DSSSL to create an SGML and
template based scripting engine for years now, but determined that I
needed a good implementation of the transformation language to make it
work.  The idea is to use architectures to introduce a set of
scripting elements into existing DTDs.  Probably the easiest way to do
this, using HTML an an example, would be to create a new DTD that
simply creates a new document element whose content model is just a
single <HTML> element, but with the scripting elements as inclusions,
meaning that they could show up anywhere in the HTML, as long as
they're nested properly (for those that aren't empty elements).  Using
architectures, the user could rename the elements and their attributes
as needed, among other "customization".
   The DSSSL transformation spec could then take the parsed document,
create an auxiliary grove, which would be the architectural instance
of the scripting elements, and process the whole thing, utilizing the
links from the auxiliary grove back to the document instance to pull
in the non-architectural (HTML, in this case) stuff as needed.
   Does this type of thing fit into your ideas on templates at all,
Didier?

Didier says:
Or we may declare a new section or "part" (like said in the code) for a
template. The <template-body> element could be with PCDATA then, parsable
but we have not to include any of its content in a DTD, only the
template-body element. Then, the content could be parsed separately like we
do for the style-specification-body element (in this case the content is
parsed by the scheme interpreter). If the template is a XML template then no
DTD Is required for this second parsing, if the template is a SGML document,
then the template as to refer to a doctype or DTD specification. Some
elements, however, are defined in a separate DTD (for the second parsing)
and are DSSSL constructs, more particularly query constructs. Most of the
query-expression return a node-list, then the node list would have to be
converted in to something like a string, an attribute, etc... before
insertion in the template. So, to process a template means to replace all
reserved elements by the result of the operation each reserved element
specify.

So, this way, we have only to update the DSSSL DTD to include a new section
or element like for instance <template> which contains an other element
<template-body> if it make sense (and probably it does) to have only a
single template per script, then the template element is simply replaced by
the template-body element. Its content is then simply PCDATA. The second
parser contains its own DTD with all its elements specified. the second DTD
would act as a language reserved word list or hierarchy. This way, the same
functionality as XSL could be included in DSSSL and provide two ways to
specify a style.

A note about the actual DSSSL DTD. I will have to check but the actual DTD
declares the style-specification-body element as PCDATA but I think that in
the original specs it is CDATA. However, to have the
style-specification-body set as PCDATA could be potentially useful. For
example, we can do a preprocess to the style-specification-body content with
the parser and parse it with a private DTD having for instance the following
element <template....> then, the first pass would get all templates, resolve
them and generate the output, then all scheme based constructs (or vise
versa, I didn't thought more on the priority mechanism). the advantage here
is that procedural or template based rules could be used. Or that DSSSL
could include XSL. In one word do the synthesis.

Again, these are "in progress thoughts". I have first to thoroughly
understand the style engine. I am slowly documenting it. Actually I am
working on the dssslSpecEventHandler class in charge of parsing the original
script document. I am trying to figure how the "parts" are working and what
each parameter means. As soon as this is completed, I'll be able to play
with new section or add news ones like for instance the "transformation"
section. Also, to optimize some processing like for instance, what if the
DSSSL script where a XML document? Would we gain some speed by not doing
architectural form processing? If yes any script beginning with the <?xml
version="1.0"?> would indicate that it is a XML document and then the whole
document processed as a XML document instead of a SGML. Without this and
with the inclusion of a DTD reference, the document would be treated as a
SGML document (and then allow more sophisticated processing like
architectural form). But I discovered that most people do not use the
architectural form capabilities, then probably, for them, a XML format would
be sufficient. So my background question I am trying to answer is What if a
DSSSL script where a xml document? The other one is: what if we integrate
templates in dsssl? But also to keep SGML processing, architectural form,
etc...So, right now, I am just playing with the idea.

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



 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist
<- Previous	Index	Next ->
Re: About Constructions rules, Brandon Ibach	Thread	RE: About Constructions rules, Didier PH Martin
Re: (commercial) applications using, Ron Ross	Date	reflection, Holger Klawitter
	Month
<-prev [Thread] next->	<-prev [Date] next->
Month Index \| List Home