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 Protocol Model Terminology


I just took a quick look at this (sorry, I've been a bit slow lately) and 
I'm completely happy with it EXCEPT for one detail.

In my diagram, note that step 4 is a two-way interaction. I saw no reason to 
break it into two steps. Thus "the SRU/S interacts with the SE" can be 
modelled as a single step.   This is different from (and not symmetric with) 
the interaction on the other side between the CA and SRU/C because those are 
two steps that occur at different times, namely the first and last step. 
(Note that in my diagram there is an error, a missing arrow representing 
step 1.)

Tony if you agree, could you redraft this: combine steps 4 and 5 into a 
single step (double sided arrow) and renumber, total 7 steps. Then I'll put 
it in the document. Otherwise it's fine.

 Thanks.

--Ray

----- Original Message ----- 
From: "Hammond, Tony" <t.hammond@nature.com>
To: "OASIS SWS TC" <search-ws@lists.oasis-open.org>
Sent: Tuesday, January 12, 2010 11:22 AM
Subject: [search-ws] SRU Protocol Model Terminology


> Hi:
>
> Following on yesterday's call I made some remarks about the SRU protocol
> model terminology. I am very chary about introducing new (or seemingly 
> new)
> terminology - even where terms may be explained in the text. We should aim
> to avoid lessons in algebra.
>
> * Existing terminology
>
>    CA      client application
>    SE      search engine
>
>    SRUP/C  SRU protocol module at the client
>    SRUP/S  SRU protocol module at the server
>
>    PRQ     searchRetrieve protocol request
>    PRS     searchRetrieve protocol response
>
>    LLP     lower level protocol
>
>
> I am wondering if the following changes might be in order.
>
>    1. Retain CA/SE. (Looked for symmetry but gave up.)
>
>    2. Drop the specious "P" in SRUP/C, SRUP/S. The term "SRUP" is
> horrendous.
>
>    3. Use REQ and RES (or RESP) for PRQ, PRS as these are readily familiar
> terms in client/server architectures. And note that we should avoid the 
> term
> "searchRetreive protocol" and instead use the term "SRU protocol".
>
>    4. Let's not be coy about the transport protocol - it *is* HTTP. I 
> worry
> that introducing a new layer of abstraction (through the term LLP) is a
> generalization too far. If we need to abstract we should probably use
> "transport protocol" rather than "lower level protocol" because we are 
> still
> using SRU semantics but over an HTTP transport layer.
>
> That would lead to the following proposal from me:
>
> * Suggested terminology
>
>    CA      client application
>    SE      search engine
>
>    SRU/C   SRU protocol module at the client
>    SRU/S   SRU protocol module at the server
>
>    REQ     SRU protocol request
>    RSP     SRU protocol response
>
>    HTTP    HTTP protocol (for transport)
>
>
> I have taken a rough cut at a revised architecture diagram (see .png
> attached) with new labelling, client/server processes more clearly
> indicated, and a cloud for topicality. If this is deemed to be in any way
> useful I could always aim to improve.
>
> Cheers,
>
> Tony
>
>
>
> ********************************************************************************
> 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 



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