Date:         Tue, 25 Jun 2002 12:13:19 -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

Alan Kent wrote:

> 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?)

In Ralph's original reference to tagPath he meant (I think) the XML analogy to the
Z39.50 tag path (which is roughly the Z39.50 element specification).  So I think
what he had in mind would be an XPath expression into the schema.

For example suppose the schema is MODS and you want to sort on date issued, you
would have an XPath expression into the MODS schema to designate the dateIssued
element within publicationInfo. Trying to come up with an example using MODS is
hard because everything (almost) is optional, so we would have to have some kind
of missing value action.

I think the confusion is that in the Sort spec, as you note elementSpec is either
an element set name or EXTERNAL -- the latter is supposed to be an
elementSpecification like eSpec (the element set name is the degenerate choice).

I'm just trying to clear this up, not advocate a position.


> > > 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?

Well I think our philosophy has been not to overload the protocol with support for
functions that aren't cited as requirements. If these are requirements, someone
should cite them and we'll support them. I think we've done good so far at
adopting functionality that people explicitly cite.

--Ray