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



Forwarding to mailing list, bad reply button :)

-------- Original Message --------
Subject:        Re: [xml] related to [Bug 346586] xsltproc return error code 0
even if errors occur
Date:   Wed, 05 Jul 2006 11:08:20 +0200
From:   Tchize <tchize myrealbox com>
To:     veillard redhat com
References:     <44AB7A17 7090809 myrealbox com>
<20060705085950 GB967 redhat com>



But my main problem is that the script has no way to know an error
occured. :)
Daniel Veillard wrote:
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

  








[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]