[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Historical trivia: who introduced into XSLT 1.0 theconstru

• From: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
• To: Rick Jelliffe <rjelliffe@allette.com.au>
• Date: Mon, 13 Jun 2022 14:37:50 -0600

Making useful things easier is a good thing to do.  Designing a better
notation for them is often an effective way to make things easier to do.

Things that cannot be done with a given mechanism cannot be made easier
to do by designing a new and better notation for that mechanism.

The use of Roman numerals instead of Arabic numerals, for example, makes
operations like multiplication and division much, much harder and more
error prone.  It does not make them impossible.  Just less convenient.

But if our goal is to prove that the cardinality of the reals is the
same as the cardinality of the integers, it does not much matter what
notation we use for numbers; nothing is going to make that proof
possible.

Saying that what is possible and what is easy are two different things
is not the same as saying that one is better than the other, only that
they are not the same.  But I admit that the distinction matters only to
those who wish to understand the world and communicate clearly; to the
rest of us it is a purely academic point of no practical import.

So sure, if you want to say that it is the namespace aliasing in XSLT
that makes it *possible* for XSLT to generate XSLT, feel free to say so.
I'm sure no one will mind.

Michael


Rick Jelliffe writes:

> On Mon, 13 Jun. 2022, 05:13 C. M. Sperberg-McQueen, <
> cmsmcq@blackmesatech.com> wrote:
>
>>
>  But 'makes more convenient' is not the same as 'enables'.
>>
>
> In general, no (I disagree): If we say that some steps enable access to a
> doorway, that is fine until we consider people in a wheelchair: the steps
> prevent access, they disable.  A ramp "makes more convenient", and in doing
> so it enables. (As soon as humans are involved, we cannot assume that what
> is not strictly needed for some is optional for all.)
>
> Another example, high level languages have enabled us to code up things we
> never could have if we were writing in assembler, despite assembler being
> the most powerful, as a matter of practicality and finite resources.
> (Without adequate modeling sugar we die of complications.)
>
> Other examples: macros or classes or for-loops or symbolic variables or
> other syntactic sugar, which are entirely "makes more convenient" but
> without which many programs could not have been written and maintained, in
> the real world.
>
> (Also, would it go too far to suggest that equating "enables" with "can be
> written" is bad engineering? "Can be read" and "can be maintained" need to
> be part of the picture.)
>
> In the case of XSLT, is the convenience gained by the alternative namespace
> so thin that it has no incremental enabling benefit for humans, that no
> project would fail (to be written, to be read, to be maintained) without
> it? Quite possibly...
>
> (I am aware that Michael is not writing in terms of software engineering,
> but theoretical capability. So I am not disagreeing with him, just
> equivocating.)
>
> Regards
> Rick
>
>>


-- 
C. M. Sperberg-McQueen
Black Mesa Technologies LLC
http://blackmesatech.com

• References:
  • Historical trivia: who introduced into XSLT 1.0 the construct thatenables XSLT to generate XSLT (i.e., XSLT's "code generation" capability)?
    • From: Roger L Costello <costello@mitre.org>
  • Re: Historical trivia: who introduced into XSLT 1.0 theconstruct that enables XSLT to generate XSLT (i.e., XSLT's "codegeneration" capability)?
    • From: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
  • Re: Historical trivia: who introduced into XSLT 1.0 theconstruct that enables XSLT to generate XSLT (i.e., XSLT's "code generation" capability)?
    • From: Rick Jelliffe <rjelliffe@allette.com.au>