Costin,
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
>
>
> > <project xmlns="antlib:org.apache.ant.core">
> > <.../>
> > </project>
> >
> > The only difference would be that <project/> would declare
> the default
> > namespace.
>
> The only difference is that people will have more to type and
> the build
> file will get more complicated.
>
I can't deny that. But the impact is neglible IMHO.
>
> > If I now want to extend the task to use nested elements, in
> what namespace
> > would they be and how would this affect the setXXX()
> interface of the
> > task? I suppose the options are to use the default
> namespace or the same
> > namespace
> > as the task. So either:
> >
> > <foo:bar xmlns:foo="antlib:com.foo">
> > <baz/>
> > </foo:bar>
> >
> > or:
> >
> > <foo:bar xmlns:foo="antlib:com.foo">
> > <foo:baz/>
> > </foo:bar>
>
> :-)
>
> Are you trying to give one example of why adding complexity
> is bad, and
> why we should avoid using namespaces ??
>
If XML namespaces should be used at all, I think they should come with as
few surprises as possible. Consider the case where a user has defined an
antlib foo with a <fileset/> type. What behaviour should be expected from
the following example?
<path>
<foo:fileset dir="." xmlns:foo="antlib:com.foo"/>
</path>
Won't the user be surprised if the regular Ant <fileset/> is used without
any notice whatsoever? I just thought the introduction of XML namespaces
would address such issues...
Cheers,
--
knut