Re: Lua

[Jay Carlson <nop@...>]

On Wed, 3 Mar 2004, Stewart, Joseph wrote:

> Hello all, I'm anxious to try out LuaXMLRPC but I can't seem to find part of
> the distribution.
>
> Earlier Jay Carlson ask the same thing:
>
> >> The Kepler Project has released the first alpha of LuaXMLRPC 1.0.
> >
> ...
> >
> > One of the first lines in xmlrpc.lua is
> >
> >   require "dom"
> >
> > and I can't find that file.
>
> But based on his later postings seems to have gotten things working. Is
> there a missing file or am I just mis-understanding the code?

I've never actually run the Kepler LuaXMLRPC 1.0, as it is indeed
missing that file.  Most of what I've said about it is based on code
examination, with what I hope are reasonable assumptions about how the
dom module has to work.

I'm having off-list discussions with the authors, who have been very
polite and responsive to the issues I brought up.  All of us want a
good implementation that has, well, let's be honest, an active
maintainer, and that's not me.

About dom:

There are only a few reasonable mid-level ways to represent XML in
idiomatic Lua and I think everyone comes up with something similar,
differing mostly in naming details.  For example, we can look at some
of the XML grammar productions:

   [39] element ::= EmptyElemTag | STag content ETag
   [40] STag ::= '<' Name (S Attribute)* S? '>'
   [44] EmptyElemTag ::= '<' Name (S Attribute)* S? '/>'

The dom module appears to represent the "Name" of an "element" as
t.tag; the stuff I posted recently under the name XmlTree represents
it as t.name.  Neither one is necessarily more correct.  But they are
really the same data---with the possible exception of how namespace
goo is represented.

Part of why I'm shoving LazyKit out into the world before it's fully
baked is to try to force discussion of these issues.  By my informal
count, there are at least five incompatible but essentially identical
mid-level XML representations in private use by various lua-l posters.
I am not convinced that I have made the correct, tasteful choices in
LazyKit.  But in the absense of discussion and publication (hopefully
in code), there's not much I can do besides ship what I have.

One temporary bright spot I see is that, at least for read-only
access, it's about half an hour's work to write metatable wrappers for
the various complete-tree representations such that their parsers can
produce suitable trees to interoperate with other people's code. :-)

(Substituting lazytree is harder, because of a design choice in
ipairs; lazytree really does need a special iterator.  But that
iterator can be trivially compatible with other physical
representations.)

Jay