[ expat-Bugs-824420 ] expat-2003-10-15 - something is broken or at least changed
"SourceForge.net" <[email protected]>
| Newsgroups | gmane.text.xml.expat.bugs |
|---|---|
| Message-ID | <[email protected]> |
Bugs item #824420, was opened at 2003-10-15 17:40 Message generated for change (Comment added) made by kwaclaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 Category: None Group: Test Required Status: Open >Resolution: Fixed Priority: 5 Submitted By: Rolf Ade (pointsman) >Assigned to: Fred L. Drake, Jr. (fdrake) Summary: expat-2003-10-15 - something is broken or at least changed Initial Comment: (.. err, sorry for steppin' in late, again :-( ) I compiled my expat based project with expat-2003-10-15 and run my test suite. For at least some rare cases, there seems to be something broken. I haven't any deep insights, so far, but since I can't spend much more time at it this night and in face of the upcomming release, I decided to just yell, only with an example. Please download the document http://www.w3.org/TR/1999/REC-xslt-19991116.xml If I run 'xmlwf REC-xslt-19991116.xml' I get REC-xslt-19991116.xml:396:0: unbound prefix This seems wrong to me in two ways. First, without the -n option, xmlwf shouldn't care at all, if a prefix isn't bound to a namespace. At least xmlwf 1.95.6 (and prior versions) didn't care (and I would say, this was right). And second, as far as I can tell, the claim itself is false; there is a xmlns:e namespace declaration in scope of that element. I stumbled over the problem while using the lib and then tried to reproduce the problem with xmlwf, for easy demonstration. So, if there is a problem, it's not with the xmlwf tool, but with the lib itself. rolf ---------------------------------------------------------------------- >Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-16 10:28 Message: Logged In: YES user_id=290026 Fix committed as xmlparse.c rev.1.116. ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-16 09:26 Message: Logged In: YES user_id=290026 Rolf, I think I was wrong when I said that prefix processing was always done - it was really only done when elementType->prefix was non-null despite of ns processing being turned off. This only happened when the element type contained a prefix already in the DTD, as far as I can tell. That fact that there was no error previously was simply that the error code for if (!binding) was XML_ERROR_NONE, which would fail to detect cases in which an error should be returned. Once I changed this then it started to return errors when it should not - as you detected. After looking at that I saw that the if (elementType->prefix) test was sometimes positive even if namespaces were turned off, which led to the error. As a result of the one-line change it should actually run faster now in those rare cases when we have prefixes in the DTD. ---------------------------------------------------------------------- Comment By: Rolf Ade (pointsman) Date: 2003-10-16 07:15 Message: Logged In: YES user_id=13222 Thanks for the quick patch, Karl! Your patch fixed the problem with the example document REC-xslt-19991116.xml. Well, since you said (and your patch suggests) that up to now expat simply always did ns checking, even if not asked for, I wonder, why it hallucinated, that the prefix binding were missing, which is not the case (as even xmlwf -n itself now - with an appropiate SYSTEM identifierer or no system identifier) - confirms). Anyway. So far, I could not decteced any other problem with the test suite of my expat pased project. I also run xmlwf against the OASIS xml test suite (with the same methodology as in #569461) and found nothing new or alarming. Tests, that are still wrong, as in previous versions are ibm/not-wf/misc/432gewf.xml sun/not-wf/uri01.xml xmltest/not-wf/not-sa/010.xml xmltest/not-wf/not-sa/011.xml And the debatable xmltest/not-wf/not-sa/005.xml which could not counted to the failed tests, because the rec allows well-formedness parser to fail at this test as well as to pass it (as already discussed in #569461) - although I personally feel, that it would be better for the expat users, if expat would signal error in this cases. Even a few preliminary benchmark tests haven't showed a problem (up to now, I don't see any slow down, which would worth mentioning). ---------------------------------------------------------------------- Comment By: Karl Waclawek (kwaclaw) Date: 2003-10-15 20:41 Message: Logged In: YES user_id=290026 Please try the attached fix: prefix_patch.diff. The (old) code was processing prefixes even if namespaces were turned off. Hopefully the changes don't break anything else. Would be nice if you could run it through the test-suite. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127