hivemind-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Jakarta HiveMind Wiki] Updated: NotXMLProposal
Date Wed, 28 Apr 2004 22:16:26 GMT
   Date: 2004-04-28T15:16:26
   Editor: <>
   Wiki: Jakarta HiveMind Wiki
   Page: NotXMLProposal

   no comment

Change Log:

@@ -184,3 +184,5 @@
 KnutWannheden: To me the crucial question is whether the module (or deployment) descriptor
should be ''descriptive'' or ''imperative'' (as seen in the make vs. Ant war).  For HiveMind
I tend to favor a descriptive form.  But it should be possible to allow both.  We'll just
have to decide which one goes into the framework and which one into the library :-)
 [ GeoffLongman]: Speaking as a Hivemind
user, XML and SDL look fine. I have not warmed up to [ YAML] at all. Using
a true scripting language like Groovy turns me off completely. Leave the descriptors as ''descriptors''
that describe or declare something and are not executable. Speaking as somebody who ''might
someday'' commit to building an Eclipse plugin for Hivemind, XML is the path of least resistance
for me. A declarative markup like SDL or [ YAML] would be ok too if the
parser support were at a level conducive to developers tools. An DOM equivalent (AST tree)
with line ''and'' character offset ''and'' range precise information is needed. FYI, no open
source XML parsers were this precise out of the box for [ Spindle].

+ChristianEssl: XML is for me. If I look at the tremendous work Howard has put into the XMLParser
I'd say a JavaCC grammar would be even easier for !HiveMind - less validation. XML is for
me because I somehow got to know what an element and an attribute is, how to start and end
the document, how to escape things, how to add comments, the meaning of whitespace, what are
valid names, knowing which block-close belongs to which start without a lot of counting and
finally knowing that others know that (and certainly much more) too. Apart of this looking
at the example Harish gave I think he actually meant an language whith only expression-instructions.
Well that's not everyones taste, but I'd call it declarative and line pricese reporting can
be maintained this way. It has the advantage that it's relatively easy to use combined with
!JavaDoc. Further it would be very easy to implement convinience methods.   

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message