-----Oorspronkelijk bericht-----
Van: SRU (Search and Retrieve Via URL) Implementors [mailto:[log in to unmask]]
Namens Mike Taylor
Verzonden: vrijdag 28 maart 2008 16:01
Aan: [log in to unmask]
Onderwerp: Price information in SRU responses

>Yakov Shafranovich writes:
> > I am working on a SRU gateway for a book publisher. One of the
> > things I have run into is that there is no way to pass pricing
> > information in SRU without using the ONIX scheme. Is there a way to
> > embed pricing information in SRU responses using other schemes?
>
>Hi, Yakov.  Sure, you can embed whatever information you want in
>records transferred via SRU, just as you can with any other XML
>document.  Just add the elements you want wherever they make most
>sense in the record, and be sure to put them in a namespace other than
>that of the standardised part of the record.  For example:
>
><dc:record xmlns:dc='http://purl.org/dc/elements/1.1/'
xmlns:mike='...'>
>  <dc:identifier>12345</dc:identifier>
>  <dc:creator>Hillare Belloc</mike:remitter>
>  <dc:title>Poems for Bad Children</dc:title>
>  <mike:price>5.99</mike:price>
></request>
>
>The problem is: how do you get the client application to recognise and
>understand the extra information you've added?  To make that work, you
>need an agreement between server and client about the format of the
>records -- in other words, the client needs to know that it will not
>just be getting DC records, but DC-extended-with-mike:price records.

Suppose my client finds that target in a registry or a user knows that
target and wants to use my client to talk to that target. My client is
capable of ignoring unknown fields and my client is also capable of
displaying unknown fields if the user wants that. 
Bad luck for that user: My client doesn't know the name of that format
and doesn't know that it is perfectly capable of presenting this format
because it is 95% Dublin Core with some extensions, as it would be
capable of presenting most other schema's containing DC with some extra
fields. There seems to be a need for a single recordSchema name for this
purpose rather than having another name for each extension.

Theo