Re: [xsl] XSLT Hello World

Subject: Re: [xsl] XSLT Hello World
From: Ihe Onwuka <ihe.onwuka@xxxxxxxxx>
Date: Tue, 25 Mar 2014 09:09:01 +0000
On Tue, Mar 25, 2014 at 8:32 AM, Graydon <graydon@xxxxxxxxx> wrote:
> On Tue, Mar 25, 2014 at 01:20:17AM +0000, Ihe Onwuka scripsit:
>> How much do I have to know about a car and it's design if I just want
>> to drive it to work and back?
> I don't think that's an apposite analogy.
> XSLT is a declarative tree-transformation language _for XML trees_; it's
> completely embedded in the XML ecology's design decisions.  It has
> meaning only in an XML environment.
> Why on earth would anyone even think to create a language that
> specialized?  (Never mind a declarative language that gets its type
> model and data structures from *different* other things also embedded in
> the XML ecology!)
> It's a basic result of systems theory that the solution has to be at
> least as complex as the problem; has to be able to generate at least as
> much variety.

but Graydon ...the problem here is "hello world"....

Here's Alan Kay

Somewhere on that page is the quotation

"Simple things should be simple complex things should be possible"

That applies  irrespective that the language is declarative
tree-transformation for XML trees completed embedded in XML ecology
design. If you demand that people engage that, or attend a training
course to get some X-Fu (love that) orientation in order to safely
extract a bit of text from something that they don't see as a tree you
are setting a price of admission that many who should be using the
language can easily be persuaded not  to pay.

No 1 rule of product design - you don't design things that make people
who engage them look or feel stupid (Abel in the other thread
elaborated as to how this came about).

If you design a form and people repeatedly fill it out incorrectly and
you look and you see that they are tripping up over the same part (or
parts) of the form you don't say - the problem is that the people
don't read or interpret the instructions for form completion properly.
Well not unless you have penal authority over them like an IRS and
even they are making efforts to make their forms easier to

> XML is there to solve a really difficult, complex problem
> about how to represent arbitrary data structures in a human and machine
> readable way for any human language.  XSLT has to be able to manipulate
> all of XML.  (Even if we don't usually even *notice* all of XML.)
> A vehicle has to manage, somehow, thrust, drag, support for its mass,
> and at most three axises of control inputs.  That's a much less complex
> problem that properly exists in a much less complex domain of solutions.
> Any given problem to which XML is applied -- some specific web site,
> some specific document representation, and so on -- is necessarily less
> complex than all of XML, too.
> XSLT is not; it's got to deal with all of XML and at least some of XML's
> environment.  (xsl:result-document, static-base-uri(), etc.)
> The idea that pseudo-function node-tests are confusing, well, if you
> don't know what nodes are (or that there are nodes!), yes, sure.  Can we
> possibly get around some requirement for specialized knowledge?  Not in
> the XML problem space, no, we can't.  The problem is too complex to have
> a simpler solution.  If we want something that works, which is able to do
> the job, we've got a requirement to handle a lot of complexity and that
> puts a lower limit on how simple things can be.
> -- Graydon, who thinks XML and XSLT are astonishingly simple for the
> problem they happen to solve

Not going to dispute a word of any of that.

Screw it. My project is going to use JSON.

Your move.

Current Thread