Re: About Constructions rules

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
<- 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
<-prev [Thread] next->	<-prev [Date] next->
Month Index \| List Home