Date: Thu, 24 Jul 2008 17:12:13 +0100
To: <xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com>
From: "Michael Kay" <mike(_at_)saxonica(_dot_)com>
Subject: RE: [xsl] [answered] collecting multiple tokenize() results into one
sequence
Message-ID: <24A7AFA7A62E4D5BBE3DE8A0C02157D8(_at_)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(_at_)lists(_dot_)mulberrytech(_dot_)com
From: Wendell Piez <wapiez(_at_)mulberrytech(_dot_)com>
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
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--