Common Lisp support for the
'Extensible Markup Language'
(CL-XML)

james anderson,

CL-XML is a collection of Common LISP modules for data stream parsing and serialization according to the "Extensible Markup Language" and anscilliary standards. The modules perform parsing and serialization between XML, XML Query, and XML Path expressions and DOM-compatible CLOS instances. The XML processor includes a conformant, validating, namespace-aware model-based parser. It supports, in particular, namespace-aware DTD-based validation. The XPATH module comprises LISP bindings for the XML Path library, an S-expression-based namespace-aware path model, and a macro-based path model compiler which implements an XPATH-algebra. The XQUERY module comprises LISP bindings for the XML Query library, an S-expression-based query model which incorporates the XPATH facilities, and a macro-based query compiler. The base CLOS model implements the XML Query Data Model in a class hierarchy which presents an Infoset compatible programming interface.

A description is available here.

Availability

BNF

The respective BNF descriptions of the respective XML, XPath, and XQuery syntax used to generate the parsers are available individually. In some cases, they have been normalized and otherwise edited to expedite parsing. I'd be interested to hear if any of the modifications would appear to affect conformance.

Source

The following source archives are available.

0.913
This release includes support for name instances. It is available initially as a .sit file only.
0.911
The source tree has been updated to 0.912
[ In-progress source is available for the curious in the code tree. Use the system definition file for reference.]
0.908
This version supports full HTTP client access with CL-HTTP and HTTP/1.0 access when compiled stand-alone.
Each archive employs the line ending and source file type appropriate for the respective platform.
previous versions
0.906 mcl, allegro
0.901 mcl

Examples

graphs
I was curious about how an automatic layout package would fare with DTD and DOM graphs. A naive generator for GraphViz's "dot" format is a straight-forward graph walk. The results are adequate for smaller examples, but larger instances will need a more refined approach. The larger files failed to load with the current GraphViz 1.7.6 beta for Windows. As I'm rather Linux/C imparied, I was fortunate and grateful, that someone was curious and ran them through the Linux version. Thus the two SVGs below, which I was able to view with Adobe's SVG plugin.

email (from "xml:tests:xml:email.xml") : DOM, DTD
channel (from "xml:tests:xml:channel.xml"): DOM, DTD
REC-xml-20001006.xml: DTD as DOT, as SVG(768K)
REC-xhtml1-20000126.html: DTD as DOT, as SVG(444K)

Anyone curious about DOCBOOK?

xquery / use case NS issues
Use-case NS of WD-xmlquery-use-cases-20010608 reserved the publication of a DTD until schemas were available. It is not clear that this delay is necessary. The documents below were processed, validated, and serialized with 0.908+

AuctionWatchList.xml
AuctionWatchList.dtd
record.dtd
AuctionWatchListOut.xml

© setf.de 2001 [20010910]