RE: [search-ws] RE: content-type for Zeerex/Explain

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

Ok, I see this more clearly now, the explainResponse in srwTypes looks like
this:


<xsd:complexType name="explainResponseType">
    <xsd:complexContent>
      <xsd:extension base="responseType">
        <xsd:sequence>
          <xsd:element ref="record"/>
          <xsd:element ref="echoedExplainRequest" minOccurs="0"/>
          <xsd:element ref="diagnostics" minOccurs="0"/>
          <xsd:element ref="extraResponseData" minOccurs="0"/>
        </xsd:sequence>
      </xsd:extension>
    </xsd:complexContent>


So what that means is that it treats the actual explain record ("record")
just like a normal response treats a database record, which means it could
be anything.  But of course it can't, it needs to be an explain record - as
contrasted with a normal response where a record could be DC, mods, marcxml,
etc. and so the schema doesn't try to define it, it leaves it as an
external.

Do we want to take the same approach for Explain? That is, put the
explainResponse in the schema (as above) and define record externally, with
the possibility that the explain payload could take on one of many different
formats? (I realize, nobody uses any different formats now, but they could.)

I don't have any problem with this approach if that's what we want to do.

--Ray




-----Original Message-----
From: Hammond, Tony [mailto:t.hammond@nature.com] 
Sent: Tuesday, June 29, 2010 11:36 AM
To: Denenberg, Ray; 'OASIS SWS TC'
Subject: Re: [search-ws] RE: content-type for Zeerex/Explain

Hi Ray:

> Good question. srw-types seems to give the illusion that it supports 
> the Explain response but I can't see any substantive explain information
in it.

I think you might be confusing the explain response type with the zeerex
payload. So the SRU explain operation returns an application/sru+xml
response (from standard 1.* schema srw-types.xsd). The record payload
happens to be zeerex-2.0.xsd.

[[
Interestingly, I suppose in analogy to the searchRetrieve record data the
explain record data could vary, e.g. An OpenSearch description??
]] 

But point is the at the wrapper is the explain response, and the contents
the zeerex description of indexes, relations and whatnot, see example from
our 1.* response below.

So it seems to me we should be doing likwise in 2.* and maintainting one
schema and one media type.

Cheers,

Tony





<?xml version="1.0" ?>
<?xml-stylesheet type="text/xsl"
href="/opensearch/common/xsl/explainResponse.xsl"?>
<srw:explainResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.loc.gov/zing/srw/
http://www.loc.gov/standards/sru/sru1-1archive/xml-files/srw-types.xsd";
xmlns:srw="http://www.loc.gov/zing/srw/";>
    <srw:version>1.1</srw:version>
    <srw:record>
        
<srw:recordSchema>http://explain.z3950.org/dtd/2.0/</srw:recordSchema>
        <srw:recordPacking>xml</srw:recordPacking>
        <srw:recordData>
            <zr:explain authoritative="true"
xmlns:zr="http://explain.z3950.org/dtd/2.0/";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://explain.z3950.org/dtd/2.0/
http://www.loc.gov/standards/sru/resources/zeerex-2.0.xsd";>
...
            </zr:explain>
        </srw:recordData>
    </srw:record>
</srw:explainResponse>


On 29/6/10 16:23, "Ray Denenberg, Library of Congress" <rden@loc.gov> wrote:

> " Isn't this what we had before (srw-types.xsd)?"
> 
> Good question. srw-types seems to give the illusion that it supports 
> the Explain response but I can't see any substantive explain information
in it.
> 
> As to the question of one schema or many, I just don't see what it 
> buys us to cram all the operations into one schema  - other than the 
> fact that we either need to cram Explain into the schema or else get 
> it a separate content type. But we certainly don't need a content type 
> for Scan, at least not for any reason that has surfaced yet.
> 
> And the more different entries you put into a schema for a content 
> type, the more you weaken the content type, it seems to me.  That is, 
> if you have a document that you claim is type application/sru+xml, 
> then the recipient of that document might be happier if he could 
> determine from that content type that it is an SRU response, rather 
> than that it is one of three possibilities, an SRU response, an 
> Explain response, or a Scan response, and have to open it up to find out
which one it is.
> 
> --Ray
> 
> 
> 
> -----Original Message-----
> From: Hammond, Tony [mailto:t.hammond@nature.com]
> Sent: Tuesday, June 29, 2010 10:43 AM
> To: Denenberg, Ray; 'OASIS SWS TC'
> Subject: Re: [search-ws] RE: content-type for Zeerex/Explain
> 
>> Similarly, if we let the SRU content type apply to both cases (SRU 
>> response and Explain) then do we need to include the Explain schema 
>> as part of the SRU response schema?
> 
> Isn't this what we had before (srw-types.xsd)?
> 
> And is there any reason not to continue to have one schema for the 
> three operations rather than one schema per operation (per endpoint 
> (per version))?
> 
> When you say SRU Response does that include or exclude 'scan"? Or was 
> the idea to have searchRetireve/explain at one endpoint and 
> scan/explain at another endpoint?
> 
> Tony
> 
> 
> 
> On 29/6/10 15:14, "Ray Denenberg, Library of Congress" <rden@loc.gov>
wrote:
> 
>> " Doesn't Atom specify a single schema but with two entry points (i.e.
>> Feed and Entry)?"
>> 
>> Which is another way of saying, the ATOM content type defintion says 
>> that if you claim that a document is of that type then it is supposed 
>> to be a valid instance of that schema (i.e. it is has one or the 
>> other root, 'feed' or 'entry').
>> 
>> Similarly, if we let the SRU content type apply to both cases (SRU 
>> response and Explain) then do we need to include the Explain schema 
>> as part of the SRU response schema?
>> 
>> -Ray
>> 
>> 
>> -----Original Message-----
>> From: Hammond, Tony [mailto:t.hammond@nature.com]
>> Sent: Tuesday, June 29, 2010 9:53 AM
>> To: LeVan,Ralph; Ray Denenberg; OASIS SWS TC
>> Subject: Re: [search-ws] RE: content-type for Zeerex/Explain
>> 
>> I agree in principle but maybe not with the specifics. ;)
>> 
>>> All Atom data is passed with the media type of application/atom+xml.
>> 
>> Doesn't Atom specify a single schema but with two entry points (i.e.
>> Feed and Entry)?
>> 
>> But I do think that one media type is more than enough for SRU. Let's 
>> face it anyway, any application that knows what application/sru+xml 
>> is will know how to distinguish between 1) explain, 2) 
>> searchRetrieve, and 3)
> scan.
>> 
>> I note also that we're talking about difference between explain and 
>> searchRetrieve. But whatever happened to scan? Is that also supposed 
>> to be in the response schema (as used to be). In fact, didn't 
>> srw-types.xsd already have multiple entry points for
> explain/searchRetrieve/scan?
>> 
>> And we don't really want a proliferatiopn of SRU media types. Who 
>> would ever get around to using them all? ;)
>> 
>> Btw, I note that OpenSearch has one media type for description and 
>> none for responses because it does not define any native responses. 
>> So the fact that the descriotion doc and response types have 
>> different media types isn't really an issue.
>> 
>> Tony
>> 
>> 
>> 
>> On 29/6/10 14:40, "LeVan,Ralph" <levan@oclc.org> wrote:
>> 
>>> All Atom data is passed with the media type of application/atom+xml.
>>> I don't see a problem with us following the same pattern.  It's not 
>>> like we're trying to use the media type to distinguish between SRU 
>>> operations.
>>> 
>>> Ralph
>>> 
>>>> -----Original Message-----
>>>> From: Ray Denenberg [mailto:raydenenberg@starpower.net]
>>>> Sent: Monday, June 28, 2010 5:44 PM
>>>> To: 'OASIS SWS TC'
>>>> Subject: [search-ws] RE: content-type for Zeerex/Explain
>>>> 
>>>> I wish to follow up on this discussion.
>>>> 
>>>> Do we really want to piggyback on the content type
>>> 'application/sru+xml'?
>>>> Yes, it will work, but is it an awful cludge or an  acceptable
>>> approach?
>>>> 
>>>> The argument that an Explain file is, after all, an SRU response,
>>> seems a
>>>> bit tortured. I'm not convinced it's a bad approach, just not
>>> convinced it's
>>>> right.   It avoids reqistering another content type, a huge pain, to
>>> be
>>>> sure, but
>>>> one thing that bothers me about this, it isn't as easy as it seems, 
>>>> if
>>> we
>>>> extend the defintion of application/sru+xml to apply to Explain, 
>>>> then
>>> we are
>>>> going to have to extend the SRU response schema to include Explain,
>>> aren't
>>>> we?
>>>> 
>>>> 
>>>> --Ray
>>>> 
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: SRU (Search and Retrieve Via URL) Implementors
>>> [mailto:ZNG@loc.gov]
>>>> On
>>>> Behalf Of Adam Dickmeiss
>>>> Sent: Tuesday, June 15, 2010 11:05 AM
>>>> To: ZNG@LISTSERV.LOC.GOV
>>>> Subject: Re: content-type for Zeerex/Explain
>>>> 
>>>> On 2010-06-15 16:38, LeVan,Ralph wrote:
>>>>> application/xml is probably fine as the content type in a response.
>>>>> But, if I want to provide a pointer to a server and indicate a 
>>>>> mime type in the link, something richer than application/xml would 
>>>>> be
>>>> desirable.
>>>>> 
>>>> OK. Thanks for clarifying.
>>>> 
>>>> / Adam
>>>>> Ralph
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Adam Dickmeiss [mailto:adam@indexdata.dk]
>>>>>> Sent: Tuesday, June 15, 2010 10:16 AM
>>>>>> To: SRU (Search and Retrieve Via URL) Implementors
>>>>>> Cc: LeVan,Ralph
>>>>>> Subject: Re: content-type for Zeerex/Explain
>>>>>> 
>>>>>> On 2010-06-14 22:52, LeVan,Ralph wrote:
>>>>>> 
>>>>>>> We just discussed that during our Oasis phone call this morning.
>>>>>>> 
>>>>> We've
>>>>> 
>>>>>>> applied to IANA for application/sru+xml.  Since an Explain 
>>>>>>> record
>>> is
>>>>>>> what you get when you send a request to an SRU server with no 
>>>>>>> parameters, we figure that the application/sru+xml covers the
>>>>>>> 
>>>>> Explain
>>>>> 
>>>>>>> response as well as the searchRetrieveResponse.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> Please remind me why application/xml is not good enough. I mean,
>>> SRU
>>>>>> 
>>>>> is
>>>>> 
>>>>>> an XML application, no? And do SOAP tools allow you to customize
>>> this?
>>>>>> 
>>>>>>> Ralph
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> -----Original Message-----
>>>>>>>> From: SRU (Search and Retrieve Via URL) Implementors
>>>>>>>> 
>>>>>>>> 
>>>>>>> [mailto:ZNG@loc.gov]
>>>>>>> 
>>>>>>> 
>>>>>>>> On Behalf Of Jonathan Rochkind
>>>>>>>> Sent: Monday, June 14, 2010 4:48 PM
>>>>>>>> To: ZNG@LISTSERV.LOC.GOV
>>>>>>>> Subject: content-type for Zeerex/Explain
>>>>>>>> 
>>>>>>>> Is there a MIME/IANA Content Type for an SRU/ZeeRex Explain
>>>>>>>> 
>>>>> document?
>>>>> 
>>>>>>>> There doesn't seem to be one registered, is there one
>>> conventional?
>>>>>>>> 
>>>>>>>> Or just use application/xml?
>>>>>>>> 
>>>>>>>> I am not sure what SRU itself does, but what I'm doing is just
>>>>>>>> 
>>>>>>>> 
>>>>>>> returning
>>>>>>> 
>>>>>>> 
>>>>>>>> a raw Explain XML document, in some cases. My app is not 
>>>>>>>> actually
>>>>>>>> 
>>>>> SRU,
>>>>> 
>>>>>>>> but is using some parts of it.
>>>>>>>> 
>>>>>>>> Jonathan
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> -------------------------------------------------------------------
>>>> -
>>>> - To unsubscribe from this mail list, you must leave the OASIS TC 
>>>> that generates this mail.  Follow this link to all your TCs in 
>>>> OASIS
>>>> at:
>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.
>>>> p
>>>> h
>>>> p
>>>> 
>>> 
>>> 
>>> 
>>> --------------------------------------------------------------------
>>> - To unsubscribe from this mail list, you must leave the OASIS TC 
>>> that generates this mail.  Follow this link to all your TCs in OASIS 
>>> at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.p
>>> h
>>> p
>>> 
>> 
>> 
>> 
> **********************************************************************
> ******
>> ****   
>> DISCLAIMER: This e-mail is confidential and should not be used by 
>> anyone who is not the original intended recipient. If you have 
>> received this e-mail in error please inform the sender and delete it 
>> from your mailbox or any other storage mechanism. Neither Macmillan 
>> Publishers Limited nor any of its agents accept liability for any 
>> statements made which are clearly the sender's own and not expressly 
>> made on behalf of Macmillan Publishers Limited or one of its agents.
>> Please note that neither Macmillan Publishers Limited nor any of its 
>> agents accept any responsibility for viruses that may be contained in 
>> this e-mail or its attachments and it is your responsibility to scan 
>> the e-mail and attachments (if any). No contracts may be concluded on 
>> behalf of Macmillan Publishers Limited or its agents by means of 
>> e-mail communication. Macmillan Publishers Limited Registered in 
>> England and Wales with registered number
>> 785998
>> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
>> *********************************************************************
>> *
>> ******
>> ****
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that 
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.ph
>> p
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that 
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.ph
>> p
>> 
> 
> 
>
****************************************************************************
> ****   
> DISCLAIMER: This e-mail is confidential and should not be used by 
> anyone who is not the original intended recipient. If you have 
> received this e-mail in error please inform the sender and delete it 
> from your mailbox or any other storage mechanism. Neither Macmillan 
> Publishers Limited nor any of its agents accept liability for any 
> statements made which are clearly the sender's own and not expressly 
> made on behalf of Macmillan Publishers Limited or one of its agents.
> Please note that neither Macmillan Publishers Limited nor any of its 
> agents accept any responsibility for viruses that may be contained in 
> this e-mail or its attachments and it is your responsibility to scan 
> the e-mail and attachments (if any). No contracts may be concluded on 
> behalf of Macmillan Publishers Limited or its agents by means of 
> e-mail communication. Macmillan Publishers Limited Registered in 
> England and Wales with registered number
> 785998
> Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
> **********************************************************************
> ******
> ****
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 


****************************************************************************
****   
DISCLAIMER: This e-mail is confidential and should not be used by anyone who
is not the original intended recipient. If you have received this e-mail in
error please inform the sender and delete it from your mailbox or any other
storage mechanism. Neither Macmillan Publishers Limited nor any of its
agents accept liability for any statements made which are clearly the
sender's own and not expressly made on behalf of Macmillan Publishers
Limited or one of its agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail
or its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan
Publishers Limited Registered in England and Wales with registered number
785998 
Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS   
****************************************************************************
****