[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]