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