[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

Subject: Re: the joy of breaking out from procedural/imperative programming style (was: Re: Peculiar Problem in .xsl file
From: Gunther Schadow <gunther@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 06 Dec 2002 13:49:00 -0500
joy functional
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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.