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.
> 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.
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" --