chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] sxml and more


From: Peter Bex
Subject: Re: [Chicken-users] sxml and more
Date: Fri, 25 Jul 2014 21:02:50 +0200
User-agent: Mutt/1.4.2.3i

On Fri, Jul 25, 2014 at 08:54:02PM +0200, Nathaniel Rudavsky-Brody wrote:
> Hello,
> 
> Since this is my first post, let me say how happy I've been since I
> discovered Chicken: thanks everyone for creating such a well-thought-out
> environment.

Hi Nathaniel, and welcome to the coop :)

> I've got a general question about the sxml tools. I've been using the
> top-level functions for a while now, for tasks I *could* do in XSLT, but
> prefer doing in Scheme. I've always found the lower-level interface(s) a
> bit intimidating.

Yeah, SXML is kind of tricky.

> But recently I got stuck on the lack of namespaces in sxml-modify, and
> started wondering if it would be possible to rewrite it, and then... well
> more generally, whether it's worth learning how to use the low-level tools,
> and what I could do with them. Or are pre-post-order and sxpath and
> sxml-path as good as it gets, for an average user like me? When I search
> around the web, I can't seem to find examples of more advanced uses of the
> tools (or at least, well-documented ones...).

If you'd like better examples or have specific questions about SSAX/SXML,
you can always try the official sourceforge project's mailinglist.
It looks dead, but there are people subscribed and when questions are
asked they do respond.  They're friendly, knowledgeable and helpful.

The biggest problem of the SSAX/SXML project is that it's basically just
a grab-bag of random libraries written around (various versions of) a
common representation.

The people who thought up the representation were pretty thorough in
modeling the complete set of standards surrounding XML, and they wrote a
very impressive set of tools for it, but for some reason it just feels
thrown together.  The naming is inconsistent, there are several
procedures that perform more-or-less the same task, and it's not built
with modularity in mind at all (we just tried very hard to extract what
seems to us as clean boundaries, and packaged those up as separate eggs).

There's been some interest in starting from scratch, using the SXML spec
as a basis, to make a consistent and well-thought-out library. 
Unfortunately, that's just an idea: there's nobody to actually put in
the massive amounts of time to actually *do* it :)
It doesn't help that SXML, as it is, is useful enough to get things done,
however painful it may be.  I guess this is a good example of "worse is
better" in action.

Sorry to disappoint,
Peter
-- 
http://www.more-magic.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]