Re: [xml-dev] Historical trivia: who introduced into XSLT 1.0 theconstruct that enables XSLT to generate XSLT (i.e., XSLT's "code generation" capability)?
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
