Hi all,
in the light of a final release of 1.6 next week, I think the DynamicConfigurator issue with namespaces needs to be resolved. I can't believe I'm the only one who has a problem with the current implementation, which concatenates the namespace URI and the local name of the element to pass it into DynamicConfigurator#createDynamicElement. This is a change that breaks backwards compatibility because the semantics of the method is changed.
So I wonder: why not just pass the elements local name to the method? That would preserve the semantics from 1.5 (except if the build file writer has decided to use colon-separated prefixes in element names [1]).
If there is a potential DynamicConfigurator implementation that needs the namespace information, such as Stefan's new XMLFragment, it will probably need more information about the namespace anyway (such as prefix mappings). So instead of hacking namespace support into DynamicConfigurator and thereby breaking backwards compatibility, an extended DynamicConfigurator interface should be scheduled for inclusion in a post 1.6 release.
BTW, I have other issues with the namespace support in 1.6, such as pervasive use of the term "uri" for namespace URIs. URI is (IMHO) a *type* of data, but does not convey it's semantics. The semantic is "namespace", the type is "URI". But I'm not gonna push this any further :-P
Are there any good arguments for not changing the DynamicConfigurator code to pass only the local name?
-- Christopher Lenz /=/ cmlenz at gmx.de
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
