Mike - Suppose we use your approach (valueless extension where 'rec' is
always implied) and along comes a LOM implementor who wants a way to include
record metadata using the LOMAM (LOM administrative metadata) schema.  What
do we tell them? 

"We'll dump all the elements you need into rec."  Yes, we might do that, but
you'd have to shoot me first. No matter, I'm confident you're not going to
suggest that. 

Two extensions? One valueless/rec-implied, and a single, second extension
where a value is supplied? 

That may be a reasonable approach but I'm not sure it solves the
interoperability problems you cite about my suggested approach.  

--Ray

-----Original Message-----
From: SRU (Search and Retrieve Via URL) Implementors [mailto:[log in to unmask]] On
Behalf Of Mike Taylor
Sent: Saturday, May 05, 2007 5:29 AM
To: [log in to unmask]
Subject: Re: Record Metadata Schema (was Re: "collection" context set)

Ray Denenberg, Library of Congress writes:
 > > under Ray's proposal, my server would not be at liberty to  > > support
only the one true record metadata schema -- or, at least,  > > I'd have to
make it reject some record metadata requests, .....
 >
 > No. Wrong.  On both counts.
 >
 > Your server would ignore the value altogether.
 >
 > The request: 'x-info-99-metadata=dc' would mean: "Please supply  >
metadata according to the 'rec' schema (unless you happen to have  > it
available in 'dc')."

Oh, yes, you're right -- I'd forgotten that under your proposal, the
parameter which specifies which formats are acceptables lies.

Then rather than have the parameter say "you can returns any of these OR
rec" wouldn't it be better just to have the parameter _include_ rec?  Seems
more transparent.

 > So: (1) yes, your server would be at liberty to support only the  > one
true record metadata schema, and (2) no, you would not have to  > make it
reject some record metadata requests.

OK.

 > And the analogy to Explain is flawed.  Are we going to put that  > level
of intellectual effort into developing the perfect metadata  > format that
we put into explain?

No, because this is a much simpler problem.  We can easily see the truth of
that by looking at the rec context-set, which is what the schema will be
based on.
	http://srw.cheshire3.org/contextSets/rec/1.1/

Ray Denenberg writes:
 > As I see it there are three choices:
 > (a Develop the perfect/universal record metadata schema.
 > (b) Develop a good (not perfect) one and allow some degree of
extensibility.
 > (c) Forget the whole matter, let people develop their own private
 >     extensions for administrative metadata.

You've forgotten (a.5), which is: "write down a Good Enough metadata schema
that meets all interested parties' present needs.  Maintain this, as we
already do for all context sets, by adding such further elements as may be
required in the future."

 > (And lest one suggest that the rec schema itself be the dumping  > ground
for all sorts of record metadata - well just look at some  > earlier
well-meaning efforts like bib1.)

Not a good analogy.  As you well know, the one-attribute-set-per-query
limitation of Z39.50 v2 meant that BIB-1 became the dumping ground for
_every_ _single_ attribute -- not just those pertaining to a well-defined
application domain.  The correct analogy is with the Record Metadata context
set.

 _/|_	 ___________________________________________________________________
/o ) \/  Mike Taylor    <[log in to unmask]>    http://www.miketaylor.org.uk
)_v__/\  "You don't want to ask customers what they _want_ out of piece
	 of software, because it might be difficult to implement" --
	 Andrew Eland.