Hello Ken,
Thanks for that suggestion. I will try it!
----- Original Message -----
From: xsl-list-digest-help(_at_)lists(_dot_)mulberrytech(_dot_)com
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Sent: Wednesday, September 7, 2011 1:10:01 AM
Subject: xsl-list Digest 7 Sep 2011 05:10:01 -0000 Issue 2619
xsl-list Digest 7 Sep 2011 05:10:01 -0000 Issue 2619
Topics (messages 60015 through 60024):
Muenchian troubles - only getting first group - Help please!
60015 by: thehulk.comcast.net
60016 by: Andrew Welch
Re: stylesheet organisation
60017 by: Andrew Welch
60018 by: Merrilees, David
60020 by: Wendell Piez
Muenchian troubles - only getting first group - I have my answer
60019 by: thehulk.comcast.net
60021 by: G. Ken Holman
WebKit transformToDocument() failing with large XML
60022 by: Dustin N. Jenkins
60023 by: Brandon Ibach
60024 by: Imsieke, Gerrit, le-tex
Administrivia:
To subscribe to the digest, e-mail:
<xsl-list-digest-subscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
To unsubscribe from the digest, e-mail:
<xsl-list-digest-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
To post to the list, e-mail:
<xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
----------------------------------------------------------------------
Date: Tue, 6 Sep 2011 05:10:22 +0000 (UTC)
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
From: thehulk(_at_)comcast(_dot_)net
Subject: Muenchian troubles - only getting first group - Help please!
Message-ID:
<1419775929(_dot_)240529(_dot_)1315285822494(_dot_)JavaMail(_dot_)root(_at_)sz0122a(_dot_)westchester(_dot_)pa(_dot_)mail(_dot_)comcast(_dot_)net>
I am having trouble with Muenchian grouping. I want to add up the charges, by
type. I expect in this particular example to output two <Total_Charge_By_Type
... /> elements, but only one is outputted!
Here is the example XML :
<Account>
<Service Name="A Service" Service_Id="89150" >
<Feature Name="Extents" Feature_Id="203943" Status="65">
<Charge Trans_Type_Name="Extent" Bucket_Type="1">
<Trans_Class>R</Trans_Class>
<Charge_Amount>
<Amount Currency_Cd="EUR">467.55</Amount>
</Charge_Amount>
</Charge>
</Feature>
<Feature Name="Service Accumulator" Feature_Id="567528" Status="65">
<Total_Charge>
<Charge_Amount>
<Amount Currency_Cd="EUR">0</Amount>
</Charge_Amount>
</Total_Charge>
</Feature>
<Feature Name="Storage" Feature_Id="267663" Status="65">
<Charge Trans_Type_Name="Pages" Bucket_Type="1">
<Trans_Class>R</Trans_Class>
<Charge_Amount>
<Amount Currency_Cd="EUR">16.64</Amount>
</Charge_Amount>
</Charge>
<Charge Trans_Type_Name="Pages" Bucket_Type="1">
<Trans_Class>R</Trans_Class>
<Charge_Amount>
<Amount Currency_Cd="EUR">0.64</Amount>
</Charge_Amount>
</Charge>
</Feature>
</Service>
</Account>
In the template that processes the <Account>, the Account is current at that
time it calls the template "muench_chargetypenames" to do the summing:
....
<!-- Now, Add up and nest in the Charges within the Services within this
Account -->
<xsl:if test="Service">
<xsl:element name="Total_Charge">
<xsl:attribute name="Amount">
<xsl:value-of select=
"sum( Service//Charge[not(Trans_Class="I")]/Charge_Amount/Amount)" />
</xsl:attribute>
<xsl:attribute name="Flag" >
<xsl:value-of select="HasSvc" />
</xsl:attribute>
</xsl:element>
<!-- Also, add up and nest in the Charges divided into separate Transaction
type names -->
<xsl:call-template name="muench_chargetypenames"/>
</xsl:if>
<xsl:if test="not(Service)">
<Total_Charge Amount="0" Flag="NoSvc" />
</xsl:if>
.....
The key is defined according to the attribute @Trans_Type_Name of the Charge
element:
<xsl:key name="TransTypes"
match="Charge[Trans_Class='R']"
use="@Trans_Type_Name"/>
And here is muench_chargetypenames :
<xsl:template name="muench_chargetypenames" >
<xsl:message>
Hey, in muench_chargetypenames
Current element name <xsl:value-of select="local-name(.)"/>
</xsl:message>
<xsl:for-each
select="Service/Feature/Charge[generate-id()=generate-id(key('TransTypes',@Trans_Type_Name)[1])]">
<xsl:variable name="ThisType"
select="@Trans_Type_Name"></xsl:variable>
<xsl:message>
Hey, Total By Type, type is <xsl:value-of select="@Trans_Type_Name"/> ,
Amount of this one is <xsl:value-of select="Charge_Amount/Amount"/>
</xsl:message>
<xsl:element name="Total_Charge_By_Type">
<xsl:attribute name="Amount">
<xsl:value-of select=
"sum(../../../Service/Feature/Charge[Trans_Class='R' and
@Trans_Type_Name=$ThisType]/Charge_Amount/Amount)" />
</xsl:attribute>
<xsl:attribute name="Trans_Type_Name" >
<xsl:value-of select="@Trans_Type_Name" />
</xsl:attribute>
</xsl:element>
</xsl:for-each>
</xsl:template>
The message output shows that the for-each is looping only once, for type
"Pages", but there should be a second time for "Extent". Why not?
( There could have been more Services, but in this example there are not.)
( I could have used ancestors::Account instead of ../../.. , but that part is
working. )
------------------------------
Date: Tue, 6 Sep 2011 09:22:38 +0100
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
From: Andrew Welch <andrew(_dot_)j(_dot_)welch(_at_)gmail(_dot_)com>
Subject: Re: [xsl] Muenchian troubles - only getting first group - Help please!
Message-ID:
<CAEG2duDF2x=Xz55eiNCBRhBrxjkQtRON_Fs0=tuc9iQ7rhOvNA(_at_)mail(_dot_)gmail(_dot_)com>
Hulk,
I am having trouble with Muenchian grouping. I want to add up the charges, by
type. I expect in this particular example to output two <Total_Charge_By_Type
... /> elements, but only one is outputted!
[snip]
The message output shows that the for-each is looping only once, for type
"Pages", but there should be a second time for "Extent". Why not?
At the risk of making you angry, you need to provide a simplified
example - remove everything that isnt used from both the xml and the
xslt, convert the xslt into a runnable stylesheet, and then provide
the expected and actual output. At the moment you've got too much
noise in there...
--
Andrew Welch
http://andrewjwelch.com
------------------------------
Date: Tue, 6 Sep 2011 09:36:42 +0100
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
From: Andrew Welch <andrew(_dot_)j(_dot_)welch(_at_)gmail(_dot_)com>
Subject: Re: [xsl] stylesheet organisation
Message-ID:
<CAEG2duBBWddBOT9p276d9odTqL_oLuCuNKqrs_X43MOiOvQ5hg(_at_)mail(_dot_)gmail(_dot_)com>
XSLT is not all that good at being used in large, multi-programmer
projects;
That's just not true, there's nothing different or special about xslt
than any other language used in a large project.
Many other languages have more support for the idea. (Since there are
(apparently) very few really big, 10+ programmer, XSLT projects, this is
not surprising.)
XSLT, for instance, doesn't have an equivalent of header files, or a
notion of "partial build".
Not sure what you mean there... you can have multiple entry points
(say root matching templates) so you can run a subset of the transform
that all ultimately get overridden by the main entry point.
there's little-to-no automerge support for version control,
Again not true... what makes you say that?
The gibbering horrors you get when a version control system with really
very good line-based code merge algorithms tries to do line-based merge
on XSLT, where you really do want a node-based merge.
Ok, I've never had a problem with it.
And this works, but every single (you understand that this is a much
simplified example; the real case gives me many warnings) such import
produces a "imported or included more than once" warning. =A0Which both
hides things I would care about in the warning list, and makes the "was
there anything in the log file?" check for "that transform worked" less
useful in a batch-processing context.
So I suspect that there's a better way to do this. =A0What that way might
be I have yet to discover, though.
Which XSLT processor do you use? I'm not sure it should be giving you
those warnings, see:
http://www.w3.org/TR/xslt20/#element-import
"The case where a stylesheet module with a particular URI is imported
several times is not treated specially. The effect is exactly the same
as if several stylesheet modules with different URIs but identical
content were imported. This might or might not cause an error,
depending on the content of the stylesheet module."
--=20
Andrew Welch
http://andrewjwelch.com
------------------------------
Date: Tue, 6 Sep 2011 13:24:50 +0100
To: "xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com"
<xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
From: "Merrilees, David" <David(_dot_)Merrilees(_at_)uk(_dot_)tesco(_dot_)com>
Subject: RE: [xsl] stylesheet organisation
Message-ID:
<233FCD50B79EA44F98E299B5D8BFE619078BFC4E5F(_at_)UKSDCCLUMS0331(_dot_)ukroi(_dot_)tesco(_dot_)org>
Hi
I work for Tesco.com. We make extensive use of XSLT on all our websites, so=
me of them are extremely large projects.
David
-----Original Message-----
From: graydon(_at_)marost(_dot_)ca [mailto:graydon(_at_)marost(_dot_)ca]
Sent: 05 September 2011 19:19
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
Subject: Re: [xsl] stylesheet organisation
On Fri, Sep 02, 2011 at 04:49:36PM +0100, Andrew Welch scripsit:
Thanks for your post, just to query one part:
And having multiple smaller files helps collaboration
Why do you think mutiple smaller files helps collaboration?
Because that way you have have one small file locked by programmer A in the=
version control system and another small file locked by programmer B in th=
e version control system.
XSLT is not all that good at being used in large, multi-programmer projects=
; there's little-to-no automerge support for version control, and various p=
rocessors throw warnings at you if you have a file included in more than on=
e place (as you want to do if you're defining a bunch of utility functions =
in a big mass of XSLT code.) But having things being broken out into small=
er files on some logical grounds -- semantic groupings of target elements, =
say -- certainly helps.
-- Graydon
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
This is a confidential email. Tesco may monitor and record all emails. The =
views expressed in this email are those of the sender and not Tesco.
Tesco Stores Limited
Company Number: 519500
Registered in England
Registered Office: Tesco House, Delamare Road, Cheshunt, Hertfordshire EN8 =
9SL
VAT Registration Number: GB 220 4302 31
------------------------------
Date: Tue, 06 Sep 2011 14:54:16 -0400
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
From: Wendell Piez <wapiez(_at_)mulberrytech(_dot_)com>
Subject: Re: [xsl] stylesheet organisation
Message-ID: <4E666C58(_dot_)4080009(_at_)mulberrytech(_dot_)com>
Jesper,
On 9/3/2011 11:10 AM, Jesper Tverskov wrote:
I still need to boil it all down to something that is possible to
explain in a minute or two in order to really understand it!
That's not too hard. xsl:import allows introducing stylesheet components
(variables, templates) at a lower "import precedence", while xsl:include
doesn't. Import precedence is a powerful feature and very useful for
some purposes, especially in modular stylesheets intended for
customization using overrides. If you want this feature, use xsl:import.
If you don't, use xsl:include.
The way import precedence works takes another minute to explain, plus
another few minutes to cover fine points such as what happens with
chains of imports. Plus, as Ken has remarked, you need to distinguish
carefully between import *precedence* and the other means of resolving
match conflicts, namely template *priority*; since both terms start with
"pr-" this can be confusing for beginners.
Of course, even in my two-minute version, I lied, since as it happens,
import precedence is the same mechanism used to resolve conflicts
between a stylesheet's templates and the built-in templates (which are
"imported" implicitly). But that's a detail not for the two minutes.
Cheers,
Wendell
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
------------------------------
Date: Tue, 6 Sep 2011 18:21:58 +0000 (UTC)
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
From: thehulk(_at_)comcast(_dot_)net
Subject: Muenchian troubles - only getting first group - I have my answer
Message-ID:
<242488589(_dot_)270446(_dot_)1315333318409(_dot_)JavaMail(_dot_)root(_at_)sz0122a(_dot_)westchester(_dot_)pa(_dot_)mail(_dot_)comcast(_dot_)net>
The problem is, I don't want to add up charges for the entire file. The file
has many accounts. I want to to add up charges by type within each account.
Many apologies if you wasted time on my previous post. When I simplified the 20
MByte of XML data, I eliminated the cause of the difficulty. (One might think
of it as a training exercise, in XSL, or perhaps, anger management).
The addition was good, restricted to the proper charges within the same
account.
But because there is just one keymap, and many accounts have the same types of
charges, each type of charge will appear in only one of the accounts - all the
other charges of that type are not #1 , that is: [1] .
I think the solution is to complicate the calculation of the keymap, by
concatenating an identifier of the Account to the use="@TransTypeName" clause.
Not yet tested.
------------------------------
Date: Tue, 06 Sep 2011 17:52:20 -0400
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
From: "G. Ken Holman" <gkholman(_at_)CraneSoftwrights(_dot_)com>
Subject: Re: [xsl] Muenchian troubles - only getting first group - I
have my answer
Message-Id:
<7(_dot_)0(_dot_)1(_dot_)0(_dot_)2(_dot_)20110906174514(_dot_)023ba3e8(_at_)wheresmymailserver(_dot_)com>
Have you considered abandoning the Muenchian approach and using the
variable approach?
The Muenchian method works easily across the entire file, and as you
say requires more convoluted values to work with subsets of the
file. And it doesn't work when using a population of items across
multiple files. But the variable method works for all cases: a
subset of a file, an entire files and multiple files (though I never
use it when the context is an entire file).
Over the years I've posted to this list a number of examples of
grouping subsets of an instance by putting the population being
grouped into a variable and then acting on the members found in that variable:
http://www.biglist.com/lists/xsl-list/archives/200401/msg00070.html
http://www.biglist.com/lists/xsl-list/archives/200401/msg00342.html
http://www.biglist.com/lists/xsl-list/archives/200501/msg00548.html
http://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/200902/msg00303.html
http://www.oxygenxml.com/archives/xsl-list/201104/msg00235.html
I hope this helps.
. . . . . . . . . Ken
At 2011-09-06 18:21 +0000, thehulk(_at_)comcast(_dot_)net wrote:
The problem is, I don't want to add up charges for the entire file.
The file has many accounts. I want to to add up charges by type
within each account.
...
I think the solution is to complicate the calculation of the keymap,
by concatenating an identifier of the Account to the
use="@TransTypeName" clause. Not yet tested.
--
Contact us for world-wide XML consulting and instructor-led training
Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/
G. Ken Holman mailto:gkholman(_at_)CraneSoftwrights(_dot_)com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers: http://www.CraneSoftwrights.com/legal
------------------------------
Date: Tue, 06 Sep 2011 15:07:54 -0700
To: XSL Users <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
From: "Dustin N. Jenkins" <Dustin(_dot_)Jenkins(_at_)nrc-cnrc(_dot_)gc(_dot_)ca>
Subject: WebKit transformToDocument() failing with large XML
Message-ID: <4E6699BA(_dot_)8080705(_at_)nrc-cnrc(_dot_)gc(_dot_)ca>
I have a bug with WebKit (
https://bugs.webkit.org/show_bug.cgi?id=67310) for large XML documents
(> 3MB) that are being run through one XSL file.
With both Safari 5.1, and Google Chrome 13.0.782.220 this happens.
If I run the XSL file using xsltproc, I get this error, but it still
produces something:
runtime error: file filter.xsl line 134 element param
xsltApplyXSLTTemplate: A potential infinite template recursion was
detected.
I'm not sure where the endless recursion would come from. I've posted
my XSL file, which is called filter.xsl:
<code>
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform";
xmlns:vo="http://www.ivoa.net/xml/VOTable/v1.1";
xmlns:v1="http://vizier.u-strasbg.fr/VOTable";
xmlns:v2="http://vizier.u-strasbg.fr/xml/VOTable-1.1.xsd";
xmlns:v3="http://www.ivoa.net/xml/VOTable/v1.0";
xmlns:v4="http://www.ivoa.net/xml/VOTable/v1.2";
exclude-result-prefixes="vo v1 v2 v3 v4" version="1.0">
<xsl:output method="xml" />
<xsl:variable name="allRows"
select="/VOTABLE/RESOURCE/TABLE/DATA/TABLEDATA/TR"/>
<xsl:variable name="allRows0"
select="/vo:VOTABLE/vo:RESOURCE/vo:TABLE/vo:DATA/vo:TABLEDATA/vo:TR"/>
<xsl:variable name="allRows1"
select="/v1:VOTABLE/v1:RESOURCE/v1:TABLE/v1:DATA/v1:TABLEDATA/v1:TR"/>
<xsl:variable name="allRows2"
select="/v2:VOTABLE/v2:RESOURCE/v2:TABLE/v2:DATA/v2:TABLEDATA/v2:TR"/>
<xsl:variable name="allRows3"
select="/v3:VOTABLE/v3:RESOURCE/v3:TABLE/v3:DATA/v3:TABLEDATA/v3:TR"/>
<xsl:variable name="allRows4"
select="/v4:VOTABLE/v4:RESOURCE/v4:TABLE/v4:DATA/v4:TABLEDATA/v4:TR"/>
<xsl:variable name="filterRows" select="$allRows[__filterExp__]"/>
<xsl:variable name="filterRows0" select="$allRows0[__filterExp__]"/>
<xsl:variable name="filterRows1" select="$allRows1[__filterExp__]"/>
<xsl:variable name="filterRows2" select="$allRows2[__filterExp__]"/>
<xsl:variable name="filterRows3" select="$allRows3[__filterExp__]"/>
<xsl:variable name="filterRows4" select="$allRows4[__filterExp__]"/>
<!--
<xsl:variable name="filterRows" select="$allRows"/>
<xsl:variable name="filterRows0" select="$allRows0"/>
<xsl:variable name="filterRows1" select="$allRows1"/>
<xsl:variable name="filterRows2" select="$allRows2"/>
<xsl:variable name="filterRows3" select="$allRows3"/>
<xsl:variable name="filterRows4" select="$allRows4"/>
-->
<!--
<xsl:variable name="filterRows" select="$allRows[TD[7]/@val>0]"/>
<xsl:variable name="filterRows0" select="$allRows0[vo:TD[7]/@val>0]"/>
<xsl:variable name="filterRows1" select="$allRows1[v1:TD[7]/@val>0]"/>
<xsl:variable name="filterRows2" select="$allRows2[v2:TD[7]/@val>0]"/>
<xsl:variable name="filterRows3" select="$allRows3[v3:TD[7]/@val>0]"/>
<xsl:variable name="filterRows4" select="$allRows4[v4:TD[7]/@val>0]"/>
-->
<xsl:variable name="nrows"
select="count($allRows)+count($allRows0)+count($allRows1)+count($allRows2)+count($allRows3)+count($allRows4)"/>
<xsl:param name="sortOrder">ascending</xsl:param>
<xsl:param name="sortColumn">1</xsl:param>
<xsl:param name="pageStart">1</xsl:param>
<xsl:param name="pageEnd" select="$nrows"/>
<xsl:param name="selectAllCriteria" />
<xsl:variable name="fieldlist"
select="/VOTABLE/RESOURCE/TABLE/FIELD|/vo:VOTABLE/vo:RESOURCE/vo:TABLE/vo:FIELD|/v1:VOTABLE/v1:RESOURCE/v1:TABLE/v1:FIELD|/v2:VOTABLE/v2:RESOURCE/v2:TABLE/v2:FIELD|/v3:VOTABLE/v3:RESOURCE/v3:TABLE/v3:FIELD|/v4:VOTABLE/v4:RESOURCE/v4:TABLE/v4:FIELD"/>
<xsl:variable name="paramlist"
select="/VOTABLE/RESOURCE/PARAM|/vo:VOTABLE/vo:RESOURCE/vo:PARAM|/v1:VOTABLE/v1:RESOURCE/v1:PARAM|/v2:VOTABLE/v2:RESOURCE/v2:PARAM|/v3:VOTABLE/v3:RESOURCE/v3:PARAM|/v4:VOTABLE/v4:RESOURCE/v4:PARAM"/>
<xsl:variable name="lc" select="'abcdefghijklmnopqrstuvwxyz'"/>
<xsl:variable name="uc" select="'ABCDEFGHIJKLMNOPQRSTUVWXYZ'"/>
<xsl:variable name="sortColumnNum">
<xsl:if test="$sortColumn != ''">
<xsl:choose>
<xsl:when test="string(number($sortColumn))='NaN'">
<xsl:call-template name="getColumnByName">
<xsl:with-param name="value" select="$sortColumn"/>
</xsl:call-template>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="number($sortColumn)"/>
</xsl:otherwise>
</xsl:choose>
</xsl:if>
</xsl:variable>
<xsl:variable name="datatype">
<xsl:choose>
<xsl:when test="$sortColumnNum=''">text</xsl:when>
<xsl:otherwise>
<xsl:for-each select="$fieldlist[position()=$sortColumnNum]">
<xsl:choose>
<xsl:when test="not(@arraysize) and (@datatype='float' or
@datatype='double' or @datatype='int' or @datatype='long' or
@datatype='short' or @datatype='unsignedByte' or @datatype='bit')">
number
</xsl:when>
<xsl:otherwise>text</xsl:otherwise>
</xsl:choose>
</xsl:for-each>
</xsl:otherwise>
</xsl:choose>
</xsl:variable>
<xsl:template name="getColumnByName">
<xsl:param name="value"/>
<xsl:variable name="tvalue" select="translate($value,$lc,$uc)"/>
<xsl:for-each select="$fieldlist">
<xsl:variable name="ID">
<xsl:call-template name="getID"/>
</xsl:variable>
<xsl:if test="translate($ID,$lc,$uc) = $tvalue">
<xsl:value-of select="position()"/>
</xsl:if>
</xsl:for-each>
</xsl:template>
<!-- ID is primary FIELD identifier (fall back to name if ID is not
available) -->
<xsl:template name="getID">
<xsl:choose>
<xsl:when test="@ID">
<xsl:value-of select="@ID"/>
</xsl:when>
<xsl:otherwise>
<xsl:value-of select="@name"/>
</xsl:otherwise>
</xsl:choose>
</xsl:template>
<xsl:template name="selectAllList">
<xsl:call-template name="selectAllTemplate">
<xsl:with-param name="rowList"
select="/VOTABLE/RESOURCE/TABLE/DATA/TABLEDATA/TR|/vo:VOTABLE/vo:RESOURCE/vo:TABLE/vo:DATA/vo:TABLEDATA/vo:TR|/v1:VOTABLE/v1:RESOURCE/v1:TABLE/v1:DATA/v1:TABLEDATA/v1:TR|/v2:VOTABLE/v2:RESOURCE/v2:TABLE/v2:DATA/v2:TABLEDATA/v2:TR|/v3:VOTABLE/v3:RESOURCE/v3:TABLE/v3:DATA/v3:TABLEDATA/v3:TR|/v4:VOTABLE/v4:RESOURCE/v4:TABLE/v4:DATA/v4:TABLEDATA/v4:TR"/>
<xsl:with-param name="delimiter" />
</xsl:call-template>
</xsl:template>
<xsl:template name="selectAllTemplate">
<xsl:param name="rowList" />
<xsl:param name="delimiter" />
<xsl:choose>
<xsl:when test="$selectAllCriteria=''">
<xsl:value-of select="$delimiter" />
<xsl:value-of select="$rowList[position()=1]/@vovid" />
</xsl:when>
<xsl:when test="contains($rowList[position()=1], $selectAllCriteria) and
$rowList[position()=1]/@vovid">
<xsl:value-of select="$delimiter" />
<xsl:value-of select="$rowList[position()=1]/@vovid" />
</xsl:when>
</xsl:choose>
<xsl:if test="count($rowList) > 0">
<xsl:call-template name="selectAllTemplate">
<xsl:with-param name="rowList" select="$rowList[position() != 1]"/>
<xsl:with-param name="delimiter">,</xsl:with-param>
</xsl:call-template>
</xsl:if>
</xsl:template>
<xsl:template match="TABLE|vo:TABLE|v1:TABLE|v2:TABLE|v3:TABLE|v4:TABLE">
<xsl:variable name="inputSpace">
<xsl:value-of select="namespace-uri()"/>
</xsl:variable>
<xsl:element name="PARAM" namespace="{$inputSpace}">
<xsl:attribute name="datatype">int</xsl:attribute>
<xsl:attribute name="ID">VOV:TotalCount</xsl:attribute>
<xsl:attribute name="value">
<xsl:value-of select="$nrows"/>
</xsl:attribute>
</xsl:element>
<xsl:element name="PARAM" namespace="{$inputSpace}">
<xsl:attribute name="datatype">int</xsl:attribute>
<xsl:attribute name="ID">VOV:FilterCount</xsl:attribute>
<xsl:attribute name="value">
<xsl:value-of
select="count($filterRows)+count($filterRows0)+count($filterRows1)+count($filterRows2)+count($filterRows3)+count($filterRows4)"/>
</xsl:attribute>
</xsl:element>
<xsl:element name="PARAM" namespace="{$inputSpace}">
<xsl:attribute name="datatype">int</xsl:attribute>
<xsl:attribute name="ID">VOV:SelectAllRows</xsl:attribute>
<xsl:attribute name="value">
<xsl:call-template name="selectAllList"/>
</xsl:attribute>
</xsl:element>
<xsl:element name="PARAM" namespace="{$inputSpace}">
<xsl:attribute name="datatype">int</xsl:attribute>
<xsl:attribute name="ID">VOV:PageStart</xsl:attribute>
<xsl:attribute name="value">
<xsl:value-of select="$pageStart"/>
</xsl:attribute>
</xsl:element>
<xsl:element name="PARAM" namespace="{$inputSpace}">
<xsl:attribute name="datatype">int</xsl:attribute>
<xsl:attribute name="ID">VOV:PageEnd</xsl:attribute>
<xsl:attribute name="value">
<xsl:value-of select="$pageEnd"/>
</xsl:attribute>
</xsl:element>
<xsl:element name="PARAM" namespace="{$inputSpace}">
<xsl:attribute name="datatype">int</xsl:attribute>
<xsl:attribute name="ID">VOV:SortColumnsList</xsl:attribute>
<xsl:attribute name="value">
<xsl:choose>
<xsl:when test="$sortOrder = 'ascending'">+</xsl:when>
<xsl:when test="$sortOrder = 'descending'">-</xsl:when>
</xsl:choose>
<xsl:value-of select="$sortColumn"/>
</xsl:attribute>
</xsl:element>
<xsl:copy>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>
<xsl:template
match="TABLEDATA|vo:TABLEDATA|v1:TABLEDATA|v2:TABLEDATA|v3:TABLEDATA|v4:TABLEDATA">
<xsl:copy>
<xsl:for-each
select="$filterRows|$filterRows0|$filterRows1|$filterRows2|$filterRows3|$filterRows4">
<xsl:sort select="TD[position()=$sortColumnNum]/@val"
order="{$sortOrder}" data-type="{$datatype}"/>
<xsl:sort select="TD[position()=$sortColumnNum]" order="{$sortOrder}"
data-type="{$datatype}"/>
<xsl:sort select="vo:TD[position()=$sortColumnNum]/@val"
order="{$sortOrder}" data-type="{$datatype}"/>
<xsl:sort select="vo:TD[position()=$sortColumnNum]" order="{$sortOrder}"
data-type="{$datatype}"/>
<xsl:sort select="v1:TD[position()=$sortColumnNum]/@val"
order="{$sortOrder}" data-type="{$datatype}"/>
<xsl:sort select="v1:TD[position()=$sortColumnNum]" order="{$sortOrder}"
data-type="{$datatype}"/>
<xsl:sort select="v2:TD[position()=$sortColumnNum]/@val"
order="{$sortOrder}" data-type="{$datatype}"/>
<xsl:sort select="v2:TD[position()=$sortColumnNum]" order="{$sortOrder}"
data-type="{$datatype}"/>
<xsl:sort select="v3:TD[position()=$sortColumnNum]/@val"
order="{$sortOrder}" data-type="{$datatype}"/>
<xsl:sort select="v3:TD[position()=$sortColumnNum]" order="{$sortOrder}"
data-type="{$datatype}"/>
<xsl:sort select="v4:TD[position()=$sortColumnNum]/@val"
order="{$sortOrder}" data-type="{$datatype}"/>
<xsl:sort select="v4:TD[position()=$sortColumnNum]" order="{$sortOrder}"
data-type="{$datatype}"/>
<xsl:if test="not (position() < $pageStart or position() > $pageEnd)">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:if>
</xsl:for-each>
</xsl:copy>
</xsl:template>
<xsl:template match="@*|node()">
<xsl:copy>
<xsl:apply-templates select="@*|node()"/>
</xsl:copy>
</xsl:template>
<xsl:template name="start" match="/">
<xsl:copy>
<xsl:apply-templates />
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
</code>
The XML source file might be a bit large to post here, but it's attached
to the bug report from above.
Anyone else experience this?
Many thanks,
Dustin
------------------------------
Date: Tue, 6 Sep 2011 18:44:28 -0400
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
From: Brandon Ibach <brandon(_dot_)ibach(_at_)single-sourcing(_dot_)com>
Subject: Re: [xsl] WebKit transformToDocument() failing with large XML
Message-ID:
<CAHHnP6tF7mhwEOC-5u=pSFjzAQ7JQ74drG=EaoBgZZQp1aCWvA(_at_)mail(_dot_)gmail(_dot_)com>
You don't have endless recursion, just really deep. (As a nod to
computer science buffs, Alan Turing would tell you that it's
theoretically not reliably possible to know if you have endless
recursion or not without infinite time to try it.) Most XSLT
processors just set a limit on recursion depth and report *potential*
endlessness. Your file is big enough to have hit the limit.
You can seek to raise the limit (xsltproc provides the --maxdepth
option for this purpose) or, better, rewrite your stylesheet to not
use recursion for that particular task. It looks like you're just
filtering and formatting a list of items. Consider using XPath to do
the filtering, rather than an XSLT choose/when, and output the
delimiter based on the position() of each node in the resulting
filtered list.
-Brandon :)
On Tue, Sep 6, 2011 at 6:07 PM, Dustin N. Jenkins
<Dustin(_dot_)Jenkins(_at_)nrc-cnrc(_dot_)gc(_dot_)ca> wrote:
I have a bug with WebKit ( https://bugs.webkit.org/show_bug.cgi?id=3D6731=
0)
for large XML documents (> 3MB) that are being run through one XSL file.
With both Safari 5.1, and Google Chrome 13.0.782.220 this happens.
If I run the XSL file using xsltproc, I get this error, but it still
produces something:
runtime error: file filter.xsl line 134 element param
xsltApplyXSLTTemplate: A potential infinite template recursion was detect=
ed.
I'm not sure where the endless recursion would come from. =A0I've posted =
my
XSL file, which is called filter.xsl:
<code>
...
</code>
The XML source file might be a bit large to post here, but it's attached =
to
the bug report from above.
Anyone else experience this?
------------------------------
Date: Wed, 07 Sep 2011 00:53:50 +0200
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
From: "Imsieke, Gerrit, le-tex" <gerrit(_dot_)imsieke(_at_)le-tex(_dot_)de>
Subject: Re: [xsl] WebKit transformToDocument() failing with large XML
Message-ID: <4E66A47E(_dot_)8000604(_at_)le-tex(_dot_)de>
But finally we�ve proven my colleague wrong who always whines that
�Saxon is slow (and requires additional infrastructure), xsltproc is fast�:
$ time xsltproc --maxdepth 5000 -o out.xml filter.xsl data.xml
real 0m28.130s
user 0m27.908s
sys 0m0.093s
$ time saxon -o:out.xml -xsl:filter.xsl -s:data.xml
Warning: at xsl:stylesheet on line 8 column 57 of filter.xsl:
Running an XSLT 1 stylesheet with an XSLT 2 processor
real 0m1.912s
user 0m0.046s
sys 0m0.077s
On 2011-09-07 00:44, Brandon Ibach wrote:
You don't have endless recursion, just really deep. (As a nod to
computer science buffs, Alan Turing would tell you that it's
theoretically not reliably possible to know if you have endless
recursion or not without infinite time to try it.) Most XSLT
processors just set a limit on recursion depth and report *potential*
endlessness. Your file is big enough to have hit the limit.
You can seek to raise the limit (xsltproc provides the --maxdepth
option for this purpose) or, better, rewrite your stylesheet to not
use recursion for that particular task. It looks like you're just
filtering and formatting a list of items. Consider using XPath to do
the filtering, rather than an XSLT choose/when, and output the
delimiter based on the position() of each node in the resulting
filtered list.
-Brandon :)
On Tue, Sep 6, 2011 at 6:07 PM, Dustin N. Jenkins
<Dustin(_dot_)Jenkins(_at_)nrc-cnrc(_dot_)gc(_dot_)ca> wrote:
I have a bug with WebKit ( https://bugs.webkit.org/show_bug.cgi?id=67310)
for large XML documents (> 3MB) that are being run through one XSL file.
With both Safari 5.1, and Google Chrome 13.0.782.220 this happens.
If I run the XSL file using xsltproc, I get this error, but it still
produces something:
runtime error: file filter.xsl line 134 element param
xsltApplyXSLTTemplate: A potential infinite template recursion was detected.
I'm not sure where the endless recursion would come from. I've posted my
XSL file, which is called filter.xsl:
<code>
...
</code>
The XML source file might be a bit large to post here, but it's attached to
the bug report from above.
Anyone else experience this?
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or
e-mail:<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--
Gerrit Imsieke
Gesch�ftsf�hrer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit(_dot_)imsieke(_at_)le-tex(_dot_)de, http://www.le-tex.de
Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930
Gesch�ftsf�hrer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard V�ckler
------------------------------
End of xsl-list Digest
***********************************
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--