[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Things that make you go Hmmmm!

Subject: Re: [xsl] Things that make you go Hmmmm!
From: Ihe Onwuka <ihe.onwuka@xxxxxxxxx>
Date: Fri, 28 Mar 2014 20:55:34 +0000

On Fri, Mar 28, 2014 at 8:34 PM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> On 28 Mar 2014, at 19:47, Ihe Onwuka <ihe.onwuka@xxxxxxxxx> wrote:
>> the question was why the select attribute appears on xsl:copy in xslt 3.0
> You've been asking a lot of such questions recently, and if you're
interested, then you would probably find it rewarding to study the process by
which these decisions are made and the language evolves. There is far too
little study in our profession of the social processes that cause our systems
to evolve in the way that they do. Most of the discussions that take place are
purely anecdotal (often descending to "the guy who designed this must have
been an idiot"), and very few researchers have made a serious and scholarly
attempt to understand the way things actually happen. The fact is, some of the
brightest people in the business get involved in language design, but they
don't always make good choices. There are many reasons for that, for example
they perceive the requirements incorrectly, they imagine the skills of the
target user base differently, and so on. The most important factor is that
there is usually tension between different designers with different
perspectives making compromises to accommodate each other and reach agreement.
Another factor is that (despite the "bicycle shed syndrome") there is a
tendency for committees to focus on the big and difficult problems and
sometimes neglect low-hanging fruit. Another is that the design process does
not include enough feedback; by the time people start reporting their
usability experiences, the decisions are difficult to change. And of course a
very big factor is that many decisions, once made, are extremely difficult to

I made many of the same observations albeit less eloquently a few days ago.


First of all I was satisfied with the first answer I got. I commented
further was because  I realised you perceived the question  in a
totally different way than I asked it.

>. Clearly this shows that the use case for it is not very strong, but my
philosophy is that orthogonality in design is more important than having a use
case for everything,

I agree 100% and that is exactly why I was surprised. My expectations
align with  the orthogonality principle. That explains my expectations
for apply-templates, apply-imports and next-match.

There is not a use case for printing an empty string. Should you
should throw an error if somebody tries to do it?

>and I managed to persuade my colleagues (who don't always share the same
philosophy) to fill this gap.

Well that explains it then.

I think the orthogonality principle is a natural default for a
functional programming language and I can't think of a good reason to
depart from that. That is a consequence of the limitations of my
knowledge and background. If I heard the reasons for the contrary
philosophy I'm sure they too would have merit, it would then become a
matter of personal taste which one would prefer.

Current Thread