Christopher Lenz wrote:Personally, I prefer DOM style as it is higher-level. The qualifiedName parameter makes sense (well, sort of) when you can enable/disable namespace support. When namespace support is always enabled (as it is in Ant 1.6) the (namespaceURI, prefix, localName) partitioning makes more sense IMHO, and is easier to use.
The prefix is in any case nearly useless to the user: <dtest xmlns:ant="antlib:org.apache.tools.ant" xmlns:uri="uri"> <uri:local/> <ant:local/> <local/> <local xmlns="antlib:org.apache.tools.ant"/> </dtest>
Yes, usually you don't need to know about the prefix. It is only necessary if the prefix is used in attribute values, as in XSLT. So if I wanted to create a task that directly embeds XSLT templates in build files, having access to the namespace prefix mappings would be mandatory.
However, I really think we should pass a NamespaceContext (working title) instead of the prefix, as explained in another post in this thread.
The problem with this is that the namespace context is only valid at parse time. So ant would have to remember the different contexts, and apply
them at runtime which is not too easy,
Ah, the often overlooked (at least by me) distinction between parse time and run time :-/
Considering this, the best choice for now might be to leave the prefix/qualifiedName information out of the interface completely (just ommitting the "prefix" parameter from the proposed interface).
For Ant HEAD, we could think about ways to preserve namespace prefix information so that it is also available at run time. When/if that is resolved, an extended DynamicConfiguratorNS interface could be made available.
Does that make sense? Chris
-- Christopher Lenz /=/ cmlenz at gmx.de
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
