 |
 |
Yuck. Despite the fun I've been having arguing philosophy, I still agree with Matthew that the solution to this particular problem is: "What problem?" > Envelope-to: [log in to unmask] > Delivery-date: Thu, 11 Aug 2005 11:47:24 +0200 > X-X-Sender: [log in to unmask] > Content-Type: TEXT/PLAIN; charset=US-ASCII > X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlx=0 > adultscore=0 adjust=0 reason=mlx engine=3.0.0-05072900 > definitions=3.0.0-05081100 > Date: Thu, 11 Aug 2005 10:44:00 +0100 > Reply-To: "Z39.50 Next-Generation Initiative" <[log in to unmask]> > Sender: "Z39.50 Next-Generation Initiative" <[log in to unmask]> > From: Robert Sanderson <[log in to unmask]> > Comments: To: "Z39.50 Next-Generation Initiative" <[log in to unmask]> > Comments: cc: [log in to unmask] > X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on bagel.indexdata.dk > X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham > version=3.0.0 > X-Spam-Level: > > Simple solution: > > > <recordSchema> in the request is a simple string. > > It can contain either the short name of a record schema (as mapped in > Explain) or the full identifier. > > > We could change the semantics to: > > It can contain one or more short names or identifiers. If more than one > is supplied and the first is a 'wrapper' schema, then the second and > subsequent should be returned within that wrapper. If the first is not > a know wrapper schema then the server should treat it as a choice of any > of the schemas. [currently an extension] > > eg: > > <recordSchema>mets dc rec</recordSchema> > > > If the server doesn't support this, it will return a diagnostic saying: > I don't support record schema "mets dc rec". > > If the server does support it, but doesn't support one of the individual > schemas, it could return: I don't support record schema "rec" > > If it's a choice and the server doesn't support any of the schemas, it > can return multiple diagnostics, one for each. > > > Rob >