ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: xml namespace support in ant2
Date Fri, 06 Sep 2002 07:54:33 GMT

Wannheden, Knut wrote:
>>-----Original Message-----
>>From: Peter Donald []
>>Sent: Freitag, 6. September 2002 01:09
>>To: Ant Developers List
>>Subject: Re: xml namespace support in ant2
>>On Thu, 5 Sep 2002 20:08, Wannheden, Knut wrote:
>>>I know this topic has been brought up before (e.g. in 
>>"Optional tasks"
>>>thread of last december [1]), but I still wonder what is 
>>the actual plan
>>>for the accepted requirement for Ant2.
>>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 
>>* 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)
> Most of these options don't have anything explicitly to do with XML
> Namespaces [1], just namespaces as a general concept. 


> I was wondering about
> the former.  Because as of now it isn't even allowed to have XML namespace
> declarations in the buildfile, as has been requested before (e.g.
>  But my point is
> that XML namespaces could actually be employed for something useful.

proposal/embed is completely SAX2 based, so there it's possible.
The point is exactly what you say: what to do with it ;-)

>>><project xmlns=""
>>>         xmlns:my="urn:my-ant-tasks"
>>>         default="test">
>>> <taskdef qname="my:foo" classname=""/>
>>> <taskdef name="baz" ns="urn:my-ant-tasks" 
>>> <target name="test">
>>>  <echo message="test"/>
>>>  <my:foo/>
>>>  <whatever:baz xmlns:whatever="urn:my-ant-tasks"/>
>>> </target>
>>>(Note the two different uses of <taskdef>.)
>>type aliasing is no problem but I think that is independent 
>>of the main issue.
> I wouldn't say this use was mainly about aliasing, but more about
> modularization.  If you write a set of custom tasks and types as part of a
> library you define them in a separate XML namespace when used.  Aliasing
> isn't a real problem in Ant anyway, because you can dynamically assign any
> name you want to a custom task or type.  So there's no real need for XML
> namespaces to avoid name clashes.

There is if you write a library that must be imported, as you say.

>>However I think you will find it hard pressed to validate 
>>anything without the 
>>runtime context being present. It may be possible but I think 
>>that it would 
>>need to be seen to be believed ;)
> I'm not talking about validation at the semantic level here, it would just
> be about lexical validation.  As I understand it, the Ant core performs most
> of the semantic but only some lexical validation.  For instance does Ant
> prevent you from specifying bogus attributes for a task, but it doesn't know
> anything about what attributes and nested elements are allowed in
> conjunction.  This validation has to be done by the task implementation, and
> it's easy to go wrong here and bloats the code.  But worst of all, it can
> result in unexpected behaviour.  Take these two uses of <fileset> for
> example:
> 	<fileset defaultexcludes="true" refid="foo"/>
> 	<fileset refid="foo" defaultexcludes="true"/>
> Assuming that there is a defined <fileset id="foo"/>.  Ant won't complain
> about the first definition (assuming the setters are invoked in the same
> order the attributes are listed), but the second one will raise a
> BuildException.  A formal specification would really help here.

Ahhh... so each "library" would have its namespace with its validation!
Now I get it , cool!

> Possibly you could also generate consistent user documentation for the tasks
> from an annotated version of this formal specification.
> There are also context sensitive XML editors using grammars to implement
> some kind of code assist.  I believe many users would find that useful as
> well.
> XML namespaces certainly wouldn't be a prerequisite for a grammar, but it
> would certainly make it easier.
> [1] Namespaces in XML

Good, now I understand :-D

You are right, if we make tasks use a namespace, they can also supply 
the schema for themselves, and be validated by XML parsing instead of 
inside themselves!

This is really very very cool, I want it in embed proposal :-)

Any practical implementative suggestions?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message