Re: [xml] release of libxml2-2.6.0beta3

[Daniel Veillard <veillard redhat com>]

On Tue, Sep 30, 2003 at 09:22:45AM +1000, Malcolm Tredinnick wrote:
> 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.

  okay, thanks !

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

  Well I dislike the lack of orthogonality and control of the set of 
old APIs like xmlSAXParseMemoryWithData() xmlSAXParseFileWithData(),
etc...
  I keep them of course but I want something I can explain in a few
pages to newbies starting with libxml2.

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

  I could store more error related data in the parser context somehow
like the Gerror block, i.e. errNo, the string, where this came from
(validation, parsing, I/O, memory, namespace, ...), and some extra
informations, see the few error routines in the beta3 version of parser.c
(near the top).

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

  Passing it through the parser context when in a parser framework,
or through a global variable (struct) also per-thread when no parser
context is available. Trying to chase down the case where an error
may get raised from the parser while no context is available sounds an
unpleasant but probably useful task <grin/>.

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

  Good, so far I didn't got any ABI compat problem I didn't fixed,
except one but it's under control :-)

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

  thanks !
  So when are you gonna push this SMIL code out ;-) ?

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/