- From: Alan Kent <ajk@mds.rmit.edu.au>
- Date: Thu, 30 May 2002 08:38:24 +1000
- To: www-zig@w3.org
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