Date:Wed, 10 Jul 2002 10:05:20 -0400
Reply-To:"Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:"Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:Ray Denenberg <[log in to unmask]>
Organization:Library Of Congress
Subject:Re: sort parameter
Comments:To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type:text/plain; charset=us-ascii
Mike Taylor wrote:
> > Date: Tue, 9 Jul 2002 13:49:52 -0400
> > From: "LeVan,Ralph" <[log in to unmask]>
> >
> > Well, the model is that the records aren't in any particular schema
> > and they get put into the requested schema on the fly. So, when you
> > ask for them to be sorted, you ask that first the records be
> > transformed to a particular schema and then you sort them on a field
> > (or fields) from that schema. Doing this, there is no mixture of
> > MODS and DC records. There are only records in the requested
> > schema.
>
> Huh. This is new to me. Matthew, is that what you'd understood too?
> Your example of surrogate diagnostics seems to imply not.
There are a few issues raised by this exchange.
You're mixing the sort/resultSet model with the present model.
Addressing the present model (leaving aside sorting for the moment) there is
the question of whether in a sequence of returned records can two records be
presented in different schemas. Obviously so if you include the surrogate
diagnostic schema, but can one record be in MODS and another in DC? Yes, if
the schema parameter is omitted and the first record is available in MODS
only and the other in DC only. Suppose the record schema parameter is
included, and it's MODS? We haven't answered this but I suspect the answer
is you get a surrogate diagnostic for the one that's not available in MODS.
Finally, the sort model you quote no longer applies, we discarded it several
weeks ago. We're not sorting result sets according to a schema, but rather
by abstract names.
--Ray