Re: Proposal for truncation type 105: Masking

On Wed, May 29, 2002 at 12:05:58PM +0100, Mike Taylor wrote:
> So we will then have the following truncation attributes in BIB-1:
> 
> 	101   process # in search term
> 	102   regExpr-1 (POSIX, IIRC)
> 	103   regExpr-2 (deliberately lkeft unspecified)
> 	104   Z39.58
> 	105   Masking (similar to, but different from, shell wildcards)
> 	106   ISO 8777 (essentially identical to 104)
> 	107   "complex", whatever that means.
> 
> Seven different ways of doing pattern-matching.  Well.  It's _easy_ to
> see how that will improve interoperability.

I understand the concern, and am in favor of deprecating (or replacing)
existing operators if they are not supported (or used) by anyone.

For example, from the above we by default between our client and server
use only 103 from the above.

I don't use 101 because its not powerful enough.
I don't use 102 because its too hard to turn into something to look
   up an index efficiently with.
I don't use 104 because it has holes in it (you cannot do all possible
   searches). 106 was a possibility to plug those holes. I would rather
   have "fixed" 104, but it would be non backwards compatible.
   (And there is no such thing as Z39.58 anyway.)
105 Ralph wants to use this
106 I want to use this because 104 is defective (currently my 103).
107 I don't know what this is either.

It would be interesting to build up a table of who supports what from
the above and deprecate (or recommend against, or at least document
which ones are in real live systems). Maybe a table of what clients and
servers support to provide guidence of which are really useful.

Note: 106 has not yet been offically proposed. (That is, standard ISO 8777
based regex support.) I can just continue to use 103 or some other private
number. I think the final regexp form that is agreed to in CQL might
impact on this too.

But I think the question at hand is the merit of Ralph's proposal.
If there is objection on the basis of too many regexps, is it worth
deprecating old ones if they are not being used by anyone?

Alan
-- 
Alan Kent (mailto:ajk@mds.rmit.edu.au, http://www.mds.rmit.edu.au/~ajk/)
Project: TeraText Technical Director, InQuirion Pty Ltd (www.inquirion.com)
Postal: Multimedia Database Systems, RMIT, GPO Box 2476V, Melbourne 3001.
Where: RMIT MDS, Bld 91, Level 3, 110 Victoria St, Carlton 3053, VIC Australia.
Phone: +61 3 9925 4114  Reception: +61 3 9925 4099  Fax: +61 3 9925 4098

Received on Wednesday, 29 May 2002 18:39:33 UTC