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
>