[tmql-wg] Error conditions

Robert Barta rho at devc.at
Sat Jul 14 06:04:23 EDT 2007


On Thu, Mar 29, 2007 at 01:55:24PM +1000, Robert Barta wrote:
> 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.

The latest version (to appear soon in a cinema near you) contains:

a) Syntax errors obviously are errors.

b) The rest are all during evaluation:

  - item reference cannot be resolved in effective map (4.2)
  - ontology topic does not have subject indicator (4.2)
  - item identifier cannot be resolved in effective map (4.3:1)
  - IRI cannot be resolved as subject identifier in effective map (4.3:2)
  - index overflow in tuple extraction (4.8.1)
  - XML fragment not well-formed (4.9)
  - function reference cannot be resolved in effective map (4.12)
  - function parameter mismatch 4.12:1, 4.12:2
  - variable not bound to a value (4.13.1)
  - OFFSET or LIMIT value not non-negative integer (6.4)
  - role type does not evaluate to a topic item (6.6.4)
  - role player does not evaluated to a topic item (6.6.4)

If someone wants to re-raise the issue that these error conditions
should be explicitly named, then this is the time. Montreal is the
next meeting.

\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
> > 
> 
> 


More information about the tmql-wg mailing list