Re: XML support in E

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.



On Tue, Jan 12, 2010 at 2:06 PM, Kevin Reid <[email protected]> wrote:

> On Oct 26, 2009, at 13:08, Thomas Leonard wrote:
>
> > Could someone give some simple examples showing how to read and write
> > XML using E?
> >
> > The XMLQuasiParser looks reasonable, but says it is deprecated in
> > favour
> > of using Terms. I can build Terms manually, but I can't see how to
> > turn
> > serialised XML into a Term, or a Term into serialised XML.
> >
> > I found this, but it doesn't say which methods to call:
> >
> > http://www.erights.org/data/terml/embeddings.html
> >
> > There's also Term.updoc in the source, which shows how to convert a
> > sml
> > DOM to a term, but not the other way around. Also, sml doesn't support
> > all of XML, e.g.
> >
> > ? sml`<foo/>`
> > # problem: Failed: syntax error: expected '>' but got '/' at 4
>
> There is no E-styled XML library built into E; this is certainly
> something which ought to be addressed.
>
> Such a library should of course use immutable trees (vs. e.g. DOM
> which is mutable) and have quasiliteral/pattern support for users.
>
>
> E-on-JavaScript's Updoc-to-HTML component is an example of XML
> manipulation in E: it uses the Java DOM libraries (and, when a real E
> XML library exists, should be converted to use it).
>   http://wiki.erights.org/wiki/E-on-JavaScript
>
>
> There are two different approaches which could be used for an E XML
> library: one is to use the Term-tree objects, and merely write an
> xml__quasiParser which allows one to use the XML-in-TermL embedding,
> as well as facilities for reading/writing XML documents. The other is
> to have a distinct object type for XML tree nodes; this has the
> advantage that its methods can be optimized for the needs of XML
> applications, and its __printOn would show XML rather than TermL.
>
> Parsing and printing could be handled for starters by using Java's
> builtin XML facilities; I'm not sure exactly how much could be reused
> vs. reimplented.
>
> Questions:
>
>   * Would you be interested in working on the project of an XML library
>     for E?
>
>   * If I were to work on it, would you use it and give feedback?
>
> --
> Kevin Reid                                  <http://switchb.org/kpreid/>
>
>
>
>
> _______________________________________________
> e-lang mailing list
> [email protected]
> http://www.eros-os.org/mailman/listinfo/e-lang
>



-- 
Text by me above is hereby placed in the public domain

   Cheers,
   --MarkM

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang