[Reddes.bvs-tech] problem with using non-standard wxis with isisxml-function in OAI

De Smet Egbert egbert.desmet at uantwerpen.be
Wed Dec 17 10:44:17 BRST 2014


Hi,

as we are testing ISIS-OAI-Provider (for a new ABCD-release) we stumbled over the following problem : when using a non-standard wxis (e.g. BigISIS or FFI), adding this as the 'isis_key_length' in the oai-databases.php with the line :
isis_key_length=bi
or
isis_key_length=ffi
and copying the BigISIS or FFI wxis.exe as resp. wxisbi.exe or wxisffi.exe in the oai-isis-provider cgi-bin folder (all this as per the instructions), the verbs work well, including the 'listrecords', but in that one we have the following special result :
- the identifier is correctly read from the database-records (proving that the right wxisbi.exe or wxisffi.exe is used)
- the metadata fields (taken from a file .i2x) however give the error :
|fatal error|unavoidable|recread/check/base|
which means that the wrong wxis was used, whereas it is supposed to be the same one as for the identifier-field (which worked well).
Now, the difference is that, as I suppose (but a lot of documentation is still missing...)  for the identifier-field the IsisScript 'getidentifiers.xis' is used and for the metadata the 'getrecord.xis' IsisScript. The difference is that in the first case no isisxml is used and in the second case it is used.
So my suspicion is for something to be wrong with the isisxml code and non-standard wxis. This is supported by another long-standing problem which we have reported on earlier without any reaction : also the XML-parser runs into empty output when calling non-standard wxis from the BVS Site (whereas the same wxis.exe works very well when called directly in iAH with the same database). So I suppose this might be based on the same issue and a solution would therefore be even more welcome as it would solve two problems in one catch.

Thanks for your attention and hoping someone at BIREME/BVS can look into this,


Egbert de Smet
Universiteit Antwerpen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas2.bireme.br/pipermail/reddes.bvs-tech/attachments/20141217/7ab1c9d9/attachment.html>


More information about the Reddes.bvs-tech mailing list