Should there be a method corresponding to dm:node-name as well as its current two components?

[GoogleCodeExporter]

Currently:

String getLocalName(N node) (and similarly for Reader/Informer/Cursor with no 
parameter)
String getNamespaceURI(N node) (ditto)

The accessor in the data model specification would be more closely modeled as:

javax.xml.namespace.QName getName(N node) (or getNodeName(N node))

For a variety of reasons, which will be included in the comments below, this 
pattern was not chosen for the original development.  The question is now 
officially reopened for discussion and resolution on the merits.

Original issue reported on code.google.com by aale...@gmail.com on 5 Nov 2010 at 6:16

[GoogleCodeExporter]

Not before 1.0.  We have adequate utility at present; adding support for 
javax.xml.namespace.QName raises more questions about other methods (we should 
extend the question to: should we just replace namespace + name with QName?).  
For initial release ... we don't want the duplication (even of a single method, 
as suggested here), and we currently are using the separated style.

Drop priority.  Deal with this post-1.0.

Original comment by aale...@gmail.com on 15 Feb 2011 at 5:40

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

I agree that this is a *very* low priority. About the only thing that would 
make this essential would be a demonstrated efficiency gain by adding such a 
method.

Set milestone to "future".

Original comment by eric%tib...@gtempaccount.com on 15 Feb 2011 at 8:56

• Added labels: Milestone-Future

[GoogleCodeExporter]

Suggestion has been made that we bump the priority on this.

Original comment by aale...@gmail.com on 26 Jul 2012 at 7:18

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

At this point, I'd be in favor of universally changing the interface, such that 
we always use QName. It's pretty much expected; apart from DOM, we're probably 
one of the very few APIs around that return namespace and local name and prefix 
separately.

Original comment by aale...@gmail.com on 3 Apr 2014 at 5:19

[aalewis-tibco]

We should probably do this, but it's actually a "refactoring", which is not a thing that is in the list of standard labels. It's an API change, too, so earliest is 1.3.

[aalewis-tibco]

No.