[ 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 fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127

Category: None
Group: Test Required
>Status: Closed
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: Fred L. Drake, Jr. (fdrake)
Date: 2003-11-02 03:13

Message:
Logged In: YES 
user_id=3066

Regression test added in tests/runtests.c revision 1.55.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2003-10-18 02:27

Message:
Logged In: YES 
user_id=3066

Just for the record, here's a more minimal document that
exhibits this problem with the version of Expat before Karl
fixed this bug:

<!DOCTYPE e:element [
  <!ATTLIST e:element
    xmlns:e CDATA "http://example.com/">
  ]>
<e:element/>


----------------------------------------------------------------------

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.