> Date: Fri, 4 Jun 2004 13:01:03 +0200
> From: Marc Cromme <[log in to unmask]>
>
> approach a) woun't fly, since then I have to know each server
> specifically to figure out where in the returned record this
> information is buried, and in which form. What a hell of a logic to
> write for a federated search over some 30-50 targets!
Actually, this works just fine in the Brave New World of SRW in which
servers know the specific profiles they are implementing (as opposed
to the naive and carefree days of early Z39.50 when people did what
they felt best). But I agree that approach (B) is much better, so
there is no need to discuss this one.
> approach b) is much better, but only if all agree that the same tag
> is used inside the extraRecordData packet to carry this information,
> and that all servers agree to encode it in some unified fashion.
Of course they do. This is precisely why people publish extensions
such as the record-schema negotiation extension described at
http://www.loc.gov/z3950/agency/zing/srw/extra-data-example.html
See
http://www.loc.gov/z3950/agency/zing/srw/extra-data.html
for a description of the process. This stuff is all well-defined.
> I do not have SRW on my fingertips, but I belive that there is no
> such 'reserved' tag inside the 'extraRecordData' tag, and if it is
> not defined by the standard, we are back to the problems of approach
> a).
Not everything belongs in the core standard. For example, SRW knows
nothing about Dublin Core per se -- the DC indexes are specified in a
separate, though related, CQL index-set document. This case is
analogous. Just so long as people know where to look for the
associated specifications, we're fine.
_/|_ _______________________________________________________________
/o ) \/ Mike Taylor <[log in to unmask]> http://www.miketaylor.org.uk
)_v__/\ "Not THOSE stars, you cloth-eared heap of anteater's
catarrh!" -- Monty Python's Flying Circus.
--
Listen to free demos of soundtrack music for film, TV and radio
http://www.pipedreaming.org.uk/soundtrack/
|
