> -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED] > Sent: Freitag, 6. September 2002 01:09 > To: Ant Developers List > Subject: Re: xml namespace support in ant2 > > > On Thu, 5 Sep 2002 20:08, Wannheden, Knut wrote: > > I know this topic has been brought up before (e.g. in > "Optional tasks" > > thread of last december [1]), but I still wonder what is > the actual plan > > for the accepted requirement for Ant2. > > I don't think there is any plan for it at this stage. There > are too many > potential uses of namespaces and associated confusion. Do you > namespace; > * property names > * types (aka tasks, datatypes, condtions, etc) > * property evaluation (ie "${javascript:performMagic()}" > * target names (ie if you depend on foo:bar target will that > execute bar > target in foo project?) > * aspects (ie add ant:fail-on-error="true" to all tasks) >
Most of these options don't have anything explicitly to do with XML Namespaces [1], just namespaces as a general concept. I was wondering about the former. Because as of now it isn't even allowed to have XML namespace declarations in the buildfile, as has been requested before (e.g. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11870). But my point is that XML namespaces could actually be employed for something useful. > > <project xmlns="http://jakarta.apache.org/Ant/v2"; > > xmlns:my="urn:my-ant-tasks" > > default="test"> > > > > <taskdef qname="my:foo" classname="org.bar.FooTask"/> > > <taskdef name="baz" ns="urn:my-ant-tasks" > classname="org.bar.BazTask"/> > > > > <target name="test"> > > <echo message="test"/> > > <my:foo/> > > <whatever:baz xmlns:whatever="urn:my-ant-tasks"/> > > </target> > > > > </project> > > > > (Note the two different uses of <taskdef>.) > > type aliasing is no problem but I think that is independent > of the main issue. > I wouldn't say this use was mainly about aliasing, but more about modularization. If you write a set of custom tasks and types as part of a library you define them in a separate XML namespace when used. Aliasing isn't a real problem in Ant anyway, because you can dynamically assign any name you want to a custom task or type. So there's no real need for XML namespaces to avoid name clashes. > However I think you will find it hard pressed to validate > anything without the > runtime context being present. It may be possible but I think > that it would > need to be seen to be believed ;) > I'm not talking about validation at the semantic level here, it would just be about lexical validation. As I understand it, the Ant core performs most of the semantic but only some lexical validation. For instance does Ant prevent you from specifying bogus attributes for a task, but it doesn't know anything about what attributes and nested elements are allowed in conjunction. This validation has to be done by the task implementation, and it's easy to go wrong here and bloats the code. But worst of all, it can result in unexpected behaviour. Take these two uses of <fileset> for example: <fileset defaultexcludes="true" refid="foo"/> <fileset refid="foo" defaultexcludes="true"/> Assuming that there is a defined <fileset id="foo"/>. Ant won't complain about the first definition (assuming the setters are invoked in the same order the attributes are listed), but the second one will raise a BuildException. A formal specification would really help here. Possibly you could also generate consistent user documentation for the tasks from an annotated version of this formal specification. There are also context sensitive XML editors using grammars to implement some kind of code assist. I believe many users would find that useful as well. XML namespaces certainly wouldn't be a prerequisite for a grammar, but it would certainly make it easier. [1] Namespaces in XML http://www.w3.org/TR/REC-xml-names/ Cheers, -- knut
