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) (©) (& 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