On Tue, 9 Jul 2002, Yyy Xxx wrote: > Using a colon for non-namespace purposes is simply bad > XML.
And with a simple config setting it is possible to use either SAX1 or SAX2 ( so even if some bad XML with : is used, it'll still work ). > I'd like to know what "namespace support" > means to Ant before its added. However, I don't think Same for me :-) At the moment using ProjectHelper2 it is possible to use SAX2 and namespaces. However there is no special meaning attached to the namespace. One first step would be to define the namespace for the core elements, and decide what to do about optional elements. My current opinion is that each 'tag library' should use one namespace, and to somehow use 'meaningfull' namespaces - but there are many choices here. So far I am convinced that we need an association between class loaders and namespaces - for example an extra attribute on the <classpathpath> to specify that it must be associated with a particular namespace. That would allow automatic loading of tasks when a namespace is used. I would also couple this with a discovery mechanism as specified in JDK1.3 services ( commons-discovery would make it very easy, and it is already a common practice in many projects ). The last 2 features would allow something like: <path id="http://jakarta.apache.org/ant/taskLib1.aar" ... /> <tlib1:task1 ns:tlib1="http://jakarata.apache.org/ant/taskLib1.aar" /> ( aar is war with 'ant' instead of 'web' :-) The first definition will associate the ns URL with a path, and then task1 is located by using discovery on that path ( thus getting the list of tasks defined in that loader ). Taskdef is no longer used. We can also use the ns URI to download the extensions automatically - that would require ProjectHelper to somehow call jjar or a similar task. A big question for me is what to do about dynamic properties. ProjectHelper supports ${ns:expression} - and I'm trying to find a way to associate the 'ns' with a namespace and with an expression evaluator ( and to find an API for the expression evaluator - most likely BSF-like based on what I learned so far ). Of course it would be nice to have the same mechanism for both. BTW, all of this should work with ant1.5+ - eventually (after those issues are solved) I'll propose this to be included in ant1.6, but it can be a separate component as well. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
