On May 03, Donal K. Fellows modulated: ...
On the other hand, I question the extent to which an optional resource requirement has any real meaning anyway. The only times I can see a use are for when you're really trying to capture some other sense of resource by proxy, such as asking for certain operating systems with an explicit executable path instead of asking for the abstract application name that is installed at that location on those systems. But I feel that people should not ask for such proxies for what they desire; they should say what they really need (Blast, Gaussian, etc.) and let the middleware take the strain.
But aren't we defining standards for the middleware to follow (and not necessarily the people)? I think it is a HUGE mistake to keep talking about these standards efforts as if they are human interfaces. That will not give us the robust machine-to-machine communication we require, including the ability to evolve in place etc. Human information consumers are too flexible and adaptable to be the evaluation criteria for whether a protocol is going to be robust between heterogeneous software agents... The point of the "optional extension" is to allow software components to behave with graceful degradation in a heterogeneous environment. If there are basic and extended ways to describe what the client software wants/needs and the extended one is "better" but not critical to function, this allows the single message exchange to express all of that and get the best available behavior. So, I think "may ignore, but should try not to" is about the right semantics for this flag. :-) I agree that critical handling is the appropriate default for extensions. My main point is that the criticality of the extension is instance-specific to the use and NOT usually a characteristic of the extended concept itself. karl -- Karl Czajkowski karlcz@univa.com