Re: My XPath mistakenly referenced an element that do

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@xxxxxxxxx <
xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> On Thu, Oct 14, 2021 at 03:17:08PM -0000, Michael Kay mike@xxxxxxxxxxxx
> 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@xxxxxxxxx
> CC&s oferC)ode, C0isses swC! mC&g.
> -- Deor  ("That passed, so may this.")