Re: [xml] related to [Bug 346586] xsltproc return error code 0 even if errors occur

[Daniel Veillard <veillard redhat com>]

On Wed, Jul 05, 2006 at 10:36:39AM +0200, Tchize wrote:
> Hello,
>
> I subscribed to xml mailing list according to your last message on bug
> 34586.
>
> I'd like to get more detailed information on a specific point. You state:
> "Not fixeable without some non-trivial work in the parser core." But
> what is not fixeable, the support of the use of namespaced elements in
> an entity declaration, or the fact an error at parsing involves an error
> in return code.

  There should be no error.
9 years ago when libxml core was designed, namespaces were not as they are
today. And libxml goal was to provide an editing toolkit:
   load, modify, save

One of the side effect of that design choice is that entities had to be shared
because if you modify the content of an entity you want that to be fixed in
the entity definition, not in some part of the replacement at one spot in the
document. I.e. libxml was designed to have shared subtree for all entities
reference. Now come namespaces as we know them, if you use namespaces
in entities which are not defined within that entity you can't share the
entities tree replacement anymore because depending on the context of the
entity reference the replacement tree will be different. I tried to get 
undefined namespace reference in entities to be an error in the XML specs
but failed.
What you are seeing is exactly that, the entity content can't be parsed out
of context in libxml2, so the node is created without the namespace you 
expect, and hence the transformation fails to do what you want.
I looked at making the entity parse contextual at the namespace level, it is
as I said not trivial, not much about the amount of changes needed, but about
making 100% sure the change in the core parser don't break in any possible 
condition and also make sure this won't break existing user code.

I am not interested into fixing a side effect of a bug, that's wasted time,
the only interesting thing to do in front of that is to fix the parsing bug.
The xsltproc error code behaviour is really peanuts compared to the real 
problem.

> What is important for our project

  which project ?

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/