On Mon, Jun 24, 2002 at 10:26:35AM -0400, Ray Denenberg wrote:
> Alan Kent wrote:
>
> > Using element paths I dislike because I don't know how to turn it into
> > a Z39.50 sort request.
>
> Wouldn't it map to 'elementSpec'? The three suggested key types -- index,
> element path, and "generic" -- map directly (almost) to the three Z39.50
> types:
> (asn.1 identifiers, in reverse order) sortAttributes, elementSpec,
> and sortfield.
I might not understand what the element paths are then. Are they
elements from an element set, or XML elements in returned records?
(The word "element" is unfortunately overloaded.) And how does a
path map onto an elementSpec? (elementSpec is a choice of an
element set name or an EXTERNAL - so how to map an element path
to an elementSpec?)
> > I hesitate to say 'lets support asending/descending, but not case
> > sensitivity or missing value action', only because someone may come
> > along later and want it.
>
> I don't hesitate to say it. Ascending/descending has been cited as a
> requirement; the other two haven't.
Haven't? Or haven't yet?
But as I said, I don't really care on this one. We support ascending,
descending, ascending by freq, descending by freq, missing value actions,
and case sensitivity. But I agree that most people don't care about
all the complexity. So I guess you are proposing:
* Have an ascending/descending flag
* The gateway can choose all the other parameter values
If you want to support three different ways of identifying what to
sort on, how are you going to differentiate them in SRU? Three
different parameters? XML in a URL parameter (yucko)?
My other concern is only slight - and that 3 sort mechanisms are overly
complex when we want to keep things simple.
Another hybrid then I will be quiet and let those who care more
on this one decide:
* sort key name - up to gateway to decide meaning (could be attribute
list, element set name, whatever gateway likes)
* ascending/descending flag
Alan
