Re: [xml] release of libxml2-2.6.0beta3

[Malcolm Tredinnick <malcolm commsecure com au>]

OK, I had a chance to do some playing around with the 2.6-beta stuff
(well, really with CVS). A few comments below, but nothing serious.

On Fri, 2003-09-26 at 11:14, Malcolm Tredinnick wrote:
> Daniel,
>
> On Fri, 2003-09-26 at 08:52, Daniel Veillard wrote:
> [...]
> > Among the question remaining:
> >   - is there any API/ABI incompatibilities left ?
> >   - Should SAX2 report DTD defaulted attribute by default or
> >     only if the option is asked for
> >   - what kind of error API people really want
> > I think once I have a clear answer on all three, it will just be a matter
> > of a bit of coding to get 2.6.0 out for good.
>
> I'm not sure what your time-frame is, but would it possible to wait
> until after the weekend before drawing the curtain here? I want to look
> at the error stuff in some detail, but I am not going to have time until
> tomorrow (Saturday).

Possibly just because of the type of applications I am using with
libxml, I do not have much in the way of real difficulties with the
existing API. Other people have posted their thoughts, which are outside
my experience set, so I have no opinion.

My only request, if it's not too much much trouble, is in the SAX error
callbacks. Currently, we can extract the filename, position in the file,
the error number, and the node we are currently parsing without any
problem. However, in the case of something like a mismatched closing
tag, I cannot see any straightforward way to work out what the parser
actually saw. I know what it is expecting and I can sort of reverse
engineer what it saw by backing up in the input stream a little bit, but
that feels very awkward. Alternatively, I can hope the format of the
error message does not change and hunt through the varargs passed into
the error callback, but again, hardly a robust programming practice. :-)

A possible solution: In parser.c:xmlEndTag1(), the information is
available (the 'name' variable that is filled in on line 7018), but it
is only put into the error string and not available on it's own. Is
there any way to pass a piece of auxilliary data around (like a pointer
to 'name' here)? I must admit that I cannot quite see how without
breaking ABI compatibility, but I am possibly not too clever, so it may
be possible.

> I also want to do some checking of my SMIL library against the new APIs,
> which may turn up some incompatibilities, since I am diving under the
> covers a fair bit in some places.

I tried the new library against a few little programs I have lying
around as well as against my libsmil and there were no problems.

> As far as the DTD default attribute, I don't really have an opinion one
> way or the either (assuming the if it's on by default, it is possible to
> turn it off somehow). I guess I would very slightly favour reporting the
> default value, but I have different programs that use each option, so it
> just needs to be changable for me. :-)

Since you have affirmed that this is all wonderfully customisable, it
really makes no difference to me.

So, in short, I cannot see anything in the new code that is going to
cause me nightmares for my limited applications. That is somewhat
impressive given all the changes you have made under the covers. Nice
job. :-)

Cheers,
Malcolm