RE: Possible conflict in 3.1 between importNode and setPrefix
Boris Kolpackov wrote on 2010-02-17: > The thing is the create* functions in each case are passed qualified names > so they set the correct prefix, according to my tests. Unfortunately, the > test that led to the original fix cannot be found. So I think it is safest > to revert the change. Gotcha. I was going to look into it myself when I had some time, because I use importNode a lot and I think I would have noticed if the prefixes dropped, but I hadn't had time. In that case, I agree with your assessment. > Done. Use the 3.1 branch for the 3.1.0 bugfixes. Thanks. -- Scott - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Possible conflict in 3.1 between importNode and setPrefix
Hi Scott, Scott Cantor writes: > It would work if the setPrefix method was altered to check for NULL before > throwing the exception. The thing is the create* functions in each case are passed qualified names so they set the correct prefix, according to my tests. Unfortunately, the test that led to the original fix cannot be found. So I think it is safest to revert the change. > Doing that now. The Debian packaging folks indicated to me informally that > it would help them justify a downstream patch to 3.1.0 if there were a patch > checked in on the branch. Do you plan to do that soon? Done. Use the 3.1 branch for the 3.1.0 bugfixes. Boris -- Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog Open-source XML data binding for C++ http://codesynthesis.com/products/xsd XML data binding for embedded systems http://codesynthesis.com/products/xsde Command line interface to C++ compiler http://codesynthesis.com/projects/cli - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
RE: Possible conflict in 3.1 between importNode and setPrefix
Boris Kolpackov wrote on 2010-02-16: > There was a test case reported on the XQilla mailing list which showed > that qualified elements would loose their prefixes during import. As a > result, the explicit call to setPrefix was added for elements and, just > to be sure, I assume, for attributes. The change for attributes was a > bad idea since it doesn't work for the xmlns="" attributes. It would work if the setPrefix method was altered to check for NULL before throwing the exception. I don't think there's any compelling reason why setPrefix should fail on xmlns="" with a null input parameter, it's just a noop. Alternatively, call setPrefix based on whether the original node has a prefix, not whether it has a namespace. > There is no Jira issue. Feel free to create one, though. Doing that now. The Debian packaging folks indicated to me informally that it would help them justify a downstream patch to 3.1.0 if there were a patch checked in on the branch. Do you plan to do that soon? Thanks, -- Scott - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Possible conflict in 3.1 between importNode and setPrefix
Hi Scott, Scott Cantor writes: > The patch backs out the change, from the look of it. What was the change > intended to address? There was a test case reported on the XQilla mailing list which showed that qualified elements would loose their prefixes during import. As a result, the explicit call to setPrefix was added for elements and, just to be sure, I assume, for attributes. The change for attributes was a bad idea since it doesn't work for the xmlns="" attributes. > Is the bug in Jira, by the way? I'm not finding it. I have some downstream > packagers that would be served by having it filed, so I can take care of > that if it's needed. There is no Jira issue. Feel free to create one, though. Boris -- Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog Open-source XML data binding for C++ http://codesynthesis.com/products/xsd XML data binding for embedded systems http://codesynthesis.com/products/xsde Command line interface to C++ compiler http://codesynthesis.com/projects/cli - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
RE: Possible conflict in 3.1 between importNode and setPrefix
Boris Kolpackov wrote on 2010-02-15: > Hi Scott, > > This is a known bug. I also have a patch: > > http://www.codesynthesis.com/~boris/tmp/xerces-c-3.1.0-dom-import.patch The patch backs out the change, from the look of it. What was the change intended to address? Is the bug in Jira, by the way? I'm not finding it. I have some downstream packagers that would be served by having it filed, so I can take care of that if it's needed. -- Scott - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Possible conflict in 3.1 between importNode and setPrefix
Hi Scott, This is a known bug. I also have a patch: http://www.codesynthesis.com/~boris/tmp/xerces-c-3.1.0-dom-import.patch Boris -- Boris Kolpackov, Code Synthesishttp://codesynthesis.com/~boris/blog Open-source XML data binding for C++ http://codesynthesis.com/products/xsd XML data binding for embedded systems http://codesynthesis.com/products/xsde Command line interface to C++ compiler http://codesynthesis.com/projects/cli - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Possible conflict in 3.1 between importNode and setPrefix
I believe there's a fix/change to the importNode method in 3.1 that's
supposed to maintain namespace prefixes across the import, but I think it's
conflicting with a check inside the DOMAttr::setPrefix method:
void DOMAttrNSImpl::setPrefix(const XMLCh *prefix)
{
const XMLCh * xmlns = DOMNodeImpl::getXmlnsString();
if (fNode.isReadOnly())
throw DOMException(DOMException::NO_MODIFICATION_ALLOWED_ERR, 0,
GetDOMNodeMemoryManager);
if (fNamespaceURI == 0 || fNamespaceURI[0] == chNull ||
XMLString::equals(fLocalName, xmlns))
throw DOMException(DOMException::NAMESPACE_ERR, 0,
GetDOMNodeMemoryManager);
My imports appear to be throwing the second exception listed because the
attribute node being manipulated is a default namespace prefix decl
(xmlns="..."). The XMLString::equals(fLocalName, xmlns) test is failing.
I haven't investigated further yet, but since this is all code internal to
Xerces, it seems like it's probably a bug. I think the problem is that the
code in importNode that's setting the prefix isn't checking if the prefix is
empty, and the check inside setPrefix really shouldn't fire unless the
prefix passed in is non-empty.
-- Scott
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
