Re: Error conditions

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.
>=20
> > Perhaps we can devise some form of hierarchical implementation requir=
ement --=20
> > specifying at the lowest level the detailed error conditions that sho=
uld be=20
> > trapped and how they should be reported and then one (or more) higher=
 levels=20
> > of broader specificity, enabling developers to implement an easier er=
ror=20
> > condition set at first.
>=20
> 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).
>=20
> 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: [email protected] [mailto:tmql-wg-bounces@isotop=
icmaps.org] On Behalf Of Lars Marius Garshol
> > Sent: Saturday, March 10, 2007 9:35 AM
> > To: [email protected]
> > Subject: Re: [tmql-wg] Error conditions
> >=20
> >=20
> > * Robert Barta
> > >
> > > A bit, yes. At least we would have a list (maybe 10?, just guessing=
)=20
> > > errors named.
> >=20
> > 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.
> >=20
> > * Lars Marius Garshol
> > >
> > >  - causes problems for implementors, because error situations tend =
to
> > >    be highly dependent on implementation strategy, and
> >=20
> > * Robert Barta
> > >
> > > OK, that should actually not happen. If the query is valid, then a=20
> > > processor MUST perform, regardless how it is implemented.
> >=20
> > Yes, and if it is an error, the processor MUST NOT perform. So we agr=
ee 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 be=
tter query processor, but that's a choice for the developer to make. Some=
 XML parsers (=C6lfred, XP) simplify things by simply reporting everythin=
g as a "syntax error".
> >=20
> > My experience is also that if you choose a different implementation s=
trategy from others you may find distinguishing between errors A and B qu=
ite a bit harder.
> >=20
> > --Lars M.
> >=20
> >=20
> > _______________________________________________
> > tmql-wg mailing list
> > [email protected]
> > http://www.isotopicmaps.org/mailman/listinfo/tmql-wg
> > _______________________________________________
> > tmql-wg mailing list
> > [email protected]
> > http://www.isotopicmaps.org/mailman/listinfo/tmql-wg
> >=20
>=20
>=20