Re: [xml] release of libxml2-2.6.0beta3

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:

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


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