Wannheden, Knut wrote:
-----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.
Yup.
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.
proposal/embed is completely SAX2 based, so there it's possible. The point is exactly what you say: what to do with it ;-)
<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.
There is if you write a library that must be imported, as you say.
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.
Ahhh... so each "library" would have its namespace with its validation! Now I get it , cool!
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/
Good, now I understand :-D
You are right, if we make tasks use a namespace, they can also supply the schema for themselves, and be validated by XML parsing instead of inside themselves!
This is really very very cool, I want it in embed proposal :-)
Any practical implementative suggestions?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
