progressive DSSSL? [was: Alternatives to Pitting HTML against SGML] 
Author Message
 progressive DSSSL? [was: Alternatives to Pitting HTML against SGML]


[snip]

Quote:
>Let me see if I can clarify:

>in a typical networking/gui app, the characters of a document
>arrive in "event driven" fashion; the network delivers X bytes
>to the application, and the application deals with them as
>an event.

>In the code I wrote, the arrival of X bytes goes into a lexical
>analyzer (SGMLLex.i3), where it becomes the arrival of X' tokens. The
>X' tokens are fed to a parser, where they become X'' state
>transitions.  The state transitions are, for example:

>    Stack before    incoming data   stack after
>    HTML,BODY       <p>               HTML,BODY,P
>    HTML,BODY,P     </p>              HTML,BODY

>get the idea? Computing the "after" stack from the before stack,
>the input token and the DTD is pretty easy.

>The trick is: given a formatter state (fonts, indentation, etc), and a
>DSSSL stylesheet, and the input token, compute the new formatter
>state.

>The brute-force implementation is:
>    * compute the new parse stack
>    * for each DSSSL selector, see if the stack matches the
>            selector. If so, evaluate the right hand side.

>            Oops! What about process-children, sequence, and
>            stuff like that?

>I just never got my head around it.

But DSSSL is not an event based model--it is a tree traversal.
In DSSSL you associate context with a make expression to create
a node in a flow object tree.  It is the creation of the flowobject
tree that can affect interactive presentation.  

For example, as the flow object tree is built, the tree could be
presented to the user.  This would require that both the grove
producer and the DSSSL engine be allowed to work on partial
trees--that is, a "not completely parsed" document.  Also, the grove
producer and DSSSL engine must run simultaneously.

Quote:
>I really wanted to see some sort of quick-and-dirty DSSSL implementation
>based on Stk or some such, so that I could see what was going on.

I have one.  I haven't released it because its getting ported to
Kawa.

The Stk version produces a grove first and the can apply a compiled style
sheet to create a flowobject tree.  The a flowobject tree can have a
semantic domain applied to it.  For example, you could apply a semantic
domain of postscript or on-line display.  The concept is setup so you can
apply many semantic domains simultaneously to the same document (grove).

In the Kawa version, we have a concept of an interior and exterior.  For
some flowobject semantic domains it is easier to implement the
semantic as an interior of the flow object.  That is, the flow object
is asked to apply itself to the domain.  For others, as in linearization of
a flowobject tree into RTF, the task of implementing a semantic domain is
easier accomplished as an exterior--a tree traversal object that can maintain
state.

Quote:
>And even if there were such a Q&D implementation, I bet it would
>slurp the whole document into memory, and then march through the
>DSSSL queries, building flow objects. That won't work in an
>interactive situation.

Yes, DSSSL really should have a complete grove to be useful.  Thus,
people might have to wait until the document is loaded to be able to
see the document.  This could be optimzed by a smart DSSSL browser
to figure out if the style sheet requires the grove be complete (e.g.
it uses queries).  If it doesn't require it, the browser could use
some partial-grove algorithm to process the document.

In the Kawa version of our interpreter, we have designed that concept of
a grove constructor.  In this way, a grove producer could create a
disk-based grove (database, etc.) and optimze the memory usage.

Quote:
>With the advent of SENG, kawa, and the like, I gather folks
>have solved this problem one way or another (threads might
>make it a LOT easier). I hope to learn how they did it!

I haven't addressed the issue of processing documents as they
are loaded.  I have some ideas--but they are just that.  Someone
needs to do some research to see what constraints you must apply
to be able to do so--not every DSSSL style sheet can be processed
as the grove is built.  

--
==============================================================================

Copernican Solutions Incorporated                           (612) 379 - 3608



Sun, 17 Jan 1999 03:00:00 GMT  
 progressive DSSSL? [was: Alternatives to Pitting HTML against SGML]


Quote:


>>And even if there were such a Q&D implementation, I bet it would
>>slurp the whole document into memory, and then march through the
>>DSSSL queries, building flow objects. That won't work in an
>>interactive situation.

>Yes, DSSSL really should have a complete grove to be useful.  Thus,
>people might have to wait until the document is loaded to be able to
>see the document.  This could be optimzed by a smart DSSSL browser
>to figure out if the style sheet requires the grove be complete (e.g.
>it uses queries).  If it doesn't require it, the browser could use
>some partial-grove algorithm to process the document.

>I haven't addressed the issue of processing documents as they
>are loaded.  I have some ideas--but they are just that.  Someone
>needs to do some research to see what constraints you must apply
>to be able to do so--not every DSSSL style sheet can be processed
>as the grove is built.  

It would certainly be very useful if someone identified the maximal
subset (or some approximation to that) of dsssl processing instructions
that can be implemented on a partial grove, to give web authors some
guidance in how to construct dsssl stylesheets.  Having a smart browser
is a good idea, but it doesn't help much if authors don't produce
stylesheets that can be used to display partial groves, so you don't
want to leave that to chance, eh?  This sounds to me like something
that should definitely be part of DSSSL-o.  

David



Sun, 17 Jan 1999 03:00:00 GMT  
 
 [ 2 post ] 

 Relevant Pages 

1. progressive DSSSL? [was: Alternatives to Pitting HTML against SGML]

2. SGML Parser in scheme (or LISP) (Was: DSSSL)

3. SGML Parser in scheme (or LISP) (Was: DSSSL)

4. Pit Your Wits Against This One...

5. Searching for HTML or generic SGML parser

6. What are SGML and HTML?

7. HTML/SGML/XML Parsers?

8. SGML,HTML,PDF and python

9. An alternative HTML generation syntax

10. Progressive slowdown

11. Distorting Dewey Progressive ideals, lost in translation

12. Progressive Daycare Promoting Eiffel For Children?

 

 
Powered by phpBB® Forum Software