One of the recurring issues in computing is the issue of inclusion/exclusion by matching or by not-matching. It often seems that a matching model is adopted by default, and not-matching, which I write as a single word to emphasize its character, is added later or not at all. For example, CSS 2 lists all sorts of very complex matching rules, but seems to ignore the idea of not-matching entirely. People who want to say that everything that is not of this class should be bold are left including everything in one matching rule and then setting apart the specific class in a separate matching rule. Similarly, a reader or author field in Lotus Notes matches the person of group or role and assigns control based on that matching. There is no provision for not-matching, in which a specific person or group or role is excluded, and everybody else is included implicitly. This makes implementing a
Chinese wall in Lotus Notes quite difficult.
Similarly, when various customers identified a need in CoexLinks to avoid converting certain doclinks into NDL attachments or URLs based on the Hint Server, we designed a feature to exclude hint servers by matching a specific list of names. While this has been popular, what is the predictable reaction? Other customers who want to exclude implicitly, or identify not-matching lists of servers. So, in our upcoming release of CoexLinks, we have added a
COEXIncludeHintServer to match the existing
COEXExcludeHintServer. Of course, this is really just a separate matching rule, but since you can do either, you wind up with a not-matching rule as well.
Now, when will IBM add a show-when formula to match the hide-when formula or a NonReader field to match the Reader field? C;mon, if we can be responsive to our customers, so can IBM, right?
Copyright © 2006 Genii Software Ltd.