On Tue, Mar 25, 2014 at 8:32 AM, Graydon <graydon(_at_)marost(_dot_)ca> 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 http://en.wikiquote.org/wiki/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
interpret/understand.
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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--