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