-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplifying the language - types have behaviour. #899
Comments
The use of the "as" attribute on To construct a document node, you can use
(which will in fact construct a document node whether or not the "as" attribute is present). |
Backwards compatability was my suspicion, and in fact its something I've been very grateful for. This was why I wondered if it was sensible to have a 'strict' mode, where these wrinkles were ironed out. the language would have fewer wrinkles, and unexpected semantics. Visual basic used to have 'strict' and 'non strict' mode that I think did something similar (though for different reasons) and haskell has all sorts of pragma options to extend and modify the interpretation of the language (though again for different reasons), i expect there are multple other examples. P.S. I havent ever considered putting xsl:document inside an element, but it all becomes clear, thanks. |
We could certainly attempt to introduce a strict mode, in which the types of all variables and parameters must be declared. I fear that it would be unpopular, requiring unwanted verbosity such as Another bit of tidying up we could attempt would be to add a coercion rule such that if the required type is
would become legal rather than throwing a type error. But we would need to check for any adverse effect on XQuery. It's not clear that any changes in this area would really deliver any benefit. It's very hard in these cases to make the language less complex; fixes for problems like this have a nasty tendency to make the rules more complex rather than less complex. |
Visual Basic strict mode did just that, but actually whilst I can see that may have some value as a canonical format, its not really the sweet spot for me, as you say, I fear that would be unpopular. The wrinkle for me is not the lack of explicit typing, but the same expression having different behaviour it it is "assigned" a different type, and the automatic defaulting of this type when this scenario arises. I'm perfectly happy with I tend to approach XSLT in 2 modes a) I have a legacy XSLT 1.0 stylesheet that needs a change, that change warrants using XSLT 3.0 but I don't want the massive task of a significant upgrade, so strict = false. I would never actively want a completely strict XSLT where everything is has to be declared. My suspicion though that this is a bigger ask, I suspect my element/document issue may be the tip of an iceberg? I notice I used "and" above in my description of the gripe, so various options would be
options 1 is easy I presume, but painful and probably unpopular. |
Unless we can translate this issue into something that is a specific proposal to change the specifications in a particular way, I think we should probably close it. |
My specific gripe (if you like) is the element/document ambiguity, its quite confusing even to a relatively middling XSLT developer (me), you effectively have to force the XSLT engine to 'cast' the data into the intended type using what looks like a type declaration, and that in itself feels very unnatural. So my understanding is literal elements inside an xsl:variable construct are implied to be document-nodes (even now I'm not sure), and ideally they would always be elements, unless there was some sort of explicit document-node element construct. I think this would break backwards compatibility to xslt 1.0?....so the only way to do it would be to have some sort of 'strict' mode, Whether that is worthwhile is debatable, I would turn it on, but thats not an overwhelming argument. my view is that of someone with relative (compared to everyone else here) little exposure to the language, it IS quite a difficult language to master. |
Indeed, this causes users a lot of problems. See for example https://stackoverflow.com/questions/53023985/whats-the-rationale-behind-result-tree-fragments and many other SO issues if you search for "XSLT result tree fragment". We all know this is a problem, the question is whether anyone is able to come up with a better solution than the one we have now. David Wheeler is credited with the phrase "backwards compatibility means deliberately repeating other people's mistakes". It would be lovely to get rid of the implicit document node creation in xsl:variable, but it is used so widely that a switch to disable it would be very rarely used. Equally, a switch to require all variables to have an "as" attribute would be widely ignored. And in particular, such facilities would be ignored by all those people who fall into the trap because they are unaware that the trap exists. So I don't hold out much hope. |
fair enough. the very lowest thing, which is nothing to do with the spec really is that this is flagged as a warning. |
As the discussion shows, this is a complex problem. No solution has materialized that appears, on balance, to be an improvement over the status quo. At meeting 060, the group decided to close this issue without further action. |
I may misunderstand something but I always find the use of types and "as" to be counter intuitive (I'd prefer to be able to run an xslt 3+ script in some sort of 'strict' mode that was a bit more rigid, but thus simpler) e.g.
consider
question - what is the type of
foo1
?answer - (according to my saxon/oxygen setup the answer is) "document-node"
consider
question - is this code valid then (I would as someone not used to xslt 2+ assume not)?
answer - yes
but surely this code is identical to foo1, so the 'type' of variable is actually changing the interpretation of the expression.
For me that's quite confusing
It would appear that these 2 values are not two different views (interfaces) of the same underlying value, else this
<xsl:variable name="foo3" as="element(foo)" select="$foo1"/>
would be valid.
It isnt (i.e. this doesn't appear to be some subtle OO style scenario where an evaluation can have multiple interfaces, here 'document-node' and 'element' are presumably disjoint types).
For me conceptually types are descriptions of expressions, they have no behaviour, yet here they appear to (to me) effect the interpretation, not simply describe it.
For me, I'd prefer a 'strict' mode where either
is a type error, because the expression is clearly a document-node OR some other mechanism to clarify the ambiguity without this conceptual wrinkle.
An expression should either have 1 interpretation, or if its ambigious, that should be an error, I don't think the language should default to prefer one over another.
P.S.
why doesnt this work? I genuinely don't know how to explicitly declare something as a document-node.
The text was updated successfully, but these errors were encountered: