Re: [bug-GIFT] Inconsistency in MRML? - perhaps there should be anMRML warning message?

[Wolfgang Mueller]

> You got it in one.

Phew.

> Certainly I can see the point of returning such a message as well as some
> results. I could imagine every message having an mrml-status attribute
> which could, say, be printed in a status bar on the client.

We might do that, but I don't know if requiring/encouraging this behavior is 
really the best idea.

> > I do think it violates something: Imagine somebody sending region queries
> > with plenty of tags, causing lots of error messages on top of the normal
> > stuff...
>
> You see this as a communication overhead problem? I submit that (at least
> at present) it should be an unlikely occurence, since if property sheets
> etc. are used properly, a well-designed client should not be sending
> messages which the server does not understand.

Yes, but I do not see the use working for something which works only in a 
restricted environment. I do not see the configuration messages as an 
overhead problem. I see things like region queries as an overhead problem. 

I think one of the strenghts of GIFT as it is, is that it feeds without 
looking at it an XML parse tree to the plugin which contains the active query 
engine. The GIFT does not have to know which tags this query engine knows. Of 
course, now the query engine can create warnings which like: 

"ERROR: this is a text query , but I am an image query engine"

However it is highly likely that we will have the same parse tree fed to both 
an image and a text query engine at the same time, in order to combine the 
results. Now it would be quite inconvenient to get results like query engine 
1 saying 

"This query contains text queries, I am not able to process them"

and the text query engine saying

"This query contains an image query, I am not able to process it".

Now extend this to the scenario where somebody sends you a 100K MPEG-7 
descriptor included into a query step tag. This was the case about which I am 
thinking. 

However, for real debugging I see some use in your suggestion.

> That is good news, but do not regard it as urgent on my part. I got done
> what I needed to get done before I left Australia, and now I am just
> reporting things as I continue to tinker and find them.

...which is very useful and welcome. The exception stuff is something I 
wanted to do for a long time, and I am just having a go at it to see what 
needs to be done. I do not think I can resolve everything (or even enough) 
now. 

> > After that we can see, how we can include such a debug-level tag into the
> > gift. We would also have to create something flexible for how to
> > let the gift
> > know what's unknown... See what I mean? All parts have to know what they
> > know. I guess that there will be some cui-known-tag-list in the
> > configuration, and a special visitor which generates warnings?
>
> I would have thought that it would come from the DTD. I guess that
> algorithm plug-ins would need a way of extending the base set though.

This would have been the case, if it wasn't for the plugins. Currently 
mrml.dtd has two purposes:

1) it gives a formal description of what is "standard" i.e. minimal MRML. It 
also contains some useful (hopefully) comments.
2) it contains (almost) all tags and attributes used in the gift package. The 
MRML string constants in GIFT and SnakeCharmer are automatically generated 
from the DTD using a perl script, thus assuring synchronisation between C++, 
the DTD and JAVA, and avoiding typos.

MRML messages are parsed, but not validated.

As a consequence, plugins can use tags&attributes that are not in the 
standard MRML DTD. The clients can send stuff not contained in the DTD etc. . 
This is why it's so flexible and easy to use, and why it's sometimes tedious 
to debug. It's a bit thinking Scheme and not Pascal. I found the use of the 
MRML DTD together with the perl script for avoiding hand-typing of text 
strings very useful. Maybe we should do something similar for Perl.

Cheers,
Wolfgang

-- 
Dr. Wolfgang Müller, assistant == teaching assistant
Personal page: http://cui.unige.ch/~vision/members/WolfgangMueller.html 
Maintainer, GNU Image Finding Tool (http://www.gnu.org/software/gift)