[tmql-wg] Error conditions

[Robert Barta]

On Sun, 2007-03-11 at 22:40 -0400, Steve Carton wrote:

> I guess I feel like a middle ground is needed here. On the one hand, we
>  could spend a lot of time and effort whittling error categories into a
>  defined set (perhaps we need to TM just for the error and what they
>  relate too :-) and then imposing that requirement on developers. On
>  the other hand, there should be some specificity or we end up just
>  like the low-end XML parsers -- giving nothing helpful to the XML
>  author.

> Perhaps we can devise some form of hierarchical implementation requirement -- 
> specifying at the lowest level the detailed error conditions that should be 
> trapped and how they should be reported and then one (or more) higher levels 
> of broader specificity, enabling developers to implement an easier error 
> condition set at first.

This was all discussed. There was VERY strong resistance from some
parties to specify ANY distinct set of defined errors, despite that
being the convention used by many recent languages (XQuery, XSLT, ...).
So the resolution was that there is NO such list (or hierarchy).

What I will do at some point is to inspect my prototype implementation
to get an clear overview of the possible cases. I'll post it here.

\rho

> -----Original Message-----
> From: tmql-wg-bounces at isotopicmaps.org [mailto:tmql-wg-bounces at isotopicmaps.org] On Behalf Of Lars Marius Garshol
> Sent: Saturday, March 10, 2007 9:35 AM
> To: tmql-wg at isotopicmaps.org
> Subject: Re: [tmql-wg] Error conditions
> 
> 
> * Robert Barta
> >
> > A bit, yes. At least we would have a list (maybe 10?, just guessing) 
> > errors named.
> 
> We could, but IMHO it's more important to finish TMQL than to include this list. Anything we add to the language extends the time it takes to finish.
> 
> * Lars Marius Garshol
> >
> >  - causes problems for implementors, because error situations tend to
> >    be highly dependent on implementation strategy, and
> 
> * Robert Barta
> >
> > OK, that should actually not happen. If the query is valid, then a 
> > processor MUST perform, regardless how it is implemented.
> 
> Yes, and if it is an error, the processor MUST NOT perform. So we agree on that. What I meant is that it's more work for an implementation to distinguish error situation A from error situation B than it is to simply say "this query is wrong". Of course, better error reports make for a better query processor, but that's a choice for the developer to make. Some XML parsers (Ælfred, XP) simplify things by simply reporting everything as a "syntax error".
> 
> My experience is also that if you choose a different implementation strategy from others you may find distinguishing between errors A and B quite a bit harder.
> 
> --Lars M.
> 
> 
> _______________________________________________
> tmql-wg mailing list
> tmql-wg at isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/tmql-wg
> _______________________________________________
> tmql-wg mailing list
> tmql-wg at isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/tmql-wg
>