Date:         Tue, 25 Jun 2002 12:33:25 -0400
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         "LeVan,Ralph" <[log in to unmask]>
Subject:      Re: sort parameter
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"

Yes, XPath style tagpaths is what I meant, but I'm still willing to go with
Alan's minimal proposal.

Ralph

> -----Original Message-----
> From: Ray Denenberg [mailto:[log in to unmask]]
> Sent: Tuesday, June 25, 2002 12:13 PM
> To: [log in to unmask]
> Subject: Re: sort parameter
>
>
> 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
>