Re: [xsl] [OT] [xslt 2.0] Difference betwen functions and templates

["Abel Braaksma (online)" <abel.online@xxxxxxxxx>]

Hi Justin,

Your remarks just beg for a comment even though this is an age old
discussion. I believe you are falling into the all-too-common trap
of treating a domain-specific programming language as a general
purpose programming language.

XSLT by design is a domain specific programming language and does
not intend to be diffferent. For its domain: transforming data of
one kind to data into another kind, a certain programming paradigm
was chosen that best fit the task (opinions may vary about 'best').
The paradigm was 'Declarative Programming' and/or 'Functional
Programming'.

Like many, when I first laid my hands on XSLT, I missed the OO
feeling I grew accustomed to from the Object Oriented programming
paradigms and I was going mad when I found that state could not be
preserved and that procedural programming was hard with XSLT.

Because of the structure of the input data, and the way it could
easiest be treated (setting a bunch of rules and let the processor
do the math for you), Declarative Programming was chosen. I am not
well educated enough in language parlor to give a reasonable
treatment of the 'why' of this decision, but my guts feeling from
several years of programming with XSLT tells me it was the right
choice.

Obviously, as it is not an OO language, XSLT will not fit in easily
with UML. But UML was designed to be general-purpose and XSLT is
not. I agree that there's a lack of good design tools for XSLT
projects, but there've never been good design tools for explaining
transformation of one format to another. I personally favor decision
diagrams, but they lack flexibility.

See also my comments below.

Cheers,
-- Abel Braaksma



> Yes, well, that left-field comment was strictly off-topic in an
> xsl-list sense but it is extremely relevant to the basic OO
> principles that W3 standards**
> including XSLT (now back to *on-topic*) seem to neglect.

They don't neglect it, they deliberately chose the paradigms that
(to their opinion) best fit the problem domain. OO just does not fit
there.

>
> **except DOM, which, in anycase, totally sucks

Use DOM with XPath and don't use it for daily tasks, but only for
specific tasks and not when streaming xml is the better approach.
Again: the problem domain must fit the chosen solution.

>
> C++ is no doubt the mother/father of UML.

agreed in a way. But it is also the mother/father to Design By
Contract or many other OO design methodologies.

Personally, i find UML severely lacking. But like many things, when
something becomes mainstream, you have to use it. It doesn't fit
easily, for instance, with procedural languages (php, perl, vb) and
gives to much for basic oo languages (i.e., uml supports multiple
inheritance, where java does not).

But again: UML fits a certain gap in the market. Use the best tool
for the job which for OO projects in GP languages will often be UML
or DbC.

>
> UML has been well migrated to address Java and some other languages
> including the non-vernacula defence industry language, ADA.
>
> (Or Java has adopted itself to a well-formed UML experience).

quite. I find some other modeling systems better suited (esp. for
auto-code generation), but that's just an opinion of course.

>
> Search Google and you will find no tangible modelling of XML or XSLT
> using UML.

Of course not. UML is not designed for XSLT, or Prolog or Haskell.
Not even for Ruby (though you could fit it somehow). It works with
VB, if you know about the shortcomings. It won't work with HTML, or
designing web pages. But there are other tools that will aid you
there. You won't be able to use it for modeling your garden, either.

>
> XSLT cannot be realisticly modelled using UML.

Indeed. Luckily so. UML is not a key for everything, nor can it be.
Ever tried to model the old Navy language CMS-2 using UML?

> I know because that
> was the essence of my penultimate contract .. to produce IEEE
> standard software engineering documentation for an XML/XSLT
> conundrum in a $mill government contract,

I wonder what you eventually have come up with. XSLT is indeed
lacking a good modeling system (not sure it needs one, there are so
many already).

>
> That said, and I do say it authoritatively, XSLT currently remains a
> great language for text-processing software bods but it *is*
> programming in the small.  Personally I love XSLT 2.0 but I do see
> it's shortcomings for programming in the large.

It is not meant for programming in the large. You can say something
like "window.open('hello world')". Don't try ;)

>
> Like Forth (I once thought, in my 20's, it to be the next best thing
> to sliced bread until I came to realize that it *was* programming in
> the small).

Forth started out as a general purpose language (with quite a
specific paradigm, I think) but nowadays finds its way in a specific
problem domain: embedded systems. It is not dead, but it is not the
'next best thing' either. Every now and then a new programming
language re-invents the wheel and becomes the 'next best thing'. But
looking back one sees that there is not such a thing and that even
general purpose languages have their specific domain eventually.

>
> Programming in the large is about being able to design and develop
> software systems that are amenable to both peer review and software
> life-cycle maintenance by people that are around when you (sic),
> the programmer in the small, are no longer around.

XSLT is meant as an aid to existing systems. A product like
StreamServe adds it as a filter to the input stream. Cocoon uses it
to manipulate templates. etc. It should be part of a larger project.
Like you use Word or Open Office as part of your project to write
documentation and Excel or Calc to do create some graphs. All is
part of your project at large and should be managed as such.

>
> Systems correctly modelled on UML at least have a greater chance of
> doing that than ad-hoc programming with languages like XSLT, Forth
> an so on.

No. Systems correctly managed and/or documented (and, if needed,
modeled) have a greater chance of survival, period. UML has nothing
to do with that. XSLT and Forth are no ad-hoc languages. You can use
any language as ad-hoc, but that does not make that language ad-hoc
in itself.

>
> XSLT, and possibly XQuery, remain to be the language of the
> high-priest programmer in the small.  My last client hired me
> because I was the only one they could find to do it (in Adelaide,
> South Australia).

Give me a call and I'll take the next plane to Australia to make
XSLT look like a well-designed well-documented and well-modeled part
of your project at large ;)

Your employer is a brave man to choose the right tool for a job and
investing in new knowledge. Some governments even give companies
money for doing so (in Holland, where I live, they do) to help
spread the word and the knowledge.

>
> Great for contract programmers to make $ while the sun shines but as
> one of those I would still prefer to produce systems and
> documentation that will outlast the memory of my sufferance working
> for them.

Stick to XSLT. You can use it transform your documentation into any
nice format, except perhaps cast in stone... which would last longer
than the bits and bytes...

Literally thousands of programs use XSLT nowadays internally,
amongst which Oracle, IBM, Microsoft products.

Luckily, XSLT is easy to learn. It takes a non-programmer perhaps
two or three weeks to get up to speed and a programmer a couple of
weeks more. It helps if either has knowledge in XML.


Cheers,

-- Abel Braaksma