On Mon, Mar 25, 2013 at 01:58:48PM -0600, Matt Gushee wrote: > SXML itself is clearly a good thing, and the tools > seem to work very well. And yet, looking at the APIs, there are these > maddening inconsistencies, and even looking at each egg in isolation > ... for example, what's up with the name 'SRV:send-reply'. How does > that relate to anything? So I'm wondering if it wouldn't be a good > idea at some point for those who work with sxml-tools and its > descendants to get together and design a more unified and usable > API(s).
Hi Matt! Glad you're suggesting this. The idea of rewriting/polishing SSAX has been idly raised in #chicken a few times. I think we all (that is, from the Chicken side of things) agree that the SXML tools really need an update, but nobody has enough time to put in the massive effort this would require. And, speaking for myself only, I don't have nearly enough knowledge of the underlying XML technology to approach this task on my own. I haven't yet asked this on the official SSAX mailinglist because it would be rude to suggest improvements without willing to put in time and effort to at least help out. At least I've raised a few concerns about the confusing multitude of APIs (there are at least 3 different APIs for doing SXML transformations in the SSAX tree), but this was seen as an advantage; each API has its own strong points. I think with the R7RS module system, the awkward API could be mostly simplified and the weird prefixes dropped. Then, for example, each alternative sxml-transformation implementation could be a different module implementing the same API. Switching would simply be a matter of changing the imported module. This would require proper modularisation, though. Currently the SSAX project is a sprawling set of files which are very tightly coupled. We've tried to untangle these as much as possible, which is why we have several eggs rather than one "SSAX kitchen sink" egg. However, we've also gotten some criticism for doing so. By the way, there's also some inconsistency as to how auxiliary information is stored. At one point the spec defined an "aux-list" to be (@@ (X Y)), and later it was generalized a little to (@ (@ (X Y))). However, some of the tools still only accept the earlier notation. Also, none of the tools consistently produce or even consume "*parent*" pointers, which could make things even more powerful and on par with the "official" DOM spec from the W3C (but this would require a post-processing step after the SXML is generated from quoted list input). Finally, some of the SSAX assume support for an arbitrary count of arguments in the host Scheme system. We've had to do some surgery in a few places to remove these limitations (Chicken, as you probably know, supports only a guaranteed number of 128 arguments with plain C, and 1024 (IIRC) with the optional assembly "manyargs" apply-hack). Unfortunately, the main sxml-transforms API itself is written with this limitation to the core, rules accepting varargs bound to a node's contents, which limits the size of XML documents Chicken SSAX code can handle. We've provided additional variants (ending with a *) which implement a slightly modified API that passes the node contents in a list. All these things make for a very weird, nonstandard SSAX implementation in Chicken and makes it hard to share code. I've never really needed namespaces much, but you're right, some of the APIs don't even deal with namespaces *at all*, like sxml-modif one, as I found out when writing a blog post about the SXML design, at http://more-magic.net/posts/lispy-dsl-sxml.html Others just don't handle them consistently. All this is a consequence of them being an afterthought. A clean solution should be found for this, because the current approach of just sticking a namespace prefix onto the symbol doesn't scale, and is hard to deal with programmatically. The above things are the minimum of things to be addressed in a reimplementation/"SSAX improved". > I know sxml-fu is intended to address that need, but it seems > kind of ad-hoc and limited scope. Just a thought. Actually, it isn't really. It only aims to provide a few convenience procedures. It's also mostly dead, because the API is, as you pointed out, rather ad-hoc and messy, and too special-purpose to be of any real use. Cheers, Peter -- http://www.more-magic.net _______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
