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

[Daniel Veillard <veillard redhat com>]

On Sun, Sep 28, 2003 at 03:17:48PM -0400, Havoc Pennington wrote:
> 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.

  I don't intent to duplicate, I intend to add. I can add with or without
an error parameter. 

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

  In libxml2 it's delivered asynchronously via a callback. If you have a
parser context the last error number is available in the context. I could
copy the string there too.

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

  Define NULL callback at the SAX level. Ignore the information items
at the DOM or xmlReader level. the parser must provide them to be conformant.
In the case of the CDATA, you can ask libxml2 to just give your text and 
loose the information that it actually came from CDATA instead of text.
   See XML_PARSE_NOBLANKS and XML_PARSE_NOCDATA options from the 
upcoming new API.
    XML_PARSE_NOBLANKS  = 1<<8, /* remove blank nodes */
    XML_PARSE_NOCDATA   = 1<<14 /* merge CDATA as text nodes */

provided as command line options too at the xmllint level:
        --noblanks : drop (ignorable?) blanks spaces
        --nocdata : replace cdata section with text nodes

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

  SAX: provide NULL callbacks
  Others: ignore the items

I have nothing better to offer, really.

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

  Well, it's all your application business. If you can't handle them
raise an error. That mean a contract has been broken between the provider
and the consumer of the information, while it still passes fine at the XML
level. If you expect a color code and get a street address in the content
of some tag you have the same problem. It's purely application logic.
But it's not where XML conformance is defined.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/