xsl-list
[Top] [All Lists]

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

2014-03-29 10:05:46

On 29-3-2014 15:39, Ihe Onwuka wrote:
On Sat, Mar 29, 2014 at 2:05 PM, Abel Braaksma (Exselt) 
<abel(_at_)exselt(_dot_)net> wrote:

2) the use-attribute-sets attribute
One answer suffices to illustrate my point which has got nothing to do
with undestanding or not understanding the semantics of copy and
copy-of.

Good. But I think understanding the semantics is vital in any discussion
of language design. Syntax and semantics are hard to be seen in isolation...


This one is on xsl:copy, because xsl:copy allows the children to be
modified. The addition of use-attribute-sets serves the use-cases where
you want to replace or augment the attributes on a certain element.

It is not available on xsl:copy-of because the semantics of xsl:copy-of
are different: it makes an unchangeable deep-copy of the selected node.
Allowing use-attribute-sets would change that semantics, which is a bad
idea. If you want to change the children, use xsl:copy, not xsl:copy-of.

You have an option use-attribute-sets makes no sense in the context of
xsl:copy-of. So if it appears you just ignore it, perhaps with a
warning perhaps not.

That is exactly what happens now, exact that you do not get a warning,
but an error, which is a stronger signal that you are trying to do
something (adding attribute sets) that cannot be done (because of the
semantics of xsl:copy-of).

You seem to argue that orthogonality means that you should add the same
properties to different instructions or functions, even if the effect is
zero, because the other attributes do not make sense. I think this is an
excellent situation where too much orthogonality would create a host of
surprises and unclarities.

Instead, orthogonality also means that if two instructions have similar
semantics, that properties for these similar semantics are available to
both, but properties that are different are not, to be able to
distinguish between the different operations and to follow that other
principle, the principle of least surprise.

And we may agree to disagree here, but I think adding a property to an
instruction that has the only effect of raising a warning or doing
nothing, is a bad idea and should, by all extend possible, be prevented.
It will only raise eyebrows and many questions on this list like "why
did you include this attribute if it only ever raises an error?". I
wouldn't have an answer ;).

(In OOP, perhaps you are referring to that, there is a design principle
where through inheritance you also inherit properties that you may not
be interested in, which you can then re-implement by raising an error.
But OOP is not applicable to a declarative language, so we don't have to
live with that problem (instead, for packages and overrides, we have
chosen a different method, you can opt in to which functions etc you are
interested in and which not)).

There is in XSLT, however, a set of attributes that really applies every
single instruction, LRE and declaration, such as xsl:use-when,
xsl:default-collation and xsl:version. These have merit, because they
actually mean something on each and every place where they can be applied.


You leave the content models the same and you only ever apply the
options that make sense for the variant you have chosen and you only
step in if what is specified would lead to an unresolvable ambiguity.

This is not an alien concept.

True, but I beg to differ that it has no use in this particular area of
language design, and no use in general unless it means something.

Take as an example the utility cURL. If I don't want the body of my
http request I specify HEAD instead of GET.

curl -v --request HEAD "http://www.guardian.com";

If I specify the content-type of the body with the --header  option

curl -v --request HEAD "http://www.guardian.com"; --header
"Content-Type:text/xml"

There is no need to burden the user with a bazillion different
signatures or to officiously refuse to cooperate  until the parameters
supplied are  are in perfect semantic harmony.

cURL can still figure out what I want, it's still a HEAD request and
it  still works.

I'm sorry, I fail to see how commandline arguments, which have their own
limitations, have anything to do with language design. The only thing
shown from this example is that using two different ways to achieve the
same thing (--header vs --request HEAD). In XSLT, we do not allow you to
use both @select on an instruction _and_ a sequence constructor, for the
reason that behavior cannot be clearly defined if both are present and
do different things (as in your example, what would happen with --header
and --request PUT at the same time)

(and while I find the comparison with cURL odd, it is one of those tools
that I can only use with looking up examples on the internet, I find it
a very ill-documented and ill-defined tool, like most commandline tools,
but this is getting very OT, it is not even a language).

Cheers,

Abel Braaksma
Exselt XSLT 3.0 processor
http://exselt.net


--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--