Re: Retrieving Full output

Edward C. Zimmermann wrote:

>Quoting Mike Taylor <mikeindexdata.com>:
>
>
>  
>
>>Selection of record _syntax_ (MARC, XML, SUTRS,
etc.) is orthogonal(*)
>>to selection of record _subset_, which is that
element-set name such
>>as "F" (full) and "B" (brief) is
for.
>>    
>>
>
>In Zebra this may be the case (I don't know) but
"F", "S" or "B" don't have
>to be record subsets. The "Brief" record (as
other "synthetic" elements)
>may indeed contain extracorporeal material. The element
"F" is really
>also misleading since there is nothing about
"F" to say that its really
>the full-record (or even that there is a "full
record") but its what's
>been (nearly arbitrarily or set forth in a profile)
decided to be the
>"F" render of the record in the specified
syntax. Nothing even says that
>these need to be constant or consistent. We indeed in
our servers often
>have different renders for different sets of users. The
semantics of what
>"F" is can even vary from record syntax to
record syntax and object to
>object (what the data behind the engine is). In some
profiles "F" may
>need to contain all the elements (per agreement in the
profile) but there
>is nothing to say this should apply to others-- and in
our case it does not.
>
>There is nothing really in Z39.50 (or in YAZ's
implementation) to prevent
>us from having fun! Some of the profiles may tie things
down but many don't.
>  
>
I'm fond of comparing it to the quantity of beer you get in
a 'large' as 
opposed to a 'small' glass. Conventions vary widely, and the
best you 
can hope for is to get more beer if you ask for 'large', but
even that 
is hardly a given.

For the same reason, most of our general-purpose Z39.50
clients will 
tend to always ask for 'F', no matter what the purpose of
the retrieval, 
rather than gambling on (or having to know about) the
particular 
behavior of the server.

SRU attempts to be a lot more specific by referring to
explicit XML 
schemas for retrieval, and allowing the client to ask for
specific 
subsets (from supporting servers) using Xpaths. Nice stuff,
but 
potentially more decisions for the client-developer to make.
 

--Seb

-- 
Sebastian Hammer, Index Data
quinnindexdata.com   www.indexdata.com
Ph: (603) 209-6853 Fax: (866) 383-4485


_______________________________________________
Yazlist mailing list
Yazlistlists.indexdata.dk
http://lists.indexdata.dk/cgi-bin/mailman/listinfo/yaz
list