hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hivemind-...@jakarta.apache.org
Subject [Jakarta HiveMind Wiki] Updated: NotXMLProposal
Date Tue, 27 Apr 2004 12:23:41 GMT
   Date: 2004-04-27T05:23:40
   Editor: HowardLewisShip <hlship@apache.org>
   Wiki: Jakarta HiveMind Wiki
   Page: NotXMLProposal
   URL: http://wiki.apache.org/jakarta-hivemind/NotXMLProposal

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -2,48 +2,54 @@
 
 HowardLewisShip, April 26 2004, 1-0-alpha-4
 
-One of the tenets of !HiveMind is that deployment descriptors for J2EE are in verbose XML.
+One of the tenets of !HiveMind is that deployment descriptors for J2EE are in verbose XML,
and that this is a bad thing.
 
 And yet, the descriptors for !HiveMind are themselves XML and can be quite verbose.
 
 Several people, especially ErikHatcher, have '''repeatedly''' pointed this out to me.
 
-As things currently stand, XML is used for two reasons:
+As things currently stand, XML is used for several basic reasons:
    * It's easy to use an XML parser to read the kind of hierarchical data inside a descriptor.
    * It's easy to generate HiveDoc directly from the XML.
+   * It is easier to use existing SAX parsers (now part of the JDK) than to write our own
parser.
 
 = Proposed Solution =
 
-WE can define our own special purpose langage for the descriptors.  The language could be
more readable and succinct than the equivalent XML. More work would have to be put
+We can define our own special purpose langage for the descriptors.  The language could be
more readable and succinct than the equivalent XML. More work would have to be put
 into the HiveDoc, to generate the HiveDoc directly from the descriptor objects, or to generate
an intermediate XML format from the descriptor objects.
 
-Here's some examples along the lines of thinking:
+I've been working on SimpleDataLanguage (SDL), which is isomorphic to a well-defined subset
of XML. Rather than get into the messy details, here's an example of a !HiveMind
+module deployment descriptor expressed as SDL: 
+
 {{{
 module (id=myapp.ui.toolbar version="1.0.1")
 {
   configuration-point(id=ToolbarActions)
   {
-    element(name=item)
+    schema
     {
-      attribute(name=label required=true);
-      attribute(name=icon required=true);
-      attribute(name=action-class);
-      attribute(name=service-id);
-
-      conversion (class=myapp.ui.toolbar.ToolbarAction)
+      element (name=item)
       {
-        map (attribute=action-class property=action translator=object);
-        map (attribute=service-id property=action translator=service);
+        attribute (name=label required=true);
+        attribute (name=icon required=true);
+        attribute (name=action-class);
+        attribute (name=service-id);
+
+        conversion (class=myapp.ui.toolbar.ToolbarAction)
+        {
+          map (attribute=action-class property=action translator=object);
+          map (attribute=service-id property=action translator=service);
+        }
       }
     }
   }
 
- contribution(configuration-id=ToolbarAction)
+ contribution (configuration-id=ToolbarAction)
  {
-  item(label=Open icon=Open.gif service-id=OpenService);
+  item (label=Open icon=Open.gif service-id=OpenService);
  }
 
- service-point(id=OpenService interface=myapp.ui.toolbar.ToolbarAction)
+ service-point (id=OpenService interface=myapp.ui.toolbar.ToolbarAction)
  {
    invoke-factory(service-id=hivemind.BuilderFactory)
    {
@@ -60,13 +66,15 @@
 }
 }}}
 
-This is pretty obviouslly darn isomorphic to the existing XML format. Remember, XML started
as a document format, where using punctuation for blocking delimiters
+Remember, XML started as a document format, where using punctuation for blocking delimiters
 was a bad idea, since such characters could show up in the document text. Our use of !HiveMind
deployment descriptors is a much more constrained environment, more like scripting
-than like pure documents. For example, quoting of attributes is not necessary for most attributes,
just the ones with whitespace (or other characters outside a specific subset).
+than like pure documents. For example, quoting of attributes is not necessary for most attributes,
just the ones with whitespace (or other characters outside a specific subset) in the value.
 
-Also, many parts of XML were intended to make it easier to write an XML parser (though, over
time, things have twisted such that a fully conformant  XML parser is now an enourmous beast).
Again ... not our concern.
+Also, many parts of XML were intended to make it easier to write an XML parser (though, over
time, things have twisted such that a fully conformant XML parser is now an enourmous beast).
Again ... not our concern.
 
-This solution involves nailing down precisely (in BNF) what our format will look like and
writing that parser. Most likely, something like ["JavaCC"] can be leveraged (depending on
licensing). Possibly, we write a simply parser that converts the above to a DOM-like format
and work from there.
+This solution involves nailing down precisely (in BNF) what our format will look like and
writing that parser. 
+I have been experimenting with ["JavaCC"], and have put together an SDL parser that emits
SAX parse events.  With very minor changes to the !DescriptorParser class 
+we could convert our XML descriptors to SDL. We could even support both formats!
 
 = Discussion =
 
@@ -136,3 +144,9 @@
 Although I haven't yet tried out to build a doc from the config file, I am pretty sure its
very simple. Beanshell already has a Bshdoc.bsh script that generates javadoc like doc.
 
 ChristianEssl: I like Harish's idea of using Beanshell. It is indeed less verbose than xml.
Maybe somehow it could be possible to replace the dependencies map and constructor-array with
a closure, which directly constructs the implementation. To me this would be the main advantage
of using an alternative config format. Apart of this can someone point out what the disadvantages
of xml are except of the verbosity and that ejb (and most other frameworks) use it too. Especially
for contributions I think xml is much better than scripting, because you basicly define your
own specialized easy-to-use language. Is there some thought of mixing scripting with xml?
  
+
+HowardLewisShip: You might notice I'm unconvinced about using scripting. The core issue is
the XML.  The way Sun uses XML (lots of elements, no attributes) is super-duper verbose. The
XML formats used by !HiveMind deployment descriptors are more straight-forward, but are still
hard on the eyes ... the extra verbosity inherent in all those open and close brackets,
+the unnecessary quotes, the long verbose close tags --- those all become distractions to
the eye, obscuring the real intent. The SimpleDataLanguage I've been proposing here is (especially
+for Java coders) more natural, because of the use of curly braces to denote enclosure of
elements.  And yet, your could easily write a translator that converts back and forth between
a subset of XML and SDL.
+
+The examples above, using BeanShell, were, in my opinion, even more obscure than the XML
versions. In addition, the code seems to expect each line to be a fully executable statement,
which is going to make anything reasonable in terms of configuration even more awkward.

---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-cvs-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-cvs-help@jakarta.apache.org


Mime
View raw message