[E-Lang] Why I want full XML

[Monty Zukowski]

> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:shap@cs.jhu.edu]
> Sent: Friday, October 06, 2000 7:42 AM
> To: e-lang@eros-os.org
> Subject: [E-Lang] Why I want full XML
>
>
> I talked in a previous email about annotations. Consider introducing
> annotations constituting some form of proof or set of
> assertions about a
>
> field:
>
> <elang:myValue ty="ul">5
>     <proof:note>forall blah in blurbus something
> something</proof:note></elang:myValue>
>
> Note that because XML is fully parenthesized, it is exceptionally easy
> for a deserializer to simply "skip" all tags that live in foreign
> namespaces. Thus, it becomes possible to read and produce annotated
> files, and also to do experimental output changes without breaking
> existing deserializers in the field.
>
> Similarly for use of attribute namespaces.
>
> I propose that E (de)serializer should be specified to reserve a
> namespace (suggest "elang") and do this kind of skipping of
> foreign name
>
> spaces.
>
> Note that this is quite different from encountering an
> unexpected (i.e.
> wrong) tag in the E namespace. This really would indicate a bug in the
> serialization or a version conflict in the deserializer, and should be
> considered a reason to die.
>
> So:
>
>     death to bugs
>     death to confusion
>     life to flexibility and interchange.
>
> Perhaps I am being silly. Certainly if one has tools to generate this
> kind of XML one should be able to use XSLT to strip them
> appropriately.
> This does mean that the deserializer must not count on unmodified
> whitespace in the output.


To me, the difficulty of such annotations lies not only in ignoring them, but
also in passing them through in a meaningful way.  After all, we're talking
about tree transformations, right?  What happens when you do something more
sophisticated than expanding code?  I'm sorry, but I'm having a brain block
coming up with a good example, maybe I don't have a point.

I like the idea of namespaces.  In my AREV->VB translator I had two
"namespaces", one for AREV and one for VB.  I had a master tree grammar with
rules for both languages in it.  For each pass I would specialize the master
grammar with translations.   In the middle passes I had a tree composed of nodes
from both languages--AREV nodes nesting VB nodes nesting AREV nodes ad
infinitum.  By the end it was all VB nodes.  But the master tree grammar which
combined both languages was needed to make sure I never ignored any part of the
tree--in this case I didn't want to ignore the other namespace.

Monty