Comments requested from anyone who has used SXML or xexprs...
I've almost finished a set of new PLaneT packages for a new variation on SXML and PLT xexprs, and am second-guessing one of the design decisions.
Originally, my main goal was to unify SXML, PLT xexprs, and SHTML. Part of that involved dropping SXML's permissiveness for extraneous list-nesting, for backward-compatibility with PLT xexprs.
The extraneous list nesting in SXML has two purposes I see: (1) Resilient to programming sloppiness, so that you can, say, just "unquote" to a procedure application, and that procedure application can either return one element or multiple elements and the SXML is still valid; (2) Possible efficiency gains in some cases, since you can do things like "`(foo ,(proc) bar)" to effectively splice rather than "`(foo ,@(proc) bar)". Since extraneous list nesting is not ambiguous in SXML, the nesting is somewhat like whitespace in a text document.
Instead, to accomplish the efficient splicing and convenience, I introduced an explicit "*splice*" form in certain contexts. So, for example, a filter procedure called in an element context during writing of XML, could return an element like "(p)" or multiple elements like "(*splice* (p) (q) (r))". Programming error that resulted in returning something that looked more like "((p) (q))" would result in an error. Syntactically, adding this to PLT exprs would be easier than adding extraneous list nesting.
However, now that the Racket Web server is loosening its coupling with xexprs, backward-compatibility with xexprs is no longer as important, so I'm second-guessing some of the decisions. It would be nice to use extraneous nesting instead of "*splice*", if only so that SXPath and "sxml-match" can work with the new dialect with few changes.
Note that the special syntax of the template library does not and will never permit extraneous nesting in the static (Racket syntax) portions of the template. Extraneous nesting is a convenience for dynamic parts.
Thoughts? Feel free to email me privately unless you think it's sufficiently on-topic for the list.
BTW, in case anyone is wondering why not just use current SXML... I have indeed had lots of success over the years with SXML, including on a large and important system. However, I have come up with what I think are some improvements to SXML, such as in symbolic character entity references, attribute value composition, some declarations, metadata syntax, a few restrictions, a fortuitous mapping to/from Racket character objects, possibly addressing the "@" symbol problem if RnRS won't budge, and some things I've found helpful in the writing and template libraries. I intend to eventually propose these as changes to the canonical SXML spec., once they're refined in practice. There will also be some simple conversion functions to/from SXML, PLT xexprs, etc.
-- http://www.neilvandyke.org/ _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
