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: 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   
********************************************************************************

sru-protocol-model.png



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