Subject: Re: About Constructions rules From: Brandon Ibach <bibach@xxxxxxxxxxxxxx> Date: Mon, 19 Jul 1999 21:37:24 -0500 |
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
Current Thread |
---|
|
<- 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 |