Subject: Re: About Constructions rules From: Brandon Ibach <bibach@xxxxxxxxxxxxxx> Date: Wed, 21 Jul 1999 02:12:02 -0500 |
Quoting Daniel Mahler <dmahler@xxxxxxxxxx>: > Brandon Ibach wrote: > > 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. > > I am not sure I understand this, but it sounds exciting. > Could you provide a hypothetical example? > Well, here's a simple example. It doesn't touch on all of the aspects of this, but it gives you an idea of my current thoughts. Suppose you have an HTML <form> with just a single <select> with the "multiple" option, so you can select a group of items from it. The scripting language would provide an "array" of sorts containing the selected items, all under the name given to the select. Let's say the name is "items". Suppose you then had the following document: <htmlscript> <html> <head><title>yOUR SELECTIONS</title></head> <body> <ul><foreach var="i" src="items"> <li>&$i;</li></foreach> </ul> </body> </html> </htmlscript> Here, <htmlscript> has been declared in the DTD to have a content model of a single <html> element, but with all of the scripting elements (which are architectural elements from the scripting architecture) as inclusions, meaning they can show up basically anywhere in the HTML. The idea of using a special kind of entity reference (the &$i; construct) for variable references is something I've been toying with. Whether it can be made to work without totally twisting the DSSSL engine is another matter. :) The result of parsing this normally is shown below on the left. The result of parsing the "scripting" architectural instance is shown in parallel on the right. (htmlscript) (script) +>(html) +>(other) +>(head) +>(other) | +>(title) | +>(other) +>(body) +>(other) +>(ul) +>(other) +>(foreach) +>(for-each) +>(li) +>(other) +>[$i] +>[$i] Here, we see that htmlscript and foreach are architectural elements corresponding to script and for-each, respectively, in the scripting architecture. All other elements, being non-architectural (part of HTML, in this case), get mapped to the default element, "other". The [$i] on the last line represents the entity reference, which, if I can figure out how to get the parsing to pass it in to me rather than trying to dereference it, I would handle as a reference to the scripting language's variable system. The problem I had in doing this with just SP is that, while it has the ability to produce either one of the instances above, it can't produce them both at the same time, with links from the latter to the former. I needed this so that I could process the scripting elements in the architectural instance, yet still reconstruct the HTML from the document instance. This should give you some idea of what I have in mind, though there are certainly a myriad of details not covered here (or even figured out yet, for that matter). -Brandon :) DSSSList info and archive: http://www.mulberrytech.com/dsssl/dssslist
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: About Constructions rules, Daniel Mahler | Thread | Re: About Constructions rules, Daniel Mahler |
Re: reflection, Holger Klawitter | Date | Re: Formatting CALS tables, Jany Quintard |
Month |