[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] RM: RFC: Instrinsically-defined maps?

Subject: [xsl] RM: RFC: Instrinsically-defined maps?
From: David Rudel <fwqhgads@xxxxxxxxx>
Date: Wed, 16 Apr 2014 11:51:47 +0200

Consider Xpath functions, Xpath maps, and Saxon Memo-functions:
A. maps and memo-functions allow caching.
B. Xpath functions and memo-functions allow computing of outputs based
on heretofore unseen inputs "on the fly" using intrinsic logic. They
also allow arities other than 1.
C. Xpath maps allow access to the keys of the hash.

It would be nice to be able to have the features of all 3 in a single
type.... in other words a memo-function whose stored keys you could

Unfortunately, there are two major barriers (in my mind, at least) to
accomplishing the above:

Saxon memo-functions are the closest thing to getting all 3, but XSLT
functions are not first-class objects, so it isn't clear how you would
direct the processor to operate on them. Also, it is not clear how the
keys should be presented if the arity is greater than 1.

For the case where arity = 1, the most natural solution would be to
allow an intrinsic definition for the map that could be used whenever
any of the extrinsic declarations are not applicable. Something like

<xsl:variable name="default.function" as="function(xs:integer) as
xs:integer" select="function($x){$x + 3}"/>

<xsl:variable name="non.static.map" as="map(xs:integer,xs:integer)"
select="map{2:= 4, 3:= 5, $default.function}"/>

The idea would be that if $non.static.map were called with an
xs:integer argument other than {2,3}, then it would return the value
"input + 3" and store that input-output pair in its hash.



"A false conclusion, once arrived at and widely accepted is not
dislodged easily, and the less it is understood, the more tenaciously
it is held." - Cantor's Law of Preservation of Ignorance.

Current Thread