In Saxon there's the vendor extension <xsl:function saxon:memo-function="yes"/>
which has been available for some years; in XSLT 3.0 it's standardised as
<xsl:function cache="yes"/>
Michael Kay
Saxonica
On 23 Jan 2020, at 17:31, David Birnbaum djbpitt(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Dear XSL-list,
Is there information anywhere about how to construct a memo function? I see
that support for it it is built into Saxon PE and EE, but does anyone know of
an example or description of how to construct a memo function in HE, or a
different XSLT engine that does already incorporate hooks for that
functionality?
Thanks,
David
On Thu, Jan 23, 2020 at 11:15 AM Michael Kay mike(_at_)saxonica(_dot_)com
<mailto:mike(_at_)saxonica(_dot_)com>
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com
<mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>> wrote:
One technique I have found useful in converting algorithms designed for
procedural programming languages is to use memo functions. For example, if
you need to assign (row, column, height, depth) properties to every cell in
a table, you don't necessarily need to construct a data structure holding
that information; if you have a function (or set of functions) that computes
the properties in terms of the corresponding properties for other cells in
the table, and if you make that computation a memo function, then the data
structure is there in the implicit memory of the memo function, and doesn't
need to be exposed explicitly in variables. To take an example with a
one-dimensional table where every cell has a colspan attribute, we can compute
function f:column($cell) { $cell ! (if (preceding-sibling::cell) then
(column(preceding-sibling::cell) + (@colspan, 1)[1]) else 1) }
and if this is a memo function, we don't need to worry about the cost of
repeated computation of the function.
Michael Kay
Saxonica
On 23 Jan 2020, at 15:59, Eliot Kimber ekimber(_at_)contrext(_dot_)com
<mailto:ekimber(_at_)contrext(_dot_)com>
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com
<mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>> wrote:
Andrew's code will almost certainly allow me to solve my immediate problem.
I would still be interested in an XSLT 3 solution that uses arrays or maps,
but I might be able to work it out myself, although I know that I don't
fully grok the best/most compact way to do things, for example, taking
advantage of higher-order functions or fold-* approaches.
Cheers,
E.
--
Eliot Kimber
http://contrext.com <http://contrext.com/>
On 1/23/20, 9:37 AM, "Martin Honnen martin(_dot_)honnen(_at_)gmx(_dot_)de
<mailto:martin(_dot_)honnen(_at_)gmx(_dot_)de>"
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com
<mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com>> wrote:
Am 23.01.2020 um 16:30 schrieb Eliot Kimber
ekimber(_at_)contrext(_dot_)com <mailto:ekimber(_at_)contrext(_dot_)com>:
I have XSLT 1-style code that converts HTML tables to CALS tables. I
discovered that this code fails for certain patterns of HTML tables in that
it miscalculates column spans in the face of row spans earlier in the
table. It doesn't fail for all tables, just specific ones (which is why we
didn't notice this bug earlier). I haven't been able to determine the cause
of the bug in the short time I've had to debug it (found the bug in the
course of trying to prepare a rush publishing job that has about 50 complex
tables in it, of course).
Rather than try to debug and fix the XSLT 1 solution it seemed easier and
better to re-implement the processing using XSLT 3 and I took a stab at
doing it using arrays last night, but quickly got bogged down in my own
lack of facility with such things. The procedural solution in i.e., Java,
would be easy: just populate the 2x2 matrix that represents the table grid
to reflect row and column spans as you process the table cells
left-to-right and top to bottom, using cells projected from earlier rows to
determine the starting column of cells in subsequent rows that get pushed
over by row-spanning cells.
However, I couldn't quickly see how to do this using arrays or maps in XSLT
3--the immutability of arrays and thus the coding patterns that take
existing arrays or maps and return new ones threw me and my feeble brain
just wasn't landing on the right algorithmic pattern.
I know there must be a general pattern for this type of processing but none
of the examples I could find were helpful.
So my request: can someone help me with this challenge and outline how to
solve this kind of problem where you take as input an HTML table where any
cell may span two or more columns and two or more rows and produce a 2x2
array representing the table's grid, where every grid cell reflects the
HTML table cell that covers it.
From that array it's then easy to determine what the CALS result should be
(where CALS represents column spans by naming the start and end columns the
cell spans).
Does Andrew's XSLT 2 code help?
http://andrewjwelch.com/code/xslt/table/table-normalization.html
<http://andrewjwelch.com/code/xslt/table/table-normalization.html>
XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/3318727> (by
email <applewebdata://207DDDB1-5D90-40FC-91F4-F204E9F129B9>)
XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/293509> (by
email <>)
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--