[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: [xsl] Re: [answered] collecting multiple tokenize() results into one sequence
Subject: Re: [xsl] Re: [answered] collecting multiple tokenize() results into one sequence
From: Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>
Date: Tue, 29 Jul 2008 15:09:15 -0400
|
Lars,
At 01:17 PM 7/29/2008, you wrote:
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.
That may be the case without the goal of "[never leaving the
programmer] wondering why the expression is illegal" being entirely
realistic. :-)
Beyond that, much could be said, but it wouldn't be on topic (even if
I thought I could add to what Mike said earlier).
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.
Indeed.
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.
I don't believe the key() function is illegal as long as its
arguments do not reference the context node. In 2.0, this can be done
if you use the third argument to establish the context of the key
(and this is useful).
Then too, I dare say this is just one of those things that an XSLT
programmer who is using such advanced features as iterating over a
sequence of atomic values simply has to get used to, through trial
and error if need be (I'm speaking of myself here :-). For these
purposes, even seeing the same "oh that again" error message can be
useful even if the verbatim content of the message isn't.
Another approach is to learn that such techniques, having such
pitfalls, might best not be regarded as methods of first resort.
Hence, we write the grouping to select nodes, not select atomics --
which (if we do it right) might leave us better off entirely.
I'm aware that none of this actually contradicts your point.
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.
In any case, it's an art. I can't count the number of occasions I
"fixed" something for one set of users only to discover I had made
things worse for others.
Cheers,
Wendell
======================================================================
Wendell Piez mailto:wapiez@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
|
