The difference between the two models -- one as a tokenized sequence, the
other as a node-set, is not in fact all that dramatic; In essence, the XML
version provides a mapping between two strings -- the month indicator "04"
and the month name "April", while the sequence provides the mapping between
a position in a list and the month name. What the tokenize() function does
is to give a useful mechanism for creating sequences, in effect raising
sequences to the same level as XML element/attribute nodes. The advantage
here is that you can store information more compactly, while still utilizing
the power of XPath/XSLT. For instance,
<monthDesignators>
<months lang="EN-US"
names="January,February,March,April,May,June,July,August,September,October,N
ovember,December" delimiter=","/>
<months lang="DE"
names="Januar;Februar;März;April;Mai;Juni;Juli;August;September;Oktober;Nove
mber;Dezember"
delimiter=";"/>
<months lang="ES" names="Enero Febrero Marcha Abril Pueda Junio Julio
Agosto Septiembre Octubre Noviembre Diciembre" delimiter=" "/>
</monthDesignators>
<xsl:function name=" dt:getMonthName"
xmlns:dt="http://www.mySchemas.com/date";>
<xsl:param name="date"/>
<xsl:param name="lang"/>
<xsl:variable name="monthDesignators"
select="document('monthDesignators.xml')//months[(_at_)lang=$lang]"/>
<xsl:variable name="months"
select="tokenize($monthDesignators/@names,$monthDesignators/@delimiter)"/>
<xsl:return select="$months[number(substring($monthNum,5,2))]"/>
</xsl:function>
The significance here is that from the standpoint of XSLT2/XPath2, there is
no real difference between a sequence of nodes and a sequence of strings -
they are both sequences. XSLT2 is perhaps not quite so disposed to
sequences -- you can do an <xsl:for-each> but not an <xsl:apply-templates>
with non-nodal sequence content, but even there, you can always create a
node from a non-node.
-- Kurt
----- Original Message -----
From: "Gunther Schadow" <gunther(_at_)aurora(_dot_)regenstrief(_dot_)org>
To: <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
Sent: Friday, December 06, 2002 10:49 AM
Subject: Re: the joy of breaking out from procedural/imperative programming
style (was: Re: [xsl] Peculiar Problem in .xsl file
Well, I would caution about your solution, Kurt:
<xml:function name=" dt:getMonthName"
xmlns:dt="http://www.mySchemas.com/date";>
<xsl:param name="date"/>
<xsl:variable name="months"
select="tokenize("January,February,March,April,May,June,July,August,Septembe
r,October,November,December",',')"/>
<xsl:return select="$months[number(substring($monthNum,5,2))]"/>
</xsl:function>
I would agree that the function is nicer than having to do the xpath
to select the month names from my table. BUT, I would want to stress
the point that most all of the data that drives your transforms should
be expressed as XML instances, and not hidden in expressions such as
in xsl:when/@test clauses or in the nifty tokenize value in the
function body.
So, the fusion of our two ideas would be this:
<xsl:variable name="monthNames">
<month digits="01" name="January"/>
<month digits="02" name="February"/>
<month digits="03" name="March"/>
<month digits="04" name="April"/>
<month digits="05" name="May"/>
<month digits="06" name="June"/>
<month digits="07" name="July"/>
<month digits="08" name="August"/>
<month digits="09" name="September"/>
<month digits="10" name="October"/>
<month digits="11" name="November"/>
<month digits="12" name="December"/>
<xsl:variable>
<xsl:function name="dt:monthName"
xmlns:dt="http://www.mySchemas.com/date";>
<xsl:param name="date"/>
<xsl:return
select="$monthNames/
month[(_at_)digits=substring($date, 5, 2)][1]/@name"/>
</xsl:function>
so that you can still say
<xsl:value-of select="dt:monthName($date)"/>
but you could add other attributes to the months (e.g., how about the
duration of each month in days, language code, etc.) and you still
could easily load such a table from an external locale resource and
you can manage these tables as XML data rather than special strings.
Functional Programming at its most basic.
I found David Carlisle's comment most interesting, he said:
except they still managed to miss out the most basic property of
functional programming languages, the ability to manipulate functions as
data. But yes I agree that having user defined functions will be a big
win. (shame about the rest of xpath2 though:-)
Two points:
#1 the function is data, but I'd have to do code generation to handle
it as data and then execute the generated style sheet to execute
the function. Of course far inferior from just executing an XML
form that happens to be a lambda expression. I still don't like
the fact that XPath is so different from XML data.
#2 what do you mean when you say "shame about the rest of xpath2
though"? Aren't you one of the guys "in control" of that spec?
regards,
-Gunther
--
Gunther Schadow, M.D., Ph.D.
gschadow(_at_)regenstrief(_dot_)org
Medical Information Scientist Regenstrief Institute for Health Care
Adjunct Assistant Professor Indiana University School of Medicine
tel:1(317)630-7960 http://aurora.regenstrief.org
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list