I'll just wade in here with my 2p.
I agree that with the number of Ant based variants...maven, jelly etc... . and
people embedding Ant inside their own applications that their is a need to
avoid collision using namespace....in addition this will also allow intermixing
of Ant with other xml vocabularies ( XSLT, etc.. ) that may process prior or
after Ant processing, though in the example provided e.g. antcontrib ( or the
proposes <antlib/> stuff library its more akin to the binding a function to a
namespace as within xslt.
a few random and possibly not applicable comments;
---------------------------------------------------------
3rd party libraries that extend Ant e.g. antcontrib depends on Ant, they are
not standalone xml vocabularies with its own processor...I see a mixing of
using namespaces for avoiding collision versus using namespaces to 'bind'
functionality a potential source of problems.
What are the benefits ? XSLT has already gone through many of these type of
issues...and my exp with the EXSLT effort suggests that you might want to come
up with some clear use cases...otherwise users will just see namespaces as
additional effort for little return.
---------------------------------------------------------
I would suggest at least inheriting part of the URI to promote sanity with 3rd
party libraries;
note I add a mythical top level root element, as there might be a need of
something like this as a general container element for ant...but this applies
to <project/> as well.
<build xmlns:ant="http:/ant.apache.org/ant/v1"
xmlns:ac="http:/ant.apache.org/ant/antcontrib">
</build>
this allows ant.apache.org to control the valid 3rd party namespaces, though of
course the Ant developer / hacker would be allowed to determine completely
seperate variants as proposed...as follows;
<build xmlns:ant="http:/ant.apache.org/ant"
xmlns:ac="http:/myversionof3rdpartylibrary.com/antcontrib">
</build>
but once again this to me smacks of using namespace to bind functionality
---------------------------------------------------------
as with all xml namespaces there is the issue of the default namespaces not
applying to attribute names. That is
unprefixed attributes have no explicit namespace, though they are assumed to be
in the namespace of the element containing them. This means that choice A
really is not an option; too much ambiguity with respect to attributes may
cause problems.
to address these as clearly as possible one would prefix all elements and
attributes;
<build xmlns:ant="http:/ant.apache.org/ant"
xmlns:ac="http:/ant.apache.org/ant/antcontrib">
....
<ac:if>
<ac:or>
<ac:equals ac:arg1="a" ac:arg2="${x}"/>
<ac:ispropertytrue ac:property="y"/>
</ac:or>
<ac:then>
<ant:echo>both conditions are true</ant:echo>
</ac:then>
</ac:if>
</build>
admittedly most would argue that its alright to get away with not prefixing the
attributes if the elements were prefixed.
as u can see adding namespaces significantly reduces the readability of the
markup...not to mention adds the burden of typing more...which is irrevelent if
one is using an editor. So as much as I would like to be able to manipulate
markup that uses 3rd party libraries ( such as antcontrib ), its probably
important to allow users to just define a standard namespace for collision
aspects. I think that the antlib effort needs to address these issues as well.
---------------------------------------------------------
I would propose, to implement a set of conventions;
- namespace aware Ant processing switch to turn on and off namespace processing
- if namespace aware processing is on to include a switch for letting ant embed
3rd party libraries or to enable namespace processing of said 3rd party
libraries...or use some clear uri naming schema to indicate choice
- http URI should be used for identifying different ant namespaces, it gives
clear readable information and points to at the very least a domain (
ant.apache.org ) that user can put into browser, maybe even define a RDDL
document
- if function binding is to be used with namespaces, e.g. as suggested with
antlib, then I would suggest a bit of refactoring and just copy what XSLT does
with binding for java function binding
- what happens when certain functionality gets folded back into Ant...having
the ability to explicitly state namespace is a good abstraction...though not
sure about the internals of Ant of handling this... at the least its important
to embed version information into the namespace uri e.g.
http:/ant.apache.org/ant/v1 or http:/ant.apache.org/ant/2003
- if you are to gain the benefits of namespaces and are looking at using XML
Schema in the future, I would suggest some considerable modeling with xml
schema... to ensure what is being proposed across Ant with respect to
namespaces jigs up with what is natural within XML Schema, though I am a
relaxng man myself....
sorry about the random nature of this posting, also some of the points maybe
ill informed or not relevent though I can see some definate parallels with what
Ant wants to do and what XSLT has been through.
cheers, Jim Fuller
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed. If
you are not the intended recipient please contact the sender immediately. Any
disclosure, copying, distribution or any other use of this communication is
strictly prohibited and may be unlawful. Stuart Lawrence Marketing
Communications Limited reserves the right to monitor and intercept
communications for unlawful business purposes.
This also confirms that this message has been swept for viruses, although
Stuart Lawrence Marketing Communications Limited accepts no responsibility for
any loss or damage resulting directly or indirectly from the use of this email
or contents.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
