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


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]