From: "Ed Summers" <[log in to unmask]>
> I think the mere fact that we are not understanding each other (or
> purposefully disagreeing) and the dearth of folks who actually need
> the functionality is reason enough to not complicate the spec by
> adding it.  There is nothing to prevent the one person who wants this
> ability to add it to their server is there?

Need to separate three issues here: (1)  not understanding/purposeful
disagreement; (2) complicating the spec (3) do this or leave it to
individual implementors.

(If I seem to belabor this, it's not because I think this extension itself
is that important, but there is a larger,  philosophical issue about how we
develop specifications for the at large SRU community.)

As to the first : there are many examples in the world where certain default
behavior is specified (in fact mandated) in the event that the desirable
behavior cannot be supported. So I'm cynical about the "not understanding"
suggestion, though I'm not suggesting "purposeful disagreement" but I am
somewhat baffled.

As to the second:

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.

If we are committed to (a) then fine, we don't need extensibility.  But I
doubt that we are going to do (a), and I think it's a bad idea to even try -
I don't think we have the expertise to develop administrative metadata for
the potential universe of SRU applications.

So, assuming we're not doing (a), then if we're not going to provide
extensibility (b), then  we should give up (c).

(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.)

However ...

As to the third issue: whether we help implementors by providing guidance
and help with specifications, or just leave them on thier own, this is the
philosophical issue, I think.

I believe that the SRU implementors group is the appropriate body to develop
commonly used and extensible specifications and extensions for the universe
of SRU applications.

--Ray