Re: [xslt] Work report/code review part 3

[Daniel Veillard <veillard redhat com>]

On Sat, Oct 13, 2001 at 08:42:16PM +1000, Keith Isdale wrote:
> Hi all,

  Okay sorry for the delay, but I was busy with other work and other parts
of libxml/xslt . 

  I did look at the part 2 code (the updated breakpoint.[ch]), globally
it is code to define hand handle a breakpoint sets, the code looks okay
(but I didn't looked in the details nr tried yet to compile it. It seems
to me that it's right place is in an XSLT debugging library, was that
what you intended ?

> This is third in the series on the work I'm doing. This email is being posted 
> earlier than I wished due to university commitments. In this email I cover 
> the xsltaddon library. The background to this new library (based on 
> xsltproc.c and xsltproc.h) is that I wanted to have the services provided by 
> xsltproc  (re-used the most of the code) but wanted to be able to override 
> some of its functionality.  

  That I didn't understand. The xsltaddon code is basically xsltprc as you
explained, it still contains a main() so it look like a standalone binary,
though you argue that it is an overritable API. this doesn't look good
to me, and I don't see how to use this code at all so far.

> This library is most likely to be subject to change in future years as its is 
> difficult to predict how library users will use xsltaddon. What I've tried to 
> model with this library's API is the basic stages that have to occur before a 
> stylesheet can be executed/processed. So think this is where discussions 
> should start. 
> 
> In any program there are five stages
>  1) Processing of command line arguments
>  2) Resource allocation
>  3) Processing  
>  4) Resource deallocation
>  5) Exiting
>  
> Hopefully the API covers these requirement sufficiently. I've been using 
> xsltaddon for some weeks now with xsldbg. Comments, suggestions? 

  I don't understand. If it's intended as a library there shall be no main()
basically a library with main() is fairly poor style. Some of the code from
xsltproc could be reused if it was exported in a library, I agree, but
I don't think the way you have taken the problem to be correct. The
entity loader code from xsltproc culd be migrated onto libxslt, xsltProcess
could be made rusable by using parameters instead of global variables
and extracted too, but trying to turn the whole thing as a library, including
the main, command-line argument scanning and main is really not proper.
At least in the current for I don't think it's something that should be done.

> In my build of libxslt xsltaddon has its own directory (like xsltproc) so I 
> also attached the Makefile.am I've used for it.

  Well as-is it's not usable, or at least offers no advantage over xsltproc,
this need more discussions/work before being integrated, if needed at all
(I would probably move more stuff fro xsltproc to libxslt instead).

> Next up : Changes recomended to transform.c  transform.h 

  Okay.
  For the moment I just have the breakpoint code which IMHO should be kept
in the debugging library, maybe more should be added.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/