[OAI-implementers] Trying to gauge interest on two features

[Sandro Zic]

herbert van de sompel wrote:
> Sandro Zic wrote:
>>Has a kind of SOAP-OAI already been implemented somewhere or discussed
>>on this
>>list?
> 
> When working on version 2.0 of the OAI-PMH we have decided to stick to the HTTP
> GET approach used in versions 1.x, but have made sure that the protocol responses
> would be SOAP-ready.  I know some OAI-implementers have done SOAP-related
> experiments, and I guess they will reply to the list to detail such work.  With
> the OAI, we plan to create a spec for a SOAP version of the OAI-PMH, but so far
> no concrete schedule has been set with this respect.  However, I expect/hope that
> this work would start in the course of 2003.

Actually, I am a REST advocate so I can happily live with the OAI-PMH 
approach ;) Nevertheless, SOAP and related technologies offer a broader 
variety of applicances, especially with WSDL, support of various 
protocols (HTTP, SMTP, TCP/IP, etc.), SOAP attachments, and so on. 
Hence, SOAP is better suited if you implement OAI related harvesting 
technologies in heterogenous or business environments, who very often 
follow the Web Services Hype.

I would very much be interested in best practices to implement a SOAP 
wrapper to an OAI data provider. For example:

How to pass the OAI arguments or how should the method signature look 
like? Do you prefer passing an associative array containing all 
arguments with the OAI arguments as the keys or each argument at a 
certain place in the method signature?

What does a remote procedure call return? Simply the complete OAI 
response as a string? A struct with the OAI header split to several 
values and e.g. the metadata from a getRecord() call in another 
parameter of the struct?

How about integrating OAI error responses and SOAP faults?

Thanks for any feedback,
Sandro