Jarl Friis <····@softace.dk> writes:
> Hi.
>
> I am new to this group.
>
> Does anybody have experience with, or some links to, SAX2-parsers or
> DOM-parsers in lisp?
>
> Jarl
Try these links:
<http://ww.telent.net/cliki/XML>
<http://opensource.franz.com/xmlutils/index.html>
Cheers,
Edi.
Jarl Friis <····@softace.dk> writes:
> Does anybody have experience with, or some links to, SAX2-parsers or
> DOM-parsers in lisp?
I'm not sure that an event-driven parser like SAX or a DOM certified
representation is really usefull with Lisp. Lisp already deals with
tree representation of datas, why not using it?
I use the Franz package 'xml-utils' to transforms an XML document
into an S-expression. After that I can extract very easily my datas
from this expression. It's more straightforward than using a kind
of intermediate representation like DOM.
I've looked at the CL-XML project (http://www.cl-xml.org/) an it's
a blind implementation of DOM and SAX Java/C++ interfaces. Maybe
I've missed the point, but IMHO it doesn't use the potential of
Lisp for this job.
--
Frederic Brunel
Software Engineer
In-Fusio - Mobile Game Connections
On 29 Oct 2002, Frederic Brunel wrote:
[snip]
> I've looked at the CL-XML project (http://www.cl-xml.org/) an it's
> a blind implementation of DOM and SAX Java/C++ interfaces. Maybe
> I've missed the point, but IMHO it doesn't use the potential of
> Lisp for this job.
If the job is implementing other tech that expose the DOM to a greater
extent, it might be worth it (e.g., SVG or Javascript). (I'm not
convinced, but it does seem possible.)
Maybe semi-mechanical porting from other langauges' DOM code would be
easier? (Ok, that's a super reach.)
Hmm. Maybe documenting the code in a more or less language independant
way? I guess...
Cheers,
Bijan Parsia.
Hi.
Thanks for all the urls.
Frederic Brunel <···············@in-fusio.com> writes:
> Jarl Friis <····@softace.dk> writes:
>
> > Does anybody have experience with, or some links to, SAX2-parsers or
> > DOM-parsers in lisp?
>
> I'm not sure that an event-driven parser like SAX or a DOM certified
> representation is really usefull with Lisp. Lisp already deals with
> tree representation of datas, why not using it?
As far as I know both SAX(2) and DOM are API, i.e. programming
interfaces, which says nothing about internal data-representation. Am
I wrong here? In the case of DOM where the whole document is
eventually stored in-memory, the most intuitive representation in lisp
would be lisp-trees. But SAX(2) works by registering call-back
functions and is not ment to store XML data in-memory.
The reason that I was interested in SAX(2)/DOM is to use standard
function-names, so programs would be easier readable.
>
> I've looked at the CL-XML project (http://www.cl-xml.org/) an it's
> a blind implementation of DOM and SAX Java/C++ interfaces. Maybe
> I've missed the point, but IMHO it doesn't use the potential of
> Lisp for this job.
The point with SAX(2) is that you don't store any data while
processing an XML document using the SAX(2) API.
Jarl
Jarl Friis <····@softace.dk> writes:
> As far as I know both SAX(2) and DOM are API, i.e. programming
> interfaces, which says nothing about internal data-representation. Am
> I wrong here? In the case of DOM where the whole document is
> eventually stored in-memory, the most intuitive representation in lisp
> would be lisp-trees. But SAX(2) works by registering call-back
> functions and is not ment to store XML data in-memory.
Yes, you're right but to share my own experience using a SAX
parser with Java the thing is that you *always* end up by building
your own object hierarchy _in memory_ from an XML document. DOM is a
useless fat API with an huge memory footprint. It's really painfull
to navigate through the tree and none of its objects could be easily
mapped onto any of yours.
> The reason that I was interested in SAX(2)/DOM is to use standard
> function-names, so programs would be easier readable.
It is not the functions names which make your programs easier and
I'm still not convinced that a Java API is _not_ adapted to
Lisp. All these standards are built for Java-like languages and have
nothing to do with Lisp.
> The point with SAX(2) is that you don't store any data while
> processing an XML document using the SAX(2) API.
Storing anything during this process is impossible. What do you want
to use XML for?
--
Frederic Brunel
Software Engineer
In-Fusio - Mobile Game Connections
Frederic Brunel <···············@in-fusio.com> writes:
> Jarl Friis <····@softace.dk> writes:
> > As far as I know both SAX(2) and DOM are API, i.e. programming
> > interfaces, which says nothing about internal data-representation. Am
> > I wrong here? In the case of DOM where the whole document is
> > eventually stored in-memory, the most intuitive representation in lisp
> > would be lisp-trees. But SAX(2) works by registering call-back
> > functions and is not ment to store XML data in-memory.
>
> Yes, you're right but to share my own experience using a SAX
> parser with Java the thing is that you *always* end up by building
> your own object hierarchy _in memory_ from an XML document. DOM is a
> useless fat API with an huge memory footprint. It's really painfull
> to navigate through the tree and none of its objects could be easily
> mapped onto any of yours.
You are right, I think I was mostly interested in SAX(2) for the same
reason.
>
> > The reason that I was interested in SAX(2)/DOM is to use standard
> > function-names, so programs would be easier readable.
>
> It is not the functions names which make your programs easier and
> I'm still not convinced that a Java API is _not_ adapted to
> Lisp. All these standards are built for Java-like languages and have
> nothing to do with Lisp.
>
> > The point with SAX(2) is that you don't store any data while
> > processing an XML document using the SAX(2) API.
>
> Storing anything during this process is impossible. What do you want
> to use XML for?
You are right, I probably ment not storing the whole document ;-) or
no more than one tag-node at a time.
I intended to write an XEmacs front-end to KDE addressbook, but It seem
that KDE pim people havn't even started using XML as their file-format
yet. Now I just consider writing an XEmacs bookmark-editor front-end,
for that DOM (opposed to SAX) or lisp-trees seem most appropriate.
Anyway I'm just glad to have the URLs in case of another time.
Jarl
Jarl Friis <····@softace.dk> writes:
> You are right, I probably ment not storing the whole document ;-) or
> no more than one tag-node at a time.
Actually, this is not really a problem to load up the whole document
as a Lisp S-expression. The memory footprint of an S-expression is
insignifiant compared to a DOM representation.
> I intended to write an XEmacs front-end to KDE addressbook, but It seem
> that KDE pim people havn't even started using XML as their file-format
> yet. Now I just consider writing an XEmacs bookmark-editor front-end,
> for that DOM (opposed to SAX) or lisp-trees seem most appropriate.
Write your tool with an S-expression as the internal format and add
an import/export tool for XML.
--
Frederic Brunel
Software Engineer
In-Fusio - Mobile Game Connections
* Frederic Brunel wrote:
> Actually, this is not really a problem to load up the whole
> document as a Lisp S-expression. The memory footprint of an
> S-expression is insignifiant compared to a DOM representation.
This isn't really correct. However efficient the representation, you
can bet that someone somewhere is thinking about *really* large
instances. For systems like this snarfing the whole instance into
memory isn't always an option. Although you can now get machines big
enough, you might not want to pay for the memory for those machines.
Remember that XML is meant to be the ultimate data format[1] - it's
not just for stuff that people write, it's also for stuff like data
streams from supermarket tills and stockmarket data that people want
to mine, and these things can generate really a lot of data.
Even for stuff that people write, there is the famous joke about
airliners not being able to lift their documentation (and it might be
quite reasonable to treat the service and design manuals of an
airliner as one huge document for some purposes).
--tim
Footnotes:
[1] This will turn out to be self-fulfilling: XML will eventually
destroy civilization, and thus can be assured of being the last
data format, anyway.
+ Tim Bradshaw <···@cley.com>:
| Remember that XML is meant to be the ultimate data format[1] [...]
|
| Footnotes:
| [1] This will turn out to be self-fulfilling: XML will eventually
| destroy civilization, and thus can be assured of being the last
| data format, anyway.
A very graphic illustration of the supreme suckiness of XML - in this
case, MathML - can be admired over in sci.math.research.
See <···················@nef.ens.fr> (or, if your news browser insists
on a "real" URL, <························@nef.ens.fr>).
Be sure to have a barf bag handy before looking, unless you're already
hardened by extensive previous exposure to the stuff.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- Yes it works in practice - but does it work in theory?
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> A very graphic illustration of the supreme suckiness of XML - in this
> case, MathML - can be admired over in sci.math.research.
I find the simpler stuff even more fascinating, especially the
plists. Free advice for Apple: If you want to turn your Jaguar into an
Laborghini, go back to your old-fashioned plists. Here's all the cruft
Apple needs in order to represent the plist
(:mcx-preferences-are-managed t)
(whatever that means):
[white:/Library/Preferences] ev% cat com.apple.MCX.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>MCX_PreferencesAreManaged</key>
<string>NO</string>
</dict>
</plist>
(interestingly, they use a less insane format for their "StartupItems" -
maybe because that speeds up boot time??
[white:Library/StartupItems/Sendmail] ev% cat StartupParameters.plist
{
Description = "Sendmail mail server";
Provides = ("SMTP");
Requires = ("DirectoryServices");
Uses = ("Disks", "Network Time", "NFS");
OrderPreference = "None";
}
)
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Laborghini
sorry for misspelling that, I hope I won't get flamed by Italians
or Lamborghini owners.
--
(espen)
"from Norway^H^H^H^H^H^Hc.l.l. - home of the Trolls"
Espen Vestre <·····@*do-not-spam-me*.vestre.net> writes:
> Harald Hanche-Olsen <······@math.ntnu.no> writes:
>
> > A very graphic illustration of the supreme suckiness of XML - in this
> > case, MathML - can be admired over in sci.math.research.
>
> I find the simpler stuff even more fascinating, especially the
> plists. Free advice for Apple: If you want to turn your Jaguar into an
> Laborghini, go back to your old-fashioned plists. Here's all the cruft
> Apple needs in order to represent the plist
>
> (:mcx-preferences-are-managed t)
>
> (whatever that means):
>
> [white:/Library/Preferences] ev% cat com.apple.MCX.plist
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
> <plist version="1.0">
> <dict>
> <key>MCX_PreferencesAreManaged</key>
> <string>NO</string>
> </dict>
> </plist>
Ah yes, now doesn't that look "Modern"? Not at all old like the NeXT
way of doing plists...
> [white:Library/StartupItems/Sendmail] ev% cat StartupParameters.plist
> {
> Description = "Sendmail mail server";
> Provides = ("SMTP");
> Requires = ("DirectoryServices");
> Uses = ("Disks", "Network Time", "NFS");
> OrderPreference = "None";
> }
:-P
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Tim Bradshaw writes:
> [1] This will turn out to be self-fulfilling: XML will eventually
> destroy civilization, and thus can be assured of being the last
> data format, anyway.
I have this idea for a science-fiction story, where someone goes
forward in time, say, 5000 years. Everything is different; the
languages have changed, computers are all `sentient' to all intents
and purposes and so on.
At some point in the story the protagonist is in the presence of
people who are trying to fix or heal some computer. They get down to
the very lowest level, which they find incomprehensible. The
protagonist says, "I know that, it's XML!" :-)
--
Fred Gilham ······@csl.sri.com || Progressive (adj): Value-free;
tolerant; non-judgemental. E.g. traditional archery instruction
methods spent tedious hours teaching the archer to hit a bulls-eye.
Progressive methods achieved better results by telling the student
archer to shoot in the manner he or she found most comfortable, then
calling whatever the arrow hit the bulls-eye.
Fred Gilham <······@snapdragon.csl.sri.com> writes:
> I have this idea for a science-fiction story, where someone goes
> forward in time, say, 5000 years. Everything is different; the
> languages have changed, computers are all `sentient' to all intents
> and purposes and so on.
>
> At some point in the story the protagonist is in the presence of
> people who are trying to fix or heal some computer. They get down to
> the very lowest level, which they find incomprehensible. The
> protagonist says, "I know that, it's XML!" :-)
If the sentient computers are using XML, then they are not sentient.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@telus.net The Rhythm has my soul.
Ray Blaak <·····@telus.net> wrote in ··················@telus.net:
> Fred Gilham <······@snapdragon.csl.sri.com> writes:
>> I have this idea for a science-fiction story, where someone goes
>> forward in time, say, 5000 years. Everything is different; the
>> languages have changed, computers are all `sentient' to all intents
>> and purposes and so on.
>>
>> At some point in the story the protagonist is in the presence of
>> people who are trying to fix or heal some computer. They get down to
>> the very lowest level, which they find incomprehensible. The
>> protagonist says, "I know that, it's XML!" :-)
>
> If the sentient computers are using XML, then they are not sentient.
>
What if they are just very stupid? They came up with self aware computers
then retrofited XML on to them after, so they could not rule the world.
marc
> I intended to write an XEmacs front-end to KDE addressbook, but It seem
> that KDE pim people havn't even started using XML as their file-format
> yet. Now I just consider writing an XEmacs bookmark-editor front-end,
> for that DOM (opposed to SAX) or lisp-trees seem most appropriate.
Emacs (and XEmacs) is provided with a simple and efficient parsing
library. Just do M-x load-library <xml> and that's it, you can parse
XML documents.
The API is just straightforward:
* (defvar bookmark (car (xml-parse-file "~/.galeon/bookmark.xbel")))
bookmark
* (xml-node-children bookmark)
((info nil (metadata (...) ...)))
* (xml-node-attributes bookmark)
((version . "1.0"))
--
Frederic Brunel
Software Engineer
In-Fusio - Mobile Game Connections
* Jarl Friis wrote:
> Does anybody have experience with, or some links to, SAX2-parsers or
> DOM-parsers in lisp?
I'd like to back up what someone else said about this. if you want
systems that work, then the best use of XML is not to use it. If you
have to use it (presumably to avoid being lynched by the XML
mob), then the best thing to do is to use an XML parser which is the
thinnest possible shim to convert things to some Lisp representation.
Doing this means that you get to be buzzword-compliant (`uses an
XML-based syntax' is pretty much compulsory in the description for any
program, *whatever* it does, now) without having to understand 9,000
pages of badly-written, rapidly changing and contradictory `standards,
which will ultimately turn out to be completely inadequate to solve
whatever problem you have anyway, however simple it is.
Unfortunately the XML mob, having lynched all the easy targets, is
becoming more demanding, since it requires more blood, and you may
well find that you have to conform with an increasingly large amount
of XML's cancerous encrustations. This means that your program won't
work any more, and you will have to employ 50 or 60 people to maintain
it as the standards change. But this is OK - no one else's program
will work either.
--tim
On 29 Oct 2002 12:24:02 +0000, Tim Bradshaw <···@cley.com> wrote:
> I'd like to back up what someone else said about this. if you want
> systems that work, then the best use of XML is not to use it. If you
This reminds me of the War Games movie (from memory): "the only way to win
is not to play".
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
> * In message <··············@zeus.intra.softace.dk>
> * On the subject of "XML parser"
> * Sent on 29 Oct 2002 10:47:12 +0100
> * Honorable Jarl Friis <····@softace.dk> writes:
>
> Does anybody have experience with, or some links to, SAX2-parsers or
> DOM-parsers in lisp?
see CLOCC/CLLIB/xml.lisp <http://www.podval.org/~sds/cllib.html>
--
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
To a Lisp hacker, XML is S-expressions with extra cruft.