Re: [xml] Re: XML libs (was Re: gconf backend)

----- Original Message ----- 
From: "Havoc Pennington" <hp redhat com>
To: <veillard redhat com>
Cc: <desktop-devel-list gnome org>; <xml gnome org>
Sent: Sunday, September 28, 2003 9:17 PM
Subject: [xml] Re: XML libs (was Re: gconf backend)

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
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
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

  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
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.


xml mailing list, project page
xml gnome org

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