Date: 2004-04-27T05:23:40
Editor: HowardLewisShip <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
