[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: Sat, 29 Mar 2014 15:13:00 +0000 |
Apologies if the example with cURL is not apposite enough but I am guillotining the time I am devoting to the discussion so not going to provide an alternative. You "lazily" evaluate the "parameters" supplied with the variant of the language construct you are invoking. xsl:copy - right I am only going to look at the subset of parameters relevant to that. In essence the language construct you choose sets a construct for how the parameters supplied are interpreted and whether they are considered at all. You return a result consistent with the relevant subset. Up to the language designer whether they want to issue a warning about parameters are ignored. Up to the programmer to investigate if he doesn't get back what he expected - that is an inherent part of the discipline of programming. On Sat, Mar 29, 2014 at 3:05 PM, Abel Braaksma (Exselt) <abel@xxxxxxxxxx> wrote: > > On 29-3-2014 15:39, Ihe Onwuka wrote: >> On Sat, Mar 29, 2014 at 2:05 PM, Abel Braaksma (Exselt) <abel@xxxxxxxxxx> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Things that make you go H, Abel Braaksma (Exsel | Thread | Re: [xsl] Things that make you go H, Ihe Onwuka |
Re: [xsl] Things that make you go H, Michael Sokolov | Date | Re: [xsl] Things that make you go H, Ihe Onwuka |
Month |
Keywords