Date:         Mon, 2 Feb 2004 16:36:17 -0500
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         "Ray Denenberg, Library of Congress" <[log in to unmask]>
Subject:      Re: XPath and Validation
Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Content-Type: text/plain; charset="iso-8859-1"

Rob -- I've made the changes, and I appreciate your last minute efforts to
craft a solution for this.

But I feel I need to raise this issue,  that I think we need to consider
carefully.   There was a point (ten years ago) in the development of Z39.50
where we introduced eSpec and it changed our whole way of thinking.  We're
at an analogous point.

Before eSpec, the Z39.50 record syntax parameter served both as (1) the
abstract view of the record for purpose of selecting elements, and (2) the
desired transfer sytax. Until we started talking about selecting elements
(beyond using simple element set names) nobody thought about the difference.
Discussion of element selection made us realize that there's a difference,
and we introduced the Z39.50 "schema" parameter  (via compSpec) to
distinguish the two.

I don't want us to do similar, elaborate modelling as we did in Z39.50. But
the fact is that we are, implicitly, modeling element selection. And the
question is: do we want our record schema parameter to be (1) the abstract
schema for purpose of record selection, or (2) the schema that we want used
for transfer of records in the response.

Z39.50 uses the first approach. Your approach is (2).   If we want our model
to be compatible with Z39.50's, I think we want to put the real schema in
the schema parameter on the request, the xPath schema in the response, and
drop the rule that they have to be the same.

--Ray


----- Original Message -----
From: "Robert Sanderson" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Monday, February 02, 2004 7:15 AM
Subject: Re: XPath and Validation


>
> Attached is a revision of record-xpath.html and a new xpath-schema.html
> which documents the schema.  Matthew, if you could generate a sensible
> .xsd for it, would be greatly appreciated.
>
> Other changes required:
>
> service.html:
>
> Change:
>   "An XPath expression, relative to the recordSchema supplied, to be
>    applied to the records before..."
> To:
>   "An XPath expression, plus optional recordSchema identifier, to be
>    applied to the records before..."
>
> Delete the second sentence.
>
>
> introduction.html:
>
> Change:
>   "The XPath given is in relation to the schema given in the recordSchema
>    parameter."
> To:
>   "The record schema against which the XPath expression should be
>    evaluated may be included in this parameter."
>
>
> records.html
> Replace the RecordXPath section with:
>
>   "This parameter may contain an XPath expression with an optional record
> schema.  If present, the server should evaluate the expression and return
> the result using the XPath result schema.  Further details are available
> in the _Record XPaths_ documentation."
>
> _Text_ linked to record-xpath.html
>
> Change:
>   "'http://www.loc.gov/zing/srw/dcschema/v1.0/'"  in the recordSchema
section
> To:
>   "'info:srw/schema/1/dc-v1.1'"
>
>
> (Phew!)
>
> Rob
>
> --
>       ,'/:.          Dr Robert Sanderson ([log in to unmask])
>     ,'-/::::.        http://www.o-r-g.org/~azaroth/
>   ,'--/::(@)::.      Special Collections and Archives, extension 3142
> ,'---/::::::::::.    Nebmedes:  http://nebmedes.o-r-g.org:8000/
> ____/:::::::::::::.
> I L L U M I N A T I
>
>
>