Yikes!!
There are a number of issues here.
1) are build script authors allowed to specify arbitary
URIs for ant type definitions?
I do not think this is a good idea.
2) what should ant do with URIs that it does not recognize?
a) use current method - unknown elements
b) ignore them
c) explicty say that the ns uri is not supported
d) convert them to Text in task/typedefs (the suggestion below)
I would prefer b) as it allows other processing of the xml content -
say in an xml processing pipeline. d) is also nice.
3) Should all processing outside Project/Target be done by PH2#ElementHandler?
I think one should be able to plug in handlers for different URIs, or URI
patterns. My UnknownUriHandler is an (possibly not very good) example.
On Monday 19 May 2003 15:33, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > 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.
He came, He saw, He destroyed...
Some xml applications ignore content outside its domain, some
do not..
> 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).
No, I think that URI handlers should be pluggable in and not all
XML should be processed via the ElementHandler / UnknownElement /
IntrospectionHandler and RuntimeConfigurable classes.
XML NS Uri's introducded via antlib/typedef should be processed via
the ANT software module (in my view). But other sources - for example
Mbean support may use a different collection of classes.
>
> 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.
I do not follow your argument here. What difference do uninterpreted URIs
make to the ANT being an gigantic antlib?
>
> > > 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.
Initially I had the default being "antlib:org.apache.tools.ant..", but I
dropped that for two reasons:
1) for bc reasons, the definitions defined by typedef or
at start up (copy, concat...) belong to the same namespace URI
as "project" and "target" and the element tags figured out by
Introspection as well as attributes like "id". So it is a special URI
from the point of view of definitions.
2) to support polymorphic behaviour, people wanted to place the type
definer in a separate namespace to other attributes, this URI
is not a "antlib".
>
> 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.
Point accepted.
>
> 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.
And one of the rules is that the names of classes follow certain patterns.
> Everybody plays by exactly the same rules.
>
> That is what I would like to achieve at the end of this exercise.
I also ..
Hence things like onerror, copied from your antlib proposal, which
allows 3th party libs to specify which tasks/types are optional (in
the same way as the ant core tasks).
Or the fact that both the core defintions and the definitions defined
by typedef, use the same type - antTypeDefinition.
Cheers,
Peter
