ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Locke <>
Subject Re: question and idea.
Date Sat, 16 Feb 2002 21:41:04 GMT

we're getting hung up on semantics here and it's totally my
fault (sorry!).  what i was getting at is that XML defines markup 
for documents and not pure-and-simple trees in this sense:

in XML you can have text nodes (PCDATA) interspersed within
any element body.  what i'm suggesting is creating a specialized
syntax that is for pure and simple node/attribute trees -- like 
config files.  the upshot of this is that you couldn't represent 
*document* markup with the syntax i'm suggesting.  so it's not really
equivalent to XML because it can only express the subset of XML that 
is about simple node/attribute trees.  does that make more sense? ;-)

it's easy to start thinking of DOM as tied to a bunch of XML angle 
brackets.  but it's a lot more than that, in my opinion.  the DOM can
be used to access any structured data, regardless of representation
or backing.  for example, you can have a DOM with a database describing 
a document instead of XML.  and a DOM consumer like Ant should never
know the difference, or care one way or the other.  since ant is really
being configured by a DOM (which just happens to be XML right now),
all I'm really suggesting is an alternative way of describing that DOM
which is less cumbersome and maybe more powerful or better tuned to
the problem of config files... some creative thinking about what 
configuration data is all about might help here... 

my little hack is to create a limited config file DOM by using the
existing SAX parser API to make DOM think it's working with XML... 
i'm not knowledgable enough to know if that's the right way to 
accomplish such a thing.  maybe it would be better done some other

--- "Glenn A. McAllister" <> wrote:
> On Sat, 16 Feb 2002, Jonathan Locke wrote:
> Hey Jonathan.  Comments inline...
> >
> > > 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.
> >
> > you bring up good points, to which i have a few responses that may or may
> > not sway you...
> >
> >  - it's *not* YAML because it's not an ML.  it's limited (intentionally)
> >    to tree structures (where XML describes document markup).
> Ah, but XML is a mechanism to *define* (not describe) structured
> documents.  The inherent structure is always tree like (at least, when
> defined with a DTD, I'm not familiar enough with XMLSchema and the like to
> comment) if it is a valid document.  Even a well-formed document is tree
> like due to the requirement of matching begin and end tags.
> <element attribute="blah">
>     <element/>
>     <someotherelement>
>     </somotherelement>
> </element>
> How is this not tree like?
> >  - it would support schemas and dtd's (which would stay the same) that
> >    describe tree structured documents.  you would get all the
> well-formedness
> >    and validation properties therein.
> Again, since all valid XML documents require a DTD or schema, how can you
> create non-tree like XML docuemnts?  Please show me an example of such a
> document that is well formed and I'll capitulate on this point.  :-)
> > > XML has been doing this for years.  Admittedly its a tad verbose, but
> > > there are worse things.  Why reinvent the wheel yet again?
> >
> > i guess my root feeling here is that tree data is not really a document.
> > it can certainly be *treated* as a document, but it's really a subclass
> > of documentness.  it's treeness and so it seems reasonable to have a
> special
> > syntax that is better able to describe "tree documents".
> I'm just reiterating my point here that I'm pretty damn sure you can't
> create a well formed (much less valid) XML document that isn't a tree.
> >
> > > 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?
> >
> > i don't think this *should* come up, as we're only replacing the SAX level
> > of DOM.  it *should* in theory be 100% transparent to higher level things
> > like document parsers, validators, schemas etc.  that is, if the XML people
> > have done there job optimally...
> But what you are proposing is to replace the parser, are you not?  The
> entity replacement mechanism used to import (parts of) XML documents is a
> function of the parser, obeying rules defined by a DTD - internal or
> external.  So either you have to have to reimplement the entity
> replacement mechanism defined by DTD or your schema language of choice, or
> you have to define a new one.
> Glenn McAllister
> SOMA Networks, Inc.
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

Do You Yahoo!?
Yahoo! Sports - Coverage of the 2002 Olympic Games

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

View raw message