three proposed additions to sxml

Neil Van Dyke <[email protected]> Sun, 02 Mar 2014 20:28:46 -0500
Newsgroups gmane.lisp.scheme.ssax-sxml
Message-ID <[email protected]>
Hello!  I would like to propose the following three additions to SXML:

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.

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.

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 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.

Thank you for considering this proposal.

Neil


------------------------------------------------------------------------------
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