- markup (76)
- xml (11)
- xslt (23)
- pipelines (8)
- atom (9)
- overlapping markup (6)
- schema (11)
- creole (5)
- dtll (1)
- xforms (1)
- xpath (1)
- xquery (2)
- coding (2)
- datagovuk (1)
- genealogy (4)
- hardware (1)
- linked data (15)
- named graphs (1)
- opendata (1)
- psi (3)
- skos (1)
- sparql (4)
- Talis (7)
- unicode (1)
- uri (4)
- versioning (1)
- visualisation (6)
- web (77)
- google (4)
- html5 (5)
- jQuery (2)
- rdf (45)
- ontologies (2)
- rdfa (8)
- rdfQuery (5)
- rest (6)
- wikis (1)
- work (3)
- legislation (2)
- xmlsummerschool09 (2)
- life (28)
- children (5)
- equality (6)
- gtd (1)
- environment (4)
- gadgets (5)
- software (3)
- xlinq (2)
- conferences (11)
- ukgc09 (1)
- xtech (9)
- xtech2008 (3)
- blog (8)
- drupal (3)
Re: Big XSLT applications just got easier to manage
Hi Jeni,
May I introduce myself: Justin Johansson from Downunder (South Australia).
My adventures with XSLT began in the early days with Instant Saxon which I used to produce my C.V. in multiple formats (txt, html, pdf). Over the years my Googling for XSLT info has often yielded information authored by yourself, among other leaders in the field so I would really respect your comments on the following.
Firstly, I chose this topic "Big XSLT applications just got easier to manage" to reply as on, since as my knowledge and use of XSLT as matured, so my XSLT apps have become bigger and bigger to the point of being bigger than Ben Hur. This, in my mind, seeded the questions: "What's the best way to factorise and reduce the amount of XSLT code one must write and manage, and how can I achieve this in a reasonable amount of time?"
Okay, that's the sizzle and now the sausage (my thought process and solution) ...
1. Use Functional Programming techniques both syntactically (to achieve conciseness of XSLT code) and algorithmically (develop XSLT solutions within an FP library framework).
2. Ponder an FP language for a model. I chose Haskell.
3. Implement how? Haskell to XSLT translator? Hmm, the impedance mismatch between the languages might just be a bit too much. Preprocess XSLT in some other way to achieve 1.?
4. Consider some use cases and see if preprocessing XSLT is the way to go.
Here's one use case that, whilst easy enough in native XSLT, still lends itself to amenability of 3.
Say you want an XSLT function to sum all but the first value in a list of values.
<xsl:function name="sum-rest" as="xs:double">
<xsl:param name="values" as="xs:double*/>
<xsl:value-of select="sum( $values[position() > 1])"/>
</xsl:function>
For conciseness, I would prefer to write something like this:
<s:function name="sum-rest">
<s:type>xs:double* -> xs:double</s:type>
<s:definition>($x : $xs) := sum( $xs)</s:definition>
</s:function>
Still the same number of lines but, to me at least, still concise because the as="" noise is somewhat reduced and the value-of select part is expressed much more succinctly.
Based on a few more complex use cases which could be solved using FP algorithmic metaphors like map, filter, foldl, etc., I concluded that preprocessing Haskell-like XSLT would provide significant advantages over writing in verbose native XSLT.
Whilst aware of the FXSL library, I felt that it did not go far enough in reducing XSLT verbosity.
As a classical musician, I felt that my solution, already largely developed, could aptly be called
Variations on the Haskell Prelude in XPath Major
for the XSLT
May I please have your comments on the idea?
Also would you be interested in reviewing the package which has been developed under Eclipse using Saxon 8b.
Thanks,
Justin Johansson
Adelaide, South Australia
+++ A horse with no name is called Lambda +++