Date:         Thu, 29 Nov 2001 15:36:41 -0500
Reply-To:     "Z39.50 Next-Generation Initiative" <[log in to unmask]>
Sender:       "Z39.50 Next-Generation Initiative" <[log in to unmask]>
From:         Ray Denenberg <[log in to unmask]>
Organization: Library Of Congress
Subject:      visibility for ZING
Comments: To: "Z39.50 Next Generation Initiative" <[log in to unmask]>
Content-Type: text/plain; charset=us-ascii

Sorry, it seems I've dropped out-of-the picture for a month
(or so). I'd like to follow-up belatedly on the things I
promised a while back -- to try to formalize ZNG (somewhat)
and give it some visibility.  Please give me comments on
these ideas. Soon as I get some feedback I'll get started.

First, I'll put up a web page for ZING, with pointers to the
two current components: SRW and ZOOM.  (I won't be doing
anything with ZOOM. Mike will maintain that.)  If someone
wants to design a logo, send it to me. (I've searched for
the logo we saw in the bar but I can't find it. If I find
it, I'll steal it. I don't think they'd care.)

For SRW, I would like to maintain a list of implementors, a
list of servers, specifications, and an issues list, for
starters (what else?)

1. Implementor information: name, organization, what your
implementing, description, other interesting information.

2. Server information: host, port, response schemas, record
schemas. What else?

3. Specifications.  Should I try to maintain the
"definitive" specifications here, or are they not stable
enough?

4. Issues list. I've looked through the discussion over the
past few weeks and listed a number of suggestions that I've
seen for consideration as  enhancements or changes.
    -  session-id
    -  server to include the query (or the whole url) in the
response
    - Database names
    - Should the response always be via soap, even when the
request is a url?
    - Diagnostics. (use human friendly,string description,
rather than bib-1 diagostics.)
    - return SUTRS
    - Record number
    - Format for DC
    - Prefixes
    - Allow url-parmeters that are not defined
    -Allow extra (even unsollicited) responses
    - Stylesheet url  in the request (so that server can put
this it in the XML-header, so that it can be used by browser
automatically.)
    -separate field and terms
    - the "I'm still dreaming" issue, which may break down
into several issues: How "exposed" should the parameters be?
In a soap envelope? In a URL?
    - Record structure
    - metadata sets

Let me know which are valid/interesting suggestions/issues,
which aren't, and what others are there.  When we come up
with a list, we'll add some description, and then I'll put
it up.

--Ray