ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "J.Pietschmann" <j3322...@yahoo.de>
Subject Re: xml namespace support in ant2
Date Fri, 06 Sep 2002 19:14:19 GMT
Peter Donald wrote:
> I don't think there is any plan for it at this stage. There are too many 
> potential uses of namespaces and associated confusion. Do you namespace;
> * property names
> * types (aka tasks, datatypes, condtions, etc)
> * property evaluation (ie "${javascript:performMagic()}"
> * target names (ie if you depend on foo:bar target will that execute bar 
> target in foo project?)
> * aspects (ie add ant:fail-on-error="true" to all tasks)

There are existing XML related specs using namespace. Perhaps
part of Ant's usage can be modeled after XSLT:
- Core: All elements defined by the Ant core specification are
   in the Ant namespace.
- Top level: Elements which are immediate children of the
  document element ant:project and which are not in the
   Ant namespace must be namespace qualified and in some other
   namespace. If the processor doesn't know how to handle such an
   element, it is silently ignored.
   In XSLT, such elements are used for putting arbitrary data
   and documentation into the file:
   <ant:project xmlns:ant="http://ant.apache.org/2002/buildfile"
     xmlns:doc="http://some.other.org/simpledoc">
    <doc:propdoc>
      <p>The property <propname/> is set if the XYZ class
      is available on the classpath</p>
    </doc:propdoc>
    <ant:property name="avail.xyz" .../>
- Extension elements: All other elements which are not in the Ant
   namespace must be in some other namespace, and it is an error if
   the processor does not know how to handle them unless they are
   in an ant:fallback element (or something similar)
(see http://www.w3.org/TR/xslt#extension for details)

I'd also suggest to introduce a version attribute on the
project element, just in case.
I'd also advice against using namespaces (more precisely: QNames)
for target and property names, see below.

As for target name scopes which become relevant for imports I'd
use the import tree approach roughly like XSLT does: the import
tree is traversed until a target is found, the subtree of this
node is skipped and the tree is traversed further, if there is
a second match, an error is thrown.
This means the following is ok, because X in B is "shadowed"
   main
     importA
        importB
          target X
        target X
while this is an error (if the imported X is invoked)
   main
     importA
        target X
     importB
        target X
Kludges like "super.X" should be avoided, partly because "super"
is hard to define both intuitively and reasonably contradiction-free,
partly for possibly clashes with a user defined target which happens
to have the name "super.X", and also for other reasons.

As for using namespaces for scoping targets: the role of namespaces
is to avoid name clashes for XML *elements*, therefore encouraging
aggregation of XML from various vocabularies and fostering reuse
of existing vocabularies. The scope for targets are projects, not
XML vocabularies. Same goes for property names.

 From time to time I ponder to write a complete specification for
Ant build files and perhaps a proper processing model, unfortunately,
this is quite time consuming and motivation is low...

J.Pietschmann


--
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