Back to reality

["Ray Denenberg, Library of Congress" <rden@loc.gov>]

We've been  focusing lately on an abstract model;  the original idea was
that this model was to be the foundation for concrete specifications,
ensuring that these specifications would be compatible with one another.  In
recent weeks - the past two calls in particular - I think we've gotten
caught up in abstracting, to the point where if we continue along the lines
of yesterday's discussion we could risk abstracting ourselves into oblivion.

It was a wise decision to step back and sketch an abstract model before
progressing too far into concrete specs.  But  I have to remind us all that
we are chartered to develop a "killer" search syntax and protocol. If you
don't think that this is a worthwhile effort, you don't have to participate
in that aspect of our work --  there are several other aspects you can help
with.  However, whether or not  "SRU 2.0" is expected to result from our
work is not a debatable point; it is part of our charter. Similarly, an
openSearch binding is part of our charter.  Criticize the charter if you
like, but I reject any suggestion that we are not supposed to be doing
these.

The abstract model or "abstract protocol definition" as we agreed yesterday
to call it, and the description language - that we now agree is where we
need to devote significant attention - are two things that we didn't think
much about initially and have come to realize are critically important to
our work.  The idea that the spec we're developing will allow a client to
access any existing server, as long as that server provides a description
file (so that the server doesn't have to make any other changes, besides
providing the description file) is another concept that we didn't conceive
initially but have now adopted as part of our work.

In the post-spec world, there will be pre-existing servers that our spec
will address, and new servers conforming to one or more of the bindings we
develop. Those of you who care only about the first category can focus your
attention on that aspect of our work.

These three things: (1) abstract protocol definition, (2) description
language, (3) a specification that will allow a client to access any server
who  provides a description file  -- these are all good things, I endorse
them enthusiastically, and I thank you all for the brainstorming that has
brought them to light. In addition though, we are charged to develop an SRU
1.2 binding, an SRU 2.0 binding, an openSearch binding,  possibly other
application bindings, and several auxiliary bindings.

I intend that we proceed with all of these components of our work and that
all these efforts be well-coordinated with one another. Each committee
member is free to choose which of these efforts to devote his/her time.

Please give this careful thought, and share your thoughts. I'm going to
consider this discussion a continuation of yesterday's call and hold off on
minutes until we have something more conclusive to report than where we
ended up yesterday.

I think it is time to start thinking about subcommittees.  I request that
each committee member consider the following list and declare which activity
you are interested in, and which you are not. (And feel free to suggest
others.)

1. abstract protocol definition
2. description language
3. SRU 1.2
4. SRU 2.0
5. openSearch binding
6. ATOM and/or RSS binding
7. other

Thanks.

--Ray