1 From mike@seatbooker.net Tue Oct 29 15:12:09 2002
2 Envelope-to: mike@miketaylor.org.uk
3 Date: Tue, 29 Oct 2002 14:11:48 GMT
4 From: Mike Taylor <mike@seatbooker.net>
6 Cc: mike@miketaylor.org.uk
7 Subject: Again: Grammar Tweaks
11 I sent this message last Friday, and didn't get a delivery failure
12 message or anything similar; but there has been absolutely zero
13 response on-list, which makes me wonder whether it mysteriously didn't
16 ... or surely it didn't get caught by people's "this message is too
17 complicated to pay attention to" filters? :-~
19 _/|_ _______________________________________________________________
20 /o ) \/ Mike Taylor <mike@miketaylor.org.uk> www.miketaylor.org.uk
21 )_v__/\ "Conclusion: is left to the reader (see Table 2).
22 Acknowledgements: I wrote this paper for money" --
23 A. A. Chastel, _A critical analysis of the explanation of
24 red-shifts by a new field_, A&A 53, 67 (1976)
27 ------------------------------- cut here -------------------------------
28 Well, it looks like the CQL grammar has settled down more or less to
29 everyone's satisfaction. So it must be time to throw it all up the
32 No, I'm joking -- mostly. I'd like to point one actual mistake (I
33 think), suggest one substantive change, and request a few cosmetic
36 For anyone who's not got it to hand, the URL for the grammar is
37 http://lcweb.loc.gov/z3950/agency/zing/srwu/cql.html
39 1. I think it's a mistake that the grammar says:
40 prox-qualifiers ::= "/" [ unit ] "/" [ relation ] "/" [ distance ] "/" ordering
41 (and the similar productions that follow) because that allows
42 prox/word/exact/3 <--- "exact" is meaningless here
44 prox/word/=/stem <--- a relation-modifier!
45 (This is not only silly, but ambiguous too)
47 So I think all the occurrences of "relation" in the productions
48 for prox need to be changed to "order-or-equal-relation".
50 2. The only thing that I'm suggesting we actually _change_ is the
51 order of the proximity parameters. Quick! Close your eyes and
52 tell me the correct order of relation, ordering, distance and
53 unit? See -- you can't do it: no-one can :-)
55 So, based somewhat on Adam's rather more difficult suggestion of
56 a couple of days ago, I propose that we change the order to:
57 relation/distance/unit/ordering
58 Rationale: you can read it out loud. If you want to find two
59 clauses with the conditions "*more* than *5* *sentences* apart",
60 you would write ``foo prox/>/5/sentence bar''.
64 3a. The "/" at the beginning of each of the prox-qualfiers
65 productions can be moved up into the definition of prox, like
67 prox::= "prox" [ "/" prox-qualifiers ]
68 which yields a slightly simpler, neater (but equivalent)
71 3b. The things that the grammar called "index-name", we have been
72 calling "qualifiers" (and talking about the "qualifier-sets"
73 that contain them.) I think that's a much nicer name than
74 "index-name", in part because it doesn't carry such a loading
75 of implementation detail. Also, remember that we way we've
76 designed things, a qualifier will typically implemented by
77 multiple indexes (a word index and a string index) so I don't
78 want to give misleading impressions.
81 That would mean that, in the name of simplicity, we'd
82 need to rename "prox-qualifiers" to something like
83 "prox-modifiers" or "prox-parameters" (which is what
84 we've actually been calling them, 4WIW) and rename
85 "qualifier" to something more suggestive such as
86 "relation-modifier" (which, again, is what we've been
89 3c. (Nearly done, honest.) I think that
90 "order-or-equal-relation" is a horrible name and would much
91 prefer to call it something like "numeric-relation", which
92 better explains its role in, for example, proximity
95 So, putting it all together, here's how I think the grammar should
98 ------------------------------- cut here -------------------------------
99 cql-query ::= cql-query boolean search-clause
101 boolean ::= "and" | "or" | "not" | prox
102 search-clause ::= "(" cql-query ")"
103 | [ qualifier relation ] term
105 relation ::= base-relation { "/" relation-modifier }
106 base-relation ::= numeric-relation | "exact" | "all" | "any"
107 relation-modifier ::= "relevant" | "fuzzy" | "stem"
108 numeric-relation ::= "<" | ">" | "<=" | ">=" | "<>" | "="
110 prox ::= "prox" [ "/" prox-parameters ]
111 prox-parameters ::= [ numeric-relation ] "/" [ distance ] "/" [ unit ] "/" ordering
112 | [ numeric-relation ] "/" [ distance ] "/" unit
113 | [ numeric-relation ] "/" distance
115 unit ::= "word" | "sentence" | "paragraph" | "element"
116 ordering ::= "ordered" | "unordered"
117 distance ::= non-negative-integer
119 qualifier ::= [ qualifier-prefix "." ] qualifier-name
120 qualifier-prefix ::= identifier
121 qualifier-name ::= identifier
123 term ::= string | ""string""
124 string ::= a character string
125 ------------------------------- cut here -------------------------------
127 Hope this helps, and that it's none of it's controversial. I guess it
128 ought not to be, except maybe the change in the order of proximity
131 _/|_ _______________________________________________________________
132 /o ) \/ Mike Taylor <mike@miketaylor.org.uk> www.miketaylor.org.uk
133 )_v__/\ The IBM 360 had no stack, and that was stupid, short-sighted
134 design. The Cray 2 has no stack either, but that's elegant