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(_at_)mitre(_dot_)org
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> 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
--~----------------------------------------------------------------
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
--~--