Well then can we try to break the problem down, into "real" vs.
"hypothetical". I see "retrieving METS" as a more potential "real" problem.
----- Original Message -----
From: "Matthew J. Dovey" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Thursday, August 11, 2005 9:45 AM
Subject: Re: Betr.: Re: rec context set schema
Also the solution proposed doesn't handle multiple levels of wrapper
schemas within wrapper schemas.
> -----Original Message-----
> From: Z39.50 Next-Generation Initiative [mailto:[log in to unmask]]
> On Behalf Of Ray Denenberg, Library of Congress
> Sent: 11 August 2005 14:41
> To: [log in to unmask]
> Subject: Re: Betr.: Re: rec context set schema
> From: "Robert Sanderson" <[log in to unmask]>
> > 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]
> I still feel strongly about overloading a parameter, which is
> why I suggested a new parameter altogether. The problem with
> that is we would have to wait until the next version. That
> might not be an altogether bad thing - as I see it now, we're
> looking at a new version sometime in 2006,
> and at least we'd have an answer to the problem. We could,
> in the interim,
> come up with a "best practice" for the current version.
> However, I would say "if it contains more than one name, the
> first is assumed to be a container ..." rather than
> introduce the choice path.