SimpleServer and GRS1 output.

Hi.

I have used SimpleServer to create an application capable of
merging 
result sets from a number of different servers. Internally I
use the 
ZOOM module to query the underlying server. In some cases I
need to 
return records in GRS1 format, and I simply do a

$args-> = $set->record($pos)->render();

Output from the render() method might be something like
this:

(3,localInfo)
     (3,source) elsevier
     (3,media) electronic
     (3,fullTxtRef)
/elsevier/ohl0163a/03014207/sz974452/97000354.pdf
     (3,cdate) 20000623
     (3,udate) 20010514
     (3,fileId) ohl0163a
     (3,orderRef) /elsevier/03014207/1997/23/4/0
     (3,key) 03014207199723418573313546919
(3,recordID)
     (3,artId) S0301-4207(97)00035-4
     (3,recTypeNr) 02
     (3,recTypeTxt) journal article
(3,article)
     (3,title) The Hotelling valuation of natural resources:
some 
further results
(3,abstract)
     (3,abstract) This paper tests the Hotelling Valuation
Principle 
(HVP) for natural resources using data from oil and gas
"pure plays" 
such as royalty trusts and master limited partnerships. The
results 
support the HVP which specifies that the value of any
mineral reserve 
may be predicted by the market price of the resource, net of
extraction 
costs. Regression results also indicate that a Box-Cox
transformation of 
variables provide a better means of estimating the
functional 
relationship between the value of an exhaustible natural
resource and 
its market price.
(3,author)
     (3,name) Jamal, A M M
(3,author)
     (3,name) Crain, John L
(3,journal)
     (3,issn) 03014207
     (3,title) Resources Policy
     (3,vol) 23
     (3,issue) 4
     (3,year) 1997
     (3,month) 12
     (3,page) 187-190
(3,ctrlT)
     (3,term) Hotelling Valuation Principle
     (3,term) natural resources
     (3,term) Box-Cox transformation



But on the client side this is what I get:

(3,localInfo)
(3,source) elsevier
(3,media) electronic
(3,fullTxtRef)
/elsevier/ohl0163a/03014207/sz974452/97000354.pdf
(3,cdate) 20000623
(3,udate) 20010514
(3,fileId) ohl0163a
(3,orderRef) /elsevier/03014207/1997/23/4/0
(3,key) 03014207199723418573313546919
(3,recordID)
(3,artId) S0301-4207(97)00035-4
(3,recTypeNr) 02
(3,recTypeTxt) journal article
(3,article)
(3,title) The Hotelling valuation of natural resources: some
further results
(3,abstract)
(3,abstract) This paper tests the Hotelling Valuation
Principle (HVP) 
for natural resources using data from oil and gas "pure
plays" such as 
royalty trusts and master limited partnerships. The results
support the 
HVP which specifies that the value of any mineral reserve
may be 
predicted by the market price of the resource, net of
extraction costs. 
Regression results also indicate that a Box-Cox
transformation of 
variables provide a better means of estimating the
functional 
relationship between the value
(3,author)
(3,name) Jamal, A M M
(3,author)
(3,name) Crain, John L
(3,journal)
(3,issn) 03014207
(3,title) Resources Policy
(3,vol) 23
(3,issue) 4
(3,year) 1997
(3,month) 12
(3,page) 187-190
(3,ctrlT)
(3,term) Hotelling Valuation Principle
(3,term) natural resources
(3,term) Box-Cox transformation

The nesting has suddenly disappeared. Am I doing something
wrong, or has 
the SimpleServer somehow altered the record along the way?

Kind regards,
-- 
Jan

_______________________________________________
Net-z3950 mailing list
Net-z3950lists.indexdata.dk
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/n
et-z3950

Jan Bauer Nielsen wrote:
> Hi.
> 
> I have used SimpleServer to create an application
capable of merging 
> result sets from a number of different servers.
Internally I use the 
> ZOOM module to query the underlying server. In some
cases I need to 
> return records in GRS1 format, and I simply do a
> 
> $args-> =
$set->record($pos)->render();
>

So the $set variable is a ZOOM result set object, right?
You cannot just return a rendered version of a GRS-1 record
to the 
client and expect that it can figure out that it is a GRS-1
record.

First of all, you have to specify that the returned record
is of the 
type GRS-1. This you specify using the REP_FORM member of
the hash 
table, i.e.

   $args-> = Net::Z3950::OID::grs1

But I'm afraight that this is not enough. The record buffer
you return 
should actually be in GRS-1 format - i.e. a binary format -
not just the 
human-readable version you get from the render() method.
Instead try 
using the Net::Z3950::GRS1 package. It was written for
testing purposes 
only many years ago and it is experimental. But feel free to
try it on 
your own risk.

Cheers,

--Anders


> Output from the render() method might be something like
this:
> 
> (3,localInfo)
>     (3,source) elsevier
>     (3,media) electronic
>     (3,fullTxtRef)
/elsevier/ohl0163a/03014207/sz974452/97000354.pdf
>     (3,cdate) 20000623
>     (3,udate) 20010514
>     (3,fileId) ohl0163a
>     (3,orderRef) /elsevier/03014207/1997/23/4/0
>     (3,key) 03014207199723418573313546919
> (3,recordID)
>     (3,artId) S0301-4207(97)00035-4
>     (3,recTypeNr) 02
>     (3,recTypeTxt) journal article
> (3,article)
>     (3,title) The Hotelling valuation of natural
resources: some further 
> results
> (3,abstract)
>     (3,abstract) This paper tests the Hotelling
Valuation Principle 
> (HVP) for natural resources using data from oil and gas
"pure plays" 
> such as royalty trusts and master limited partnerships.
The results 
> support the HVP which specifies that the value of any
mineral reserve 
> may be predicted by the market price of the resource,
net of extraction 
> costs. Regression results also indicate that a Box-Cox
transformation of 
> variables provide a better means of estimating the
functional 
> relationship between the value of an exhaustible
natural resource and 
> its market price.
> (3,author)
>     (3,name) Jamal, A M M
> (3,author)
>     (3,name) Crain, John L
> (3,journal)
>     (3,issn) 03014207
>     (3,title) Resources Policy
>     (3,vol) 23
>     (3,issue) 4
>     (3,year) 1997
>     (3,month) 12
>     (3,page) 187-190
> (3,ctrlT)
>     (3,term) Hotelling Valuation Principle
>     (3,term) natural resources
>     (3,term) Box-Cox transformation
> 
> 
> 
> But on the client side this is what I get:
> 
> (3,localInfo)
> (3,source) elsevier
> (3,media) electronic
> (3,fullTxtRef)
/elsevier/ohl0163a/03014207/sz974452/97000354.pdf
> (3,cdate) 20000623
> (3,udate) 20010514
> (3,fileId) ohl0163a
> (3,orderRef) /elsevier/03014207/1997/23/4/0
> (3,key) 03014207199723418573313546919
> (3,recordID)
> (3,artId) S0301-4207(97)00035-4
> (3,recTypeNr) 02
> (3,recTypeTxt) journal article
> (3,article)
> (3,title) The Hotelling valuation of natural resources:
some further 
> results
> (3,abstract)
> (3,abstract) This paper tests the Hotelling Valuation
Principle (HVP) 
> for natural resources using data from oil and gas
"pure plays" such as 
> royalty trusts and master limited partnerships. The
results support the 
> HVP which specifies that the value of any mineral
reserve may be 
> predicted by the market price of the resource, net of
extraction costs. 
> Regression results also indicate that a Box-Cox
transformation of 
> variables provide a better means of estimating the
functional 
> relationship between the value
> (3,author)
> (3,name) Jamal, A M M
> (3,author)
> (3,name) Crain, John L
> (3,journal)
> (3,issn) 03014207
> (3,title) Resources Policy
> (3,vol) 23
> (3,issue) 4
> (3,year) 1997
> (3,month) 12
> (3,page) 187-190
> (3,ctrlT)
> (3,term) Hotelling Valuation Principle
> (3,term) natural resources
> (3,term) Box-Cox transformation
> 
> The nesting has suddenly disappeared. Am I doing
something wrong, or has 
> the SimpleServer somehow altered the record along the
way?
> 

The line



-- 
--------------------------------------------------------
Anders Sønderberg Mortensen
sondbergindexdata.dk            http://www.indexdata.dk
Index Data     Ph.: +45 3341 0105     Fax: +45 3341 0101
--------------------------------------------------------


_______________________________________________
Net-z3950 mailing list
Net-z3950lists.indexdata.dk
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/n
et-z3950

Jan Bauer Nielsen writes:
 > I have used SimpleServer to create an application
capable of merging 
 > result sets from a number of different servers.
Internally I use the 
 > ZOOM module to query the underlying server. In some
cases I need to 
 > return records in GRS1 format, and I simply do a
 > 
 > $args-> =
$set->record($pos)->render();
 > 
 > Output from the render() method might be something
like this:
 > 
 > (3,localInfo)
 >      (3,source) elsevier
 >      (3,media) electronic
 >      (3,fullTxtRef)
/elsevier/ohl0163a/03014207/sz974452/97000354.pdf
 > [...]
 > 
 > But on the client side this is what I get:
 > 
 > (3,localInfo)
 > (3,source) elsevier
 > (3,media) electronic
 > (3,fullTxtRef)
/elsevier/ohl0163a/03014207/sz974452/97000354.pdf
 > [...]
 > 
 > The nesting has suddenly disappeared. Am I doing
something wrong,
 > or has the SimpleServer somehow altered the record
along the way?

The best way to find out what's going on here is to generate
an APDU
dump, which tells you the True Story of what's happening on
the wire.

Please connect to your SimpleServer-based merging server
using
	yaz-client -a apdulog the.address.of.your:201/server
do a search and a retrieval, exit yaz-client, and email me
the
generated file "apdulog".  Then we'll see what's
going on.  One
possibility is that the record is being built and
transferred just
fine, but the client is displaying it wrongly.

We may as well come out and admit that the GRS-1 handing in
SimpleServer is pretty iniquitous: there are no Perl
structures
defined to represent a GRS-1 record, so the only
representation is a
string containing the rendered record, as in your first
example above
-- the only way to get SimpleServer to return GRS-1 is by
making up a
rendered record and returning it for the glue-code to
re-parse and
build into C-level GRS-1 structures for serialisation. 
This
re-parsing is obviously error-prone.  I think we would have
fixed it
ages ago if we'd known anyone who was still using GRS-1 

 _/|_	
____________________________________________________________
_______
/o ) /  Mike Taylor    <mikeindexdata.com>    http://www.miketaylor.or
g.uk
)_v__/  "America is not really a melting pot [...]
America is a bunch
	 of different groups that, when times aren't so good, don't
get
	 on so well" -- Paul Simon.



_______________________________________________
Net-z3950 mailing list
Net-z3950lists.indexdata.dk
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/n
et-z3950