Julian Graham wrote:
Glad you guys agree -- can I perhaps interest you in a discussion of the technical details of such a package?
See, it was on purpose I didn't go there. I didn't want to intimidate you or scare you away from SSAX which I'm sure can be helpful almost regardless of what it does.
But, on my wish list:
~ both streaming and DOMish APIs
~ get the Unicode processing within such perfect
~ get namespace handling perfect
~ don't forget to properly handle processing instructions and comments
~ handle insignificant whitespace well (see below about representation-agnostic...)
~ get the parsing and printing perfect
~ include an accurate XML pretty-printer
~ performance, space and time, are critical
~ DOM and SAX models should be representation-agnostic: ~~ handle in-core, abstractly represented datums ~~ make it possible to read and pretty print datums while PRESERVING insignificant whitespace! ~~ allow DOM and SAX models to refer to external, lazily-read resources -- e.g., I want to use DOM over a datum that is still largely on disk
~ XPATH-based accessors are critical. They should work well for XPATHs generated on-the-fly at run-time. They should work even better if the query is known ahead of time and can be compiled.
~ XSLT and XQUERY: these matter, a lot, and in theory Scheme engines should really shine here (perhaps see what Per Bothner's been up to)
~ Schema checking (DTD and XSchema) matters a lot -- and should be implemented very accurately
~ A loosey-goosey "approximate HTML" parser is critical
~ An HTML pretty-printer that satisfies common browsers is critical -- c.f. the html output mode of XSLT processors
~ the nasty hard part: interoperability with foreign functions matters (but probably can't be done perfectly). Have a look at Xerxes and XQilla, for example. This is a real hard problem for HLLs that like to be combined with foreign C and C++ libraries: too many same-but-different DOM APIs in one process.
~ it should all be very fast
~ probably will take a week or two to write :-)
Given that there's a disparity in terms of exports among the various distributions for different Scheme platforms, I think it might be wise to choose a particular distribution and then re-port it to the requisite interpreters. The distribution I'm most familiar with is the one in guile-lib (http://home.gna.org/guile-lib/), but, unfortunately, it's a bit messy under the hood, since it includes, I think (could be wrong), an old stable release of SSAX coupled with some upstream work, so I don't know if it makes the easiest base for doing a port. Does anyone have any experience with any of the other ones, like PLT's?
The SSAX functionality that's most important to me is:
- ssax:xml->sxml (obviously)
- The ssax:make-parser syntax, for customizing parser behavior
- The utility functions used by the default parser, such as
ssax:skip-internal-dtd, ssax:read-pi-body-as-string, etc., since these make customizing the parser much, much easier.
Thoughts?
I have experience with a few 80% solutions in other languages. I have a decent amount of experience with XML generally.
You frighten me with your eagerness to customize parsers -- that seems to rather miss the point of an exchange format.
80% solutions can be used for lots of stuff -- almost anything you do will be useful.
80% solutions tend to fall down hard as soon as you run into items from my requirements list above.
Perhaps my serious suggestion is: don't worry so much. Just get a package out there that does any damn thing that might be useful and then go from there. Separate concerns: a snowball for XML processing that happens to have some mud in it is a good place to start -- then separately, start making that snowball really top-notch. Don't make "getting XML in Scheme perfect" a pre-condition for "here's a snowball for XML processors".
-t
On 7/12/07, Thomas Lord lord@emf.net wrote:
All-things that get to root of making W3C-ish stuff better in portable Scheme are, in some sense, worth a heck of a lot.
Scheme traditionally spends a lot of effort getting right very general, widely applicable numerical data; XML data and the protocols associated with it deserve just about as much attention, and for similar reasons (in my opinion).
-t
Ezequiel Birman wrote:
I'd love to see SXML/SSAX as a snow package. Being new to scheme, it tooked me a lot of time to figure out how to install it for SCSH and Scheme48.
Snow-users-list mailing list Snow-users-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/snow-users-list
Snow-users-list mailing list Snow-users-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/snow-users-list