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/extraQuery-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>
|
