[ 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 21:40 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rolf Ade (pointsman) Assigned to: Nobody/Anonymous (nobody) 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 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110127&aid=824420&group_id=10127