[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
voluntary.
Cheers,
and thanks for your good questions
Wolfgang