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

Re: [xsl] discoverable design, was RE: When to use text()

Subject: Re: [xsl] discoverable design, was RE: When to use text()
From: Ihe Onwuka <ihe.onwuka@xxxxxxxxx>
Date: Wed, 26 Mar 2014 06:33:18 +0000

On Wed, Mar 26, 2014 at 12:39 AM, Michael Sokolov
<msokolov@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On 3/23/2014 11:56 AM, Dimitre Novatchev wrote:
> Maybe a key component of a discoverable system design is how the system
> behaves when a user makes a mistake, and I think a key reason why text() is
> so confusing to people is that it often works as expected even when the user
> is laboring under a misapprehension:

the question is whose misapprehension.

If 99 out of a 100 people walk up to an ATM and experience the same
problem and make the same mistake interpreting the instructions, who
or what exactly is labouring under misapprehension.

> the distinction between string() and
> text() may be stark to an experienced user, but to a neophyte it is
> profoundly subtle.  In many (most?) circumstances, they appear to be doing
> the same thing (single text node child atomized automatically).  There's no
> use proposing a solution to this problem (although I did like text-node()),
> but I do think it bears thinking about.

Things of this ilk boil essentially boil down to the same thing. The
working group sit down and consider how to deal with an issue. These
issues entail cross-disciplinary considerations, so the working group
do the best they  can and we have no reason to believe anybody else
could do better but sometimes what they emerge with is a compromise
and sometimes what they emerge with is a consensus.

It is not uncommon that the solution that emerges is one that requires
you to think like an XSLT/XQUERY/XML/XPATH parser/processor and this
is where I part company with some list members.

Whats the distinction between string and text. I personally don't give
a damn what any processor thinks.
The words string and text and the concepts and symbols of equality
where embedded in our consciousness long before any of these
programming languages were conceived. Along comes this Johnny come
lately language and someone tells me this is how you must think of
these concepts now -  and you are labouring under a misapprehension if
you don't and you need to read a specification or undergo some
training to correct that.

Again I am inclined to ask who or what exactly is labouring under a

> People often talk about the "principle of least surprise" as a way of
> getting at creating intuitive designs: the idea being to make things work
> the way people are going to expect.  But as we've been pointing out, it
> isn't always clear how to do that, given a complex internal model that is
> unknown to users, and even if it were, it may even be impossible in a
> sufficiently complex system, since choices must be balanced against each
> other. Inevitably when one thing becomes easier and more obvious, something
> else is made more obscure, remote or difficult to apprehend.

I remember reading someone say that they don't think of EQ and = as
being the same. I would venture that if most of us were to verbalize
these 2 symbols we would emit the same sound. If thats the case Sapir
Whorfism suggests it is very hard to distinguish one fromr another
even if you know that they have distinct meanings in the XPath domain.
 Also the  concept of (in)equality is ingrained upon us from
childhood, the sound and the symbol we emit to signify that emerges
from our subconscious and that is why despite knowing the distinction,
the symbol that most frequently see when I look at my code  is = even
when I don't want the existential semantics.

So on the Working Group there were great document people and there
were great database people and they knocked heads and came up with
something but maybe there was no psychologist or linguist who could
have stepped back and said yeah that compromise looks workable on
paper but 99% of the people that encounter it are going to get that

> The best-designed languages anticipate common mistakes. In C, people so
> often confuse assignment "=" and comparison "==", which could often behave
> deceptively similarly that a compiler warning was introduced for perfectly
> valid expressions like if(a = 1).

The C people got that wrong. Many a C programmer will tell you
otherwise but the fact is =, == and the more egregious === are syntax
that result  from abusing human tolerance and adaptability.

> So maybe if we fail to eliminate surprise altogether, we can strive at least
> not to bury the surprises under innocent-seeming default, automatic magical
> behaviors that mask a deeper misunderstanding. Let's avoid too much
> cleverness and make the surprises obvious!

A possible viewpoint is that the more educated (in the narrow sphere
of X-Fu documentation) you become the less surprised you are going to
be. While that is true  that does not make for a balanced approach
because it is predicated on how large this technology should loom in
the overall scheme of your life. Personally I have a backlog of Daily
Show episodes and Behavioural Economics coursework that are more
pressing, others  have people to manage or kids football to watch.

A lesson I think that emerges. We should be more careful about
displacing our priorities on others - whether they be intuitive
semantic interpretations or specification precise. That goes for all
walks of life.


from 0:40 to 0:55.

Current Thread