Hi again Roger,
Also, to be less flippant - it is due to complexities like these that we do
not use these technologies in isolation, but embedded in other processes
and technologies that help to sort out the actual issues.
For example, in this case perhaps your schema does not require your 'foo',
so schema-aware XPath does not help, or it is not practical for some other
reason.
Maybe in this case what you have is a divergence between your programming
contract (foo is required) and your schema (foo is not required).
So insulate this by using a Schematron that requires foo (as appropriate),
over and above the schema, which does not.
Is this solution too demanding? (Not just defensive XSLT with extra
tests in your XPath but an entire Schematron?) I always wonder, when we get
to that point. What problem are we actually trying to solve?
Cheers, Wendell
On Thu, Oct 14, 2021 at 9:59 AM Martin Honnen
martin(_dot_)honnen(_at_)gmx(_dot_)de <
xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
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 <
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... ...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/174322> (by
email <>)
--
...Wendell Piez... ...wendell -at- nist -dot- gov...
...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
...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/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--