Just to say that I agree wholeheartedly.

> Envelope-to: [log in to unmask]
> Delivery-date: Thu, 15 Jul 2004 20:14:06 +0200
> X-BitDefender-Scanner: Clean, Agent: SMTP PROXY 1.5.6 (Mesquite)
> X-BitDefender-Spam: No (0)
> Content-Type: text/plain; charset="iso-8859-1"
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> Importance: Normal
> Date: Thu, 15 Jul 2004 12:03:47 -0600
> Reply-To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
> Sender: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
> From: Peter Noerr <[log in to unmask]>
> Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on bagel.indedata.dk
> X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham
>       version=2.63
> X-Spam-Level:
>
> Hi All,
>
> This is a relatively cool thread by now, but blame various "xLA" conferences
> and having to clean up email for weeks afterwards.
>
> As a producer of a metasearch engine (and hence a client to all "real"
> servers and also a server to our clients - all at once) I would like to put
> in 2c worth for more machine readable (parseable) diagnostics.
>
> We have to understand the diagnostics from a variety of servers (not all
> Z39.50) and represent what happened to the end user in a consistent fashion.
> This means that we need machine readable diagnostics so our engine can
> "interpret" them and correlate with similar problems occurring in other
> environments. The problems get reported individually to the user, but need
> to be consistent. (So the example that started this: "fo* vs *oo" cannot be
> reported variously as "unrecognized masking character", "left truncation not
> allowed", "unrecognized term", etc. (Imagination may now run wild with
> alternatives.)) We need to convert all into one diagnostic and present that
> to the user. Thus the more specificity in machine readable form the better.
>
> There is one other aspect of this which seems to have been missed entirely
> (or is handled in some clever way I'm missing) and that is multi-lingual
> forms of the user friendly text message. All the diagnostic user messages
> were quoted in English, not entirely surprisingly. But we certainly, and
> almost all library systems probably, have to allow for interfaces in
> different languages. That includes translating the
> error/diagnostic/informative messages that systems further away from the
> user pass back. Language here also means "level of" language. So end users
> may get a different message to staff users for the same problem. This
> multi-lingualism is obviously a function of the system 'nearest' to the
> user, and that is almost certainly not the Z39.50 server. So, in these
> circumstance, the 'user friendly text message' becomes a bit moot. Except
> that it is very necessary for the person creating the translations in the
> first place and debugging their attempts.
>
> Peter
>
> p.s. I agree that the problem term should be returned as part of the
> message.
>
> Dr Peter Noerr
> Chief Technical Officer
> Museglobal, Inc.
>
> tel: +1 801 208 1880
> fax: +1 801 208 1889
> cell:+1 801 910 4912
>
> [log in to unmask]
> www.museglobal.com
>
>
>
>
> > -----Original Message-----
> > From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]On Behalf Of
> > Ray Denenberg, Library of Congress
> > Sent: Thursday, July 01, 2004 1:06 PM
> > To: [log in to unmask]
> > Subject: Re: diagnostic examples
> >
> >
> > >  In this case, I think the
> > > best we can do is to show the rejected term.
> >
> > Lacking any other suggestion, let's go with this one.
> >
> > --Ray
> >
>