Re: the joy of breaking out from procedural/imperative progr

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[@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@xxxxxxxxxxxxxxxxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Friday, December 06, 2002 10:49 AM
Subject: Re: the joy of breaking out from procedural/imperative programming
style (was: Re:  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[@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@xxxxxxxxxxxxxxx
> 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