Z39.50 IMPLEMENTORS GROUP MEETING Day 1 - September 21, 1994 ASSIGNMENT OF MINUTES DUTY Denise Troll was drafted by Mark Hinnebusch to take the minutes for the ZIG. In posting these minutes, I've tried to retain the flavor and confusion of the discussions. In several cases, discussion was deferred until later in the meeting, but was never taken up again. (Someone should cite these for the next ZIG agenda?) I included the names of the speakers whenever I had them in my notes. INTRODUCTIONS AND STATUS REPORTS ZIG members introduced themselves and provided quick updates of their Z39.50 work. Those attending were: Ball, Alan - Aball Software Bivona, Eric - Dartmouth College Blair, George - ConQuest Software Inc. Brainard, John - VTLS Brewster, Dave - Eisenhower National Clearing House Cattey, Bill - MIT Dekkers, Max - Pica Denenberg, Ray - Library of Congress Donelan, Sean - DRA Dousti, Parviz - Carnegie Mellon Computing Services Esty, Jay - Silver Platter Evans, Charles - EBSCO Ferrin, Eric - Penn State University Fuchs, Rich - RLG Gamiel, Kevin - MCNC-CNIDR Gaster, Jeanne - West Publishing Co. Gravbart-Cervone, Jeff - Ameritech Library Services Gutsky, Mike - CD Plus Hinnebusch, Mark - FCLA Jordan, Bill - University of Washington Kopp, Kurt - University of Missouri Kunze, John - University of California Lazear, Manette - Mitre LeVan, Ralph - OCLC Loy, David - Dialog Lynch, Clifford - University of California Lynch, Denis - TRW Manson, Bob - Eisenhower National Clearing House Marchuk, Mike - Follett Sofware McLean, Brad - Gaylord Information Systems Moen, Bill - Syracuse University Needleman, Mark - University of California Oates, Andrew - GEAC Orlik, Ralph - Library of Congress Over, Paul - NIST Preston, Cecilia Randall, Sara - Ameritech Library Services Roby, Thorn - CARL Corp. Smith, Gary - UMI Soffer, Stuart - Taliesin Software Research Stovel, Lennie - RLG St. Pierre, Margaret - Consultant, WAIS Inc. Sullivan, Terry - FCLA Tibbetts, Margery - University of California Troll, Denise - Carnegie Mellon University Libraries Troll, Ryan - Carnegie Mellon University Libraries Turner, Fay - National Library of Canada Turtle, Howard - West Publishing Co. VanDam, Dennis - West Publishing Co. Waldstein, Bob - AT&T Warnock, Archie - A/WWW Enterprises Washborne, Brent - MARCorp Wibberly, Les - CAS Wooder [??], Chris - Bunyip Information Systems Zeeman, Joe - Software Kinetics FORUM REPORT Approximately 25-30 people attended the Z39.50 forum, including 7 or 8 new ZIG members and 1 non-ZIG person. Cliff Lynch explained that the forum was held as a proactive, experimental approach to the v3 ballot process. How well we reached voting NISO members beyond the ZIG is uncertain. Several forum items were put on the ZIG agenda: bib-1 attributes, Explain testbed, version 3 interoperability testbed. Considerable time at the forum was also spent discussing the size of the standard document itself. Ray Denenberg commented that the outreach to voting NISO members did not happen at the forum. Some attendees were frustrated that the objectives were not achieved, but the impression overall was that a good high level discussion did occur. We may need another forum after the ballot if there are a lot of "no" votes. Perhaps those who vote "no" should meet with the ZIG. A second forum should be better prepared and aimed at non-ZIG members meeting ZIG experts. The event could be timed with ALA or ASIS, where non-ZIG members will be gathered. STATUS OF BALLOT AND DRAFTS Ray Denenberg briefly described the editorial process with NISO and the review cycle. There was no time for a review cycle prior to distribution of the NISO version, which is missing the copyright statement. There will be a review cycle prior to the final publication. Fixed ASCII is currently available online. The ballot period is September 1 to November 30. SHORT WALKTHROUGH OF BALLOT DRAFT Ray Denenberg paged through the latest draft of the standard and noted changes since the previous ZIG meeting. Changes were made based on discussion at that meeting or on the list. Les Wibberly raised a question about the role of ballot comments and "yes" and "no" votes. Ray responded that we will work hard to resolve problems ("no" votes or negative comments) with strong technical merit, but ignore comments with little technical merit. Denis Lynch and Ralph LeVan asked in unison: who will resolve the problems, the ZIG or the Maintenance Agency? Ray said it was not useful to speculate on this until we see the comments. We will try to resolve problems at the January ZIG meeting. NISO requires "a good faith effort to resolve 'no' votes." We will reballot at NISO's discretion. Additional comments of merit / interest during the walkthrough: * Page 95 - urx; boundary between url and urn is murky- testy discussion deferred to later in the meeting. [Cliff Lynch, Denis Lynch, Ray Denenberg] * The diagnostics we need won't become apparent until we implement v3. Diagnostics may need to be modified or redone in v4. [Ray Denenberg] * We can add, but not change, things until next ballot. [Mark Hinnebusch, Ray Denenberg] * We need a mechanism to handle cases where implementors have done something in the draft that is later removed. Topic deferred until discussion of ballot cycle and standard development. [Les Wibberley] * What about color support? [Mark Hinnebusch] * Pages 148, 150 - Should cross-reference Maintenance Agency document that lists registered types and int units. The document does not (yet) exist [Ray Denenberg]. Is this a profiling issue since it's an implementors' agreement [Ralph LeVan]? If it is a profile agreement, then it doesn't belong in the standard [Ray Denenberg]. But interoperability depends on a set of int units [Les Wibberley]. The standard should reference the Maintenance Agency, which may point somewhere else, e.g., Ralph LeVan at OCLC [Mark Hinnebusch]. REGISTER Hasn't changed since July. The register was circulated for people to mark changes or initial if there are no changes. New members were to add themselves to the register. Editorial comment: The register never reached all of the attendees. For example, I'm a new member and I didn't get it. Ray, how are we going to address this? PLANS FOR PROGESSION OF VERSION 4 Ray Denenberg, editor of the standard document, briefly described the historical procedure for creating a new version. In short, version 3 started with an outline indicating new features. By draft 4, the document showed changes to version 2. By draft 7, it included appendices. By the next ZIG meeting, Ray will have an outline of version 4. ZIG members should submit proposals for things to be included, omitted or changed in v4. We may do a formal survey a year from now, like we did with v3. It's not clear that we'll spend years preparing and balloting v4. That is, we may need a different NISO process for quick additions and changes, i.e., a "fast track" for "amendments" to the standard. URL SUBGROUP STATUS REPORT The URL subgroup is defining one or more URLs for Z39.50. Paper work is available. We can craft this as one URL, but are keeping things separate for now. The goal of this subgroup at the ZIG meeting is to reach concensus on the URL(s). [Brad McLean] RELATIONSHIP OF BALLOT CYCLE AND PROTOCOL DEVELOPMENT Lines between v2 and v3 implementations are fuzzy. What are the rules? Tables need to be prepared faster than the ballot process. [Bob Waldstein] There is a distinction between the protocol version and the standard and the version of a particular OID [Ray Denenberg]. For example: * Z39.50-1992 = v2, which can use scan, sort and new attribute values * Z39.50-1994 = v2 and v3 * Z39.50-1996 (?) - may not require a new version of the standard Then a discussion ensued about what should be part of the standard and what should live outside of the standard as an implementors' agreement. Here are some snippets to give you the flavor of the discussion: * If it's not in the standard, it's an implementors' agreement and belongs in the OIW (Open System Environment Inplementor's Workgroup) [Ralph LeVan]. * No, bib-1, record syntaxes and OIDs are more than implementors' agreements [Ray Denenberg]. But if they're part of the standard, we can't add new ones (legally) without a ballot. * Some of these items, e.g., record syntaxes, will be useful outside of Z39.50, for other internet information services [Cliff Lynch, Chris ??] Summary of issues to be considered: (a) complaints that the standard is too long, (b) how do we maintain the integrity of the objects (on which interoperability depends) if they are maintained outside of the standard, (c) re-use of items [Ray Denenberg] Assuming that the Maintenance Agency will maintain the integrity of object definitions, we can move them outside of the standard, but the ZIG must reach concensus to do this. What is our concensus-building process? We also need a mechanism for maintaining attribute sets outside of the standard. Ray Denenberg proposed a model where the Maintainence Agency maintains or delegates maintenance, e.g., to STAS or CNIDR. Should attribute sets be discussed or posted on listservs? Should their be advisory boards for attribute sets since they're discipline specific? This led to a discussion of how we decide when something gets a public, rather than a private, OID. Who will control and maintain public OIDs if they move outside of the standard? Ralph LeVan proposed that the ZIG decides whether an attribute set gets a public OID and makes a recommendation to the Maintenance Agency. The ZIG may delegate the content of the attribute set to another group to determine or specify. Mark Hinnebusch and others asked why the ZIG should be involved. Why not just go straight to the Maintenance Agency? The topic closed with some general observations: * All attribute sets are not created equal. * Bib-1 must be part of the standard, if only for political reasons [Ray Deneberg]. * Explain and Extended Services must be part of the standard. "WHITHER THE ZIG" Fay Turner expressed concern about the ZIG continuing development of v4 before v3 is stabilized, standardized and implemented. She asked for a clarification of the role of the ZIG. The group agreed to the following functions for the ZIG: * To create / evolve the standard * To document the standard * To discuss related issues, e.g., testbeds * To profile developments * To work towards interoperability * To implement and stabilize the standard, leading to review of the standard and an analysis of whether it's meeting its objectives * To act as an advisory board for the Maintenance Agency Alan Ball objected to two other roles proposed for the ZIG: * To promote use of the standard * To conduct research related to the standard and its use Les Webberley said that we are (or should be?) implementing and verifying that things work before we include them in the standard for ballot. Given the roles of the ZIG, what about its size and the frequency and length of meetings? Perhaps subgroups should be created to address each bulleted item above, with each subgroup holding separate--but not overlapping--meetings at the ZIG [Mark Hinebusch]. Bob Waldstein objected to dividing the group into subgroups. Historically, some subgroups have worked (e.g., Explain), others have not. Sara Randall proposed that the testbed should be a high priority, but run in parallel with v4 development. She commented that we thought v2 was impossible to implement, but we did it. History may repeat itself with v3. This led to a brief discussion of models for the testbed, e.g., single vs. multiple group implementations, proof of concept vs production requirements. "The right approach depends on the context" [Ray Denenberg]. Cliff Lynch noted that you can do anything you want with v3 and still comply with the standard, even if you can't interoperate with anyone. (Maybe because the focus of v3 was on new features?) Cliff is concerned that more subgroups will create an even larger spec with even less likelihood of interoperability. A modularized standard was proposed as an alternative to the current situation. Mark Hinnebusch used the metaphor of a car to elaborate the model: * You want a car = you want Z39.50. * You want a compact car = you want bare bones Z39.50. * You want a luxury car = you want Z39.50 with Extended Services. So--what does "Z39.50" mean? We need profiles to conduct a testbed [Ray Denenberg]. That's v4 again [Alan Ball]. We need profile testbeds [Ralph LeVan]. Z39.50 v2 had an implicit profile, i.e., bib-1; v3 has multiple profiles, with intersections and cross overs that have not been addressed, but must be addressed for interoperability [Brad McLean]. We should make the goals of Z39.50 v3 explicit [Max Dekker]. Bill Catty stated the (a?) bottom line: We need to standardize bibliographic searches so that we get the same results across bibliographic databases. Mark Hinnesbusch agreed that we need a basic v3 bibliographic profile. Ray Denenberg proposed 2 bibliographic profiles: one for v2 and one for v3 (which may be a subset of the v2 profile--hints of the DRA use attributes controversy). Ralph LeVan proposed that the OIW SIGLA write the bibliographic profile. Ray Denenberg agreed to meet with Ralph privately to discuss this. Mark Hinnebusch suggested that future ZIG meetings should put v3 implementation issues on the agenda first, followed by v4 protocol development issues. Alan Ball requested that the agenda be prepared and distributed in advance of the meeting. Les Webberley proposed that subgroups meet informally the day before the ZIG meeting. NEXT ZIG MEETINGS * January 11-13 - Palo Alto, California; tutorial and resolving "no" votes * April 26-28 - Leiden, Netherlands * September 18? - Library of Congress, Washington D.C. KNOWLEDGE SHARING Current tools (ISO DE and SNACC [??]) "require tweaking" the ASN.1 to get it to compile correctly [Denis Lynch]. We need to collect and distribute this information to implementors. There was a brief discussion of whether we should fix the v3 ASN.1 so that it compiles correctly [Les Webberley], or whether we should fix the tool [Ray Denenberg, Denis Lynch, Bob Waldstein]. Bob has (or will create?) a Mosaic home page with ASN.1 tips. STAS Les Webberley distributed 4 documents related to STAS and requested a public OID to replace the current private OID. CAS is giving up ownership of the attribute set and elements and turning maintenance over to CNIDR because publishers and vendors are more comfortable using them if they're in the public domain. USPTO is already using STAS. Do the STAS attributes and elements go into the standard? We include CCL, GILS, WAIS [Ray Denenberg]. Or should the standards document or a cover letter attached tell people to contact the Maintenance Agency for information about CCL, GILS, WAIS, STAS? Providing the ability for commercial groups to add attributes adds breadth and encourages use of the standard. (For example, Dialog may add attributes for astronomical coordinates.) This was followed by a big debate about STAS search field codes which were seen as problematic because they (a) confuse client and server roles, (b) add to the complexity of interoperability, (c) create unnecessary grief with international languages and character sets. The search field codes will not be required as part of the Type 1 query, but may be passed from the server to the client for display. If different vendors are going to produce different attribute sets, we need a mechanism for normalizing and removing redundancies across attribute sets. Also, should use attributes include structure, e.g., for dates? [Ralph LeVan] Z39.50 IMPLEMENTORS GROUP MEETING Day 2 - September 22, 1994 PRESENTATION OF COMPLETED Z39.50 URLS The session and fetch URL is completed. The proposed URL was: Z39.50://host[:port][/database][/docID][/...] When users click on this URL, it will open a Z39.50 client ("helper application"), point to the existing service, construct a RPN query, and return a result set with one or more items. The Z39.50 client will then either convert the items to HTML for display in Mosaic or open the Z39.50 client to the user. The Z39.50 client is responsible for determining whether or not to open to the user. [Brad McLean] Potential problems cited for this proposal were: * DocIDs change over time. The ID should be a logical ID. [Ryan Troll] * What about the result set name? Should it be included [Alan Ball]? Is this a transient or persistent result set [Ray Denenberg]? Result set name is not part of the query [Denis Lynch]. * Prefix Z39.50. Mosaic clients reference an external table that indicats what "helper" application to launch. MIME figures out how to display the items retrieved. Three unresolved issues remain [Brad McLean]: 1. Element set names (ESN) - The client decides if the URL does not supply ESN. ESN to be specified at a later date. 2. Should we restrict this to retrieving a single document or enable retrieving multiple documents (with the client deciding what to do if there are multiple items)? 3. Access control (user ID and password). Mark Hinnebusch noted that the common URL handles user ID and password, but we must use Z39.50 ID Auth. Do we want 2 URLS (one to fetch and close, the other to be interactive) or 1 URL (that launches a helper to determine whether to fetch and close or run interactive)? Mark Hinnebusch framed the question, but many ZIG members participated in the lengthy debate, in the midst of which Ray Denenberg pointed out that the URL must include the record syntax. The debate was tedious, but well done, with ZIG members switching camps throughout. Leaders (rhetors) eventually arose for the two camps and final arguments were given. Ralph LeVan argued for 2 URLs. Denis Lynch argued for 1 URL. Mark Hinnebusch somehow divined concensus and the shot was called: there will be 2 URLs: Search URL: Z39.50s://host[:port][/database[+database...] [/term[&ESN=elementset][&RS=recordsyntax[+recordsyntax]]]] Retrieve URL: Z39.50r://host[:port][/database[+database...] [/term[&ESN=elementset][&RS=recordsyntax[+recordsyntax]]]] Database name is required. Any missing components default to the client's choice. If more than one record syntax is provided, the first one in the sequence is preferred. If the client cannot handle the preferred syntax, it my choose among the others. John [??] was commissioned to take our URL proposal to the IETF URL group. INCOMPLETE Z39.50 URLS Due to the time spent debating the search and retrieve URLs, the discussion of incomplete Z39.50 URLs was deferred to the URL list: listserv@cnidr.org subscribe zurl zurl@cnidr.org EXPLAIN TESTBED Max Dekker will be the leader for the Explain testbed. He will be conducting a pilot test of Explain starting in January 1995. Mark Hinnebusch will be conducting a similar pilot in Florida, perhaps offering a public domain Explain service to help other groups get started. The Explain testbed discussions will use the ZIG listserv. This is a risky undertaking because Explain is being balloted now. Ray Denenberg encouraged the undertaking nonetheless, saying that we can fix the final version of the standard text later. OIW / SIGLA MEETING REPORT Ralph LeVan described the OIW as "a legal fiction of the federal government to collaborate on standards development." SIGLA is the group where implementors agree on library information standards. They have profiled GILS and WAIS (both Z39.50 profiles), and are currently working on an ILL profile. Ralph is the chair of SIGLA. SIGLA is supposed to meet with the OIW (quarterly meetings, registration $300), but Ralph has proposed their meeting with the ZIG instead. BIB-1 DISCUSSION The bib-1 attributes discussion group, led by Bill Catty, met over lunch and briefly reported to the ZIG. Bill is the custodian of a new version of the previous (non-normative) document. A new listserv will be created for this discussion. The new list with recommended semantics for interoperability will be available at the next ZIG meeting. Mark Hinnebusch summarized the work plan: * Figure out the semantics of the attributes (if possible) - what they mean and how they work. * If attributes are ambiguous, recommend that they be deprecated. INTEROPERABILITY TESTBED (ZIT 1994-1995) Cliff Lynch agreed to lead a series of focused interoperability testbeds for implementors, emphasizing technical issues and demonstrating new kinds of applications, services and data (rather than a testbed for user communities). The goals are to demonstrate interoperability and the usefulness of subsets of v3 [Les Webberley]. The Explain testbed (led by Max Dekker, with Mark Hinnebusch, Ralph LeVan, and Bob Waldstein) is one component of ZIT 1994-1995. Brad McLean proposed that we identify viable subsets of v3. Cliff took an informal poll of what ZIG members were planning to implement in the next 6 to 9 months. The votes looked something like this: 17 - scan 13 - explain 12 - item order 8 - sort 8 - segmentation, full text and images 7 - different record syntaxes 6 - access control 6 - resource control 3 - WAIS and GILS profiles 3 - close 2 - added search info 1 - presenting ranges 1 - concurrent operations 1 - URL 1 - diagnostics 1 - STAS 1 - extended services 2 - delete result set 1 - save result set 1 - update CHARACTER SET AND LANGUAGE NEGOTIATION Max Dekker distributed a draft proposal entitled "Definition of character set / language negotiation record," but discussion was postponed until the April ZIG meeting. Between now and then, Max will work with Les Webberley and Ralph LeVan to strengthen and clarify the proposal. Z39.50 IMPLEMENTORS GROUP MEETING Day 3 - September 23, 1994 SET USER PARAMETERS Les Webberley distributed a proposal for Set User Parameters Extended Service. The proposal will be considered for the next version of the standard. The proposal does not enable the system manager to profile user groups. Mark Hinnebusch asked whether this feature should use the Update function--seems as if it should if it sets user profiles. Ray Denenberg pointed out that we got rid of the Usage Accounting Extended Service by folding it into Update. Mark then decomposed the Set User Parameters proposal into three functions: 1. Request access control (prompt-1) 2. Change parameter on operation 3. Change parameter on user The proposal includes a parameter to highlight search terms (ON or OFF). This feature does not fit the Extended Services model, but rather should be set using the Other Info parameter [??]. What is the character of a user profile? * transient - endures for this session / association only * permanent - endures across associations It is important to enable users to change their password. The target may even ask users to change their password. We have no Trigger Access Control mechanism. This is a version 4 issue [Mark Hinnebusch]. According to Ray Denenberg, there are 4 states for an OID: 1. local private 2. local well known 3. public 4. public in standard We need a mechanism for moving private OIDs to well known or public OIDs. The Z39.50 Maintenance Agency will maintain a list of local well known OIDs, the people to contact about them, and a brief description of them. ZIG members should send local well known OIDs to Ray Denenberg. CONCATENATION AND ENCAPSULATION Ray Denenberg distributed a proposal for concatenation and encapsulation, which may be used separately or together. The proposal will be considered for inclusion in version 4. Concatenation provides a "look ahead" capability and enables multiple requests to be sent in a "group" APDU, e.g., search and sort. Encapsulation reduces the number of messages that must be sent by enabling requests and responses to be sent in the Init, in effect providing a "connectionless mode" for Z39.50. Discussion ensued: * Are we (or should we be) building a scripting language for use with Z39.50? * How will concatenation and encapsulation handle access control [Ryan Troll]? The target will ask if a user ID and password are needed [Ray Denenberg]. * Concern about "connectionless mode" [Ryan Troll]. This vocabulary will not be used in the standard, i.e., it's not really a true "connectionless" Z39.50 [Ray Denenberg]. * Does it work both directions [Parviz Dousti]? No, clients can send group requests and targets can send group responses [Ray Denenberg]. * What about asking for multiple responses in a single request? For example, if the whole thing fails, return a group response for the last thing that worked [Ralph LeVan]. Discussion went round and round on this: Perhaps have an option to request individual responses for each request, with a group request terminated by a group response. Perhaps have an optional flag or client preference to request only a group response--the target can override it if there is a problem. * Concern about interaction with concurrent operations [Mark Hinnesbusch]. We cannot replace concurrent operations with (for example) 6 concatenated group requests. (There are no threads in concurrent operations. No need for reference IDs.) * We need PDUs and conditional logic so that we can send requests like "execute one PDU after these other 2 have completed" [David Loy]. We need to include a sequence of requests and conditions [Ralph LeVan]. * How will we handle errors [Cliff Lynch]? Are we prepared to pull piggyback-present if we do concatenation (to reduce complexity and avoid multiple ways of doing the same thing)? Yes? Then we should deprecate piggyback-present so people don't have to change their code [Mark Hinnebusch]. Or we could deprecate piggyback-present in v4 and cut it from the standard in v5? If the scripting language cannot do piggyback-present, the language is broken [??]. Is there an intermediate step before "deprecation"? We can't deprecate something in v3 before v3 is balloted [Brad McLean]. Mark Hinnebusch concluded from the discussion that the concept of the proposal is good, but that it needs more work. He proposed that a new subgroup be formed to do this work with Ray Denenberg and report back at the next ZIG meeting. Ray asked that conditions be posted to the list to determine whether a new subgroup is needed. At what point can we give up backward compatibility with v2 and SR [Parviz Dousti]? At some point, we must give up backward compatibility [Mark Hinnebusch]. We must talk about this at length and soon [Cliff Lynch]. This issue is one of the reasons why the v3 testbed is important [Denis Lynch]. "ALL RECORDS IN DATABASE" RESULT SET NAME We need a way to refer to all records in a database, so that we can limit the result set without expending the resources to search a database and retrieve everything [Bob Waldstein]. Potential problem: The result set name must include the database name. If we set this string, how can we represent a logical (group) database? How about if we agree on a use or relation attribute that does this [Mark Hinnebusch]? Should the attribute be part of the standard or an implementors' agreement? Mark Hinnebusch proposed a relation attribute with specific semantics to return all records in a database irrespective of Term. Could also use urx with some Term to construct a URL; the client will turn this into a relation attribute. (Brad McLean owns the URL description.) The bottom line is that the target knows one thing: the relation attribute. Mark will post his proposal. Bob Waldstein will post alternatives. We will probably discuss this at the next ZIG meeting. It's a religious issue--some people don't like doing this with a relation attribute. NEW ATTRIBUTE TYPES RANKED LIST QUERY SEARCHREQUEST-1 Peter Ryall distributed handouts related to ranked list queries. After initial experiments with ranked list queries, the new attributes may be used with other attribute sets and query types. This work will be discussed at the next ZIG meeting. Questions and comments: * Will query Type 102 be a superset of Type 1 so you don't need different software? Probably not. The algorithm to resolve 102 queries is different or unknown or at least not agreed upon [Cliff Lynch]. * Result sets from Type 102 queries should be compatible with result sets from Type 1 queries. Caution to model this correctly. * Listserv for this subgroup: adv-search-list@meaddata.com or send request to Peter Ryall. PROJECT SERVICE We need post-processing functionality executed against a result set, like the "project" command in Orbit or Dialog. For example, give me the top 10 authors of books with "unix" in the title or the top 10 companies with hair spray patents. This feature needs data and metadata, i.e., number of occurrences. [Bob Waldstein] Questions and comments: * Do we need concatenation to do this? An Extended Service to do this? Bob Waldstein prefers not to do it as an Extended Service. Les Webberley is already doing something like this ("filtering") as an Extended Service. * Should it be batch or background mode? Maybe. Sometimes. * Does it return a result set? No, a result set maps to a database [Ray Denenberg]. Yes, it maps to a virtual database, which is the initial result set [Mark Hinnebusch]. Caution to define this carefully. * The model to pursue is a scripting language [Ryan Troll]. Bob will look at Les's Extended Service and think more about this. RPN QUERY ON ELEMENTS INSTEAD OF ATTRIBUTES We need a way to ask questions about records already retrieved, not database indexes [Bob Waldstein]. Bob wants to query a single entry in a result set in a way that is unrelated to the way the database was built. For example, is there an A subfield in field 100 followed by M with a Q? The discussion was moved to the list. There was supposed to be an "ordinal position in result set" use attribute in v3, but it was pulled at the last minute. Should this be re-visited for v4? Mark Hinnebusch suggested using a schema to say that database elements are also use attributes (hence searchable). But how would we express numerical comparisons [Bob Waldstein]? ASN.1-1994 Ray Denenberg attended a tutorial on the new ASN.1 and presented a brief overview of changes and issues of concern: * There are new ASN.1 types, e.g., Open Type replaces Any Type. * There are two standardized variants of BER called CER and PER. Some redefinitions in ASN.1 affect BER; some do not. The Packed Encoding Rules (PER) are not compatible with BER. If we want to use PER, there will be a big problem with the change to Choice (e.g., "..." to add things to a choice or sequence does not work with PER). Some people want to use PER. PER never sends tags, only lengths. * OIDs can be negotiated. * If Z39.50 adopts ASN.1-1994, we can simplify the syntax, but the new syntax is not all backward compatible with the old. * There are 3 new character strings. * Macros and value negotiation are not compatible between ASN.1-1990 and ASN.1-1994. Info Object Class replaces macros; it's very complicated but may be helpful with Extended Services. ASN.1-1990 has become obsolete. We must convert to ASN.1-1994 "over the next few years as convenient." If we continue to use BER, we could be OK, but if we convert to PER, some items we're using will not be backward compatible [Ray Denenberg]. There are no available tools, e.g., compilers, to convert now [Brad McLean]. Existing tools are an important consideration [Les Webberley]. This discussion will continue at the next ZIG meeting. V3 TESTBED RE-VISITED Testbed participants must have a working v2 client or server. They may need to link bogus documents to a test database to test the item order feature. Features to be implemented, core extensions and cleanups (e.g., diagnostics) will be decided in the near future. [Cliff Lynch] There are two levels of testing operating in the testbed: 1. Interoperability testing - People will distribute clients so that different groups can test them with different servers. 2. Interwork testing - This testing is more difficult and focused: e.g., did I get the right item for my order? [Max Dekker] Cliff will organize the testbed activities between now and November. The testbed will be underway by the end of 1994.