Re: XMLRPC 0.0 for Lua

["Jay Carlson" <nop@...>]

"Martin Spernau" <martin@traumwind.de> writes:

[XMLRPC 0.0]

> Wow! This is great news!
>
> two questions:
> 1) have you / will you add your Implementation to the list :
> http://www.xmlrpc.com/directory/1568/implementations
> ?

After more people than me have successfully run it.  :-)  Actually the
target audience for this is one particular person, and he's not awake yet.
But sure, especially after I write more documentation.

> 2) is there a big difference in using expat as parser to using plain Lua?
> Maybe one should try and make some tests...

Go ahead, it shouldn't be that hard.

The big motivation for expat was a guarantee of correct XML tokenization.
There are lots of little annoying issues in XML, even in the XML-RPC DTD,
and I wanted to know somebody else had taken care of them.  Speed wasn't the
issue.

Right now, there is an bad dependence of XMLRPC on LxpTree because of
whitespace handling.  Lemme explain.

LxpTree normally parses

    <a>   <hello>world</hello>   </a>

as

    {"a", "   ", {"hello", "world"}, "   "}

I tried to design a mode where character data would only be reported for
certain terminals, such that whitespace wouldn't screw up the trees.  I want

    <value>
        <i4>7</i4>
    </value>

to parse as {"value", {"i4", "7"}} instead of {"value", "\n\t   ", {"i4",
"7"}, "\n\t"}.  Oh, and for my purposes, all adjacent strings should be
merged; given "<q>a&amp;b</q>", expat is allowed to return {"q", "a", "&",
"b"} when I want {"q", "a&b"}.

So LxpTree has a mode where you can specify particular tags as wanting
chardata, and it'll also merge all chardata in a node to the end.  Except
that my code is badly written, and I'm not sure why it works.

What I may do is implement a post-processor for trees to merge/eliminate
whitespace and that should improve conformance and allow other XML parsing
implementations to be dropped in.

Jay