A brief pre-sequiter:
Is there a general objection to the SRU DC schema allowing inclusion of
elements from other schemas, and if so what is it?
Thanks
John
On Mon, 2008-03-31 at 18:16 +0200, Theo van Veen wrote:
> Clients might crash on unsollicited extraRecordData, there are only a
> few extensions that would be a candidate and we didn't design the
> mechanism, so let's forget it.
>
> Theo
> BTW, I was not proposing to put the price information in
> extraRecordData. Actually I made a remark about the use of
> extraRecordData for this purpose because the extraRecordData relies so
> much on bilateral agreements and a priori knowledge. Price information
> can be in an ONIX record or in a DC-alike recordSchema "DC-with-prices".
>
>
>
> -----Oorspronkelijk bericht-----
> Van: SRU (Search and Retrieve Via URL) Implementors [mailto:[log in to unmask]]
> Namens Mike Taylor
> Verzonden: maandag 31 maart 2008 17:22
> Aan: [log in to unmask]
> Onderwerp: Re: Price information in SRU responses
>
> Wait, wait! You're saying that you want SRU's _default_ behaviour to
> be that server should return all and only the additional information
> that you consider useful?!
>
> Clearly that is going to vary depending on who you are, what
> application you're running, etc. What would be really useful would be
> a mechanism for specifying, on a request-by-request basis, what
> particular additional information you're interested. If only we'd
> thought to design such a mechanism!
>
> _/|_
> ___________________________________________________________________
> /o ) \/ Mike Taylor <[log in to unmask]>
> http://www.miketaylor.org.uk
> )_v__/\ If two decades of commercial programming have taught me
> anything,
> it's NEVER to trust dual CPUs, "uninterruptible" power supplies
> or RAID disks.
>
>
>
>
> Theo van Veen writes:
> > Ray,
> >
> > I don't know what will be returned with "accept any". I only want to
> get
> > extensions that are - within reason - considered useful to be
> presented
> > to the user. When I look at the extensions at
> > http://www.loc.gov/standards/sru/resources/extensions.html there is
> only
> > one extension that I consider useful for users.
> >
> > I agree with Rob's argument that one doesn't want implementers to
> return
> > anything and everything, including base-64 encoded full text
> > books/images, but that also holds when using "accept any". But I'm
> > afraid that currently we miss the interesting extensions. I don't
> know
> > how many extensions exist that are not registered and not part of
> > explain but would be interesting for users.
> >
> > I will have to check what generally is returned when using "accept
> any".
> >
> >
> > BTW which server supports the "info:srw/extension/2/extraQuery-1.0"
> > extension?
> >
> >
> >
> > Given the lack of support for this, let's leave it the way it is.
> >
> >
> >
> > Theo
> >
> >
> >
> > ________________________________
> >
> > Van: SRU (Search and Retrieve Via URL) Implementors
> [mailto:[log in to unmask]]
> > Namens Ray Denenberg
> > Verzonden: maandag 31 maart 2008 16:04
> > Aan: [log in to unmask]
> > Onderwerp: Re: Price information in SRU responses
> >
> >
> >
> > Theo, explain why the "accept" mechanism doesn't solve this problem.
>
> >
> >
> >
> > The client can indicate that it is prepared to accept any extra-data,
> or
> > extra-data of specific categories.
> > http://www.loc.gov/standards/sru/resources/accept.html
> >
> >
> >
> >
> >
> > --Ray
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ----- Original Message -----
> >
> > From: Theo van Veen <mailto:[log in to unmask]>
> >
> > To: [log in to unmask]
> >
> > Sent: Saturday, March 29, 2008 10:52 PM
> >
> > Subject: Re: Price information in SRU responses
> >
> >
> >
> > I'm not talking about sending anything and wasting bandwidth.
> > There are extensions that are useful to all users and extensions that
> > are only useful for specific situations. The server knows that better
> > than the client. I would consider a client that breaks down on
> > unsollicited extra data not well implemented. As a user I would
> prefer a
> > client that allows me to see the unsollicted extra data. But my
> client
> > wouldn't say to the server that it accepts anything because the
> client
> > can not judge the usefulness for the user. The server can.
> >
> > Theo
> >
> > ________________________________
> >
> > From: SRU (Search and Retrieve Via URL) Implementors on behalf
> > of Dr R. Sanderson
> > Sent: Sat 3/29/2008 12:23 PM
> > To: [log in to unmask]
> > Subject: Re: Price information in SRU responses
> >
> >
> >
> > > 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
> >
> > This is my main problem with the proposal.
> >
> > 1. Surely if an extension is not useful, it wouldn't exist?
> >
> > 2. Assuming that there are non-useful extensions, how do you
> > determine
> > if an extension is or is not useful to the current client?
> >
> > 3. Assuming that you have a well implemented server, you could
> > return
> > an AWFUL lot of extra data about a record, the search, the terms
> > in
> > scan, etc. You're just wasting everyone's bandwidth and
> > processing time
> > by sending unwanted data that the client probably doesn't know
> > what to
> > do with. Yes you can safely ignore it, but that is not a zero
> > cost
> > option.
> >
> > 4. If, as a client, you want to get back anything, we have a
> > way to do
> > it -- the accept extension. I don't see why this should be
> > forced on to
> > everyone when clients that want it can easily have it. Just put
> > it at
> > the beginning along with the static operation and version
> > parameters and
> > forget about it. :)
> >
> > 5. For some clients, getting back unknown elements could break
> > them if
> > they use very strict XML processing rules. Enforcing something
> > that is
> > known to break otherwise well implemented clients is not good
> > behaviour!
> >
> > Rob
> >
> > <html xmlns:v="urn:schemas-microsoft-com:vml"
> xmlns:o="urn:schemas-microsoft-com:office:office"
> xmlns:w="urn:schemas-microsoft-com:office:word"
> xmlns="http://www.w3.org/TR/REC-html40">
> >
> > <head>
> > <meta http-equiv=Content-Type content="text/html; charset=us-ascii">
> > <meta name=Generator content="Microsoft Word 11 (filtered medium)">
> > <!--[if !mso]>
> > <style>
> > v\:* {behavior:url(#default#VML);}
> > o\:* {behavior:url(#default#VML);}
> > w\:* {behavior:url(#default#VML);}
> > .shape {behavior:url(#default#VML);}
> > </style>
> > <![endif]-->
> > <style>
> > <!--
> > /* Font Definitions */
> > @font-face
> > {font-family:Tahoma;
> > panose-1:2 11 6 4 3 5 4 4 2 4;}
> > /* Style Definitions */
> > p.MsoNormal, li.MsoNormal, div.MsoNormal
> > {margin:0in;
> > margin-bottom:.0001pt;
> > font-size:12.0pt;
> > font-family:"Times New Roman";}
> > a:link, span.MsoHyperlink
> > {color:blue;
> > text-decoration:underline;}
> > a:visited, span.MsoHyperlinkFollowed
> > {color:blue;
> > text-decoration:underline;}
> > span.E-mailStijl17
> > {mso-style-type:personal-reply;
> > font-family:Arial;
> > color:navy;}
> > @page Section1
> > {size:595.3pt 841.9pt;
> > margin:70.85pt 70.85pt 70.85pt 70.85pt;}
> > div.Section1
> > {page:Section1;}
> > -->
> > </style>
> > <!--[if gte mso 9]><xml>
> > <o:shapedefaults v:ext="edit" spidmax="1026" />
> > </xml><![endif]--><!--[if gte mso 9]><xml>
> > <o:shapelayout v:ext="edit">
> > <o:idmap v:ext="edit" data="1" />
> > </o:shapelayout></xml><![endif]-->
> > </head>
> >
> > <body bgcolor=white lang=EN-US link=blue vlink=blue>
> >
> > <div class=Section1>
> >
> > <p class=MsoNormal><font size=2 color=navy face=Arial><span
> style='font-size:
> >
> 10.0pt;font-family:Arial;color:navy'>Ray,<o:p></o:p></span></font></p>
> >
> > <p class=MsoNormal><font size=2 color=navy face=Arial><span
> style='font-size:
> > 10.0pt;font-family:Arial;color:navy'>I don’t know what will be
> returned
> > with “accept any”. I only want to get extensions that are
> - within
> > reason - considered useful to be presented to the user. When I look
> at the
> > extensions at <a
> >
> href="http://www.loc.gov/standards/sru/resources/extensions.html">http:/
> /www.loc.gov/standards/sru/resources/extensions.html</a>
> > there is only one extension that I consider useful for users.
> <o:p></o:p></span></font></p>
> >
> > <p class=MsoNormal><font size=2 color=navy face=Arial><span
> style='font-size:
> > 10.0pt;font-family:Arial;color:navy'>I agree with Rob’s
> argument that one
> > doesn’t want </span></font><font size=2 face=Arial><span
> > style='font-size:10.0pt;font-family:Arial'>implementers to return
> anything and
> > everything, including base-64 encoded full text books/images, but
> that also
> > holds when using “accept any”. But I’m afraid that
> currently
> > we miss the interesting extensions.</span></font><font size=2
> color=navy
> > face=Arial><span
> style='font-size:10.0pt;font-family:Arial;color:navy'> I don’t
> > know how many extensions exist that are not registered and not part
> of explain but
> > would be interesting for users. <o:p></o:p></span></font></p>
> >
> > <p class=MsoNormal><font size=2 color=navy face=Arial><span
> style='font-size:
> > 10.0pt;font-family:Arial;color:navy'>I will have to check what
> generally is
> > returned when using “accept any”.
> <o:p></o:p></span></font></p>
> >
> > <p class=MsoNormal><font size=2 color=navy face=Arial><span
> style='font-size:
> > 10.0pt;font-family:Arial;color:navy'>BTW which server supports the
> “</span></font><font
> > size=2 face=Arial><span
> style='font-size:10.0pt;font-family:Arial'>info:srw/extension/2/extraQue
> ry-1.0</span></font><font
> > size=2 color=navy face=Arial><span
> style='font-size:10.0pt;font-family:Arial;
> > color:navy'>” extension? <o:p></o:p></span></font></p>
> >
> > <p class=MsoNormal><font size=2 color=navy face=Arial><span
> style='font-size:
> >
> 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
> >
> > <p class=MsoNormal><font size=2 color=navy face=Arial><span
> style='font-size:
> > 10.0pt;font-family:Arial;color:navy'>Given the lack of support for
> this, let’s
> > leave it the way it is. <o:p></o:p></span></font></p>
> >
> > <p class=MsoNormal><font size=2 color=navy face=Arial><span
> style='font-size:
> >
> 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
> >
> > <p class=MsoNormal><font size=2 color=navy face=Arial><span
> style='font-size:
> >
> 10.0pt;font-family:Arial;color:navy'>Theo<o:p></o:p></span></font></p>
> >
> > <p class=MsoNormal><font size=2 color=navy face=Arial><span
> style='font-size:
> >
> 10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
> >
> > <div>
> >
> > <div class=MsoNormal align=center style='text-align:center'><font
> size=3
> > face="Times New Roman"><span lang=NL style='font-size:12.0pt'>
> >
> > <hr size=2 width="100%" align=center tabindex=-1>
> >
> > </span></font></div>
> >
> > <p class=MsoNormal><b><font size=2 face=Tahoma><span lang=NL
> style='font-size:
> >
> 10.0pt;font-family:Tahoma;font-weight:bold'>Van:</span></font></b><font
> size=2
> > face=Tahoma><span lang=NL
> style='font-size:10.0pt;font-family:Tahoma'> SRU
> > (Search and Retrieve Via URL) Implementors [mailto:[log in to unmask]]
> <b><span
> > style='font-weight:bold'>Namens </span></b>Ray Denenberg<br>
> > <b><span style='font-weight:bold'>Verzonden:</span></b> maandag 31
> maart 2008
> > 16:04<br>
> > <b><span style='font-weight:bold'>Aan:</span></b>
> [log in to unmask]<br>
> > <b><span style='font-weight:bold'>Onderwerp:</span></b> Re: Price
> information
> > in SRU responses</span></font><span lang=NL><o:p></o:p></span></p>
> >
> > </div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'><o:p> </o:p></span></font></p>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=2 face=Arial><span
> style='font-size:10.0pt;
> > font-family:Arial'>Theo, explain why the "accept" mechanism
> doesn't
> > solve this problem. </span></font><o:p></o:p></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'> <o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'>The client can indicate that it is prepared to accept
> any
> > extra-data, or extra-data of specific categories. <a
> >
> href="http://www.loc.gov/standards/sru/resources/accept.html">http://www
> .loc.gov/standards/sru/resources/accept.html</a><o:p></o:p></span></font
> ></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'> <o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'> <o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=2 face=Arial><span
> style='font-size:10.0pt;
> > font-family:Arial'>--Ray</span></font><o:p></o:p></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'> <o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'> <o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'> <o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'> <o:p></o:p></span></font></p>
> >
> > </div>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'> <o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'> <o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'>----- Original Message ----- <o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <blockquote style='border:none;border-left:solid black
> 1.5pt;padding:0in 0in 0in 4.0pt;
> >
> margin-left:3.75pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt
> '>
> >
> > <div style='font-color:black'>
> >
> > <p class=MsoNormal style='background:#E4E4E4'><b><font size=2
> face=Arial><span
> >
> style='font-size:10.0pt;font-family:Arial;font-weight:bold'>From:</span>
> </font></b><font
> > size=2 face=Arial><span style='font-size:10.0pt;font-family:Arial'>
> <a
> > href="mailto:[log in to unmask]" title="[log in to unmask]">Theo van
> Veen</a> <o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><b><font size=2 face=Arial><span
> style='font-size:10.0pt;
> > font-family:Arial;font-weight:bold'>To:</span></font></b><font size=2
> > face=Arial><span style='font-size:10.0pt;font-family:Arial'> <a
> > href="mailto:[log in to unmask]"
> title="[log in to unmask]">[log in to unmask]</a>
> <o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><b><font size=2 face=Arial><span
> style='font-size:10.0pt;
> > font-family:Arial;font-weight:bold'>Sent:</span></font></b><font
> size=2
> > face=Arial><span style='font-size:10.0pt;font-family:Arial'>
> Saturday, March
> > 29, 2008 10:52 PM<o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><b><font size=2 face=Arial><span
> style='font-size:10.0pt;
> > font-family:Arial;font-weight:bold'>Subject:</span></font></b><font
> size=2
> > face=Arial><span style='font-size:10.0pt;font-family:Arial'> Re:
> Price
> > information in SRU responses<o:p></o:p></span></font></p>
> >
> > </div>
> >
> > <div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'><o:p> </o:p></span></font></p>
> >
> > </div>
> >
> > <p class=MsoNormal><font size=3 face="Times New Roman"><span
> style='font-size:
> > 12.0pt'>I'm not talking about sending anything and wasting bandwidth.
> There are
> > extensions that are useful to all users and extensions that are only
> useful for
> > specific situations. The server knows that better than the client. I
> would
> > consider a client that breaks down on unsollicited extra data not
> well
> > implemented. As a user I would prefer a client that allows me to see
> the
> > unsollicted extra data. But my client wouldn't say to the server that
> it
> > accepts anything because the client can not judge the usefulness for
> the user.
> > The server can.<br>
> > <br>
> > Theo <br>
> > <br>
> > ________________________________<br>
> > <br>
> > From: SRU (Search and Retrieve Via URL) Implementors on behalf of Dr
> R. Sanderson<br>
> > Sent: Sat 3/29/2008 12:23 PM<br>
> > To: <a href="mailto:[log in to unmask]">[log in to unmask]</a><br>
> > Subject: Re: Price information in SRU responses<br>
> > <br>
> > <br>
> > <br>
> > > 2) we may rely on system engineers to deal with unsollicited in
> a<br>
> > >responsible way. Many servers have extensions that might be
> useful for<br>
> > >others. Only extensions that are not useful for others should be
> on<br>
> > >request only<br>
> > <br>
> > This is my main problem with the proposal.<br>
> > <br>
> > 1. Surely if an extension is not useful, it wouldn't exist?<br>
> > <br>
> > 2. Assuming that there are non-useful extensions, how do you
> determine<br>
> > if an extension is or is not useful to the current client?<br>
> > <br>
> > 3. Assuming that you have a well implemented server, you could
> return<br>
> > an AWFUL lot of extra data about a record, the search, the terms
> in<br>
> > scan, etc. You're just wasting everyone's bandwidth and
> processing time<br>
> > by sending unwanted data that the client probably doesn't know what
> to<br>
> > do with. Yes you can safely ignore it, but that is not a zero
> cost<br>
> > option.<br>
> > <br>
> > 4. If, as a client, you want to get back anything, we have a
> way to do<br>
> > it -- the accept extension. I don't see why this should be
> forced on to<br>
> > everyone when clients that want it can easily have it. Just put
> it at<br>
> > the beginning along with the static operation and version parameters
> and<br>
> > forget about it. :)<br>
> > <br>
> > 5. For some clients, getting back unknown elements could break
> them if<br>
> > they use very strict XML processing rules. Enforcing something
> that is<br>
> > known to break otherwise well implemented clients is not good
> behaviour!<br>
> > <br>
> > Rob<o:p></o:p></span></font></p>
> >
> > </blockquote>
> >
> > </div>
> >
> > </body>
> >
> > </html>
--
John Harrison <[log in to unmask]>
University of Liverpool Library
|