In addition to that, I think Saxon EE with schema-aware XSLT 2/3 and
xs:import-schema would warn you about the use of a path like
"Document/foo" if there is no match in the schema for a possible
element. I don't think it is an obligation of a schema-aware XSLT
processor but I think it is a feature of Saxon EE.
Am 14.10.2021 um 15:55 schrieb Wendell Piez wapiez(_at_)wendellpiez(_dot_)com:
Roger,
I think your colleague is right, but not very right.
You forget that a missing 'foo' may be an error in one document and a
feature in another document in the very same system. Indeed it is part
of the semantics that constitute the reason why we save
documents, that we do not always have complete prior knowledge of
every foo. (Otherwise what are we computing, etc.)
If your schema requires foo, then use a schema-aware XPath engine, and
your colleague has the feature he wants. That would be an appropriate
way to layer in the requirement without him having to test every case.
Meanwhile, good luck making your case for why an essential feature is
not always a problem.
Cheers, Wendell
On Thu, Oct 14, 2021 at 9:46 AM Roger L Costello costello(_at_)mitre(_dot_)org
<mailto:costello(_at_)mitre(_dot_)org>
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com
<mailto: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
--
...Wendell Piez... ...wendell -at- nist -dot- gov...
...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
...github.com/wendellpiez. <http://github.com/wendellpiez.>..
...gitlab.coko.foundation/wendell...
XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
EasyUnsubscribe <http://lists.mulberrytech.com/unsub/xsl-list/582271>
(by email <>)
--~----------------------------------------------------------------
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
--~--