ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: antlib / proposal of Peter Reilly
Date Mon, 19 May 2003 14:33:21 GMT
> From: peter reilly [mailto:peter.reilly@corvil.com]
> 
> On Monday 19 May 2003 11:50, Wannheden, Knut wrote:
> >
> > I don't quite see why it would be impossible to have 
> meaning-free URIs. 
> 
> Nothing is impossible..., but it is difficult to have 
> meaning-free URIs and to
> support (as in ignore) other URIs.
> 
> I would like ant to ignore other namespaces so that it is a 
> civilized member
> of the xml community.
> 
> For example the following specifies which processor deals with which
> element tag:
> 
> <project xmlns:h="http://www.w3.org/1999/xhtml"
>          xmlns="ant:core">
>   <echo message="hello world"/>
>   <h:html>
>     <h:body>hello world</h:body>
>   </h:html>
> </project>
> 
> the above produces "hello world" as an ant script and "hello 
> world" in an NS
> aware browser.
> 

I really think this is the very worst that we can do to ANT.
The above example is nore than just confusing, it seem to me
quite meaningless. I can see situations where could be valid
for ANT not to interpret another NS but not just plain ignore it.

For example it would be nice if I could write the following:

<project xmlns:h="http://www.w3.org/1999/xhtml"
         xmlns="ant:core">
  <echo file="out.html">
    <h:html>
      <h:body>hello world</h:body>
    </h:html>
  </echo>
</project>

with the result being a file out.html containing:
    <h:html xmlns:h="http://www.w3.org/1999/xhtml">
      <h:body>hello world</h:body>
    </h:html>

But in here we are not ignoring the XHTML, instead we are
able to interpret it to be "equivalent" to TEXT for the purpose
of parsing. Which is not the same.

BTW, this is what things like XSLT do when you use other namespaces.

> > I
> > think it makes perfectly sense.  Namespaces are to avoid 
> name clashes.
> 
> This is not the only reason for XML namespaces. The standard says
> that are to allow "elements and attributes that are defined 
> for and used
> by multiple software modules".
> 

Besides of the issue of how to completly ignore things (as you wanted above)
all your different NS that you force people to use (all the diferent antlib:xxx)
are all process by the same software module (i.e., ANT).

The thing I do not like is that it continues forcing us to have a CORE
which has special rules to manage its special NS and any other libraries
which are force to use NS designators.

Moreover, it means that until the end of time we will have to continue
shipping ANT as a monolitic gigantic antlib containing every definition
for CORE and OPTIONAL tasks. Why? Because that is the only way to have
them all using the default namespace.

If instead we use uninterpreted URIs which are only there for collision solving
then we can chop things in reasonable componets and still being able to
use them in a backward compatible manner.

> >  IMO
> > an URI starting with "antlib:" should always mean that the following
> > denotes a package with that antlib.  What would happen if I 
> had a Java
> > package on the classpath called "arbitarystring"?
> 
> The definitions are appended to the definitions defined in {converted
>   package}/antlib.xml.
> 
> This is the same behaviour as definitions going into the 
> default namespace.
> 
In your example above you use 'xmlns="ant:core"' instead of 'xmlns="antlib:org.apache.tools.ant..."'
so it does not seem to be the same behaviour, there is something magical about CORE.

If you were to tell me that there is some sort of implicit 'xmlns="antlib:...."' for the core
that I could accept, but I really dislike having some other special notation.

Notice that in Java, the only special thing about the language is the it provides
an implicit 'import java.lang.*;' that is all, appart from that the language makes
absolutely no distinctions between Java CORE and any third party libraries.
Everybody plays by exactly the same rules.

That is what I would like to achieve at the end of this exercise.

Jose Alberto

Mime
View raw message