Re: Why '1+' instead of '+1'?

John Thingstad wrote:
> On Sat, 14 Jan 2006 21:59:12 +0100, Nathan Baum
> <nathan_baum@xxxxxxxxxxxxxx> wrote:
>
> You are serious :)

No.

> I interpreted the post as a joke.

It was.

> 2. It is inefficient for a computer to interpret.

Is it? Surely one would compile XSLT into a more efficient form.
Ideally, it should be no less efficient than an equivalent XML
transformation program written in assembly.

> 3. It is equally inefficient for a programmer to write.

I suppose that depends upon the programmer. I'm vaguely competent at
XSLT and can write simple stylesheets with ease. But then I was in no
mood to write a style*** for the hypothetical "LispML to SexprML"
transformer.

Generally when I want to some text transformed I either use LaTeX,
which produces superior quality output and is generally very concise,
or PHP, which makes it easy to generate new content out of thin air.

If I were going to use XSLT in a production system, I'd write some Lisp
macros to transform a sane transformation specification into XSLT. More
likely is that I'd use that same specification to construct a
transforming function directly, however.

I suspect that most other production systems based upon XSLT actually
generate XSLT automatically from a simpler specification.

> Seems to me the worst of all possible worlds.
> Wouln't you be better off with Perl? (shudder)

Not really. Perl isn't an XML transformation language. Having said
that, I have nothing but love for Perl, especially the upcoming Perl 6,
which grows ever more Lisp-like (as do all languages).

> Then it is the whole motivation of what XLM is trying to do.
> To make one representation that fits all. Particularly
> the Dublin project for a general toxonometry of all data.

No. In fact, XML's purpose is, in a sense, the very opposite of this.
(It may be worth noting that Dublin metadata isn't exclusively an "XML
application" and can just as easily (some might say "more easily") be
stored as symbolic expressions.)

XML is very much like Lisp. It combats the notion that one must make
One Format To Rule Them All by making one metaformat with which one can
construct arbitrarily subformats. Like (well-designed) Lisp (domain
specific languages), you can mix and match (well-designed) XML
(applications).

For example, one should be able to put a MathML equation in an SVG
image in a HTML document. It's easy to object that one can already do
that by storing the three parts in different files and inserting them
in each other. However, one might just as easily object to allowing a
single Lisp source file to use DSLs for parsing text, querying
databases and typesetting musical notation.

Whilst you _could_ use a seperate program for each function, having
them in one source file allows a certain level of interaction between
them. For example, future versions of XHTML/CSS should support using
inline SVG documents as icons for bulleted lists (technically, this is
already supported, but I doubt most browsers are able to render it).
Such icons could change their appearance depending upon where they
appear -- e.g. they could display a stylised version of the current
item's numerical index in the list -- or their content -- e.g. they
could be green for a differential equation, blue for a summation and
red otherwise.

None of this is impossible without XML, but is likely a lot more
difficult. In the numbered list example, I'd have to generate each
bullet image seperately, manually assign each item the correct bullet
image and manually correct those assignments when a new item changes
the numbering for items after it.

Now this is rather more praise than I typically lavish upon XML. The
fundamental point is that whilst XML isn't the _best_ universal generic
structured data format, it is the _only_ universal generic structured
data format. Just getting rid of it or replacing it isn't going to be
an option even in the far future, and even then you'd need to come up
with something _technically superior_ and not just nicer to read and
write.

Lisp doesn't count since Lisp 'data' can't portably self-describe
itself. Plus, a data-is-code format is highly non-optimal for documents
intended for general consumption: there are PDF viruses, and the
intentional security hole in WMF is currently rather famous. Perhaps
the only data-is-code format that hasn't had viruses in it is the
Truetype format. (Truetype fonts contain 'bytecode' instructions for
drawing the font.)

And, really, since XML is _designed_ to be a Lingua Franca for
translation to and from other document formats, y'all can just stop
bitching about XML and use symbolic expressions, converting between XML
when external programs require it. (That's not aimed at you John, I
didn't get the impression you were bitching about XML 'in principle'.)

> 3. shema for describing the structure
> ...
> I get the feeling that XML is trying to skip level 3 altogether.

XML has at least two schema systems. One is the unreasonably limited
'DOCTYPE' system. The other is the unreasonably complex (but actually
effective) XML Schema system. Presumably, XML Schema files are intended
to be generated automatically, like XSLT. For example, a database
server might export a table to XML, and at the same time export a
schema to XML Schema.

> I find it amusing that you think XML is industrial strength while
> Common Lisp is not. I'm sure Franz would like to hear abouth that one..

You were intended to find it amusing that I thought XML was an
industrial strength _programming language_.

.