[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [bug-GIFT] Inconsistency in MRML? - perhaps there should be anMRML w
RE: [bug-GIFT] Inconsistency in MRML? - perhaps there should be anMRML warning message?
Thu, 27 Sep 2001 15:21:21 -0600
> 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
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
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
> 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
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.