[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.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
> ****************************************************************************
> ****
>
>
> ---------------------------------------------------------------------
> 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
********************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]