OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

search-ws message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [search-ws] sru version


Tony - 

Let's say then that you have:

http://myserver/mysru/cat  for version 2.0 and
 http://myserver/mysru/dog   for version 2.1

And perhaps you have an explain record at each:

an explain record at  http://myserver/mysru/cat      explaining the version
2.0 cat server and
and an explain record at http://myserver/mysru/dog    explaining the version
2.1 dog server.

One question you asked is, what would an explain record explain at 

http://myserver/mysru/ 

the "bare endpoint" as you put it.   "The most current?"  "A random
version?" 

I would think neither.   Could we define a new type of record, which say
"I'm a bare endpoint off of which hangs one or more SRU servers" and list
them, and for each, the path and version?


I would support the page-based discovery model you suggest. Would you like
to write something up in more detail?

Thanks.

--Ray




-----Original Message-----
From: Hammond, Tony [mailto:t.hammond@nature.com] 
Sent: Friday, June 11, 2010 11:40 AM
To: Denenberg, Ray; 'OASIS SWS TC'
Subject: Re: [search-ws] sru version

Hi Ray:

You say:

> But the suggestion (and the list discussion) seems to imply that in 
> the case where there are multiple servers on a base url, that there be 
> some sort of naming convention for the path names that hang off of the 
> base url, like in the above example, 'version2.0' and 'version2.1'.

And then:

> That's a somewhat troubling assumption (to me).

But it's more than troubling. It's bad architecture. Period. We already have
this specific guidance from the W3C:

    "Agents making use of URIs SHOULD NOT attempt to infer properties of the
referenced resource."

    http://www.w3.org/TR/webarch/#uri-opacity

I am totally opposed to any global (i.e. spec defined) practice to insert
version in URI names. (Local implementations, by contrast, can choose to do
whatsoever they see fit.)

The proper way to allow for version negotiation (if any required) is through
the existing mechanism - a dedicated parameter. The only change from 1.*
practice is that we allow this parameter to be optional instead of requiring
it (which only adds to link boilerplate).

But this does lead to a (small) problem where multiple versions may be
maintained on the same endpoint. What Explain record does an implementation
return by default on the bare endpoint? The most current? Or a random
version?

I am not sure whether the spec has any business in telling implementors how
they can deploy. I think it should confine itself to defining the semantics
and leave it to implementors to support single or multiple versions across
single or multiple endpoints.

You also say:

>   On the other hand, we have been almost completely silent about how a 
> client goes about finding out where the different SRU version are.

The current SRU discovery model is registry based - i.e. a centralized
model. I wonder if we should rather be considering page-based discovery
using link/@rel elements to point onto Explain records as does OpenSearch to
point onto Description documents - i.e. a distributed model.

This distributed approach is, after all, more in keeping with the way of the
Web. In fact, one might even consider whether there is anything to be gained
by building directly on (or at least piggybacking on) the OpenSearch
Description mechanism (or an SRU extension of it) to point onto Explain
records. 

For what it's worth, below is what we currently do on our pages where we
provide two parallel link/@rel locations, one to OpenSearch and one to SRU:

==
    <link rel="search" href="opensearch.xml"
type="application/opensearchdescription+xml" title="nature.com"></link>
    <link rel="search" href="request" type="application/sru+xml"
title="nature.com"></link>
==

I note that version is encoded in the Explain record and could also be made
explicit in an OpenSearch SRU Extension.

I guess this could all do with some further thought though.

Cheers,

Tony





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

> Matthew you said (on the SRU list):
> 
> "iii) for servers running multiple versions the idea is that the 
> client goes first for the explain record (which would be at a single 
> URL and cover all versions)"
> 
> In the example, you suggested that you could have a 2.0 server at
> 
>                http://myserver/mysru/version2.0
> 
> and a 2.1 server at
> 
>                http://myserver/mysru/version2.1
> 
> 
> This needs discussion.
> 
> You are suggesting that an explain record would be at  
> http://myserver/mysru/ and it would cover both servers.
> 
> And/Or, I presume, there could separate explain records, one for each 
> server. One each at:
> http://myserver/mysru/version2.0 and http://myserver/mysru/version2.1
> 
> But the suggestion (and the list discussion) seems to imply that in 
> the case where there are multiple servers on a base url, that there be 
> some sort of naming convention for the path names that hang off of the 
> base url, like in the above example, 'version2.0' and 'version2.1'. 
> That's a somewhat troubling assumption (to me).  There should be no 
> reason why you couldn't have completely opaque names for your servers,
e.g.
> 
> http://myserver/mysru/cat  for version 2.0 and
> http://myserver/mysru/dog   for version 2.2
> 
>   On the other hand, we have been almost completely silent about how a 
> client goes about finding out where the different SRU version are.
> 
> Let's put this on the agenda for Monday.
> 
> --Ray
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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]