DOM does not give you access to the NS prefix, at least when you create an
element from the document. Why would you need the prefix? Granted, even XSL
uses the prefix in attribute values (xs:string), but it's bad XML according
to EffectiveXML and others... The namespace prefix is the
business of the XML file writer, not the XML application. --DD
Actually, DOM *does* give you access to the namespace prefix, see the org.w3c.dom.Node#getPrefix method.
As you say, XML applications such as XSLT use namespace prefixes in attribute values (XPath expressions, mostly). XSLT would be rather unusable if it did not provide the XPath evaluator access to the prefix mappings in the document. Whether some consider it bad practice doesn't really matter IMHO.
But anyway, the DynamicConfiguratorNS interface I proposed doesn't help much for applications such as XSLT which make heavy use of namespace prefixes. Indeed, passing the prefix is probably utterly useless. Rather, the DynamicConfiguratorNS would need access to the full namespace-prefix-mappings at the current location in the document. Maybe a NamespaceContext object should be passed in instead?
public interface NamesapceContext {
public String getPrefix(String namespaceURI);
public String getURI(String namespacePrefix);
}What do you think? Chris
-----Original Message----- From: Christopher Lenz To: Ant Developers List Sent: 12/12/2003 4:12 AM Subject: Re: DynamicConfigurator namespace problem
Am 12.12.2003 um 10:23 schrieb Stefan Bodewig:On Fri, 12 Dec 2003, Peter Reilly <[EMAIL PROTECTED]> wrote:
Yes, either add DynamicConfiguratorNS or revert the change I made yesterday to DynamicConfigurator.
I'm more inclined to add DynamicConfiguratorNS.
Same here. Proposed interface:
public class DynamicConfiguratorNS {
public Object createDynamicElement( String namespaceURI, String prefix, String localName);
public void setDynamicAttribute( String namespaceURI, String prefix, String localName, String value);
}
Where namespaceURI, prefix and localName have the same semantics as in DOM Level 2: http://www.w3.org/2003/01/dom2-javadoc/org/w3c/dom/Node.html
I don't think this interface should extend DynamicConfigurator. The only effect would be that implementors also would need to implement the old two pair of methods.
Cheers, Chris
-- Christopher Lenz /=/ cmlenz at gmx.de
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
