xmlxslt-devel

Re: not a HASH (a short patch)

[Geert J. <Gee...@Da...>]

Hi,

Comment out line 503, by putting a # before 'local', that will help..
(cannot try myself, but since I placed the code there myself, I'm pretty convinced that will fix your problem.)

Greets,
Geert

>    2. BUG: Not a HASH reference? (Janus Liebregts)
> 
> --__--__--
> 
> Message: 2
> Date: Thu, 04 Jan 2001 17:47:29 +0100
> From: Janus Liebregts <ja...@li...>
> To: xml...@li...
> Subject: BUG: Not a HASH reference?
> 
> Hi,
> 
> Strugling with XML XSLT and PERL, I used the 0.24 version of XML::XSLT
> 
> everytime my script fails with this error:
> 
> Not a HASH reference at /usr/lib/perl5/site_perl/XML/XSLT.pm line 492
> 
> using this script:
> 
> use XML::XSLT;
> $xslfile = "$ENV{DOCUMENT_ROOT}/de.xsl";
> my $parser = XML::XSLT->new ($xslfile, "FILE", warnings => "Active");
> $parser->transform_document ("$ENV{DOCUMENT_ROOT}/Bewoners/links.xml",
> "FILE");
> $parser->print_result("$ENV{DOCUMENT_ROOT}/Bewoners/linksnew.xml");
> $parser->dispose ();
> 
> regards,
> janus

XML::XPath

[Geert J. <Gee...@Da...>]

Hi all,

I am convinced that XML::XPath can be used very easily for getting node-set selections (xsl:value-of etc.). Anyone comment on this? Anyone interested?

Greets,
Geert

Re: XML::XPath

[Geert J. <Gee...@Da...>]

Yes, a resulting node-set is incompatible... I was only thinking that far most xpath-expressions are used to select a value with xsl:value-of. That function always returns one of the simplest variable types, string or number... In those cases the result of XPath is just the value.

Oh, I forgot that XPath is also used for xsl:variable, one can store the resulting node-set in a variable. Maybe it is possible to manipulate the resulting tree so that becomes a DOM-tree. If the structures resemble each other enough, it might even be done relatively quick.

Other alternative: parse the XPath expression and construct a block of perl-code to retrieve the set, saving as much variable usage as possible and saving many function-calls as well. Though the parsing itself may cancel the gain of speed...

Greets,
Geert


Pavel Nejedly wrote:
> 
> On Fri, Jan 05, 2001 at 09:39:44AM +0100, Geert Josten wrote:
> # I am convinced that XML::XPath can be used very easily for getting node-set
> # selections (xsl:value-of etc.). Anyone comment on this? Anyone interested?
> 
>   Hmmm... But it's incompatible with XML::DOM (or is it?)
>   But I agree that XML::XPath would help us...
> 
>   Pavel

Re: XML::XPath

[Pavel N. <bi...@at...>]

On Fri, Jan 05, 2001 at 10:46:14AM +0100, Geert Josten wrote:
# Yes, a resulting node-set is incompatible... I was only thinking that far
# most xpath-expressions are used to select a value with xsl:value-of. That
# function always returns one of the simplest variable types, string or
# number... In those cases the result of XPath is just the value.

  yes, but you have to parse the file twice - once for DOM and once for
  XPath - perhaps we can forget DOM and use XPath DOMish API only...

  Pavel

Re: [XML::XSLT] Re: XML::XPath

[Geert J. <Gee...@Da...>]

> # Yes, a resulting node-set is incompatible... I was only thinking that far
> # most xpath-expressions are used to select a value with xsl:value-of. That
> # function always returns one of the simplest variable types, string or
> # number... In those cases the result of XPath is just the value.
> 
>   yes, but you have to parse the file twice - once for DOM and once for
>   XPath - perhaps we can forget DOM and use XPath DOMish API only...
> 
>   Pavel

The latter idea is a nice consideration, but requires that the full length of XSLT.pm has to be rewritten. It will definitely mean a gain in speed, without doubt, unless the stripped down version of the DOM-tree that the XPath-module uses has too little support to manipulate trees for transformation purposes; that is not what XPath was meant for...

About the first: yes, the xml has to be parsed twice, but reading in the XML is not the bottleneck! :) The real bottleneck is the 'speed' of DOM-function. The other bottleneck is memory-usage, but that can only be solved by incorporating memory-swapping techniques. And doing that in Perl?? Hmmm.... :P

Geert