You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by bu...@apache.org on 2010/08/05 11:15:14 UTC
DO NOT REPLY [Bug 49707] New: Mix of qualified and local names for
AbstractElement.setAttributeNS
https://issues.apache.org/bugzilla/show_bug.cgi?id=49707
Summary: Mix of qualified and local names for
AbstractElement.setAttributeNS
Product: Batik
Version: 1.7
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: SVG DOM
AssignedTo: batik-dev@xmlgraphics.apache.org
ReportedBy: jfm@macqel.eu
In the method "setAttributeNS" of the class "AbstractElement":
- the 2nd argument "qualifiedName" is supposed to be a qualified name
- a call to "getAttributeNodeNS" use the argument "qualifiedName"
- a call to "createAttributeNS" use the argument "qualifiedName"
The problem is that "getAttributeNodeNS" requires a local name (and not a
qualified name).
So, when I give a qualified name as second argument to "setAttributeNS",
the serach made by "getAttributeNodeNS" always return null (even when the
attribute already exists).
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
DO NOT REPLY [Bug 49707] Mix of qualified and local names for
AbstractElement.setAttributeNS
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49707
--- Comment #6 from Helder Magalhães <he...@gmail.com> 2010-08-22 11:44:26 EDT ---
(In reply to comment #5)
> > Otherwise I would make a test like that:
> > - create a document D with an element E with attribute xml:id="id1"
> > - then I would call: E.setAttributeNS( ..., "xml:id", "id2");
> > - and finally I would test the result of a call to D.getElementById("id1")
> > Guess it is non null and return elt E?
>
> This doesn't happen for me with current SVN Batik.
@Marchant:
As hinted by Thomas, please provide further information, such as:
* Batik version (or revision when working with SVN);
* Java version (JRE, JDK, vendor - Sun/Apache/OpenJDK, etc.);
* SVG document version;
* XML parser being used (Batik's or an external one).
The SVG document version being requested is somehow a shoot in the dark: May
this have something to do with an SVG-version specific issue? (See bug 46791,
for example.) Hope I'm not just adding more noise to this! ;-)
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
DO NOT REPLY [Bug 49707] Mix of qualified and local names for
AbstractElement.setAttributeNS
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49707
--- Comment #3 from Thomas Deweese <de...@apache.org> 2010-08-20 07:35:19 EDT ---
(In reply to comment #2)
> YOUR code in the library is:
> public void setAttributeNS(String namespaceURI,
> String qualifiedName,
> ^^^^^^^^^^^^^^
> you want a QUALIFIED name as 2nd argument; ok that is as in W3C DOM
> documentation
> Attr attr = getAttributeNodeNS(namespaceURI, qualifiedName);
> ^^^^^^^^^^^^^
> Here you give a QUALIFIED name as argument but as explained in the online
> documentation, getAttributeNodeNS NEED a LOCAL name.
I agree that this line is in error. We should pass the localName
here, however
> So you have the incorrect behaviour I have explained in my first comment
This I don't follow. The call to getAttributeNodeNS will fail
returning null, but that simply means that we create a new attribute
node which might be inefficient but wouldn't make getAttributeNodeNS
fail for you.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
DO NOT REPLY [Bug 49707] Mix of qualified and local names for
AbstractElement.setAttributeNS
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49707
Marchant Jean-François <jf...@macqel.eu> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #7 from Marchant Jean-François <jf...@macqel.eu> 2010-08-23 06:59:12 EDT ---
Hi
I have tried to reproduce my problem in a little example but I did not succeed
:-(
Anyway, the most important is that the error in
"AbstractElement.setAttributeNS" will be fixed.
Thanks for your support
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
DO NOT REPLY [Bug 49707] Mix of qualified and local names for
AbstractElement.setAttributeNS
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49707
Thomas Deweese <de...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |NEEDINFO
--- Comment #5 from Thomas Deweese <de...@apache.org> 2010-08-22 11:14:05 EDT ---
(In reply to comment #4)
> The bug I encountered that is a consequence of the mistake in
> - You say your code create a new attribute for me. Yes, but so I have as a
> result two attributes with the same name?
No the new value replaces the old value.
> - In my code, the bug arise when the attribute is an Id attribute like
> (xml:id).
> The consequence of your error was that the map 'elementsById' in your class
> "AbstractDocument" was not well updated. Finally, my call to "getElementById"
> on the document gave bad results.
Have to tried your test with the current SVN version of Batik?
I can't reproduce your bug as described below with it. I ask because
the code in the 'wrong' branch could just as easily be done by users
(similar calls are available in the public DOM) in which case this
would fail for them as well, so this bug is more serious than the
performance issue.
> Anyway, I suppose you will fix the agreed error in "setAttributeNS"?
Yes, but I want to make sure that you agree that the xml:id bug is
fixe in current SVN first, otherwise this simply hides the real bug.
>
> Otherwise I would make a test like that:
> - create a document D with an element E with attribute xml:id="id1"
> - then I would call: E.setAttributeNS( ..., "xml:id", "id2");
> - and finally I would test the result of a call to D.getElementById("id1")
> Guess it is non null and return elt E?
This doesn't happen for me with current SVN Batik.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
DO NOT REPLY [Bug 49707] Mix of qualified and local names for
AbstractElement.setAttributeNS
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49707
--- Comment #1 from Helder Magalhães <he...@gmail.com> 2010-08-19 19:01:21 EDT ---
(In reply to comment #0)
> In the method "setAttributeNS" of the class "AbstractElement":
The relevant documentation can be found online (Batik class [1] which
implements a W3C DOM interface [2]).
> So, when I give a qualified name as second argument to "setAttributeNS",
> the serach made by "getAttributeNodeNS" always return null (even when the
> attribute already exists).
You seem to be using distinct DOM interfaces to achieve apparently related
results...? (It seems like you'd want to use "getAttributeNS" [1] instead.)
Please check the proper documentation and confirm if the above makes sense
(maybe marking the issue as invalid), or please try to add more information.
;-)
[1]
http://xmlgraphics.apache.org/batik/javadoc/org/apache/batik/dom/AbstractElement.html#getAttributeNodeNS%28java.lang.String,%20java.lang.String%29
[2]
http://www.w3.org/2003/01/dom2-javadoc/org/w3c/dom/Element.html#getAttributeNodeNS_java.lang.String__java.lang.String_
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
DO NOT REPLY [Bug 49707] Mix of qualified and local names for
AbstractElement.setAttributeNS
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49707
--- Comment #4 from Marchant Jean-François <jf...@macqel.eu> 2010-08-20 08:06:27 EDT ---
The bug I encountered that is a consequence of the mistake in
AbstractElement.setAttributeNS is quite complex
- when I said that "getAttributeNodeNS" failed, it is the one in your code, not
in my code
- You say your code create a new attribute for me. Yes, but so I have as a
result two attributes with the same name?
- In my code, the bug arise when the attribute is an Id attribute like
(xml:id).
The consequence of your error was that the map 'elementsById' in your class
"AbstractDocument" was not well updated. Finally, my call to "getElementById"
on the document gave bad results.
Anyway, I suppose you will fix the agreed error in "setAttributeNS"?
Otherwise I would make a test like that:
- create a document D with an element E with attribute xml:id="id1"
- then I would call: E.setAttributeNS( ..., "xml:id", "id2");
- and finally I would test the result of a call to D.getElementById("id1")
Guess it is non null and return elt E?
Thanks for your support.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org
DO NOT REPLY [Bug 49707] Mix of qualified and local names for
AbstractElement.setAttributeNS
Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49707
--- Comment #2 from Marchant Jean-François <jf...@macqel.eu> 2010-08-20 01:31:35 EDT ---
I do not understand your comment.
Here another way of explaining what I found in your code.
YOUR code in the library is:
public void setAttributeNS(String namespaceURI,
String qualifiedName,
^^^^^^^^^^^^^^
you want a QUALIFIED name as 2nd argument; ok that is as in W3C DOM
documentation
String value) throws DOMException {
if (attributes == null) {
attributes = createAttributes();
}
if (namespaceURI != null && namespaceURI.length() == 0) {
namespaceURI = null;
}
Attr attr = getAttributeNodeNS(namespaceURI, qualifiedName);
^^^^^^^^^^^^^
Here you give a QUALIFIED name as argument but as explained in the online
documentation, getAttributeNodeNS NEED a LOCAL name. So you have the incorrect
behaviour I have explained in my first comment
if (attr == null) {
attr = getOwnerDocument().createAttributeNS(namespaceURI,
qualifiedName);
attr.setValue(value);
attributes.setNamedItemNS(attr);
} else {
attr.setValue(value);
}
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-dev-help@xmlgraphics.apache.org