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

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

  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 Veillard      | Red Hat Network
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

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