Re: [ssax-sxml] deleting html tags with pre-post-order

[David A. <da...@al...>]

On Thu, Jun 12, 2003 at 11:09:08AM +0200, Joerg F. Wittenberger wrote:
> "Neil W. Van Dyke" <ne...@ne...> writes:
> 
> > Would be transformed to:
> > 
> >     (p "Candy is " "sw" "ee" "t" ".")
> > 
> > However, my first attempt, attached to the bottom of this email, results in:
> > 
> >     (p "Candy is " ("sw" ("ee") "t") ".")
> > 
> > Is this an unavoidable artifact of how "pre-post-order" works?  Or is
> > there a way to get the desired output from "pre-post-order" without
> > post-processing it with "SRV:send-reply" or similar?
> 
> to my understanding you are sort of hit by the limits of SXML.  What's
> missing here is the notion of a node-list as of DSSSL.  In contrast to
> Scheme lists as used by SXML DSSSL node-lists are never understood to
> be nested (though the implementation is free to use nested Scheme list
> to represent DSSSL node-lists).
> 
> You have two choices:
> 
> a) modify your tree walking rules to automatically flatten the list
> (no idea how to do that).
> 
> b) [pick up code from askemos]


In my opinion, there is indeed a slight design problem in
pre-post-order.

In texmacs, I systematically use append-map to process subnodes, and
all converter functions return a node-list. 

This has a cost: an extra cons is created and immediately deleted when
a subnode handler return a one element node-list. But this makes
things simpler and more regular. That removes the need of a cleanup
pass to remove null lists from the output and this makes hierarchy
collapsing trivial.

Well, texmacs does not use pre-post-order, but its xml converters
solve a similar class of problems and use sxml as input. My converters
a more sophisticated than pre-post-order, they also do some elaborate
pre-processing and post-processing like normalizing whitespaces in the
input, collapsing adjacent string nodes in the output and some more
obscure things required by the texmacs data format.

But the append-map solution applies to pre-post-order as well.


Generally, I think that a well designed converter should work in only
one pass. I considered writing an essay about this, but this is such a
common problem that there is probably one hundred papers around
dealing with this design issue. Anyone has a pointer?

-- 
                                                            -- ddaa