[racket] comments requested from users of SXML and PLT xexprs

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/