Re: XML support in E

On Jan 12, 2010, at 17:34, Mark Miller wrote:

> I have become ever more attracted to JsonML <http://jsonml.org/> as  
> a way to handle XML data. Since E's term trees already handle JSON,  
> I suggest using the JsonML mapping of XML data into JSON structures.  
> I suggest we would then have no need for an XML quasi-parser. We  
> could just use the term tree quasiparser in quasi-JsonML format, to  
> manipulate XML trees as translated to JsonML structures. Even for  
> text markup, which is the best case for the XML vs JsonML  
> comparison, I still find JsonML notation more readable than XML.

Against JsonML:

* I do not see a specification for JsonML; not even as much of one as  
JSON started with.

* It does not appear to have any handling of XML namespaces; this is  
fatal. The programmer must not be required to manually manage prefix  
declarations inside of XML tree-composing code or they will get it  
wrong (or have to think hard about issues that the software could be  
handling for them).

* The point of JsonML as described is to handle XML documents as  
native JavaScript values; in that case, we might as well use E lists  
and maps, rather than the double-embedding inside the JSON subset of  
term-trees.

For having an XML quasiparser:

* I disagree regarding readability, at least in that I want to have  
the choice of either notation.

* E's goals of robustness and security suggest that we should provide  
facilities which are attractive safe substitutes for plain-text string  
interpolation. Having an XML quasiparser means that it is *trivial* to  
write xml`<title>$docTitle</title>` instead of `<title>$docTitle</ 
title>` and get “XSS”/“injection” “protection”, even if the programmer  
knows nothing of the details of the XML tree representation.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>