What, _again_?!

Whatever happened to double jeopardy?  We must be on about septuple
jeopardy by now.

 _/|_	 ___________________________________________________________________
/o ) \/  Mike Taylor    <[log in to unmask]>    http://www.miketaylor.org.uk
)_v__/\  When a company calls its PC the `PC', and its DOS `DOS', it comes
	 as little surprise when it calls its windows system `Windows'.



Theo van Veen writes:
 > Ray,
 >  
 > For me the possibility of getting unsollicited data has always been a very important issue. Not allowing it is a real barrier for a lot of innovation. I know that there is an option to specify to accept anything. In my view this should be the default. Let me explain why.
 > 1) we shouldn't worry about thin clients. I use a thin client for testing pruposes  that works on my mobile phone. It handles onsollicited data very well.
 > 2) we may rely on system engineers to deal with unsollicited in a responsible way. Many servers have extensions that might be useful for others. Only extensions that are not useful for others should be on request only
 > 3) we should not forget that there are users behind the SRU clients. We can not require users to first select the extensions. That would make the applications for users quite complicated. When a server supports price information - either as extraRecordData or as extra element in the recordData - the user will be more pleased when it is just displayed rather than that he first had to ask for it. 
 > 4) as far as extensions to DC are concerned. There are many recordSchemas containing DC plus something extra. Do we really want users to select recordSchema's containing DC or DC plus something extra? My experience is based on federated search and indexing distributed resources. It takes hardly no effort to present extra data or elements. It introduces a lot of complexity when a selection has to be made a priori.
 > 5) we should prevent the need for a priori knowledge: Extension require a priori knowledge
 > 6) the argument that a client wouldn't know what to do with unsollicited data doesn't hold. We use clients that allow the user to attach functions to elements in recordData without us knowing those elements. 
 > 7) The SRU extension mechanism is relying so heavily on bilateral knowledge that it is a barrier for local use. 
 >  
 > My proposal would be the following:
 > 1) introduce a recordSchema dcterms plus extensions (anything, unspecified) called DCX. 
 > 2) allow extraRecordData with the restriction that these data can be used by external applications but can also be ingnored. The fact that the extarnal applications have to be changed to deal with these extraRecordData is not a restriction in my view.
 >  
 > I know that I raised these points several times before and that there always have been objections but I also realise that the SRU community has changed and that now there may be more support for my proposal.
 >  
 > Theo
 > 
 > ________________________________
 > 
 > From: SRU (Search and Retrieve Via URL) Implementors on behalf of Ray Denenberg, Library of Congress
 > Sent: Fri 3/28/2008 6:36 PM
 > To: [log in to unmask]
 > Subject: Re: Price information in SRU responses
 > 
 > 
 > From: Theo van Veen <mailto:[log in to unmask]>  
 > 
 > > I don't remember the arguments. 
 > 
 >  
 > The argument is that if servers are allowed to send unsolicited extra-data then they will overload the client with useless information, a particular burden on thin clients. 
 >  
 > There is a mechanism for a client to indicate that it is prepared to accept any extra-data that the server wants to send.  A client for which information overload is not 
 > an issue might avail itself of this feature.   See http://www.loc.gov/standards/sru/resources/accept.html
 >  
 > I don't think this addresses the issue at hand.  The client wants price information. The only sensible way I can think of to meet this requirement is via the schema definition.   Using the ONIX schema could be the simplest or most expedient short-term approach.  Simply providing extensibility within the DC schema does not seem to me to be a very interoperable approach.  What namespace would this price element come from?  If we wanted to come up with some utility element set and create a namespace for it, I'd be willing to support that, if that seems like a good idea. 
 >  
 > --Ray
 >