[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [search-ws] sru version
Hi Ray:
> 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.
But isn't it the current practice to provide an explain record at the
endpoint?
> 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?
Funny you mention that. Something that we have on many of our apps and which
we recently added to OpenSearch is not dissimilar. We have a '/versioninfo'
path to provide app-specific implementation data. See e.g.
http://www.nature.com/opensearch/versioninfo
Maybe a similar mechanism could be used? But that of course adds a whole lot
more complexity and in practice how many implentations are really going to
be maintaining multiple versions?
Wouldn't it just be simpler to run off the explain record (as now) and have
version number recorded there, and add to the explain record some elements
noting any other versions and where to access them. For example, not wholly
dissimilar to content negotiation, one might have multiple versions on same
endpoint which could be accessed by the 'version' parameter, or the explain
record could note alternate locations for other versions.
The explain record does have a serverInfo section which maybe could be made
a repeatable element?
> I would support the page-based discovery model you suggest. Would you like
> to write something up in more detail?
Sure. Could draft something up for review.
Cheers,
Tony
On 11/6/10 17:50, "Ray Denenberg, Library of Congress" <rden@loc.gov> wrote:
> 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
> ****************************************************************************
> ****
>
********************************************************************************
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]