Skip
repetitive navigational links
L-Soft  -  Home of  the  LISTSERV  mailing list  manager LISTSERV(R) 14.5
Skip repetitive navigational links
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (January 2002)Back to main ZNG pageJoin or leave ZNGReplyPost a new messageSearchProportional fontNon-proportional fontLog in
Date:         Thu, 10 Jan 2002 15:54:34 -0500
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Ray Denenberg <[log in to unmask]>
Organization: Library Of Congress
Subject:      Re: Betr.: Re: test server SRU
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type: multipart/alternative;

On the question of whether an SRU response should be wrapped in SOAP, I looked at the original ZNG document at http://www.loc.gov/z3950/agency/zng.html (July 12). It says: "Description of Search/Retrieve: The Search/Retrieve request may be submitted either as a URL or as an XML record wrapped in SOAP. The response will always be an XML record, possibly with embedded database records. (If the response was to a SOAP request, then it will have a SOAP wrapper also.)" So it doesn't say it explicitly but I think we can infer that the intention was that no, an SRU response should not have a SOAP wrapper. --Ray Theo van Veen wrote: > It seems that an important difference between SRU and SRW is indeed the goals that we have in mind. The separation between SRU and SRW however makes it now more acceptable to allow for different goals and it also makes it easier to differentiate in choices that are good for one of both protocols but are not good for the other. > > As fa as the SOAP-envelop is concerned. It is not needed for SRU, but it was suggested earlier to use this envelope for the purpose of compatabilty. If it is agreed that URL-based requests will not return a SOAP-envelope we will remove this envelope. > > As far as the other issues are concerned I haven't formulated an opinion yet as I am not really aware of the restrictions of WSDL and SOAP-toolkits with respect to my prereferences. > > Theo > > > >>> [log in to unmask] 08-01-02 23:55 >>> > On Tue, Jan 08, 2002 at 02:36:26PM -0500, Larry E. Dixson wrote: > > Theo, > > I wanted to report that I was able to successfully retrieve and > > display records from your test server. > > > > For example: > > http://redbelly.bk.nl/cgi-zoek/srw.pl?query=vrml&recordSchema=dc_record&collection=DUTC > > retrieved the following: > > > > <SOAP-ENV:Envelope xmlns:zng="urn:z3950:zng_prototype1" xmlns:SOAP- > > ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP- > > ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> > > <SOAP-ENV:Body> > > <zng:searchRetrieveResponse> > > <zng:resultSetReference> > > <zng:resultSetName>200218.108.kqf</zng:resultSetName> > > </zng:resultSetReference> > > <zng:totalHits>1</zng:totalHits> > > <zng:query>vrml</zng:query> > > <zng:setLimit>3000</zng:setLimit> > > <zng:records> > > <zng:record> > > <zng:recordNumber>0</zng:recordNumber> > > <zng:recordId>DUTC:4612</zng:recordId> > > <zng:schema>dc_record</zng:schema> > > <zng:recordData> > > <rdf:Description xmlns:dc="http://purl.org/dc/elements/1.1/" > > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns"> > > <dc:creator>Margulies, Stephen</dc:creator> > > <dc:creator>Bauman, Johanna</dc:creator> > > <dc:title>The power of woe, the power of life : Images of > > women in prints from the Renaissance to the > > present</dc:title> > > <dc:date>1999</dc:date> > > </rdf:Description> > > </zng:recordData> > > </zng:record> > > </zng:records> > > <zng:status> > > <zng:statusCode>0</zng:statusCode> > > </zng:status> > > </zng:searchRetrieveResponse> > > </SOAP-ENV:Body> > > </SOAP-ENV:Envelope> > > First its great to see people having a go at implementing things. So I > am not trying to criticise - just work out issues as we go along. > > But I am a little confused - mainly about goals. I don't have any > immediate plans for SRU (that is, the URL version). But the above > response packet seems to be a mix of SOAP and other things. > > For example, I believe with *SOAP* (and SRW) that the most robust > approach for recordData is going to be as a string (I may be wrong). > As such, all the tags would need to be released with &lt; etc inside > the <zng:recordData> element. One reason was that SOAP does not > permit all of XML - for example processing instructions are > not permitted in SOAP, so to allow all valid XML records inside SOAP, > using string is the safest way to go. > > The thing with SOAP is that if you use a toolkit, the fact that > SOAP uses XML to encode packets is irrelevant. No-one looks at > SOAP packets. SOAP has lots of weird decoding rules that mean > you would never want to apply an XSLT style sheet to a SOAP packet. > Also, only a subset of the SOAP toolkits support document/literal > encoding (which is the closest thing to the packet above). > So its not an ideal choice in terms of implementations. > So I recommend putting XML in SOAP as a string and let the application > parse the string as XML. > > But for SRU it is clearly very useful to return records as XML. > So I think its probably wrong to put SOAP-ENV:Body and SOAP-ENV:Envelope > wrappers around the whole packet. > > Maybe what should be done is to define XML schemas for the data > structures, where the schema is reused between WSDL (for SOAP) > and SRU (the URL scheme). But its important to realise that in > SOAP a WSDL schema *does not* define the wire representation of > XML in SOAP packets (confusing, possibly stupid, but true). It > defines an abstract data structure that SOAP then defines its > own encoding rules for (unless you use document/literal encoding). > > I have previously put forward the opinion that using strings for > record data is the best approach with SOAP. > > However, there is the alternative of document/literal encoding. > One alternative approach that has some attractiveness is to say > - use document/literal encoding for record data > - require that all record data in SRW/SRU have an XML schema defined > - don't allow record data to contain processing instructions > > I guess put another way, do people want to be able to insert arbitary > XML documents in as record data to be returned, or is it acceptable > to say with SRW/U that record data must have an XML schema defined > and PI's are not supported. > > Oh, there is another ramification by the way - do we want a single > WSDL file (for SRW/SOAP anyway) that represents SRW? If so, then > record XML schemas cannot go in there - because you will have a > different WSDL file per record XML schema. So there will be no > standard file. If you make recordData a string, then you can have > a single standard WSDL file for SRW. > > I personally still lean towards a single SRW WSDL file, possible > only by using string for record data (unless someone can show me how!). > In that case, maybe SRU should be based on use of XML schemas and > not WSDL files. I thought SRU was for people without SOAP toolkits > around (just a HTTP client), so you want nice clean XML coming back, > not complex SOAP packets. > > Alan


[text/html]


Back to: Top of message | Previous page | Main ZNG page

LISTSERV.LOC.GOV CataList email list search Powered by LISTSERV email list manager