Hello all
I would like to extract information from XML using lisp for further
processing. Which resources are availalbe for reading XML file either
even driven or storing all the information contained in the XML file
withing a lisp data structure?
Alfonso Esteban Gonzalez Sencion <·······@alcatel.es> writes:
> I would like to extract information from XML using lisp for further
> processing. Which resources are availalbe for reading XML file either
> even driven or storing all the information contained in the XML file
> withing a lisp data structure?
If you don't care about the lisp implementation, I suppose you can
use the XML parser from Emacs. It converts an XML document to an
S-expression. After that process, it's very easy to extract
informations. Do you have any examples?
--
Frederic Brunel
On Tue, 14 Oct 2003 09:49:17 +0200, Alfonso Esteban Gonzalez Sencion <·······@alcatel.es> wrote:
> I would like to extract information from XML using lisp for further
> processing. Which resources are availalbe for reading XML file
> either even driven or storing all the information contained in the
> XML file withing a lisp data structure?
<http://www.cliki.net/XML>
While we're on the subject, I was wondering which of the Common Lisp
XML libraries are considered the "best", or at least which one is the
most used. After my rants about CL needing consolidation for sockets,
threads and XML I guess I should put my coding where my mouth is and
use what's closest to a "standard".
Alfonso Esteban Gonzalez Sencion <·······@alcatel.es> wrote:
>Hello all
>
>I would like to extract information from XML using lisp for further
>processing. Which resources are availalbe for reading XML file either
>even driven or storing all the information contained in the XML file
>withing a lisp data structure?
>
>
>
>
Oops! Alfonso Esteban Gonzalez Sencion <·······@alcatel.es> was seen spray-painting on a wall:
> I would like to extract information from XML using lisp for further
> processing. Which resources are availalbe for reading XML file either
> even driven or storing all the information contained in the XML file
> withing a lisp data structure?
I use the code below which uses the Expat parser to parse XML (or
SGML); the code below represents a "driver" that transforms the output
into Lisp S-expressions that may be read in using READ.
So I READ the stream in, giving me a list which I can then walk
through for whatever purpose I choose.
The main purpose I use it for is to walk through Galeon and Epiphany
bookmark files to transform them into "nearly DocBook SGML" output.
What was _most_ interesting was when I did the Epiphany "list walker."
I copied over the Galeon version, and expected to need to rewrite a
fair bit of the code (since the XML is "shaped" a bit differently).
To my surprise, it worked _perfectly_ after changing barely more than
the names of the symbols that it was looking for.
That was dually surprising:
- Working perfectly the first time;
- FAR fewer changes than expected; about 95% of the code was
identical.
It's arguably "evil" because it uses a C program; it will
comprehensively parse any legitimate XML or SGML, which is all the
apology I need.
One of these days, I ought to rewrite my web pages from DocBook into
Lisp, and I would certainly need the full SGML form to do that :-).
--
(reverse (concatenate 'string "gro.gultn" ·@" "enworbbc"))
http://cbbrowne.com/downloads/expat-parser.c
Faith is the quality that enables you to eat blackberry jam on a
picnic without looking to see whether the seeds move. -- DeMara Cabrera
mmmhhh... Just an idea, you could use xslt with xalan (in java or c++) to transform an XML file
into S-expressions that will be later loaded into lisp.
That could solve my problem too, but I would rather prefer to have everything in lisp.
Christopher Browne wrote:
> Oops! Alfonso Esteban Gonzalez Sencion <·······@alcatel.es> was seen spray-painting on a wall:
> > I would like to extract information from XML using lisp for further
> > processing. Which resources are availalbe for reading XML file either
> > even driven or storing all the information contained in the XML file
> > withing a lisp data structure?
>
> I use the code below which uses the Expat parser to parse XML (or
> SGML); the code below represents a "driver" that transforms the output
> into Lisp S-expressions that may be read in using READ.
>
> So I READ the stream in, giving me a list which I can then walk
> through for whatever purpose I choose.
>
> The main purpose I use it for is to walk through Galeon and Epiphany
> bookmark files to transform them into "nearly DocBook SGML" output.
>
> What was _most_ interesting was when I did the Epiphany "list walker."
> I copied over the Galeon version, and expected to need to rewrite a
> fair bit of the code (since the XML is "shaped" a bit differently).
> To my surprise, it worked _perfectly_ after changing barely more than
> the names of the symbols that it was looking for.
>
> That was dually surprising:
> - Working perfectly the first time;
> - FAR fewer changes than expected; about 95% of the code was
> identical.
>
> It's arguably "evil" because it uses a C program; it will
> comprehensively parse any legitimate XML or SGML, which is all the
> apology I need.
>
> One of these days, I ought to rewrite my web pages from DocBook into
> Lisp, and I would certainly need the full SGML form to do that :-).
> --
> (reverse (concatenate 'string "gro.gultn" ·@" "enworbbc"))
> http://cbbrowne.com/downloads/expat-parser.c
> Faith is the quality that enables you to eat blackberry jam on a
> picnic without looking to see whether the seeds move. -- DeMara Cabrera
>>>>> "Alfonso" == Alfonso Esteban Gonzalez Sencion <·······@alcatel.es> writes:
Alfonso> mmmhhh... Just an idea, you could use xslt with xalan (in
Alfonso> java or c++) to transform an XML file into S-expressions
Alfonso> that will be later loaded into lisp.
Alfonso> That could solve my problem too, but I would rather
Alfonso> prefer to have everything in lisp.
Hey, there's an interesting idea... at least one which might help out
a pet peeve I have. I work with this huge Java web-app, which uses
Xalan and XSLT for page rendering, and it's really slow. The pages are
rather large, with lots of bits done dynamically, and I'd been
wondering if a compiled Lisp versions of each page (i.e. one page
template becomes a new function) would speed it up. Has anyone tried
this sort of thing?
Tim Lavoie <········@spamcop.net> writes:
>>>>>> "Alfonso" == Alfonso Esteban Gonzalez Sencion <·······@alcatel.es> writes:
>
> Alfonso> mmmhhh... Just an idea, you could use xslt with xalan (in
> Alfonso> java or c++) to transform an XML file into S-expressions
> Alfonso> that will be later loaded into lisp.
>
> Alfonso> That could solve my problem too, but I would rather
> Alfonso> prefer to have everything in lisp.
>
> Hey, there's an interesting idea... at least one which might help out
> a pet peeve I have. I work with this huge Java web-app, which uses
> Xalan and XSLT for page rendering, and it's really slow. The pages are
> rather large, with lots of bits done dynamically, and I'd been
> wondering if a compiled Lisp versions of each page (i.e. one page
> template becomes a new function) would speed it up. Has anyone tried
> this sort of thing?
Yes. The Web front-end to my SCM project does exactly this. The page
templates are lisp source code. When the server gets a request for a
page, it loads the template, compiles it, and caches the result. It's
pretty zippy once the pages get cached (and of course I check
timestamps on the file so you don't have to do anything when you
update a template). The compilation is a tad slower than I would
like, though.
>>>>> "Joe" == Joe Marshall <···@ccs.neu.edu> writes:
Joe> Tim Lavoie <········@spamcop.net> writes:
>> Hey, there's an interesting idea... at least one which might
>> help out a pet peeve I have. I work with this huge Java
>> web-app, which uses Xalan and XSLT for page rendering, and it's
>> really slow. The pages are rather large, with lots of bits done
>> dynamically, and I'd been wondering if a compiled Lisp versions
>> of each page (i.e. one page template becomes a new function)
>> would speed it up. Has anyone tried this sort of thing?
Joe> Yes. The Web front-end to my SCM project does exactly this.
Joe> The page templates are lisp source code. When the server
Joe> gets a request for a page, it loads the template, compiles
Joe> it, and caches the result. It's pretty zippy once the pages
Joe> get cached (and of course I check timestamps on the file so
Joe> you don't have to do anything when you update a template).
Joe> The compilation is a tad slower than I would like, though.
The existing Java+Xalan+Xerces setup does some one-shot parsing and
caching of the XSL templates the first time after the server is
started, but the transform times can still be quite long (seconds). It
would be better if it saved the "compiled" template for next time, as
happens with regular JSP templates, and real executable code would be
better yet. I know Lisp could do this well, but playing nicely with the
existing setup may be more trouble than it is worth.
Some of this of course can't be blamed on XSL, at least directly; its
complexity has led to some blind cut-n-paste template coding, with
evil speed penalties, but that is another issue. Lackeys will be
beaten.
Cheers,
Tim
--
"Experience is simply the name we give our mistakes."
--Oscar Wilde
Tim Lavoie wrote:
>
> >>>>> "Alfonso" == Alfonso Esteban Gonzalez Sencion <·······@alcatel.es> writes:
>
> Alfonso> mmmhhh... Just an idea, you could use xslt with xalan (in
> Alfonso> java or c++) to transform an XML file into S-expressions
> Alfonso> that will be later loaded into lisp.
i don't think i could think i could sleep nights if i were to recommend that
to someone with a straight face.
there are numerous lisp-only xml parsers. for many uses, eg on the order of
the document entity from simple-xml[0] with an s-expression document model,
and only the unicode support inherent in the respective lisp runtime, the
whole thing fits in one function.
> Alfonso> That could solve my problem too, but I would rather
> Alfonso> prefer to have everything in lisp.
>
> Hey, there's an interesting idea... at least one which might help out
> a pet peeve I have. I work with this huge Java web-app, which uses
> Xalan and XSLT for page rendering, and it's really slow. The pages are
> rather large, with lots of bits done dynamically, and I'd been
> wondering if a compiled Lisp versions of each page (i.e. one page
> template becomes a new function) would speed it up.
most likely. it would be hard not to.
> Has anyone tried
> this sort of thing?
there are also any number of html-template libraries. have you tried them?
what does the given page rendering require which argued for xslt in the first place?
i've gone far enough down that road to be able to compare how i would be able
to code page generation using a lisp-internal xslt compiler, v/s how i can
code page generation using concise access and generation expressions, but
without xslt pseudo-rewrite semantics. i decided i neither needed, nor wanted
to go any further.
[0] http://www.w3.org/XML/simple-XML.html
>>>>> "james" == james anderson <··············@setf.de> writes:
james> i don't think i could think i could sleep nights if i were
james> to recommend that to someone with a straight face.
james> there are numerous lisp-only xml parsers. for many uses, eg
james> on the order of the document entity from simple-xml[0] with
james> an s-expression document model, and only the unicode
james> support inherent in the respective lisp runtime, the whole
james> thing fits in one function.
I suppose, but Xalan is already used, and familiar to the Powers That Be.
>> [ ... ] I'd been wondering if a compiled Lisp versions
>> of each page (i.e. one page template becomes a new function)
>> would speed it up.
james> most likely. it would be hard not to.
No kidding. Let's just assume that (lack of) performance is a known
issue here. :(
>> Has anyone tried this sort of thing?
james> there are also any number of html-template libraries. have
james> you tried them? what does the given page rendering require
james> which argued for xslt in the first place?
The primary issue is that XSLT is used in both the web and desktop
apps, with all the inertia of being deployed in production
environments. In any case, I'm quite new there, so I get neither the
blame for the design, nor much say in how to improve things. On the
other hand, if some spare-time effort demonstrates an improvement
without breaking everything else, then I'd likely be given the time
really test things out.
james> i've gone far enough down that road to be able to compare
james> how i would be able to code page generation using a
james> lisp-internal xslt compiler, v/s how i can code page
james> generation using concise access and generation expressions,
james> but without xslt pseudo-rewrite semantics. i decided i
james> neither needed, nor wanted to go any further.
Heh. I'm not sure I want to either; I've done lots of web-app
programming (non-Lisp so far), but with little exposure to XSLT up to
now. XSL strikes me as pretty hideous, but it's already there, and
likely to stay. Beating it into submission would be nice though.
james anderson <··············@setf.de> writes:
> Tim Lavoie wrote:
>>
>> >>>>> "Alfonso" == Alfonso Esteban Gonzalez Sencion <·······@alcatel.es> writes:
>>
>> Alfonso> mmmhhh... Just an idea, you could use xslt with xalan (in
>> Alfonso> java or c++) to transform an XML file into S-expressions
>> Alfonso> that will be later loaded into lisp.
>
> i don't think i could think i could sleep nights if i were to recommend that
> to someone with a straight face.
You need to develop a better sense of schadenfreude.
I can suggest in all seriousness that it would be reasonable to
manipulate XML with Visual Basic (all you need is a Perl shim talking
SOAP and you can generate the rest from an IDL file).
This alone is worth hours of entertainment.