Re: [xml] release of libxml2-2.6.0beta3

[Malcolm Tredinnick <malcolm commsecure com au>]

On Mon, 2003-09-29 at 18:36, Marc Liyanage wrote:
> On 26.09.2003, at 00:52, Daniel Veillard wrote:
>
> >   - what kind of error API people really want
>
> I am using libxml and libxslt in an XML editor GUI application.  
> Currently I have to intercept the message via an error handler.
>
> There are several issues for me in this situation:
>
> - I have to parse the format string and then use varargs to get at  
> information contained in the message, the most important information  
> being the line number (I need this to highlight the line causing the  
> error in the GUI). This parsing is error-prone, it would be better if I  
> could get this information in a structured way. In Java, I can pick up  
> this information in a clean way out of the Exception or "Locator"  
> objects.

The API documentation points out that the setLocator SAX call in libxml
2.5 is not needed since all the information is available via the
InputStream that is part of the current xmlParserCtxt. At least in C,
this is correct (in the Python bindings, you cannot get at this
information, but that is just a matter of filling out the bindings at
some point). So, as explained below, you can pick the information out of
the error handler.

> - The handler seems to be called for xsl:message messages too, but  
> there is no clean way for me to find out if an error occurred or if it  
> was simply an xsl:message. Currently I abort processing if the handler  
> is invoked at all under the (clearly wrong) assumption that the handler  
> only gets called for errors.
>
>
> So I guess what would be useful is a clean way to get at the structured  
> error information.
>
> - Severity (like the log level proposed by another poster previously)

What would the levels be? Currently you get two levels: warning
(non-fatal) and error (fatal). I guess somebody needs to work out what
other levels are reasonable.

My vote would be to have error levels like 'annoying', 'common',
'oversight', 'really silly'. :-)

> - Line number if available
> - Column number if available

These last two you already have access to.

The error handlers get called with an xmlParserCtxtPtr (ctx) and the
ctx->input structure contains the current line and column values. The
only problem here (in 2.5) is that you need to interpret the column
value a bit: ot seems to give the column number since the beginning of
ctx->input->line, but it can cross line boundaries. For example, you may
end up seeing line 43, column 166 and you have to munge this to see that
it is line 46, column 18 or whatever.

You can also see in xmllint.c how some errors are formatted there.

Cheers,
Malcolm