Re: [xsl] things about grouping

Subject: Re: [xsl] things about grouping
From: Geert Bormans <geert@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 28 Nov 2012 11:49:20 +0100
Basically you are expecting that the semantics of a spoken language is copied 1 to 1 to the syntax of a programming language,
implying that the context should be found where you as a person (with your personal language and cultural background) would expect to find it.
That is dangerous, and from the programing language design not robust enough.
I think you are overlooking the fact that for a machine you simply need to be more precise.


Where do you draw the line?

"Jesse James was robbing a bank"
"He played the lead role in Jesse James"

We all know that in the first sentence I am talking about the person and in the second I am talking about the movie.
A computer will never know unless we give it a bunch of logic and some big databases.
And my youngest daughter can only imply this since she never heard about the legendary robber, or the movie about him


If I had to weight consistency against spoken language semantics,
I would value consistency higher
and I am happy that "A intersect B" and "A except B" behave the same predictable way


I have to make a note that in exercises in my face to face hands-on XSLT courses,
students get such concepts as "except" right pretty fast, without examples.
For me that means that the design is not too far off


What is your next request?
Do you want this to work since it is ingrained in us since childhood?
<xsl:choose>
<xsl:when test="color = 'red'">...
<xsl:when test=". = 'blue'">....
in the second when the '.' refers to the color element in the previous branch,
simply because in my Flemish language that is what I would expect?

Sometimes in language design we need to make decisions on how far we can go with drawing parallels to spoken language expectations
and often it is necessary to break the parallel at some point.... and yes, that can lead to discussions like this one.
Given that each programmer possibly has a different cultural, socio-cultural and language background,
and given that these discussions don't come up too often, I don't think it is bad after all.


Maybe an interesting analysis would be to measure the perceived semantic consistency of languages such as Ruby,
since that was originated in a cultural context pretty different from the English one


Cheers

Geert



At 11:06 28/11/2012, you wrote:
On Wed, Nov 28, 2012 at 9:47 AM, David Carlisle <davidc@xxxxxxxxx> wrote:
> On 28/11/2012 07:04, Ihe Onwuka wrote:
>
>> Well XPath has direct support for union and intersect so for
>> completeness we would expect it to support difference. Thats
>> reasonable isn't it. So lets go to the part of the specification that
>> deals with set theoretic operators and see what it says.
>>
>> The first hint of trouble is in the URL.
>>
>> http://www.w3.org/TR/xpath-functions/#union-intersection-except
>>
>> Lets read on and see why there is support for union and intersection
>> and not difference.
>>
>> op:union        Returns the union of the two sequence arguments,
>> eliminating
>> duplicates.
>> op:intersect    Returns the intersection of the two sequence arguments,
>> eliminating duplicates.
>> op:except       Returns the difference of the two sequence arguments,
>> eliminating duplicates.
>>
>> So difference is supported except (pun intended) it is called except.
>>
>> But (sic) the semantic of except  that has been ingrained in us since
>> childhood is that when you say  A except B, B takes it context from A.
>
>
>
>
> You are not really suggesting that set difference operation (except) should
> behave differently with respect to the current node than the union and
> intersect operations (or list concatenation are you?
>

I'm saying that since the set union operator is called union and the
set intersect operator is called intersect then the set difference
operator should be called difference - not except and if the argument
is that's what it is called  in the spec my response is that in this
particular instance I don't think that was a reasonable or rational
thing to do.

> in all these cases A and B are evaluated the same way
>
> A|B
> A intersect B
> A except B
> A,B
>
> If I understand your message correctly you are arguing that it would somehow
> have been simpler if in the third case only the current node when evaluating
> B was somehow different, I'm not sure what exactly,
> would you want to evaluate B at every item in A?
>
> In general XPath operators take _values_ (Xpath sequences) not expressions
> so they are always (conceptually) evaluated before the operator. A except B
> evaluates A and B and then returns all teh items in A that are not in B.
>
> The path separator / and filter [] are different in that they are specific
> syntax that changes the current item.
>


If you are going to support an operator called except then it's
semantics should be that such that it takes it's context from it's
left hand side consistent with the semantic we have grown up with
since childhood and further it should be distinct from set theoretic
operators. If that cannot be supported due to pre-existing conventions
or it leads to bastardisations like A[except B] (which will lead to a
bunch of questions as to why the need for the []), then don't support
it. It's syntactic sugar anyway.

Current Thread