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

[David Squire]

> Hi, David,
>
> I guess you don't mind that I put the answer of your message to
> the list, as
> I think it's important, and I assume you just forgot to do a reply-all
> instead of a reply.

You got it in one.

> > Question: is there any good reason why an algorithm which is
> requested in a
> > query should not automatically be configured if it has not already been?
>
> You will laugh, but two years ago I started out this way, and then I quit
> because of said exception trouble. But yes, I think that it is good to
> request at least a bit of rigor from the client. I find it's
> better to give
> the client some message

I probably don't agree with you, but I see your point.

>
> "Hya, you did not configure correctly"
>
> than giving some results, where the user never finds out if it
> was what he
> configured.

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.

> > Regarding the "collection", "collection-id" thing, perhaps the server
> > should return some sort of mrml warning message when it
> receives elements
> > it does not recognize. This would not violate the graceful degradation
> > principle, since the client could ignore them, but it would
> help developers
> > to find out what is going on.
>
> 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.

> I would regard it as useful to be able to send something like a
>
> cui-debug-level="1"
>
> attribute with the top-level mrml tag. Than you can program a
> reaction to the
> tag like <!-- unknown tag <sumpn> contents of this tag ignored -->
>
> To summarise the reactions I will take to our series of mails is
> that I am
> looking into the exception business NOW for some parts of the
> evening, and I
> will see in a more detailed fashion how things can be moved in the right
> direction. The goal of this is to make the gift more stable. As I
> see things,
> instability is mainly in libMRML, so changes there will benefit all query
> engines.

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.

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

Cheers,

David