This seems sensible, two search services could be provided, (1) the  
direct SRU implementation and (2) a URL which provides the service  
that renders into XHTML, the later would simply be a server-side  
transform on the content of the later. I've done something similar to  
this on other search services. Then for power users, you could  
provide a link to a form that provides the power search, or encode a  
link in the HTML Search results which would perform the search  
against the standard SRU interface returning raw XML. I guess if  
there are SRU clients out there like there are RSS readers, such a  
link could be easily pasted into them and/or carried around as a  
bookmark.

Personally, I like the idea of having the browser do the rendering  
via XSLT, but there is always the challenge that not all clients will  
have this capability, it may be better to serve it out in different  
formats and tailor the format based on the client request headers.  
But thats another topic.

-Mark

On Apr 25, 2006, at 12:06 PM, Eliot Christian wrote:

> Regarding the note from Tony Hammond:
>
> In my Google Earth applications (see Technical Annex in http:// 
> www.search.gov/cap/ge.ppt ), I have an intermediary that renders an  
> SRU response into KML (an XML dialect peculiar to Google Earth.) A  
> PHP program (not a stylesheet, though it uses XPath) handles the  
> transform from SRU XML to KML.
>
> It seems equally valid to me that people have SRU layered  
> underneath an intermediary that renders HTML. I don't see why it  
> should matter to the SRU community whether that intermediary has  
> been written with the stylesheet programming language or any other  
> programming language.
>
> Eliot
>
> At 11:39 AM 4/25/2006, LeVan,Ralph wrote:
>> I'm afraid it doesn't seem to be SRU if you return HTML.  When you  
>> return a stylesheet, you still return XML and have the browser  
>> render the XML to HTML.
>>
>> I'm afraid that you're closer to OpenSearch than you are to SRU,  
>> but OpenSearch doesn't define a standard query grammar.
>>
>> Rob Sanderson has had discussions with the OpenSearch folks about  
>> support for CQL.  He might have a suggestion for you.
>>
>> Ralph
>>
>>> -----Original Message-----
>>> From: SRU (Search and Retrieve Via URL) Implementors  
>>> [mailto:[log in to unmask]]
>>> On Behalf Of Tony Hammond
>>> Sent: Tuesday, April 25, 2006 10:12 AM
>>> To: [log in to unmask]
>>> Subject: SRU Question re XML Processing
>>>
>>> (This is a copy of a private mail I sent to Ray D. over a couple  
>>> months
>>> ago
>>> and to which he graciously replied, but also suggested that I  
>>> send to the
>>> list to get a wider perspective. Apologies for not mailing sooner  
>>> but got
>>> sucked up into some other projects, though ready to refocus on  
>>> this now.
>>> Appreciate any guidance. And very much hoping the answer is  
>>> "Yes!" :)
>>>
>>> Hi:
>>>
>>> Got a question that you may be able to help us out with. We (NPG)  
>>> are
>>> looking to make available some HTML snippets that folks can cut  
>>> and paste
>>> onto their own websites which would provide a search textbox on  
>>> their
>>> pages
>>> to run against our own search indexes and return (in first  
>>> instance) our
>>> standard HTML result pages. I have been thinking that we  
>>> shouldn¹t really
>>> be
>>> using our ASP search syntax (because proprietary, obscure,  
>>> account in
>>> plaintext, etc.) but rather a Œstandard¹ search syntax.
>>>
>>> Naturally SRU springs to mind (as does OpenSearch).  Mapping  
>>> (either) URI
>>> querystring is trivial. Question I have is more particular. SRU  
>>> returns
>>> XML
>>> to the user (with possibly a stylesheet reference attached). Is it
>>> acceptable (in the SRU scheme of things) to allow for the  
>>> possibility of
>>> an
>>> intermediary (in this case, our own server) to render the XML and  
>>> deliver
>>> HTML back to the user. Does that break the spirit of SRU? I could  
>>> imagine
>>> that initially (since we anyway deliver HTML) that one could have  
>>> a Œfaux¹
>>> stylesheet reference which could be applied to the result set and  
>>> serve up
>>> HTML to the user. We do also have the ability to acquire raw XML  
>>> back from
>>> the ASP, and so could also provide alternate Œsnippets¹ which  
>>> would allow
>>> for querying with SRU and getting native SRU XML docs back, or  
>>> with (real)
>>> stylesheets to get other renderings, e.g. (X)HTML includes, RSS,  
>>> etc.
>>>
>>> Does this make sense in the SRU context, to allow for the  
>>> possibility that
>>> a
>>> server could intermediate the SRU return on the basis of a  
>>> stylesheet
>>> reference included in the XML document (whether real or faux).  
>>> And with a
>>> stylesheet reference we could just return native SRU XML? I don¹t  
>>> want to
>>> run against the spirit of SRU. (And still need to catch up with  
>>> latest
>>> version of OpenSearch.)
>>>
>>> Thanks for any comments you may have time for.
>>>
>>> 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
>>> ******************************************************************** 
>>> ******
>>> ******