[Chicken-users] handling XML

[Ivan Shmakov]

>>>>> Peter Bex <address@hidden> writes:
>>>>> On Tue, Mar 12, 2013 at 08:15:14PM +0000, Ivan Shmakov wrote:

[…]

 >> Yet another idea is to prepare an XML document (using either
 >> notation) holding the “mostly static” part of the result, and also
 >> an XML document holding all the “repeated” (or “optional”) subtrees.
 >> Both the “insertion points” in the former, and such subtrees, are
 >> then marked, one way or another (e. g., I opted to use the HTML
 >> ‘class’ attribute), and the code simply composes the result by
 >> attaching such pieces to each other.

 > Is this code available somewhere?

        Not at this moment; hopefully, it'll be released by this fall.

        FWIW, the code is quite ad-hoc, even by the Perl standards, so I
        doubt that anyone could learn from it at this stage.  One of the
        flaws of the current algorithm is that it's “code-driven,” and
        not “data-driven”: instead of walking over the XML template and
        invoking the code as soon as a “marked” element is found — think
        of (xml-map (lambda (node) (cond (… (else node)))) dom) — or
        perhaps similarly with mutation — the code explicitly /searches/
        for the elements matching certain XPath expressions (hardcoded,
        too), one by one, and performs the respective edits to the tree.

        … BTW, is there a libxml binding for Chicken?  Unless I be
        mistaken, the library is widely considered to be the fastest XML
        engine currently in existence.

 > It sounds like a good alternative to SXML, but somewhat friendlier to
 > designers (who aren't likely to be using emacs with paredit :P).

        I believe it is!

        One more point is that with this approach, one could potentially
        combine many individual tools into a single processing
        environment, irrespective of the particular programming
        languages these tools are written in.  A kind of “Unix 2.0.”

 >> There's a minor convenience in the use of the “XML” notation for the
 >> templates, too: such templates may be constructed in a way that
 >> allows for them to be viewed with the target application itself
 >> (such as a Web browser, should XHTML be considered.)

 > The disadvantage of that notation is of course the opportunity for
 > generating ill-formed XML, unless you run some kind of parsing step
 > over it and raise an error as soon as you encounter bad
 > nesting/syntax.

        It's my understanding that a standards-compliant XML parser is
        /required/ to raise an error given an XML document that isn't
        well-formed.  (Obviously, it doesn't make a sense to claim that
        an “XML-based processing” is in use, unless the input XML
        document is indeed parsed first.)

[…]

-- 
FSF associate member #7257