Re: chains of SXML transformations?
"Hoehle, Joerg-Cyril" <[email protected]> Wed, 22 Oct 2003 10:47:11 +0200
| Newsgroups | gmane.lisp.scheme.ssax-sxml |
|---|---|
| Message-ID | <[email protected]> |
Hi,
Oleg wrote:
>The problem can be rectified, by changing pre-post-order as shown in
>the appendix. [...] This operation seems to make sure
>that each node of a tree is an SXML node.
That's it!!! it's much cleaner than an a posteriori pass through the output, trying to remove superfluous nesting. Great solution!
Having the handlers during processing already see proper SXML is a clear improvement, which allows easier macros, e.g. a reliable "first" transfomer
(first . ,(lambda (tag . elems) (first elems)))
; because elems is a proper SXML node/list
; ignore attributes (@)
Your solution is not 100% right, though (ah, those nasty border cases):
(define identity-transforms
;; A string is seen converted to (*text* string) by pre-post-order
`((*default* . ,(lambda x x))
(*text* . ,(lambda (trigger str) str))))
(pre-post-order-proper '(Request (Prio 1) (stuff 3))
(append
`((Prio *macro* . ,(lambda x '()))
) identity-transforms))
-> (Request () (stuff 3))
ought to be: (Request (stuff 3)) for proper SXML.
>For a pure SXML-to-XML conversion, the splicing-in seems to be an
>overkill.
Indeed, SXML->X|HT|ML doesn't need it. It has proven useful so far.
Thank you very much again!
Jorg Hohle.
-------------------------------------------------------
This SF.net email is sponsored by OSDN developer relations
Here's your chance to show off your extensive product knowledge
We want to know what you know. Tell us and you have a chance to win $100
http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54