Ralph <[log in to unmask]> wrote:
> You seem to have some confusion about recordPacking. In the fragment
> you twice seem to be saying that the alternative to XML for a record
> response is plain text. That's not true.
>> The results of searchRetrieve operations can be returned
>> in any number of formats, as specified via explain
>> operations. Examples might include structured but plain
>> text streams or data marked up in XML vocabularies such
>> as Dublin Core, MARCXML, MODS, etc. Below is a simple
>> request for documents matching the free text query "dogs":
>> In this case, the server returns three (3) hits and by
>> default includes Dublin Core title and identifier elements.
>> Each record is packaged in XML as opposed to formatted
>> plain text:
> Records are always returned as XML. RecordPacking specifies whether
> XML can be embedded directly into the response or if it should be
> into a single string and then embedded. The rendering simply turns
> '<' and
> '&' into HTML entities of some kind. This renders the XML record
> to the XML parser that is handling the response. Subsequent
> processing can
> turn the entities back into characters and the XML record can then be
> over to an XML parser. This string representation can save
> wasted parsing during the message processing.
> It would seem that string encoding would be the clear choice for all
> responses; so why the XML recordPacking option? For those of us
> thin clients in SRU, we use XSL stylesheets to render the response.
> string encoded records look like a single atom to XSL and can't be
> rendered. So we asked for the records to be directly embedded; hence
> XML recordPacking.
Thank you for the feedback. This is *exactly* the sort of thing I
required. I will edit accordingly, and share with y'all the URL of
article when it gets published.
Eric Lease Morgan
University Libraries of Notre Dame