Re: three proposed additions to sxml

On Sun, Mar 02, 2014 at 08:28:46PM -0500, Neil Van Dyke wrote:
> Hello!  I would like to propose the following three additions to SXML:

Hi Neil!

> 1. Entity references *may* be represented by lists of two elements, with 
> the first element the symbol "&" and the second element either a number 
> or a case-sensitive symbol, meaning, respectively, a numeric character 
> entity reference or a named entity reference.
> Examples: (& 151)  (&copy)  (& rArr)  (& |rArr|)
> Rationale: I have been using this in an SXML dialect for many years, 
> especially for embedded HTML and XML code in Scheme files, and it has 
> seemed a big win for readability and ease of typing.

I concur that this is a useful addition.  However, I think it would be
more consistent to define it as yet another "generalisation" of XML
syntax.  If & is an SXML element name, its textual contents should be
the entity name.  Textual contents are usually not symbols or numbers,
but strings.  Most SXML tools do accept symbols as text contents, but I'm
not sure all do, and AFAIK the spec doesn't allow for it so it would be
another needless complication IMHO.

> 2. The symbol "=" *may* be used in place of the symbol "@", to introduce 
> attribute lists.
> Example: (p (= (id foo) (align "center")) "text")
> Rationale: It makes dense Scheme code with lots of ",@" more readable if 
> attributes do not also use the "@" character, and also "=" seems a nice 
> intuitive choice for XML attributes.

I don't see the usefulness of this.  The main problem I see is that SSAX
is already internally inconsistent; the aux-list is accepted as
(@@ (key "value")) by some tools and as (@ (@ (key "value"))) by others.
Unfortunately, I'm afraid the same inconsistency would probably also
creep in with the entity names, but there it wouldn't be as much of a
problem because most tools will view it as just another element.
The @ is a good choice due to xpath also using it for referring to
attributes.  Besides, the = might interfere with sxpath, as txpath uses
this sign for comparisons.  So far I think the sxpath language doesn't
use the = sign, but it could.

> 3. The keyword symbols, such as "*TOP*" and "*PI*", *may* be lowercase.
> Examples:  *top*  *pi*
> Rationale: The symbols are already visually quite prominent in (modern 
> all-lowercase) Scheme code, even when the symbols are in lowercase, and 
> also I would like to leave the visually very prominent all-caps symbols 
> in Scheme code for other purposes (such as for syntax transformer 
> pattern variables).

I don't have a strong opinion on this, except for the inconsistencies
that might result from modifying some but not all SXML tools.

> I arrived at these three proposed additions after experimenting with 
> many changes to SXML.  With most of the changes that I do not list here, 
> I ultimately decided that the existing SXML way was best, leaving me 
> with only these three to propose.
> 
> I would like to be able to use these proposed additions in my Scheme 
> libraries, and to call it "SXML", without that creating confusion.

I agree, having one thing which is called "SXML" would be great, there's
already too much divergence.

I've been thinking about this for a longer time, and I think the SXML
APIs aren't very clean, and the main codebase is not very modular;
it's a bit of a random grab-bag of (admittedly extremely useful) tools.
As R7RS and Snow pick up steam, it would be great to have an SXML
library with better naming conventions, consisting of separate modules.
The main problem is that it would require a great deal of effort which
I currently don't have the energy to put into it (and the SXML tools
are Just Good Enough as they are).

Having well-chosen library names would make it much easier to share SXML
code.  SSAX itself is quite portable, but the way it's packaged for the
various Schemes is not.

Cheers,
Peter
-- 
http://www.more-magic.net

------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk