Re: [dssslist] Re: Markup Technology Position

Subject: Re: [dssslist] Re: Markup Technology Position
From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx>
Date: Thu, 14 Jul 2005 21:28:15 -0400
This is a favourite discussion of mine as well, though on the other side of
the wall.

At 2005-07-14 11:16 +0100, Norman Gray wrote:
On 2005 Jun 22 , at 16.10, Maltby, David G wrote:

Let me say that I have a warm place in my
heart for DSSSL/Scheme. I knew little about functional programming in
1999 when started with DSSSL, but I know now that I am better at
imperative languages for the effort of learning Scheme.


I personally
enjoy writing Scheme over XSLT. In terms of syntax it just flows
out of
my brain faster.  Even with the lot's infuriating silly parenthesis, I
can use a text editor for Scheme

Ah, my favourite hobbyhorse.

I cannot get on with the XML syntax for XSLT, and find it hugely

Having developed hands-on training courses and taught both DSSSL and XSLT to the audiences who are responsible for producing day-to-day results from XML (many of whom are not programmers), treating XSLT as a templating language and DSSSL as a programming language makes XSLT *far* more accessible to non-programmers.

Heedless of the fact that XSLT is, itself, Turing Complete and can be used
as a programming language in edge cases where simple templating is
insufficient, so much of the work with XSLT is simple templating of the
result tree in template rules.  Deciding which small fragments of the
result tree are associated with nodes of the source tree, and representing
those small fragments of the result tree as the "satisfaction" of the
processing of a source node.  Non-programmers quickly accept the concept of
templating a transformation with samples of the result that can be
assembled by the XSLT processor into a completed result tree.

What better way to represent samples of node trees than with XML syntax?

I feel that the choice of using XML syntax is both apropos and a wise
choice of the designers.

Too bad XPath isn't also structured XML so that it, too, could be massaged
with XSLT.

I personally appreciate the use of XML for XSLT because it reinforces that
structure is being used to create structure.

Now, I love DSSSL, but I am a second generation computer programmer (though
my father never did tackle LISP, I learned LISP-like languages when I
learned DSSSL) so programming is second nature to me.  Still today there
are some algorithms that I "map out" in DSSSL syntax in order to see the
recursive nature of XSLT templates that would be needed when simple
templating doesn't give the required answer.

I went as far as to develop an alternative lisp-like
syntax, and a parser which could turn it into a SAX stream ready for
plugging into your favourite transformer.

Why come up with another data format? Well, I've just read your thread, so I see why you think so, but I think it is a hard sell, and I don't think you could sell me.

I think it's great, but
when I announced it on xml-dev a while ago[1] it took off and soared
on its thermals in much the same way a brick does.  Oh well...

:{)} What a lovely picture you paint.

I sadly missed the original post, so thanks for referencing it, but I don't
think I could be swayed to accept an alternate syntax for nodes than the
syntax for which there already are many processors.

Now, if LX: was merely an editing fagade ... merely the user interface to
the editing of an XML document ... *that* would be entirely acceptable in
my eyes.  Feed it XML but see LX: and export only XML and no alternative
syntax.  I'm totally for considering alternative, thinking-outside-the-box,
gee-why-hasn't-anyone-thought-of-doing-it-this-way user interfaces, but
only if what goes in and comes out of the back end meets an existing
standard.  Then I can look at XML documents *any* way I may wish too,
including the LX: way if I prefer, but I'm not obliging anyone else to look
at XML documents any differently than they have been standardized.

Have you considered creating an LX:-based XML document editor rather than
an LX:-based data format?

I hope this helps.

. . . . . . . . . . Ken

World-wide on-site corporate, govt. & user group XML/XSL training.
G. Ken Holman                 mailto:gkholman@xxxxxxxxxxxxxxxxxxxx
Crane Softwrights Ltd.
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Breast Cancer Awareness
Legal business disclaimers:

Current Thread