Re: [docbook-apps] Re: "No ID for constraint linkend" when usinghtml/profile-docbook.xsl

[Jirka Kosek <jirka at kosek dot cz>]

Daniel Veillard wrote:

>   Well, if that mean that all keys must be recomputed on all node-set()
> results, beware this could cost *a lot* at runtime. What I suspect is that
> the keying property that you obtain from Saxon is due to the fact that nodes
> are reused, if you really build a new document, then it's a completely
> different process, a node which was a key in the first document may not
> be a key in the resulting node set and vice-versa, because the key will have
> to be recomputed from scratch. Looking at just how much (too much) processing
> is done by the docbook stylesheets, the fact that I implement that fully
> could have a very serious impact on performances, that could be true for
> others processors too.

I understand your point but I personally prefer functionality over speed 
(of course only if speed is then enough to use whole solution). I think 
that it will not be as bad. If you will use DocBook stylesheets with 
profiling and cleaning of HTML output, node-set() will be called once on 
(almost) whole input document and then for each outputted chunk of HTML. 
I don't know internals of libxslt but I think that this could lead to 
speed penalty corresponding to double of time necessary to parse and 
prepare input document (once for node-set() on input document and once 
for node-set()s on generated result). This time is however very small 
compared to stylesheet parse and prepare time and stylesheet runtime.

I will be very glad if libxslt could compute keys for node-set(). If 
there is a big speed penalty, there is always possibility to make this 
behaviour optional controlled by some parameter. (Yes, I know as a 
programmer I also don't like hacks like this.)

>   At some point I may simply just drop the ball, all these node-set and
> functions extensions are radical extensions from the XSLT-1.0 spec, they
> *completely* change some of the assumptions I made when I engineered 
> the libxslt implementation based on XSLT-1.0 spec, especially w.r.t. to the
> lifetime of objects, scope of access of objects etc...

But without these functions many things are really very hard to do. Do 
you plan to support XSLT 2.0, which incorporates many of these functions 
and extensions?

--
-----------------------------------------------------------------
  Jirka Kosek  	
  e-mail: jirka@kosek.cz
  http://www.kosek.cz

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature