RE: [xsl] [xslt 2.0] Local functions

[Justin Johansson <procode@xxxxxxxxxx>]

Dear xsl-list,

This thread has been going on for a long while now so, as originator,
I feel it time to distill it.

After feedback from this list, I'm happy, if not somewhat pleased,
to relegate all memories of local functions in programming languages
to the Pascal era.

This thread has digressed onto some very interesting issues so,
now referring to self-or-decendant:recap below, I would like to 
address some of these.  There is also a big correlation with
topics I have posted on other threads regarding software engineering,
UML modelling of XSLT, programming in the small or large etc.

>Michael Kay:
>The more interesting question to ask is:
>Why didn't these attempts catch on, and what's going to be different about
yours?

Now, this is the $64,000 question (perhaps different in Euros).

The attempts by others to produce friendlier XSLT quoted by Mike were:

>Before inventing your own, take a look at Ed Willink's NiceXSL at
>http://nicexsl.sourceforge.net/ 
>An earlier attempt was Paul Tchistopolskii's XSLScript, which was at
>http://www.pault.com/XSLScript/pault/prod/XSLScript

No doubt there are others.  Hey, there' even one mentioned on W3C XSLT pages
called ShoXSLT??? (Short XSL from New Zealand) but sorry I cannot find the
link.

ALL THESE ATTEMPTS are about reducing syntax noise, possibly introducing
lossy interchange with the XML InfoSet, and they do offer absolutely
nothing else.

>Michael Kay (recap yet again):
>Why didn't these attempts catch on, and what's going to be different about
yours?

The reason these attempts did not catch on is best articulated by James Clark
(though in a different context) in his article :-

"Do we need a new kind of schema language?"
http://blog.jclark.com/2007/04/do-we-need-new-kind-of-schema-language.html

"For the payload format, XML has to be the mainstay, not because it's
technically wonderful,
but because of the extraordinary breadth of adoption that it has succeeded
in achieving.
This is where the JSON (or YAML) folks are really missing the point by
proudly pointing to
the technical advantages of their format:
any damn fool could produce a better data format than XML."

So what's the difference with my attempt, respectfully, Dr. Kay?

My coments/responses to your <well-formed/> question are as follows :-

In the delinquent absence of support by the W3C for higher-order functions
in XSLT,
my attempt is to produce a translator from a syntax which expresses a
higher level
of XSLT formulation to native W3C-compliant XSLT 2.0.

In adopting such a translation, my preference is to use XSLT 2.0 as the
translation
engine.  This is to leverage as much as possible from tools and techniques now
available to XSLT 2.0.

The experimental syntax of my current formulation is XML-based, as is XSLT.

Whilst admiring the attempts of NiceXSl et. al., I am not keen to go in that 
direction, as one could say XQuery has, quite so soon.

As you are most probably aware, applying a Huffman Encoding to common
prose in the English language yields a minimal bit encoding for the letter
'e'.

My current approach sees similarly for reducing syntax noise in XML-based
higher-level XSLT programs by relegating common/most-frequently occurring
select attributes on instruction elements , to text nodes.

There is an element of literate programming in my attempt also.

Refer Donald E. Knuth (Stanford, California: Center for the Study of
Language and Information, 1992)

http://www-cs-faculty.stanford.edu/~knuth/lp.html

One goal of my attempt, in the spirit of good software engineering, is to 
have documentation produced ahead of code,

Further, as has been mentioned elsewhere on this fine list, good XSL
applications
rely on having schemas produced ahead of time of actual XSLT coding and it
is a design of my appoach that typing of arguments to functions be mandatory
and declared without hindrance to the programmer.

(That's also an unashamed plug for schema-aware XSLT processors).

Further, design-by-contract is as important an issue in OO as it is in XSLT.**

XSLT will evolve to "programming-in-the-large" in the not too distant
future. **

** My assertations.

Though never intended by the original designers of XSLT, 

Do I need to say anything more to make my point?

Should we still be coding directly in a suped-up assembly language in 2007?

XSLT reduces to nothing other than a stream of byte codes pertaining to some
very intelligent and cleverly-designed kind of Code-DOM (c,f, ,Net CLI).

Should we be programming within this institution?

Well, as Groucho Marx said,

"Marriage is a fine institution if you want to live in an institution."

I commend my comments to the list.


Justin Johansson

Mad XSLT-er from Downunder (or should that be at large or in-the-large?)




<recap>
Justin Johansson said:
>> To that end, I'm working on a translator from a language with 
>> a higher level syntax (ie. either reduced XML or no XML at 
>> all) into XSLT 2.0.

Michael Kay said:
>Apart from technical details of the syntax chosen, the more interesting
>question to ask is: why didn't these attempts catch on, and what's going to
>be different about yours?

>I think the main factor that inhibits take-up of such tools is that you
>can't really get by without learning the underlying language - you need this
>knowledge firstly to communicate with others about the language (e.g to read
>books and participate in forums), and secondly to understand error messages.
>So you're asking people to learn two languages instead of one. That's a high
>entry cost for the sake of saving a few keystrokes. (And with XSLT 2.0, the
>saving in keystrokes is a lot less because the worst verbosities, like the
>5-line function call, have disappeared.)
</recap>

<recap>
So FTIOA (For the information of all) The orginal thread question was:

I'm presuming that many would agree that a programming language
based upon an XML syntax is not pretty.  However we all put up with
XSLT because at the end of the day it does a damm good job with text
processing despite the tedium.

To that end, I'm working on a translator from a language with a higher level
syntax (ie. either reduced XML or no XML at all) into XSLT 2.0.
The translator itself is an XSLT stylesheet, though eventually the translator
itself will be written in the language of the higher level syntax.

It occurs to me that it is possible to simulate local functions in XSLT 2.0
(which effectively could be declared inside xsl:template and xsl:function
elements
and the local function elements themselves).

Now, given that it can be done, question is :-

Would it be desirable if XSLT 2.0 were to support local functions?

Justin Johansson
</recap>

Justin Johansson

Mad XSLT-er from Downunder (or should that be at large or in-the-large?)