Re: About Constructions rules

Quoting Didier PH Martin <martind@xxxxxxxxxxxxx>:
> Yes you are right, DSSSL is based on an event based mechanism and the
> document drive what's happening. The grove navigation, in fact, provides the
> events or nodes to be pattern matched by rules. A push model is more related
> to templates. In that case, the script contains the output document as a
> template and then some part of the template is modified by the script
> constructs. The more I think about his, the more I come to think that a
> <style-specification-body> should be restricted to event driven construction
> rules and that a other sgml element could be set for templates like for
> example <template-body> itself a child of <template>. It would be more clean
> that way and two kind of approach could be used to produce an output:
> a) style based and constructing flow objects
> b) template based and incorporating information from the source document or
> doing computation to insert computed elements (like queries, etc..). Anyway,
> this is a snapshot of my actual "in progress" thinking.
> 
   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?

> I would say simply: welcome aboard Brandon. This would be a pleasure to work
> with you. I think implementing the transformation part is what is missing to
> get a complete product. We'll post the result of our archeological research,
> so this could help better understand the openJade internals.
> 
   Well, I'm glad you're enthusiastic about the idea :), but I was
also looking for some comment on the technicalities of fitting the
transformation language into the current architecture.  Of course,
that could be difficult to comment on without knowing more about the
transformation language.  Perhaps when I have a better outline of how
the implementation might work, you'll be able to better answer this.

-Brandon :)


 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist
<- Previous	Index	Next ->
RE: About Constructions rules, Didier PH Martin	Thread	RE: About Constructions rules, Didier PH Martin
Need help for the query example, Didier PH Martin	Date	Re: Need help for the query example, Brandon Ibach
	Month
<-prev [Thread] next->	<-prev [Date] next->
Month Index \| List Home