Re: [xslt] Release of libxslt-0.12.0



On Mon, Jun 18, 2001 at 05:37:06PM +0200, Luke Kenneth Casson Leighton wrote:
> > API for extension, and get the variable/parameter handling to be fixed.
> 
> you mean the char **params?

 No the one computed at the stylesheet execution time, not the users
ones which are fine now.

> i sent in a patch to do
> a state+next() fn, hope you like it :)  it keeps the
> legacy fns that still take char **, with an example
> state+next() fn based on getting the next 'var=val' in the
> char ** array,

  Well it wasn't looking an urgent thing to fix. It also sort of
break the XSLT processing model. The XSLT process does the evaluation
of the parameters, it don't receive them precomputed. This is a 
significant difference and checking whether your patch was a clear
spec violation or something acceptable, I didn't yet had the time to
really look at it. It still looks more a possible serious problem
than an enhancement honnestly. I tend to prefer computing again this
fixed set of values (initially) than introducing potential serious
hazard in the way the computation gets done (which is a real pain
to debug and get fixed when this occurs). I hope you understand my
hesitation ant why I didn't incorporated it so far.

> a suggestion.  you have a xsltSaveToFile, to Fd, and to a buffer,
> but not save-to-memory, like in libxml.

  Hum, building an Output buffer for memory is doable easilly. I
can add this into libxslt directly since it's a fairly common API.

> also, someone else mentioned problems saving to xxxx because of
> dumping doc *without* the stylesheet.
> based on this, what i did was set up a memory buffer,
> called xsltSaveTo, then _re-parsed_ the memory buffer _back_
> into a document.

  I am not sure I fully understand. the transform function puts
everything possible onto the tree but some things cannot be saved
in the tree (like the indent = ...), so it is really needed to 
do a serialization to get them, yes.

> 
> so, i have a couple of suggestions that may make this a little
> easier:
> 
> how about either a)
> 
> create a xsltSaveToMem

  yes

> b)
> 
> 'create' a doc using the stylesheet and the source doc document, saaay.... as
> 
> xsltSaveToDoc.
> 
> xmlDocPtr *xsltSaveToDoc(xmlDocPtr *cur, xsltStyleSheet *sheet);

  this should be idempotent. Except for formatting spaces added to the
tree. What else are you missing ?

> what do you think?

  that I will provide an XSLT serialization to memory. the xsl:document
construct may require an update of this API anyway, as well as streaming
on output. So this may change a bit within the next month anyway.

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/
Sep 17-18 2001 Brussels Red Hat TechWorld http://www.redhat-techworld.com




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