Re: XML libs (was Re: gconf backend)

[Havoc Pennington <hp redhat com>]

On Sun, 2003-09-28 at 14:17, Daniel Veillard wrote:
> > Introducing exceptions to the current API at this stage is basically a
> > bad idea, since you have too many old functions that don't use them and
> > you don't want to double the API. So perhaps the always-call-callback
> > approach is right.
> 
>   I can introduce error informations for the new APIs being rolled out and
> add one for teh xmlReader interface too.

I'm just worried that duplicating the API with error variants isn't
serving the goal of a smaller/simpler API.

>   You seems to have a per-function approach. Parsing errors for XML
> are codified, and are part of the spec actually, so except for memory
> allocation errors, you won't get a "per function" error but an error
> per defined in the spec once the condition is recognized.

It's not me that has a per-function approach, it's C. ;-)

At some point I call a function to parse the config file. It either
fails or doesn't fail. If it fails, it needs to return the reason it
failed.
 
>   handling CDATA should be done. And XML doesn't define compliance for
> an application but for a parser. What the parser provides back to the 
> application, what and when errors are raised is part of the spec, not what
> the application does with the data returned, that's something you
> seems to misunderstand about XML compliance. What I warned about was
> that using a non compliant parser may loose data (silently) or build
> into application code expectations on broken behaviour.

I guess I don't see the value of exposing XML features in the API I'm
using if I'm not using said features correctly. My app ends up with
undefined behavior if these XML features are present in the document.
I would rather that my XML lib or wrapper API defined the behavior:
handle automatically, silently ignore, or return an error; whichever is
most likely to be useful.

In other words I'm very happy for the XML library to understand all
these features internally, in order to parse correctly. But I'd like it
to do something with the features other than give them to my app to
figure out. Because my app is just going to get confused.

I guess I'd say the current Reader API is fine as long as silently
ignore is the right behavior for those extra node types. I can easily
implement silently ignore in my app. But if the app should be throwing
an error or doing something else when it gets these nodes, I don't know
how/when/whether to do that.

Havoc