ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glenn A. McAllister" <gl...@somanetworks.com>
Subject Re: question and idea.
Date Sat, 16 Feb 2002 19:26:29 GMT
On Sat, 16 Feb 2002, Jonathan Locke wrote:

>
> is the SAX part of ant's XML parsing 100% pluggable?
> is there a mechanism for doing this?

To the best of my knowledge Ant uses JAXP, which means you can plug in any
JAXP compatible parser.

>
> anyway, i have had an idea for some years now that i'm finally
> ready to act on, especially if anyone would be interested in
> helping out.  the basic idea is to create a SAX parser that
> accepts a simplified non-markup-style data format that is useful
> for representing configuration files and other such strictly-tree
> data in a more readable format.  ant makefiles would be one such
> data source.  although it would mean you couldn't work with
> makefiles using tools with hardcoded SAX parsers, it does play
> within the larger XML story, as XML is touted as being format/
> source independent.  i'm sure some people will see this as crazy,
> but i'm hoping that others will see some value.  ;-)

I'm affraid I'm leaning on the crazy side here. :-)

>
> as an example (would love some useful feedback), here is the first
> example from the ant documentation:
>
> <project name="MyProject" default="dist" basedir=".">
>

<snip>Rest of example</snip>

>
> and here it is in my proposed simplified XML format:
>
> project
> {
>     name    = "MyProject"
>     default = "dist"
>     basedir = "."
>
>     // Set global properties for this build
>     property(name = "src"   value = ".")
>     property(name = "build" value = "build")
>     property(name = "dist"  value = "dist")
>
>     target(name = "init")
>     {
>         // Create the time stamp
>         tstamp()
>
>         // Create the build directory structure used by compile
>         mkdir("${build}")
>     }

<snip>Rest of modified file format</snip>

> i personally find this substantially easier to create, read and maintain.
> the parser is pretty simple.

The problem is, it isn't XML.  Maybe I'm missing the point, but it seems
to me that you've just created YAML; XML is supposed to make the mechanism
of parsing these files easier by providing two well defined properties:
well-formedness and the potential to validate (partially) the structure of
the document.

XML has been doing this for years.  Admittedly its a tad verbose, but
there are worse things.  Why reinvent the wheel yet again?

the rules might be this (roughly):
>
> 1. each tag name must be followed either by ( or {
> 2. for (, an XML attribute list follows.
>    (as added syntactic sugar, if the dtd/schema only defines one
>     attribute, the "token = " part can be omitted).
> 3. after any attribute list, the body of the tag is (optionally)
>    defined in { }.
> 4. a set of attributes belonging to the tag can immediately
>    follow the open { (but cannot appear elsewhere in the body.
> 5. tags can be nested.
>
> constructive comments and feedback are welcome.

The rules you have defined are fine as far as they go, but I'm willing to
bet there are lots of issues you haven't address.  For example, how do you
manage importing external documents?

My $0.02.  (I mourn the loss of the cent character from the keyboard...
and yes, I do remember when there was a cent character..)

Glenn McAllister
SOMA Networks, Inc.



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message