ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject RE: xml namespace support in ant2
Date Mon, 30 Sep 2002 17:33:20 GMT
My opinion:

1. I hate using schema for validation. XML is not the only way to use
ant - there are already projects using ant tasks as beans, and it's a good
code reuse. 
Besides, schema is still slow ( and will allways be - due to it's 
complexity). Even Relax or simpler schemas can't ever beat the if()
in the task, which also cover the use of the beans.

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 ).

3. The embed proposal uses SAX2, but it is not doing anything ( yet ) with 
the namespaces. My original plan was ( and still is ) to use the namespace
as an ID, and use it to locate the task definition using getResource().
For a task in NS, I would look up META-INF/ant/encoded(NS)/SOMETHING - and 
locate the description of the tasks in that namespace and additional 
metadata. The descriptor should support both properties (for simple cases)
and an XML form. 

4. A very tricky issue is the syntax of the ID. We can use a meaning-less
string, or a URL that can be used to download the lib. Even in the first 
case ( arbitrary string ) we can have a 'antlib registry' - but it would 
be extra overhead. I know there are many (strong) opinions on this.

5. Even if ns is added, most people will still prefer to use the default
namespace. It's just much easier to type and use ( at least IMO - and from
what I've seen ). Should we restrict the default ns to ant core tasks and
force everyone to use ns for extensions ? I don't think so.  

6. Namespaces should be used instead of 'taskdef' whenever possible 
( i.e. the descriptor  ).


Costin

Wannheden, Knut wrote:

> This reply is a little bit late (just got back from holiday) but I think
> it's an important topic and I was wondering if anybody has given this more
> thought in the meantime.
> 
> With some minor adaptions I think your general description of the usage of
> XML namespaces sounds very good.
> 
>> -----Original Message-----
>> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>> Sent: Freitag, 6. September 2002 23:54
>> To: Ant Developers List
>> Subject: Re: xml namespace support in ant2
>> 
>> So instead we could say that
>> 1) all ant: namespace elements are core ant.
>> 
> 
> Well, what the namespace prefix is in the buildfile is really up to the
> user.  It's just the URI that matters.  So all of thw following should
> work:
> 
> <project xmlns="urn:ant-namespace">
>  <target name="test"/>
> </project>
> 
> <xyz:project xmlns:xyz="urn:ant-namespace"/>
> 
> But specifying it as the default namespace as in the first example or
> using "ant" as the prefix will probably be the most common usages.
> 
> When you say "core ant" I assume you're talking about <project>, <target>,
> all core and optional tasks and types in the distribution.
> 
>> 2) different namespaced elements have to be defined before use as
>> taskdefs, typedefs or antlibs, and ant treats them accordingly
>> 
> 
> I think saying it the other way around would be more correct.  I.e. Custom
> tasks and types have to be declared to use a different XML namespace.
> 
>> 3) all namespaced tags that are not declared as in (2) must
>> be declared
>> beforehand as <namespacedef namespace="nms" handler="..."/>,
>> so that the
>> Ant ProjectHelper can use that particular Handler to process the
>> extension. A convenient nullHandler is created when the
>> handler is not
>> specified.
>> 
> 
> What would this be used for?  Isn't it enough with task and type
> extenstions?  Other extensions would certainly raise confusion...
> 
> The primary benefits I see of using XML namespaces the described way are:
> 
> - Mechanism to avoid name clashes of different tasks and types
> - Schemas (grammars) could be written for Ant buildfiles covering the Ant
> core elements and external tasks and types.
> 
> The schemas in turn would allow the validation of tasks and types to take
> place externally and at an earlier stage.  With externally I mean that the
> tasks and types wouldn't need code to do the validation themselves.
> 
> At a later stage the schemas could maybe even be the basis for the
> documentation.  Also, the different usages of a task could maybe be bound
> to the different processing modes somehow.
> 
> Playing some with RELAX NG and Sun's MSV validator I found that it was
> quite
> easy to specify grammars for the different Ant tasks and types.  Even
> writing grammars that support other namespaces isn't very hard.  That way
> a grammar which validates buildfiles using other namespaces for external
> tasks
> and types can be constructed easily.  It should also be quite easy to
> allow external tasks to specify their own grammar for validation.
> 
> Any thoughts?
> 
> Cheers,
> 
> --
> knut

-- 
Costin



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message