Can xsl throw an exception when value-of xpath does not exist?

[inquirydog]

Hi-

One frusterating thing for me with xsl is that I don't know
how to make xslt throw some sort of exception when a value-of path
does not exist. For instance, suppose I have the following line in
xslt

<xsl:value-of select="/blah/q" />

and my xml document does not have a node /blah/q. The output would
just leave this part of the document empty. Sometimes this is what I
would like, but often it is indicative of a mistake (for instance, a
spelling mistake in the node name). Spelling mistakes in the xml
document can be caught by a schema or dtd, but ones in the xslt
transformation can not be caught at all (as far as I know). Am I
incorrect? Is there a way to do this? If not, I would suggest that
it be added.

Oh, and I know it *can* be done by using extra coding like
<xsl:if> but this ceratinly isn't an acceptable solution considering
that the node has to be typed in twice in the xslt document therefore
not serving the purpose of testing for spelling mistakes, etc.

thanks
-I

[Andy Dingley]

On 15 Aug 2004 14:12:36 -0700, in********@hotmail.com (inquirydog)
wrote:

Oh, and I know it *can* be done by using extra coding like
<xsl:if> but this ceratinly isn't an acceptable solution

Stick it in a variable, test the variable, if not empty then output
the variable.

[Robin Johnson]

in********@hotmail.com (inquirydog) wrote in message news:<80**************************@posting.google. com>...

Hi-

One frusterating thing for me with xsl is that I don't know
how to make xslt throw some sort of exception when a value-of path
does not exist. For instance, suppose I have the following line in
xslt

<xsl:value-of select="/blah/q" />

and my xml document does not have a node /blah/q. The output would
just leave this part of the document empty.

This will do it, since you're using value-of and not copy-of:

<xsl:variable name="foo">
<xsl:copy-of select="/blah/q"/>
</xsl:variable>
<xsl:choose>
<xsl:when test="$foo">
<xsl:value-of select="$foo"/>
</xsl:when>
<xsl:otherwise>

<xsl:message><!-- set terminate="yes" for termination -->
<xsl:text>WARNING: node was unexpectedly empty</xsl:text>
</xsl:message>

</xsl:otherwise>
</xsl:choose>

If /blah/q contained a tree structure you wanted to process further,
you'd need to use exsl:node-set or XSLT 2.0.
--
Robin Johnson
Lead Developer, enCircle Solutions Ltd.
first initial last name at encircle dot co dot uk

[inquirydog]

"Magnus Henriksson" <ma***************@ericsson.com.SPAMTRAP> wrote in message news:<cg**********@newstree.wise.edt.ericsson.se>. ..

Sorry for getting into this thread so late...

As far as I can tell, you want to check if an XPath expression evaluates to
an empty node set, and if so, report this as an error. To me, this is the
job of a schema (XML Schema, DTD, Relax, ...). If you do not have a schema,
all bets are off, and you need to check the conditions yourself, in the
stylesheet or in another way. Personally, if I would need to transform an
XML document without a schema, I would do some basic checks using Schematron
(or a custom stylesheet), before transforming.

What I am trying to say is that I think it is necessary to separate the
transformation from the "validation".

I fully agree with this in theory. The problem is that given
the way that schemas and xsl work today this solution is very flawed.
Most of the problems that I mentioned above are still not fixed. For
instance, the xpath expression must be expressed somehow redundantly
(in the transformation and in the schema). This is a big problem if
there is a typo in the xslt transformation- ie my schema makes sure
that I have an element called <dogname>, but the transformation tries
to use <dawgname>. Oops! Now my results are incorrect and no one is
there to tell me about it. Second, someone might change the
transformation and forget to change the schema. Again trouble. Third
it requires the developer to do much extra work for simple things.

Modularity in schemas vs transformations would probably be a
good thing in the final solution to this problem, but as it stands
today the present solution isn't very useful.

thanks
-I

[inquirydog]

pt**@interlog.com (Patrick TJ McPhee) wrote in message news:<2o************@uni-berlin.de>...

How about putting the results of the expression in a variable and
testing that? Sure, the programmer will have to do it, but I guess
the programmer has to get something right somewhere along the line.
Surely you don't want your entire process to be dependent on every
XPath expression returning data.
Definitely not! But there needs to be a simple way to test
for the existence of data for the cases that you need to, which I
think would be often.
You can use xsl:message with terminate='yes' to have the script exit
immediately.
I didn't know about that. That is quite useful to know
actually (solves part of the problem).
Now, you're probably right that there's a deficiency here, but unless
you come up with a concrete, workable syntax that resolves your specific
problem, it's difficult to discuss its merits.
I don't know what was not concrete about the solutions I mentioned
earlier
Could be many things. Perhaps a global processing directive that
changes the default to expecting that a value-of be non-empty, or to
exactly contain one item. Perhaps an extra attribute in a value-of to
expect this (complainIfEmpty="true").

but at any rate I've thought about it some more and have another
perhaps better solution. What about inventing new elements like
value-of with type checking in them, like

<xsl:unique-value-of select="xpath expression"> (checks for
one and only one node in the node set).

and other common patterns

<xsl:value-of-list select=xpath expression" separator=",">
(prints out a list of nodes separated by the separator, checks that
the list has at least one element)

<xsl:apply-unique-template select="xpath expression"> (works
like xsl:apply-templates, but checks that the node set is of length
one).

<xsl:list-apply-template separator="," select="xpath
expression"> (works like xsl:apply-templates, but checks that the node
set has one or more elements, and puts the separator between the
outcomes of the apply templates).

thanks
-I

[inquirydog]

[e-mail] (Robin Johnson) wrote in message news:<5b**************************@posting.google. com>...

in********@hotmail.com (inquirydog) wrote in message news:<80**************************@posting.google. com>...
[wanting to ensure that a node-set is not empty before using it]

So far I am unaware of a good solution to the problem I mentioned.
Honestly, I can't see what's not 'good' about sending the result of
the expression into a variable and then testing that variable; exactly
as if you wanted to check that, for example, a numeric expression
didn't evaluate to zero.

Sure, I *could* just write the whole thing on a universal
Turing Machine and get the same results, but why would I want to. In
many cases to do the value-of properly the work needed to do that will
be so great that most people will not do it, and as a consequence most
xslt transformations will not be written to a reasonable enough
quality that they will be used in the business community.

I was going to write a simple example of a transformation
written with just value-of vs full out properly to show you the amount
the proper way would bulk it out, but decided I don't even want to do
that. XSLT right now makes certain checks very difficult.
Can you write a schema for your input documents, and validate them
against that before running the stylesheet?

See email above.

thanks
-I

[inquirydog]

Hi-

Thanks for the response. It is too bad that xslt makes it so
difficult to do these simple checks. If anyone out there who has some
say in the future direction of xslt, I would definitely vote to
somehow add a mode or something that would complain if an xpath
expression doesn't exist. I am trying to debug someone elses xslt
right now and it is very difficult to guess the form that they want
the document in (sure, they could have written a schema to verify
against, but they didn't. At any rate that would be of little use for
typos in the stylesheet).

thanks
-I
[e-mail] (Robin Johnson) wrote in message news:<5b**************************@posting.google. com>...

in********@hotmail.com (inquirydog) wrote in message news:<80**************************@posting.google. com>...

Hi-

One frusterating thing for me with xsl is that I don't know
how to make xslt throw some sort of exception when a value-of path
does not exist. For instance, suppose I have the following line in
xslt

<xsl:value-of select="/blah/q" />

and my xml document does not have a node /blah/q. The output would
just leave this part of the document empty.

This will do it, since you're using value-of and not copy-of:

<xsl:variable name="foo">
<xsl:copy-of select="/blah/q"/>
</xsl:variable>
<xsl:choose>
<xsl:when test="$foo">
<xsl:value-of select="$foo"/>
</xsl:when>
<xsl:otherwise>

<xsl:message><!-- set terminate="yes" for termination -->
<xsl:text>WARNING: node was unexpectedly empty</xsl:text>
</xsl:message>

</xsl:otherwise>
</xsl:choose>

If /blah/q contained a tree structure you wanted to process further,
you'd need to use exsl:node-set or XSLT 2.0.

[David Carlisle]

It is too bad that xslt makes it so
difficult to do these simple checks. If anyone out there who has some
say in the future direction of xslt, I would definitely vote to
somehow add a mode or something that would complain if an xpath
expression doesn't exist.

Why do you find the test

<xsl:if test="not(/a/b/c)">
there is no /a/b/c/ element
</xsl:if>

hard to use? what syntax would you have in mind that would be more
direct than this?

David

[Robin Johnson]

in********@hotmail.com (inquirydog) wrote in message news:<80**************************@posting.google. com>...

Thanks for the response. It is too bad that xslt makes it so
difficult to do these simple checks.
Without meaning to be evangelical, but it looks simple enough to me
once you get used to the look and feel of XSLT.
If anyone out there who has some
say in the future direction of xslt
(Just to make it clear, I have no such say.)
I would definitely vote to
somehow add a mode or something that would complain if an xpath
expression doesn't exist.
The problem there is, how do you define an XPath expression that
"doesn't exist?" All XPath expressions 'exist' except syntactically
invalid ones (which do indeed cause the processor to complain), they
just sometimes point to empty node-sets. It's easy to test whether a
node-set expression is empty by slapping an if or a choose round it.

(True, this sort of thing becomes a fair bit easier when you have a
proper tree-fragment data type, as in EXSLT or XSLT 2.0.)
I am trying to debug someone elses xslt
right now and it is very difficult to guess the form that they want
the document in (sure, they could have written a schema to verify
against, but they didn't.
Job security, I guess. Can you find any samples of input xml documents
lying around?
At any rate that would be of little use for typos in the stylesheet).

Well, I don't personally think it's the job of the implementor of a
programming language to protect you from other people's ambiguous
typos, but your mileage may vary.
--
Robin Johnson
Lead Developer, enCircle Solutions Ltd.
first initial last name at encircle dot co dot uk

[Andy Dingley]

On 16 Aug 2004 20:13:38 -0700, in********@hotmail.com (inquirydog)
wrote:

It is too bad that xslt makes it so
difficult to do these simple checks.
XSLT syntax is _meant_ to be difficult. It's not for humans to write,
it's for machines to write. The original "grand plan" involved much
smarter editors and CASE tools which hid the admitted lumpiness of the
line-by-line syntax away from the users.

I would definitely vote to
somehow add a mode or something that would complain if an xpath
expression doesn't exist.

This is really bad and wrong. The values of XPath expressions don't
"not exist", they evaluate to empty sets. If you think about the
programming environment in the right way, as a calculus, then this is
the obvious way to do things. And you _have_ to think about XSLT the
right way, for if you don't , then it will bite you.

--
When the only tool you have is a hammer,
everything looks like a hard disk.

[Robin Johnson]

On 27 Aug 2004 14:40:05 -0700, in********@hotmail.com (inquirydog)
wrote:
[...]

This is a big problem if
there is a typo in the xslt transformation- ie my schema makes sure
that I have an element called <dogname>, but the transformation tries
to use <dawgname>. Oops! Now my results are incorrect and no one is
there to tell me about it.

Yes, if you type the wrong code, you'll get the wrong results.

I can't think of a language that doesn't have that 'limitation'.
--
Robin Johnson
Lead Developer, enCircle Solutions Ltd.
first initial last name at encircle dot co dot uk

[Robin Johnson]

On Tue, 17 Aug 2004 13:49:10 +0100, Andy Dingley
<di*****@codesmiths.com> wrote:

On 16 Aug 2004 20:13:38 -0700, in********@hotmail.com (inquirydog)
wrote:

It is too bad that xslt makes it so
difficult to do these simple checks.

XSLT syntax is _meant_ to be difficult. It's not for humans to write,
it's for machines to write. The original "grand plan" involved much
smarter editors and CASE tools which hid the admitted lumpiness of the
line-by-line syntax away from the users.

Which was, in my opinion, rather misguided; you can't make programming
easy by sticking on a nice front-end. Programming is hard because
precise thought is hard, not because you have to remember a lot of
keywords and syntax.

Still, the 'lumpiness' of the XML syntax makes it easy to navigate
your program structure... once you're used to it. My only major gripe
with the syntax is that comments can't be nested, which can make
debugging a bit cathedralgic (script-like # comments as a processor
extension anyone?)
--
Robin Johnson
Lead Developer, enCircle Solutions Ltd.
first initial last name at encircle dot co dot uk

[inquirydog]

Robin Johnson <[e-mail]> wrote in message news:<ip********************************@4ax.com>. ..

On 27 Aug 2004 14:40:05 -0700, in********@hotmail.com (inquirydog)
wrote:
[...]

This is a big problem if
there is a typo in the xslt transformation- ie my schema makes sure
that I have an element called <dogname>, but the transformation tries
to use <dawgname>. Oops! Now my results are incorrect and no one is
there to tell me about it.

Yes, if you type the wrong code, you'll get the wrong results.

I can't think of a language that doesn't have that 'limitation'.

Actually, I can't think of a language which doesn't catch typos-

-----

c:

printq("you dude\n");

compilation result:

In function `main':
: undefined reference to `printq'
collect2: ld returned 1 exit status

---

perl:

x = x + &;

run result:

line 4: syntax error near unexpected token `;'
line 4: ` x = x + &;'

---

java:

static public void main(String args[])
{

File file = new File("qq");

file.createNewFile();

}

compilation:

test.java:13: unreported exception java.io.IOException; must be
caught or
declared to be thrown
file.createNewFile();
^
1 error

(one of the reasons that I love Java is because it is great at compile
time error checking, finding perhaps 90% of my bugs right off the bat)

---

I am merely requesting that xslt have the same error checking
capabilities as just about every other language out there (it does in
some ways, but I am pointing out what I consider to be a large
ommision in the language). Using a schema to check that address.xml
has a <street> element in it like this

<xsd:element name="street" type="xsd:string" />

and using an xslt transformation with the following typo

<xsl:value-of select="name" />
<xsl:value-of select="stret" /> <-- typo, should be street
<xsl:value-of select="city" /> <xsl:value-of select="state" />
<xsl:value-of select="zipcode" />

would contain an error that should be but is not caught by the xslt
translation software. Granted, as some have pointed out here, you can
store all xpath expressions in a variable, do a test with instructions
to complain and stop processing, and then use the value-of with the
variable, but given that 1). Most people won't do this, and 2). It
could increase the size of many otherwise simple transformations by
probably double (ie- consider how big my simple example above would
become), I don't think this is a reasonable way to do things.
I believe that xslt is the way of the future of development, and am
eager to patch all the holes and growing pains that all new
technologies experience. I've given some of what I believe are
reasonable suggestions about how I think that should be done, if you
have a tangible reason why you think they are a bad idea, I would love
to listen. I am not sure how essentially saying -all languages have
problems- and throwing up your arms moves xslt forward.

thanks
-I

[Patrick TJ McPhee]

In article <80************************@posting.google.com>,
inquirydog <in********@hotmail.com> wrote:

[collection of syntax errors elided]
% i am merely requesting that xslt have the same error checking
% capabilities as just about every other language out there (it does in

Well, you're not though. XPath (not XSLT) does catch syntax
errors. What it doesn't catch, like any other language, is incorrect
logic and incorrectly typed data. In this case, you're asking for
an exception to be thrown when an XPath expression returns
an empty node set, and the connection between that and incorrectly
typed expressions is tenuous at best.

% I believe that xslt is the way of the future of development, and am

The future of development of what, exactly? I was thinking about this
problem as I napped through a matinee screening of the Yu Gi Oh! movie
yesterday, and it seems to me that the solution to this problem in XSLT
is the same as the solution in every other language. When you perform a
query against an external data source and you want to throw an exception
when it doesn't return a value, you test for that condition and handle
it the way you want to. If it's too difficult to do this in XSLT, then
perhaps that's a sign that there's a more fundamental problem with XSLT.
--

Patrick TJ McPhee
East York Canada
pt**@interlog.com

[inquirydog]

pt**@interlog.com (Patrick TJ McPhee) wrote in message news:<2p************@uni-berlin.de>...

In article <80************************@posting.google.com>,
inquirydog <in********@hotmail.com> wrote:
Sorry I didn't respond all week. I was away on vacation and got
some great relaxation. For now I am back to my xml work....

% i am merely requesting that xslt have the same error checking
% capabilities as just about every other language out there (it does in

Well, you're not though. XPath (not XSLT) does catch syntax
errors. What it doesn't catch, like any other language, is incorrect
logic and incorrectly typed data. In this case, you're asking for
an exception to be thrown when an XPath expression returns
an empty node set, and the connection between that and incorrectly
typed expressions is tenuous at best.

Most other languages do more than catch syntax errors though
(ie- I specifically put in the java example to show such an example- a
missed exception.) I personally believe that the more error checking
the better(sheesh, if I could just get the computer to write the code
for me I would), and think I have found an example of a typical error
that I believe that xslt doesn't catch properly (without way too much
unnecessary work). And I have personally been burned by this very
error in the past. The small change to xslt that I suggested in this
thread (or something like it) would certainly make it easy to avoid
this in the future.

Just to reiterate what I have written earlier, I don't want
xslt to throw an exception for all empty node sets returned, but I am
calling for a simple way to tell xslt to do that if requested.
% I believe that xslt is the way of the future of development, and am

The future of development of what, exactly?
Software development, of most kinds. I am of the opinion that
xslt is going to revolutionize the way software is written. Unlike c,
c++, java, perl, python, ml and other functional languages, etc., xslt
is a truely data-dentric language. I can do in a page of xslt what
might take double that in the other languages written. xslt is to c,
c++, java what jsp is to servlets, except that jsp's only get half the
picture (easy outputs html data, doesn't easily manipulate data).
Since I've learned about xslt in the last year roughly half of my
programming tasks have turned over to it. And xslt isn't even fully
polished yet, once it is it will be much nicer. The very stuff I am
writting about in this thread needs to get fixed before xslt is going
to be widely adopted as a replacement for other languages.
I was thinking about this
problem as I napped through a matinee screening of the Yu Gi Oh! movie
yesterday, and it seems to me that the solution to this problem in XSLT
is the same as the solution in every other language. When you perform a
query against an external data source and you want to throw an exception
when it doesn't return a value, you test for that condition and handle
it the way you want to. If it's too difficult to do this in XSLT, then
perhaps that's a sign that there's a more fundamental problem with XSLT.

It isn't fundamental. I am not suggesting anything that a
simple attribute addition couldn't fix, although I do think that the
particular change needs some discussion so that it solves the problem
as fully as possible.

thanks
-I