On Wed, 09 Jun 2004, Peter Reilly <[EMAIL PROTECTED]> wrote:
> In the 1.6 beta discussion, it was decided that the nested
> elements of these tasks should also have the same xml ns as
> the tasks themselves. The reason for this was consistency.
"consistency with the way XML namespaces are supposed to work" and
that's not been the only reason.
> I believe that this makes build scripts more complicated than
> they need to be.
Quite possible.
> Some people say that one can avoid some that the problems by
> changing the default namespace:
>
> <for item="dir" xmlns="antlib:net.sf.antcontrib">
> <path>
> <dirset dir="."/>
> </path>
> <ac:sequential xmlns="antlib:org.apache.tools.ant">
> <echo>The dir is ${dir}</echo>
> </ac:sequential>
> </for>
The most difficult part to understand here is why echo is not inside
the AntContrib namespace - and this is solely an implementation detail
and not really related to namespace prefixes as such. And it
certainly adds to the confusion.
> Using default namespace in this way is not good xml style,
Not?
> and it is in my opinion confusing.
Not for XML tools, at least it shouldn't. It probably confuses the
hell out of users.
> Reason 2: Conversion of build files that use <taskdef resource=""/>
Could be solved with changing default namespaces on elements,
probably.
> Reason 3: Use of <macrodef>
Could be solved with changing default namespaces on elements,
probably.
> <macrodef name="example">
> <element name="files" implicit="yes"/>
> <sequential>
> <x:task>
> <files/>
> <x:task>
> <copy todir="z">
> <files/>
> </copy>
> </sequential>
> </macrodef>
wouldn't this here work?
<macrodef name="example">
<element name="files" implicit="yes"/>
<sequential>
<task xmlns="URI-for-prefix-x">
<files/>
<task>
<copy todir="z">
<files/>
</copy>
</sequential>
</macrodef>
> I propose to allow nested elements discovered by reflection to
> be in the tasks namespace and in the ant default namespace.
I think I know what you mean, let me try to clarify what I
understand:
A nested element discovered by reflection is looked up in
(1) the task's namespace
(2) the namespace associated with Ant's core, no matter what the
prefix of Ant's core may currently be and no matter what the default
namespace currently is.
And (2) would only kick in if (1) fails.
I could support this proposal.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
