[xslt] Re: xslt digest, Vol 1 #64 - 6 msgs

[Luke Kenneth Casson Leighton <lkcl samba-tng org>]

> Message: 2
> Date: Mon, 18 Jun 2001 13:12:26 -0400
> From: Daniel Veillard <veillard@redhat.com>
> To: xslt@gnome.org
> Subject: Re: [xslt] Release of libxslt-0.12.0
> Reply-To: xslt@gnome.org
> 
> > 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. 

parameters.  the char** array?  it's just an array
of var, val, var, val, NULL.

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

take a look at it more carefully: it's not doing pre-evaluation
or anything, or expecting to do any kind of dynamic evaluation.

it's functionally directly equivalent to what was already there,
a char **, except with a void*state and a function with the
same type of semantics as the unix pwd / NIS pwd / dbm getnext() set
of functions.  pass in the void* to the function, get back the
next char*var and the next char* val.

there's nothing fancy about it, i just didn't want to have to
convert an apr_table_t's entries into a char **, it seemed
like a silly thing to have to do, and i thought other people
might want to do likewise.

i _can_ think of a better way to do it, though.

you pass in a function and a void* with the same semantics as
apr_table_get()

the fn's prototype should be:

const xmlChar * /* the variable value: NULL if it doesn't exist */
xsltStyleUserParamGet(xsltStyleUserParamTable *state, const xmlChar *varname);

[match this against apr_table_get's prototype, it's identical]

then you _could_ potentially get user params that depend on the
document or the stylesheet, but personally i don't think that's
a good idea.

the impact of adding and using a function like this was quite heavy,
so i decided not to do it: unfamiliar code.

whereas, the patch i sent you was trivial to implement, and
minimal impact.


> > 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.
 
ack!  great!  because i had to cut/paste your code and use that :)

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

urr.... *curious*.

why?

is that to do with the global variable [xmlIndent??...]

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

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

oo.  i _should_ know what that means.  had to look it up.

idempotent: first usage of 'thing' has an effect.  subsequent uses
do not.  i.e. 'set thermostat to 20 deg' is idempotent.
'increase thermostat by 5 deg' is _not_ idempotent.


> Except for formatting spaces added to the
> tree. What else are you missing ?
 
nothing that i don't know about :) :)


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

ack.  will follow with enthusiasm :)

luke

p.s. you'll be pleased to know that i can view the REC-xml-2e.xml xml
spec test WITH the markup diffs, using xvl:

http://localhost/test/REC-xml-2e.xvl?show.diff.markup=1

the xvl page is this:

<page raw="yes" xmlns:xvl="http://undefined"
		xmlns:xslt="http://undefined"
		xmlns:encode="http://undefined"
		xmlns="xvl:xvl">
<encode:encode encode="base64">
  <xslt:input file="REC-xml-20001006.xml" style="REC-xml-2e.xsl" args=""/>
</encode:encode>
</page>

the base64 encode is needed because the document output cannot be re-parsed
as xml but only as html [or it couldn't when i was playing around, so
i did the encoding for safety /paranoia reasons].  only when it arrives
at mod_virgule is the document un-encoded and sent out untouched as an
HTML page for the browser to deal with :)]

i think that using libxslt like this is amazingly powerful.

it's possible to have xvl specify a different stylesheet based on
the HTTP headers received from apache.  i.e. you can decide at run-time,
if the client's browser is netscape, use a different stylesheet.

if it's a text-only lynx browser, use a different stylesheet.
WAP, whatever.

or even pass in user-params to one stylesheet to get it to do
different browsers for itself.

this is very cool :)  _and_ it's a standard.  love it, daniel :)

luke