ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jim Fuller" <jim.ful...@stuartlawrence.com>
Subject RE: Namespace support in ant 1.6
Date Tue, 11 Nov 2003 10:54:00 GMT
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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message