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

["WebShark" <webshark ono com>]

----- 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
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
>
> _______________________________________________
> xml mailing list, project page  http://xmlsoft.org/
> xml gnome org
> http://mail.gnome.org/mailman/listinfo/xml
================================
http://www.acsione.com