Dear XSL-List,
XSLT already supports type declarations (in non-schema-aware processing) in
certain contexts (such as variables, parameters, function results) with
the @as attribute. Is it possible (that is, potentially useful) to extend
the use of @as to other contexts? Possible advantages (over new keywords or
new syntax) include that we would be extending a method with which we're
already familiar in different contexts and it provides a compact way to
specify cardinality and typing. We could already, in a cumbersome way, use
it to address Roger's situation: instead of applying <xsl:value-of>
directly to the result of evaluating an XPath path expression, he could
create a variable equal to that result and use @as to validate the type and
cardinality of the result. This round-about approach makes the code harder
to read and harder to debug because we would be creating a variable not
because we need one (for the usual reasons that we use variables), but only
because creating a variable makes it easy to perform type and cardinality
checking.
For what it's worth, I'm a fan of the current default behavior because in
my own experience the fact that asking for something that does not exist is
not an error, or even a mistake, makes my XSLT more nimble (I can apply the
same XSLT to documents of the same type that vary in small ways, as is
common with the types of texts I need to process). Additionally, as the
discussion here has shown, there are methods (albeit sometimes cumbersome
ones) of trapping empty results when we need to. Meanwhile, @as is
light-weight, familiar, and, where it is currently used, optional. I don't
have a fully thought-out proposal, and the situation isn't entirely
analogous to variable typing, since value-of returns an atomic value and we
might want to perform type and cardinality checking on the value of the
XPath expression on the @select attribute, and not just on the atomic value
created by the <xsl:value-of> element. I don't know whether that difference
is worth exploring, or whether it's a deal-breaker, but @as seemed like
something that might be mentioned in this conversation, even if only
eventually to rule it out.
Best,
David
On Thu, Oct 14, 2021 at 11:26 AM Graydon graydon(_at_)marost(_dot_)ca <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
On Thu, Oct 14, 2021 at 03:17:08PM -0000, Michael Kay
mike(_at_)saxonica(_dot_)com
scripsit:
I've sometimes wondered whether a "soft" checker (lint-like) that warns
you of potentially void paths (by reference to a schema and/or instance
document) might not be a valuable tool.
Any kind of XSLT linter would be a fine thing to have.
Or a run-time checker might be less complicated than a compile-time
checker: Add an option selection="strict" at the xsl:transform level, and
then
Document/foo is treated as one-or-more(Document)/one-or-more(foo)
while if you want zero-or-more(Document)/zero-or-more(foo)
then you have to use some new syntax like opt(Document)/opt(foo)
Even adding req() as a synonym for one-or-more() might be enough to
encourage people to write req(Document)/req(foo) in order to get better
diagnostics.
I prefer keeping the default behaviour of the XPath expression and
adding req(). This would be very handy for those "of course there's a
document, wait, oops" expressions.
Or perhaps a "\" operator that behaves like "/" except the RHS is not
allowed to be empty.
Overloading backslash seems a titch rash. And this would be harder to
read than req() would be.
--
Graydon Saunders | graydonish(_at_)gmail(_dot_)com
Þæs oferéode, ðisses swá mæg.
-- Deor ("That passed, so may this.")
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--