[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [bug-GIFT] Inconsistency in MRML?

From: Wolfgang Müller
Subject: Re: [bug-GIFT] Inconsistency in MRML?
Date: Wed, 26 Sep 2001 10:24:46 +0200

> Well, I can certainly verify that if a query is done with an algorithm ID
> for which a configure has not been done, an exception is thrown deep in
> GIFT and the default algorithm is used (though I don't believe that there
> is anyway to tell this from the MRML - perhaps a query response should
> indicate what algorithm was used to create it so that an interface could
> catch this behaviour.

In fact the exception business was cancelled, when I realized that the gcc 
2.81 did EITHER support exceptions, OR runtime type identification (RTTI), 
but not the two at the same time (at least with the gift I got only one to 
work at a time).

What I will write "soon"  is orderly exception handling which should also 
avoid the annoying crashes we get in certain situations. When this exception 
business is done, calling for an unconfigured algorithm will give you an 
error (mrml error message, which the client can show).

What I meant with my kind of laconical message "this is a bug" refers to the 
fact, that with the SnakeCharmer client, I have only "collection-id" in my 
query-step tag. So the use of "collection" is a bug in the program that uses 
this tag.

Moreover, the mrml.dtd (./dtd/mrml.dtd) names as attributes for the 
query-step attributes:

<!ATTLIST query-step   
                           result-size    CDATA #IMPLIED
                           result-cutoff  CDATA #IMPLIED
                           query-type     (query|at-random) "query"
                           algorithm-id   CDATA #IMPLIED

(There was also a query-step-id, but that has been suppressed, as the 
query-step should be well-defined by the session.)

What I want to say by this is, that any sending of a collection-id is purely 

and thanks for your good questions

reply via email to

[Prev in Thread] Current Thread [Next in Thread]