> From: Jim Fuller [mailto:[EMAIL PROTECTED] 
> 
> > I in particular do not like the business of a programming language 
> > (which is what ANT XML really is) where non-understood things are 
> > silently ignored. (-1)
> 
> [Jim Fuller] completely agree with this statement, though I 
> think the idea of a processing switch that turns off strict 
> 'ant' processing would be useful to have intermingled xml 
> documents, e.g. build.namespace with a variety of flags with 
> the default.
> 

My problem with processing flags for this is that in this case is not
an option. If for your file down there, I do not call ANT with such
flags, it will not be able to process it. So, the flag is an integral
part of the meaning of the buildfile. What this says to me is that the
information being conveyed by the flag should be expressed on the
buildfile
itself. What happens on calls to <ant/>, shall I be strict or loose?
Are you saying that we are in an ALL or NOTHING kind of environment?

> > I think that causes more harm than good. I think stuff that must be 
> > ignored (ant the writer knows about it) must be somehow 
> marked as such 
> > (e.g., <?ant-ignore ...?>).
> 
> [Jim Fuller] I don't understand why one can't use the XML 
> method of using namespaces to avoid collision....consider the 
> following project build which maybe developed by multiple 
> developers, this example has other concepts that are 
> periphery to my main arg (like a default Ant
> namespace)
> 

But I am using namespaces to avoid collisions. Actually I am relying
on namespaces to avoid collisions. The only additional thing is
that require you to declare that such namespaces are not for ANT to
process.
I want the buildfile to be self contained and self documented
on that regard. In other words, the discussion here is all about
whether to add to your example below, ONE additional line near the
beginning:

<?ant-ignore uri="http://www.w3.org/1999/02/22-rdf-syntax-ns#"; ?>

> <project xmlns="http://ant.apache.org/ant/v16"; name="demo" 
> default="build" basedir=".">
> 
> <rdf:Description 
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
>                  xmlns:dc="http://purl.org/dc/elements/1.1/";
>                  ID="build">
>    <dc:subject>build</dc:subject>
>    <dc:subject>some software project</dc:subject>
>    <rdf:revision>
>       <rdf:Description 
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax ns#"
>          xmlns:dc="http://purl.org/dc/elements/1.1/";
>          ID="buildl.1">
>          <dc:version>1</version>
>          <dc:creator>Jim Fuller</dc:creator>
>          <dc:date>2001-11-25</dc:date>
>          <dc:description>Build file that demonstrates the 
> intermingling of xml elements.</dc:description>
>       </rdf:Description>
>    </rdf:revision>
> </rdf:Description>
> 
> <target name="clean">
> 
> </target>
> 
> <target name="create">
> <rdf:Description 
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
>                  xmlns:dc="http://purl.org/dc/elements/1.1/";
>                  ID="build">
>    <dc:subject>build</dc:subject>
>    <dc:subject>docs subproject</dc:subject>
> </rdf:Description>
> </target>
> 
> <target name="docs">
> 
> <rdf:Description 
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
>                  xmlns:dc="http://purl.org/dc/elements/1.1/";
>                  ID="build">
>    <dc:subject>build</dc:subject>
>    <dc:subject>docs subproject</dc:subject>
> </rdf:Description>
> </target>
> 
> <target name="test">
> <rdf:Description 
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
>                  xmlns:dc="http://purl.org/dc/elements/1.1/";
>                  ID="build">
>    <dc:subject>build</dc:subject>
>    <dc:subject>test subproject</dc:subject>
>    <rdf:revision>
>       <rdf:Description 
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax ns#"
>          xmlns:dc="http://purl.org/dc/elements/1.1/";
>          ID="build1.2">
>          <dc:version>2</version>
>          <dc:creator>Bobby Fuller</dc:creator>
>          <dc:date>2002-11-25</dc:date>
>          <dc:description>amended all java tests to include 
> debug information.</dc:description>
>       </rdf:Description>
>    </rdf:revision>
> </rdf:Description>
> </target>
> 
> <target name="build">
> 
> </target>
> 
> </project>
> 
> the above example shows a build file being 'tagged' with xml 
> to reflect author information...I don't think that this is 
> such a strange use case...though of course I wouldn't impose 
> this format when primarily using manual text editor...this is 
> of course xml generated with other tools. 
> 
> By putting in an ant element or XML PI you are forcing the 
> ant authors idea of XML structure onto everyone else who may 
> have related build meta data...which is fine if you always 
> consider that build.xml will reside in a standalone file with 
> no integration or association to other meta data. All right I 
> will stop beating this dead horse, thx for the time.
> 

The question is whether at the end of the day you are writing a 
buildfile for ANT or you are writing some other type of composite
document
which includes an ANT project. If the former, then I do not see
why the PI is such a strain; if the later, then it seems to me
such source may need to be preprocess as part of an execution
pipeline to extract the buildfile source out of mix content.
Of course, that could be done, in the presence of <?ant-ignore?>,
with an XSLT that just adds the necessary PIs and renders the rest
of the file as it is.

This brings back an old feature that was debated I guess a long time
ago (on ANTs timescale) about enabling ANT to apply XSLT style sheets
directly on the execution pipeline. To borrow from some XHTML processors
(e.g., IE) you would have something like:

  <?xml-stylesheet type="text/xsl" href='style\ant.xsl'?>

which will just be applied on the fly before the project instance
is created. At the time, I guess the feeling was that you could could
achieve the same by having a project that used the <style/> task
to generate the file, and then called <ant/> on the output.

Jose Alberto

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to