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 misapprehension. > > 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 wrong. > > 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. http://www.youtube.com/watch?v=utFtLv_lbHw from 0:40 to 0:55.