[E-Lang] Draft Kernel-E DTD & Sketch of translation to debuggable Java

[Mark S. Miller]

At 03:30 AM 9/27/00 , Tyler Close wrote:
>The XML stuff was implementing SOAP v1.1 for Droplets. Currently, SOAP
>is the main format for two Droplets servers talking to each other.
>This code is in the Droplets library, which is Open Source. It's not
>on the waterken.com site yet, but I can post a Beta if you want to use
>it.

Please!  I'd like to at least read it.  If you rolled your own XML parser & 
DOM-like tree, I may very well use that part.  As for SOAP, what do you 
think of it?


>Before you put too much effort into developing E's DOM subset, or
>deciding on the use of Minimal-XML, I think we should identify some
>target tasks for the use of XML in E. For example, if one of the goals
>is to enable E programs to access web resources using SOAP, then
>supporting only Minimal-XML would not be a good idea.

Goals in priority & time order:

* Provide a readable format to convert JOSS to and fro, for debugging purposes.
* Provide a parse-tree formal for representing and transforming Kernel-E 
   program for purposes of compiling to Java/ELib and C++/ENative.
* Enable JOSS/Pluribus to be able to speak "XML", whatever that means, so we 
   can avoid the phenomenon Alan speaks about of getting beat up for speaking 
   something "proprietary".  (Funny that JOSS is standard, whereas a new XML 
   DTD is proprietary, but the world can only see it the other way around.)
* Integrate ANTLR (after some changes Monty is planning to make) into E as a 
   quasi-parser generator.  Such a generator needs to leverage a universal 
   parse-tree representation, where this representation has been extended to 
   support $-holes and @-holes.  In the absence of the XML issue, the natural 
   choice would be the S-Expressions already built into ANTLR.
* Be able to leverage the quasi-parser framework for dealing with existing 
    XML data in the world, like SOAP.

For all but the last, Minimal-XML is fine.  If we start with Minimal-XML, 
when we hit this last issue we have three choices:
* Grow from Minimal-XML to full XML at that time
* Use "Minimizer" to embed XML into Minimal-XML
* Build a parallel set of tools.

The last item is sufficiently far away that I feel happy with this.  In the 
meantime if anyone else wants to use E with XML tools, they can engage in 
the last two options as easily as I.  I've already linked Xerces-J with E 
and used it from E in a perfectly happy fashion.  E's use of Minimal-XML 
does nothing to make this harder.


>I think just accepting XML, in all of its gory detail, is the only
>meaningful course of action. Doing anything less just brings all the
>disadvantages of XML without providing its main advantage, a common
>transport format.

Minimal-XML has very few of the disadvantaged of XML.  It really is just a 
bad notation for S-Expressions.  It also has the only advantage of XML: it 
is a compatible subset, so when asked, we can honestly say "We are XML 
compatible".  It's just like inheritance.  In marketing speak, this is known 
as a "check-off item".


>I've posted a new Beta for Acid on the waterken.com site at:
>http://www.waterken.com/Acid/2.0/
>
>The new Beta includes the hooks that Droplets uses to support SOAP
>messaging. E does not have these hooks (nor any of this richness of
>reference types), so I think you should take a look. The design is
>different from your "negotiate everything at connect time" approach.

Downloaded it.  Will look.  Thanks!


         Cheers,
         --MarkM