Re: [xsl] My XPath mistakenly referenced an element that doesn't exist and I got no error message ... is this bad language design?

["Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Having said all this, of course you (and your friend) are perfectly correct:
the fact that "void paths" are not statically detected is a major cause of
debugging headaches, and a solution to the problem that prevents those
headaches would be highly desirable.

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.

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.

Or perhaps a "\" operator that behaves like "/" except the RHS is not allowed
to be empty.

Michael Kay
Saxonica

> On 14 Oct 2021, at 16:06, Michael Kay mike@xxxxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> This was the thinking that led to the design of the "static typing" feature
in XQuery 1.0, which has been a notable failure. Even it its diluted form as
implemented in schema-aware XPath/XQuery without static typing (where Saxon
will potentially give you a warning here) it has not been a conspicuous
success.
>
> The main reason, I think, is it requires extra coding effort up-front, and
only gives you returns when debugging, later, if you don't get things right
first time. Not many people are prepared to make that investment.
>
> Looking at your example, match="/" will match the document node of any XML
document, whatever its type. To catch an error here, you first have to make it
clear that the rule is only intended to apply to a particular kind of
document, for example by writing
>
> match="document-node(schema-element(Document))"
>
> which is quite a bit more verbose than your original; and it also requires
you (a) to import the schema for this document type, and (b) to validate the
instance against the schema before applying the stylesheet.
>
> I would still encourage people to do that: it will detect many of your
coding mistakes. But realistically, we're all inclined to take the path of
least resistance, even if that path leads you into dragon-infested territory.
>
> Michael Kay
> Saxonica
>
>> On 14 Oct 2021, at 14:45, Roger L Costello costello@xxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> Hi Folks,
>>
>> Here is my (very simple) XML document:
>>
>> 	<Document>Hello, world</Document>
>>
>> My XSLT program contains a xsl:value-of with a simple XPath expression:
>>
>> 	<xsl:template match="/">
>> 	    <xsl:value-of select="Document/foo eq 'abc'"/>
>> 	</xsl:template>
>>
>> In the XPath expression I mistakenly referenced an element -- foo -- that
does not exist.
>>
>> I ran the XSLT program on the XML document. No error was generated.
>>
>> My colleague argues that such behavior is bad language design:
>> ---------------------------------------------------
>> Languages which define such mistakes to just return "empty" node lists or
false, or such are not helping anybody. They just turn author mistakes into
silent, hard-to-detect behaviors.  In my view this is a major mistake in the
XPath language.
>>
>> All path expressions should be strongly, statically type-correct, so
Document/foo has to be a possible path. But if element foo is optional, then
any given instance may not have element foo and so a path like Document/foo
can be type correct, but meaningless for a particular data document. One can
explicitly test, e.g.,
>>
>> if ( exists(Document/foo) ) then (Document/foo eq 'abc') else....
>>
>> If you just use the expression without this test, and node foo doesn't
exist, then it should cause a failure.
>> ---------------------------------------------------
>>
>> Do you agree with my colleague's assessment? Is this behavior in XPath an
indication of bad language design?
>>
>> /Roger