Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 18020 invoked from network); 16 Feb 2002 23:36:15 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 16 Feb 2002 23:36:15 -0000 Received: (qmail 29740 invoked by uid 97); 16 Feb 2002 23:36:19 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 29717 invoked by uid 97); 16 Feb 2002 23:36:18 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 29706 invoked from network); 16 Feb 2002 23:36:18 -0000 Message-ID: <001b01c1b742$b9c7ad00$6401a8c0@darden.virginia.edu> From: "Erik Hatcher" To: "Ant Developers List" , References: <20020216214104.29867.qmail@web20810.mail.yahoo.com> Subject: Re: question and idea. Date: Sat, 16 Feb 2002 18:36:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I actually think you're on to something here. I don't know if there are any technical constraints that would prevent you from firing SAX events into Ant or not, but if you can do so then you've decoupled Ant from filesystem build.xml. I'd suspect that it'd be quite difficult to read a makefile and fire it into Ant in some reasonable way though. Certainly it would be an interesting proof-of-concept if nothing else, but perhaps this is much more than that. Erik ----- Original Message ----- From: "Jonathan Locke" To: "Ant Developers List" Sent: Saturday, February 16, 2002 4:41 PM Subject: Re: question and idea. > > 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 > way. > > --- "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. > > > > > > > > > > > > > > > > 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 > http://sports.yahoo.com > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- To unsubscribe, e-mail: For additional commands, e-mail: