[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] Re: [answered] collecting multiple tokenize() results into one sequence


Subject: [xsl] Re: [answered] collecting multiple tokenize() results into one sequence
From: Lars Huttar <huttarl@xxxxxxxxx>
Date: Tue, 29 Jul 2008 12:17:10 -0500

Date: Thu, 24 Jul 2008 17:12:13 +0100
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Subject: RE: [xsl] [answered] collecting multiple tokenize() results into one sequence
Message-ID: <24A7AFA7A62E4D5BBE3DE8A0C02157D8@Sealion>

How to clarify the error message? What about (borrowing language from the above paragraph):
"Invalid initial / or // in path step: Cannot select the root node of the tree that contains the context node, because the context item is not a node."


It's a little long, but given that I'm not the first one who has been unhelped by the existing error message, wouldn't it be worth it to make this somewhat obscure problem clearer?

I'll see what I can do to improve it.



Thanks... your attention to detail and user desires is appreciated!


One of the difficulties in designing run-time error messages

Actually this was labeled as a compile-time error message in my case. But no doubt it can occur at run-time as well...

 is that it's
dangerous to make assumptions about what constructs were used in the
original source code, since the same run-time code can be produced from many
different source code formulations.

OK, that makes sense. I can see why ""Invalid initial / or //" would often be inapplicable.
As Wendell pointed out below, an XPath expression starting with "." would be an occasion for this error; although in such a case it would be much easier IMO for a programmer to see why the expression is illegal when the context item is an atomic value.


However, there are many cases where
Saxon saves information at compile time for use in the event of a run-time
error, so that better diagnostics can be produced, and it might be possible
to do the same here.

That would be nice... the root (excuse the term) of the problem here is that you're trying to communicate to the programmer an error that is caused by a condition that is camouflaged. The programmer is trying to access the context node when there is no context node, but often it is far from clear (to us mortals) that the stylesheet as written would need to access the context node!


Incidentally I was doing some searching and ran across an email on this list where Sal Mangano, author of the XSLT Cookbook, had the same trouble: "Second, I am not sure why I can't set a variable using key() just because the Context node is atomic." [http://markmail.org/message/gsulhq6hb6nceqwd]

That makes me feel better! :-) If it confused Sal Mangano, then I'm not necessarily so dumb.

Date: Thu, 24 Jul 2008 12:49:06 -0400
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Subject: RE: [xsl] [answered] collecting multiple tokenize() results
  into one sequence

At 12:12 PM 7/24/2008, Mike wrote:
How to clarify the error message? What about (borrowing
language from the above paragraph):
"Invalid initial / or // in path step: Cannot select the root
node of the tree that contains the context node, because the
context item is not a node."

It's more general than that, since you'll also get the error for a path such as ".//node".


Maybe something like "Path expression invalid: the context item is not a node".

One of the difficulties in designing run-time error messages is that it's
dangerous to make assumptions about what constructs were used in the
original source code, since the same run-time code can be produced from many
different source code formulations.

Indeed. This is why saying less is often better. Hence, my suggestion says even less than the current "Cannot select a node here: the context item is an atomic value".



Hi Wendell,
"better" in what sense?
Here, saying less may make it easier to maintain correctness of the error message across all situations...
and I grant that an error message that's incorrect or unclear for the particular instance can be misleading and frustrating...
but if a terse, correct error message leaves the programmer wondering why the expression is illegal, it seems to me that it's still failed an important goal of error messages.


On the other extreme, explanatory paragraphs and tutorials are too much to expect from error messages. Maybe the best bet is to give an error ID or URL or some other reference that makes it easy to look up more information on why a particular error occurred.

But if Mike could use Saxon's extra compile-time diagnostic information to deliver a customized error message, that would be pretty handy.
E.g. if the offending expression used anything that was relative to the current document... initial / or //, or key(), etc... the error could point out the offending step to the user.


A less specific but still helpful (when true) bit of information to tell the user would be that the given path requires (or, is relative to) the current document. That would cover the case of initial "/", key(), and maybe others that implicitly access the current document.
This does not explain everything to the user, but may give them the missing data point that allows them to connect two seemingly unrelated dots.



Hey Lars,

<!-- gather all tokens into one sequence of strings, then group
by identical strings -->
<xsl:for-each-group select="for $tags in //item/meta return
tokenize($tags, ',')" group-by=".">
<xsl:sort select="." /> <!-- alphabetical order -->
<h2><xsl:value-of select="."/>:</h2>
<ul>
<xsl:for-each select="//item[contains(meta, .)]">
<xsl:sort select="name"/>
<li>...

How about:


<xsl:for-each-group select="//item" group-by="tokenize(meta,',')">
   <xsl:sort select="current-grouping-key()"/>
   <h2><xsl:value-of select="current-grouping-key()"/>:</h2>
   <ul>
     <xsl:for-each select="current-group()">
       <xsl:sort select="name"/>
                    <li>...

Grouping does not require that there be a single grouping key for each item grouped, and an item may appear in more than one group.

Ooh... that's a lot more elegant. :-)
I had seen the verbiage about multiple keys in the description of the group-by attribute, but had not grasped its implications.
Like Michael M-H said... there's more power here than meets the eye. Maybe I will have to get a newer edition of the Programmer's Reference. :-) As far as I'm concerned, the author has earned it! :-)


Thanks,
Lars


Current Thread
Keywords