Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 3306 invoked from network); 24 Feb 2000 12:54:11 -0000 Received: from mailman.zeta.org.au (203.26.10.16) by locus.apache.org with SMTP; 24 Feb 2000 12:54:11 -0000 Received: from zeta.org.au (ppp218.dyn143.pacific.net.au [210.23.143.218]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id XAA09813 for ; Thu, 24 Feb 2000 23:58:25 +1100 Message-ID: <38B5291C.D167DEF3@zeta.org.au> Date: Thu, 24 Feb 2000 23:50:36 +1100 From: jon seymour X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ant-dev@jakarta.apache.org Subject: Re: Proposal: XML output from ant tasks References: <8525688F.003FA011.00@d54mta04.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Instead of a series of XML fragments, if we are going to do XML, we > should make sure that it is well formed. For starters, it means that > everything needs to be nested inside of a single XML element. > > - Sam Ruby I wouldn't worry too much about well-formedness in the sense of having a top level element. A program I built used XML-like log streams, but we don't attempt to have a top level element 'cos we really can't guarantee that we'll generate the end tag at the end of the log stream. Also, it is much easier to write Element level filters if you don't have to worry about preserving the parent element. If you actually want to process the log stream as a well structured XML entity, it is a simple matter to use an external entity reference to imbed a fragment of the log stream into an enclosing element. jon.