archive/tests

   1 From mike  Tue May 23 08:49:36 2006
   2 X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil]
   3         ["10552" "Tuesday" "23" "May" "2006" "09:43:08" "+0200" "marc" "marc@indexdata.dk" nil "326" "SRU Server lint/tester" "^X-Spam-Status:" nil nil "5" nil nil nil nil nil nil nil nil nil]
   4         nil)
   5 Return-path: <marc@indexdata.dk>
   6 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on bagel.indexdata.dk
   7 X-Spam-Level:
   8 Envelope-to: mike@miketaylor.org.uk
   9 Delivery-date: Tue, 23 May 2006 09:43:10 +0200
  10 Received: from localhost.localdomain [127.0.0.1]
  11         by localhost with POP3 (fetchmail-6.2.5)
  12         for mike@localhost (single-drop); Tue, 23 May 2006 08:49:36 +0100 (BST)
  13 Received: from user.indexdata.dk ([213.150.43.10] helo=[10.0.1.66])
  14         by bagel.indexdata.dk with esmtp (Exim 3.35 #1 (Debian))
  15         id 1FiRXp-0004lO-00; Tue, 23 May 2006 09:43:09 +0200
  16 Message-ID: <4472BD0C.1000102@indexdata.dk>
  17 User-Agent: Debian Thunderbird 1.0.7 (X11/20051017)
  18 X-Accept-Language: en-us, en
  19 MIME-Version: 1.0
  20 References: <17522.6764.89623.774386@localhost.localdomain>
  21 In-Reply-To: <17522.6764.89623.774386@localhost.localdomain>
  22 Content-Type: text/plain; charset=UTF-8; format=flowed
  23 Content-Transfer-Encoding: 8bit
  24 X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham
  25         version=3.1.1
  26 From: marc <marc@indexdata.dk>
  27 To: Mike Taylor <mike@miketaylor.org.uk>,  adam@indexdata.dk,
  28  Ralph LeVan <levan@oclc.org>
  29 Subject: SRU Server lint/tester
  30 Date: Tue, 23 May 2006 09:43:08 +0200
  31
  32 Mike Taylor wrote:
  33 > Guys,
  34 >
  35 > Ralph's fixed his SRU-lint web-page.  It takes a few minutes to get
  36 > its head around foo.indexdata.dk, but it does manage, and has some
  37 > useful things to say.
  38 >
  39
  40
  41 Hej Ralph
  42
  43 Thanks for a fast fix of your SRU Server tester
  44 http://alcme.oclc.org/srw/SRUServerTester.html
  45 for the Alvis-Zebra SRU server URL
  46 http://foo.indexdata.dk
  47
  48 I think your SRU checker does a nice job. And it did indeed find some
  49 errors in our implementation, so we all can improve. Thanks for that!
  50
  51 I have a couple of small comments:
  52
  53
  54 1)
  55 You test scan like this:
  56
  57 http://foo.indexdata.dk?version=1.1&scanClause=rec.id+=+dog&operation=scan&responsePosition=1&maximumTerms=5
  58
  59 I think you should always add a responsePosition=3 to the mix, as there
  60 might be indexes (and there are here!) where the term 'dog' comes
  61 lexocographically after the last index entry, and you get a fat empty
  62
  63 <zs:scanResponse>
  64 <zs:version>1.1</zs:version>
  65 </zs:scanResponse>
  66
  67 But using
  68
  69 http://foo.indexdata.dk/?version=1.1&operation=scan&scanClause=rec.id+%3D+%28dog%29&responsePosition=3&maximumTerms=5&stylesheet=
  70
  71 gives you
  72
  73 <zs:scanResponse>
  74 <zs:version>1.1</zs:version>
  75 <zs:terms>
  76 <zs:term>
  77 <zs:value>FFFEBE6A0D7773AF401A728D5C818AEB</zs:value>
  78 <zs:numberOfRecords>1</zs:numberOfRecords>
  79 </zs:term>
  80 <zs:term>
  81 <zs:value>FFFF3A78648AC540304B1F50A2C0D644</zs:value>
  82 <zs:numberOfRecords>1</zs:numberOfRecords>
  83 </zs:term>
  84 </zs:terms>
  85 </zs:scanResponse>
  86
  87 By the way, an empty index is not that useful, but I think it's not
  88 necessarily an error to have one unpopulated index, so using a warning
  89 from your side is a good choice, I feel.
  90
  91
  92 2) scan relation 'exact'
  93
  94 You try
  95 http://foo.indexdata.dk?version=1.1&scanClause=rec.id+exact+dog&operation=scan&responsePosition=1&maximumTerms=5
  96
  97 with relation 'exact', but my explain never told you that the server
  98 supports relation 'exact'.
  99
 100 I think, my correct server response to this should be a fatal
 101 diagnostic, and your correct test result should have been 'diagnostic
 102 this-and-that expected'.
 103
 104 Unless it's mandatory that any index supports 'exact', in which case an
 105 error should be reported (I need to look in the specs to be sure ..)
 106
 107 3) test of search retrieve
 108
 109 You are doing a decent job here. I have a suggestion for a slight
 110 improvement: you might want to use your information from a scan in the
 111 follwing way:
 112
 113 - search for a term _not_ found in the index, and see that there are 0
 114    hits (and the response is correct)
 115
 116 - search for at term found in the scan response, and see that the number
 117    of hits equals the number of hits claimed in the scan response
 118
 119 I know, it's more work to check for numbers, but it's also a nice sanity
 120 check on top of a syntax/protocol check.
 121
 122 4) huge records: some of the records are insane huge (up to 5 MB of
 123 XML). For example you hit one here:
 124
 125 http://foo.indexdata.dk?version=1.1&query=alvis.entity-disease+=+"dominant
 126 optic atrophy"&operation=searchRetrieve&maximumRecords=1
 127
 128 You might want to test for XML response message size before doing
 129 anything else to it, and report a warning like 'response too huge to be
 130 tested, exceeds X MB of XML'
 131
 132 (I know, I should use anotheŕ default schema here, to give small
 133 records, for example the 'dc' schema. We have to improve too ..)
 134
 135 5) recordSchema
 136 In these cases, one might want to try the other record schema's to see
 137 if one get something useful there .. I did not see you testing any
 138 recordSchema of those I did mention, nor testing non-existent record
 139 schema's ..
 140
 141 6) In general, testing with wrong arguments on almost any place one can
 142 do is a good idea as well, as the hardest part of SRU/SRW is to get the
 143 diagnostics right ..  for example record position too high, or
 144 non-existing relaiton or index, non-existing operation .. ect ..
 145 (Yes, I know, this is huge work to do ..)
 146
 147 7) Finally, useability: I think it's a nice idea to have this report
 148 formatted in XHTML tables, with nice links to click on for each test
 149 case, such that one can just execute the request which did produce
 150 errors/warnings. This is of course only eye-candy, but also a cheap
 151 improvement of useability.
 152
 153
 154 Still, I think  you did a very decent job, and created  a very useful
 155 service. I thank for the problems discovered with my service. I have
 156 some programming to do as well ..
 157
 158
 159 Marc Cromme
 160
 161 Index Data
 162
 163 > ------- start of forwarded message -------
 164 > Return-path: <levan@oclc.org>
 165 > X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on bagel.indexdata.dk
 166 > X-Spam-Level:
 167 > Envelope-to: mike@miketaylor.org.uk
 168 > Delivery-date: Mon, 22 May 2006 21:07:05 +0200
 169 > Received: from localhost.localdomain [127.0.0.1]
 170 >       by localhost with POP3 (fetchmail-6.2.5)
 171 >       for mike@localhost (single-drop); Mon, 22 May 2006 20:56:19 +0100 (BST)
 172 > Received: from mshieldserver1.oclc.org ([132.174.29.209])
 173 >       by bagel.indexdata.dk with smtp (Exim 3.35 #1 (Debian))
 174 >       id 1FiFk9-0005kc-00
 175 >       for <mike@miketaylor.org.uk>; Mon, 22 May 2006 21:07:05 +0200
 176 > Received: From OAEXCH2SERVER.oa.oclc.org ([132.174.29.222]) by mshieldserver1.oclc.org (WebShield SMTP v4.5 MR2);
 177 >       id 1148324788949; Mon, 22 May 2006 15:06:28 -0400
 178 > X-MimeOLE: Produced By Microsoft Exchange V6.5
 179 > Content-class: urn:content-classes:message
 180 > MIME-Version: 1.0
 181 > Content-Type: text/plain;
 182 >       charset="us-ascii"
 183 > Content-Transfer-Encoding: quoted-printable
 184 > Message-ID: <811A02A11096B343880D2EEF72C4C83202FCD5E9@OAEXCH2SERVER.oa.oclc.org>
 185 > X-MS-Has-Attach:
 186 > X-MS-TNEF-Correlator:
 187 > Thread-Topic: [Adam Dickmeiss: Re: [Tech-alert] SRU Server lint/tester]
 188 > thread-index: AcZ7Hk4E9wk02cosR0uT69PyXob4kACsz3fA
 189 > X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
 190 >       version=3.1.1
 191 > From: "LeVan,Ralph" <levan@oclc.org>
 192 > To: "Mike Taylor" <mike@miketaylor.org.uk>
 193 > Subject: RE: [Adam Dickmeiss: Re: [Tech-alert] SRU Server lint/tester]
 194 > Date: Mon, 22 May 2006 15:06:28 -0400
 195 >
 196 > Let's just pretend I didn't send that last email, okay?
 197 >
 198 > So, lovely Explain records we're having today!
 199 >
 200 > I've fixed the blow up.  You've got a couple of searches that return
 201 > very large records that I think are peculiar.  Your stylesheet can't
 202 > render them and I report that I'm getting an error 400 from them.
 203 >
 204 > Run the test against the server again and let me know if there's
 205 > something more I should be doing.
 206 >
 207 > Thanks, Mike!
 208 >
 209 > Ralph
 210 >
 211 >
 212 >>-----Original Message-----
 213 >>From: Mike Taylor [mailto:mike@miketaylor.org.uk]
 214 >>Sent: Friday, May 19, 2006 4:29 AM
 215 >>To: LeVan,Ralph
 216 >>Subject: [Adam Dickmeiss: Re: [Tech-alert] SRU Server lint/tester]
 217 >>=20
 218 >>Hi, Ralph.  FYI, it seems that your SRU lint barfs on our server.
 219 >>=20
 220 >>------- start of forwarded message -------
 221 >>Return-path: <tech-alert-bounces@lists.indexdata.dk>
 222 >>X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on
 223 >>bagel.indexdata.dk
 224 >>X-Spam-Level:
 225 >>Envelope-to: mike@indexdata.com
 226 >>Delivery-date: Thu, 18 May 2006 18:38:14 +0200
 227 >>Received: from localhost.localdomain [127.0.0.1]
 228 >>      by localhost with POP3 (fetchmail-6.2.5)
 229 >>      for mike@localhost (single-drop); Thu, 18 May 2006 17:49:11
 230 >
 231 > +0100
 232 >
 233 >>(BST)
 234 >>Received: from kebab.indexdata.dk ([83.133.64.60])
 235 >>      by bagel.indexdata.dk with esmtp (Exim 3.35 #1 (Debian))
 236 >>      id 1FglVt-0007y3-00; Thu, 18 May 2006 18:38:13 +0200
 237 >>Received: from localhost ([127.0.0.1] helo=3Dkebab.indexdata.dk)
 238 >>      by kebab.indexdata.dk with esmtp (Exim 4.50)
 239 >>      id 1FglVU-0001I6-DK; Thu, 18 May 2006 18:37:48 +0200
 240 >>Received: from user.indexdata.dk ([213.150.43.10]
 241 >
 242 > helo=3Dbagel.indexdata.dk)
 243 >
 244 >>      by kebab.indexdata.dk with esmtp (Exim 4.50) id 1FglUy-0001Hv-WF
 245 >>      for tech-alert@lists.indexdata.dk; Thu, 18 May 2006 18:37:36
 246 >
 247 > +0200
 248 >
 249 >>Received: from dickmeiss.net ([213.173.244.115] helo=3D[10.0.0.18])
 250 >>      by bagel.indexdata.dk with esmtp (Exim 3.35 #1 (Debian))
 251 >>      id 1FglUj-0007QK-00
 252 >>      for <tech-alert@lists.indexdata.dk>; Thu, 18 May 2006 18:37:01
 253 >
 254 > +0200
 255 >
 256 >>Message-ID: <446CA2AC.1030200@indexdata.dk>
 257 >>User-Agent: Thunderbird 1.5.0.2 (X11/20060501)
 258 >>MIME-Version: 1.0
 259 >>References: <446C8BB1.6080206@indexdata.dk>
 260 >>In-Reply-To: <446C8BB1.6080206@indexdata.dk>
 261 >>Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
 262 >>Content-Transfer-Encoding: 7bit
 263 >>X-BeenThere: tech-alert@lists.indexdata.dk
 264 >>X-Mailman-Version: 2.1.5
 265 >>Precedence: list
 266 >>Reply-To: Announcements/discussion of interesting technology
 267 >>      <tech-alert@lists.indexdata.dk>
 268 >>List-Id: Announcements/discussion of interesting technology
 269 >>      <tech-alert.lists.indexdata.dk>
 270 >>List-Unsubscribe: <http://lists.indexdata.dk/cgi-
 271 >>bin/mailman/listinfo/tech-alert>,
 272 >>
 273 >
 274 > <mailto:tech-alert-request@lists.indexdata.dk?subject=3Dunsubscribe>
 275 >
 276 >>List-Archive: <http://lists.indexdata.dk/cgi-bin/mailman/private/tech-
 277 >>alert>
 278 >>List-Post: <mailto:tech-alert@lists.indexdata.dk>
 279 >>List-Help: =
 280 >
 281 > <mailto:tech-alert-request@lists.indexdata.dk?subject=3Dhelp>
 282 >
 283 >>List-Subscribe:
 284 >
 285 > <http://lists.indexdata.dk/cgi-bin/mailman/listinfo/tech-
 286 >
 287 >>alert>,
 288 >>      <mailto:tech-alert-request@lists.indexdata.dk?subject=3Dsubscribe>
 289 >>Errors-To: tech-alert-bounces@lists.indexdata.dk
 290 >>X-SA-Exim-Connect-IP: 127.0.0.1
 291 >>X-SA-Exim-Mail-From: tech-alert-bounces@lists.indexdata.dk
 292 >>X-SA-Exim-Scanned: No (on kebab.indexdata.dk); SAEximRunCond expanded
 293 >
 294 > to
 295 >
 296 >>false
 297 >>X-Spam-Status: No, score=3D-2.5 required=3D5.0 tests=3DAWL,BAYES_00,
 298 >>      FORGED_RCVD_HELO autolearn=3Dham version=3D3.1.1
 299 >>From: Adam Dickmeiss <adam@indexdata.dk>
 300 >>Sender: tech-alert-bounces@lists.indexdata.dk
 301 >>To: Announcements/discussion of interesting technology
 302 >>      <tech-alert@lists.indexdata.dk>
 303 >>Subject: Re: [Tech-alert] SRU Server lint/tester
 304 >>Date: Thu, 18 May 2006 18:37:00 +0200
 305 >>=20
 306 >>marc wrote:
 307 >>
 308 >>>SRU Server tester
 309 >>>
 310 >>>Try it: surf into
 311 >>>http://alcme.oclc.org/srw/SRUServerTester.html
 312 >>>
 313 >>>and give the Alvis-Zebra SRU server URL
 314 >>>http://foo.indexdata.dk
 315 >>>into the box.
 316 >>>
 317 >>>Have fun!
 318 >>
 319 >>Sort of. I get a big Java runtime exception. Nice.
 320 >>=20
 321 >>/ Adam
 322 >>=20
 323 >>
 324 >>>Marc
 325 >>>
 326 >>
 327 >>=20
 328 >>=20
 329 >>_______________________________________________
 330 >>Tech-alert mailing list
 331 >>Tech-alert@lists.indexdata.dk
 332 >>http://lists.indexdata.dk/cgi-bin/mailman/listinfo/tech-alert
 333 >>------- end of forwarded message -------
 334 >
 335 > ------- end of forwarded message -------
 336
 337
 338 --
 339
 340 Marc Cromme, cand. polyt, Ph.D
 341 Senior Developer, Project Manager
 342
 343 Index Data Aps
 344 Købmagergade 43, 2
 345 1150 Copenhagen K.
 346 Denmark
 347
 348 tel: +45 3341 0100
 349 fax: +45 3341 0101
 350
 351 http://www.indexdata.com
 352
 353 INDEX DATA Means Business
 354 for Open Source and Open Standards
 355
 356
 357
 358