Re: [xml] release of libxml2-2.6.0beta3

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"  

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.


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