ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wannheden, Knut" <>
Subject RE: xml namespace support in ant2
Date Wed, 02 Oct 2002 07:16:57 GMT

> -----Original Message-----
> From: Costin Manolache []
> Sent: Dienstag, 1. Oktober 2002 19:26
> To:
> Subject: RE: xml namespace support in ant2
> Wannheden, Knut wrote:
> > If not schemas should be used for validation for the 
> reasons you mention I
> > still think there should be some other mechansim.  Ideally 
> this mechanism
> > would ensure proper usage, allow consistent documentation 
> to be generated
> > and simplify the code inside a task.  As it is now task 
> code gets very
> > cluttered with validation code, which is sometimes even 
> wrong (because of
> > lack of a good mechanism).  IMHO having a set of setXXX(), 
> createXXX(),
> > addXXX(), addConfiguredXXX(), setDynamicAttribute(), and
> > createDynamicElement() methods just isn't the right way to 
> express how a
> > task is to be used.
> Documentation is one issue - and schema may be the right way 
> to document
> a task. Or javadoc and xdoclet ( which could generate a schema ? ).
> Having a method validate its parameters remains IMO the right way to 
> write code. And is far cleaner ( and faster ) than any alternative. 
> It is true - there is a duplication between the code checking 
> if( param>10 ) throw InvalidArgumentException 
> and the documentations or eventually schema. However having a 
> 'validation' mechanism ( and there are few ) is more complex ( 
> at least IMO ).
> I don't thing it's clutter to validate your params - just 
> good programming.

Certainly there are different things one can validate in the usage of a task
or type.  The validation you seem to be talking about is the actual values
of the parameters.  And, no question about it, this is better validated by
the task itself.  What I am more concerned about is the different
combinations of attributes and nested elements (in XML lingua) which are
allowed.  Take the "refid" attribute of types for example: If you specify
the refid attribute, then no other attributes or child elements are allowed.
And how is this ensured?  The setRefid() method and setXXX(), createXXX()
methods all do mutual checking that the other hasn't been set.  This both
clutters the code and is error prone.  To take a worse example: recently a
"file" attribute was added to <fileset>, and just as the "refid" attribute
it can't be used in conjunction with any other attributes or child elements.
If you want to implement all this validation in the task (which hasn't been
done) I'm sure your head would ache even before you'd be done.  Not to talk
about when you look at it a few weeks later.  This problem is solved *very*
easily with a grammar language like RELAX NG.  And as it is now, most tasks
and types would benefit from this kind of validation, because they have
different "usage modes" where attributes and child elements are optional,
required, mutually exclusive, etc.

> >> 2. However schemas are good for documenting the task and 
> for possible
> >> tools. As long as we don't use them for validation ( which
> >> I'll -1 as strong
> >> as I can ).
> >> 
> > 
> > Yes, they would provide a good means to document tasks.  
> But they could
> > also
> > be used for validation.  If the tasks should be possible to use
> > differently (e.g. as beans) I think there should be a 
> mechanism which
> > allows for validation in both modes.
> So instead of a task checking its params, you would prefer some
> external mechanism. I think we should agree to disagree on this.

Yes, for the kind of validation I described above, I do think an external
mechanism (such as a schema) would be preferable.  But I don't want to say
that this should be the only way to perform validation.  I was hoping it
would make things easier if it were possible.

> But even if a majority would prefer external validation, schema is
> one of the worse possible solutions. There are some tools
> ( aspectj ? ) that are doing this at the code level ( or bytecode ?),
> but again I personally prefer explicit java code. 

Can you show me an example of how to (lexically) validate a <fileset>
instance?  I think you'll have a a hard time doing it simpler than with

> >> 6. Namespaces should be used instead of 'taskdef' whenever possible
> >> ( i.e. the descriptor  ).
> >> 
> > 
> > I was thinking that namespaces would primarily be used to 
> clearly separate
> > Ant core tasks from the custom loaded tasks and let the 
> user use any name
> > for the task.  To load custom tasks the buildfile writer 
> would then either
> > do a <taskdef> or an <antlib>.  E.g.
> > 
> >   <taskdef name="copy" ns="urn:abc-namespace"
> >            classname=""/>
> >   <bla:copy xmlns:bla="urn:abc-namespace"/>
> > 
> > This would not require that a descriptor exists for every task.
> The can be used for tasks that don't have descriptors. 

That was the idea.

> But if a task has a descriptor, there is absolutely no reason to
> require the use of taskdef ( unless the user wants to - for example
> to change a task name, which should be strongly discouraged and 
> is no longer needed with ns ).

Yes, I agree.  But are descriptors loaded automatically by Ant?  I thought
they were loaded by a <antlib> element.

> > For <antlib> you would require that there be a descriptor 
> which is located
> > with the encoded namespace URI as you say.  Then you'd probably do
> > something like:
> > 
> >   <antlib resource=""/>
> >   <bla:copy xmlns:bla="urn:abc-namespace"/>
> Yes, that's the main use case. 
> However I would like to also use 'discovery' mechanisms. That may gain
> majority or not - but what I hope is that the hook will be accepted
> allowing user-components to support extensions ( just like 
> ant-contrib defines procedural tasks, or embed defines alternate
> XML processors ).
> > where the antlib property would define the namespace URI it 
> uses.  (In all
> > examples the namespace attributes could of course also be 
> declared in an
> > enclosing element, like <project>.)
> As I said, for myself I would rather use:
>  <foo:bar xmlns:foo="" >...</foo:bar>
> And a discovery mechanism will locate 
>   META-INF/ant/|xml
> inside the classpath, or display a message that I need to download
> a library from that location - and not require use of taskdef.

So you propose that all taskdefs take place completely automagically?  No
<antlib> either?  IMHO it would feel more natural if there were a descriptor
for an ant library loaded by an <antlib>, which would specify its namespace
URI.  And then task and type elements using that namespace what be located
and loaded from the respective library.  But that's just a detail I guess.
More important is the general use of namespaces.  And as I understand it
you're also a proponent of using XML namespaces to scope tasks.  Also there
should be a namespace reserved for Ant tasks and types.

I don't see too much of a gain in requiring that the namespace URI be a URL.
I think if the specification says any URI should be allowed (in the newest
draft it's even IRIs) then I think it would be confusing if Ant would
restrict it to URLs.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message