From: Denise Troll Z39.50 Implementors Group Meeting Minutes 1-11-95 1. MINUTES - DT drafted to do minutes. 2. MODIFICATIONS OF AGENDA. MH asked for additions or changes to the agenda. BW added agenda item on Z39.50 FAQ. 4:00 today SIGLA OIW meeting (RL). End noon on Friday. 3. INTRODUCTIONS AND STATUS REPORTS People introduced themselves and gave updates on their Z39.50 work. (I didn~t record all of the status reports, so please contact the folks below if you need information.) Blair, George (Conquest Software Inc.), gblair@cq.com Brainard, John (VTLS Inc.), john@apollo.vtls.com Brewster, David (Eisenhower Nat. Clearing House), brewster@enc.org Buckley, Chris (Cornell Univ.), chrisb@cs.cornell.edu Cattey, Bill (MIT), wdc@mit.edu Chang, Jui-wen (RLG), br.jxc@stanford.edu Chin, Ho-chun (RLG), br.hcc@rlg.stanford.edu Christian, Eliot (U.S. Geological Survey), echristi@usgs.gov Collins, Tim (NLM), collins@occs.nlm.nih.gov Dekkers, Max (PICA), dekkers@pica.nl Denenberg, Ray (Library of Congress), ray@rden.loc.gov Dill, Jeus (Endeavor Info. Systems), jens@marcorp.com Donelan, Sean (Data Research), sean@dra.com Emerson, Jim (P.S.S. Tapestry), conje@saigus.com Esty, Jay (Silverplatter), jaye@silverplatter.com Evans, Charles (EBSCO Publishing), evans@world.std.com Ferrin, Eric (Penn State Univ.), egf@psulias.psu.edu Gaster, Jeanne (West Publishing), jgaster@research.westlaw.com Graubart-Ceroone, Jeff (Ameritech), graubart@notis.com Heyano, Scott (Univ. of Washington), slh@cac.washington.edu Hinnebusch, Mark (FCLA), mark@mark.fcla.ufl.edu Holman, Brian (Brigham Young Univ.), brian_holman@byu.edu Jordan, Bill (Univ. of Washington), bjordan@u.washington.edu Kuchnir, Alex (Tribase Corporation), alexk@tribase.com Kunze, John (UC Berkeley, NLM), jak@nlm.nih.gov Levan, Ralph (OCLC), rrl@oclc.org Lillie, Dwight (MDL Information Systems), dwight@mdli.com Loy, David (K-R Info, Dialog), loy@dnt.dialog.com Lynch, Clifford (Univ. of CA), clifford.lynch@ucop.edu Lynch, Denis (TRW), dml@bis.trw.com Marchuk, Michael (Follett Software), mmarchuk@class.org McLean, Brian (Gaylord), brad@saturn.gaylord.com Mills, Julie (TRW), jm@svl.trw.com Moen, Bill (Syracuse Univ.), wemoen@mailbox.syr.edu Nassar, Nassib (CNIDIR), nrn@cnidr.org Needleman, Mark (Univ. of CA), mark.needleman@ucop.edu Oates, Andy (GEAC), a.oates@geac.com Orlik, Ralph (Library of Congress), orlik@mail.loc.gov Over, Paul (NIST), over@nist.gov Petersen, Eric (EWOS), elp@f-and-l.dk Preston, Cecilia (Univ. of CA), cpreston@info.berkeley.edu Randall, Sara (Ameritech), srandall@notis.com Roby, Thorn (CARL Corporation), troby@carl.org Rothman, John (Harvard Univ. Libraries), jon.rothman@harvard.edu Ryall, Peter (Lexis-Nexis), peterr@meaddata.com Salter, John (Eisenhower Nat. Clearing House), salter@enc.org Soffer, Stuart (Taliesin Software Research), soffer@acm.org Stovel, Lennie (RLG), bl.mds@rlg.stanford.edu St. Pierre, Margaret (WAIS rep., independent consultant) Sullivan, Terry (FCLA), fcltps@nervm@nerdc.ufl.edu Tibbetts, Marjorie (Univ. of CA), margery.tibbetts@ucop.edu Troll, Denise (CMU Libraries and Sirsi), troll+@andrew.cmu.edu Turner, Fay (Nat. Library of Canada), fay.turner@nlc-bnc.ca Turtle, Howard (West Publishing), turtle@research.westlaw.com (?) Van Dam, Dennis (West Publishing), dvandam@research.westlaw.com Waldstein, Bob (AT&T), wald@library.att.com Washburne, Brent (Endeavor Info. Systems), brent@marcorp.com Wibberly, Les (CAS), les.wibb@cas.org Zeeman, Joe (Software Kinetics), zeeman@sofkin.ca Zemon, Art (Data Research), art@dra.com REGISTER (RD) - will update in February 4. WALKTHROUGH OF BALLOT AND VERSION RD led us through the post-ballot draft, pointing out what~s different from the draft discussed at the last ZIG. The changes were made as a result of ballot comments. (Note: the list below is what RD specifically mentioned. There are a few other change bars in the post-ballot draft. If you want the detailed nitty-gritty, get this draft.) * Abstract and Foreward added as a result of ballot comments. * Pg. 1 - Added reference to ILL protocol (ISO 10160); removed reference to IEEE; reference to regular expressions removed (at one place, still occurs another place). * Pg. 2 - New definition: Access point clause. * Pg. 3 - new definitions: Element set name & Element specification identifier. * Pg. 4 - New definitions: Item and Result set item. * Pg. 5 - New definitions: Service and Tag, TagPath, etc. and Triple. * Pg. 6 - New definitions: Z39.50-association. * Pg. 7 - 3.1.5. "Identifiers" instead of "names." * Pg. 13 - 6 types defined, not 5. * Pg. 15 - Technical change: total number of response records = Number-of-records-returned. * Pg. 17 - 3.2.3.1.7. New, but wrong (3 parameters - need definitions). * Pg. 18 - 3.2.3.2. Note 1 is new (why segment service is modeled as request). * Pg. 19 - 3.2.4.1.4. First paragraph, add failure-9. * Pg. 27 - Error: operation status. * Pg. 29 - 3.2.9.2. Note is new. * Pg. 30 - 3.2.9.4. Rewording to clarify = Aborted Operations - last sentence of first paragraph (Wait-action assumes....); 3.2.10.1.1. Searching Predefined info categories, end of first paragraph. * Pg. 31 - ExplainCategory (two occurrences). * Pg. 32 - TermListInfo (no hyphen pp. 31 and 32); Retrieval RecordDetails. * Pg. 58-59 - Technical change: sort request and sequence, tag 5, and sort element. * Pg. 60 - Close should not have reference ID (doesn't fit model), but can't take it out without consultation with ZIG (RD). Disagreement and discussion ensued (DL, MH, LW, MN, LS). Suggestion to add comment: if target initiates Close, ref ID should not be included (DL, MH). RD doesn't like that; will leave it in and continue discussion later. (pg. 30 [?] service definition does include Note) * Pg. 62-63 - Not discussed; also skipped State Tables. * Pg. 74 - Last paragraph is new. * Pg. 76 - Attribute set bib-1: may change based on yesterday's discussion. New attributes: bib-1 Anywhere (1035); relation attribute Always Matches (103); structure attributes String (108) and Numeric String (109) [BW too restrictive; deferred further discussion until later.] First paragraph of ATR.1.2. Attribute Combinations (new with typo). * Pg. 77 - Rewrite suggested by ballot comment. * Pg. 78-80 - Discussion of error diagnostics. Type column indicates if diagnostic is surrogate or non-surrogate. Agreed to drop Type column indicating surrogate or not (revise text to accommodate). * Pg. 82 - Scan (1008), termList1 and termList 2 are new. * Pg. 83 - AccessCtrl: password invalid and password expired. * Pg. 91 - Explain, PerElementDetails name: Several cases where HumanString was changed to InternationalString. Distinction between name strings (used by protocol) and message strings (used by people, with language options). * Pg. 93 - IconObject rewritten. Errors with curly braces (already fixed in ASCII version). Restriction to black and white icons is too restrictive (MH). * Pg. 99 - GRS: OS (octet string) to be changed to another name, e.g., octet. Four new tags for ElementMetaData (7, 8, 9, 99). * Pg. 100 - Tag 3 value of triples. * Pg. 103 - Resource Report Format: error under Estimate, Type is not implicit. * Pg. 104 - Problem with ShouldSave (prompt vs request). * Pg. 114 - PeriodicQuerySchedule: problem with import and export specifications, to be fixed in final text. PeriodicQuerySchedule will import Destination. Destination to be moved to export specification. * Pg. 123 - Replace HTML with new example of SGML DTD, e.g., TEI (HTML is registered as MIME type). Need to clarify HTML and SGML usage in Z39.50 context (LW). * Pg. 124 - Piece: 6 is new (step). Meta-Data requested, 8, 998 and 999 are new. * Pg. 126 - [Sorry, couldn't hear what was said.] * Pg. 128 - TagSet G changes to publicationDate and DocumentContent. * Pg. 140 - RET.3.3.1.2. update table of Types and Subtypes. Conclusion: the small number of changes indicates the stability of the document (RD). 5. RESOLUTION OF BALLOT COMMENTS *** BRIEF EXPLANATION OF PROCESS (RD) *** (1) No votes - We must convince the voter to withdraw the "No" vote or change it to "Yes" with or without comments (they must explicitly do this in a letter), _or_ make a case that we have done everything reasonable to resolve the problem. (2) Yes with comments votes - We want to resolve as many comments as are reasonable. *** SUMMARY OF BALLOT (RD) *** 26 total votes: 15 yes, 6 yes-with-comments, 4 no, 1 abstain CARL is voting yes, but vote hasn't been received or counted. What's the significance of the low number of votes? Think we got enough votes to decide (CL). Sign ificant number of members haven't voted (many are here at ZIG...). RD sent reminders. *** RESOLVING THE ISSUES *** (1) ASSOCIATION OF JEWISH LIBRARIES - Voted "no." RD sent letter in response to their comments. So they withdrew their "no" vote. (2) DRA - ZIG attribute sub-group created profile of bib-1 attributes and other things to try to resolve DRA comments. What about NISO publishing profiles as separate standard number (CL, MH)? Should the bib- profile be maintained by NISO or by the Z39.50 Maintenance Agency (RD)? Could also mention in standard the existence of profiles and where to get them (CL). ISP is normalization of profile, which is indistinguishable from implementors' agreement (RL). Attribute sub-group working on OPAC attributes (subset of bib-1). We need a better term than "OPAC" attributes. At issue is non-normative doc to help people understand bib-1 and provide insights into interoperable searches (BC). Soliciting comments from ZIG members, e.g., good comments from JZ and MH. Working on response to (resolution of) DRA comments. Need clearer prose on what a "use attribute" is in relationship to an "access point." Need work on what "greater than" and "less than" mean. Need agreement on code sets, e.g., record types, institutions, language, etc. Much debate, no closure, because of infinite number of codes and extent of changes required to v3, which is already in ballot. DRA comment: at bare minimum we need interoperable ATS searches (Author, Title, Subject). Could call it "minimum bibliographic search." RD has detailed notes from subgroup's work. The group proposed "word list with adjacency" as a new attribute. Disagreement about truncation. Why not just require Type 101 queries with proximity (MH)? Is the issue one of definitions, profiles, what (CL)? We are defining semantics for bib-1 (RD). Provisional conclusion or approach: we need a couple attributes to be added to bib-1 and required for profile (RD). Defining "authors" to provide interoperable author search: subgroup was unable to specify semantics. Instead proposed guidelines or format of simplified set of tools (BC), e.g., Author, Author-Personal, Author-Conference, Author-Corporate. Not defined in terms of MARC fields. Don't want to profile something that's not in Z39.50 (LS). This won't satisfy DRA: Jim Michaels wants attribute set, indexing rules, etc. (MH). Jim's gone now, so we need to convince Sean (RD). We need to prescribe normalization rules, etc. (BC). (3) P.S.S. TAPESTRY - Voted "no" because of scope, interoperability and conformance issues. Scope issue has been dealt with, but not the other two reasons (yet). Standards affect how vendors market their software products, even though the standard is not a marketing strategy (JE). Tapstry is in the process of moving from v2 to v3. They want clearly defined levels of conformance so that they know what to implement and how to market their software. Need to be concrete to facilitate interoperability. Tapestry will change their "no" vote to a "yes" vote based on clarifying discussion and promise of future efforts in these areas. They want to be involved. We will rewrite the conformance clause to clearly define what constitutes minimal conformance; hadn't thought about levels of conformance within the conformance clause (RD). Too late in the game to add levels of conformanc, so let's do that with profiles (RD). We need to market Z39.50 based on conformance to profiles. That's acceptable to Tapestry. We need more expository writing about Z39.50. Potential problem with multiple levels of conformance: non-intersecting sets (discussed ad nauseam with profiles). Potential starting point for non-intersecting profile problem: testbed (BM). "There are limits to the extend to which standards bodies provide implementation support," e.g., no one at IETF will tell you how to implement tcp-ip (CL). (4) RLG - Voted "no" because (a) the delineation between v2 and v3 is not clear (addressed somewhat in new Foreword); (b) compliance is vague (need new conformance clause); (c) various editorial comments, but the new text addresses almost all of them. However, LS is not happy with all of the suggested revisions. (5) ACS - Voted "yes, with comments." (Discussion occured on day 2.) (6) LC - Comments incorporated in new text. Not to be discussed unless ZIG wants to (RD). (7) NOTIS - Standard should specify syntax of attribute types other than Use. Want organized testbed. Disagreement over whether testbed should be critical to vote on standard documentation (CL and NOTIS). We're writing standards for things we haven't done yet, rather than writing RFC on what we've done (MH). We need one or more conformance test suites, but no one's willing to do the work (MH). It's more than willingness to do the work: it's costly, requires neutral ground (e.g., not-for-profit), management, etc. (CL). Discussion of whether or how to change Explain, or the extent of changes to Explain allowable during the ballot process. Must be careful about changes because people are writing to the standard; we may need two versions of Explain--one considered for ballot and the evolving one (DL). Problem also with v3 not addressing HTTP, SGML and X.12. NOTIS wants gateways in the protocol to these other standards. (8) NATIONAL LIBRARY OF MEDICINE - abstained, with comments. (a) Why 2 kinds of segmentation? (b) Explain looks too difficult just to get basic functionality. (c) Scan should be mandatory (RD interpretation of their comment). Want Scan and Sort incorporated in Search command. Response from ZIG: resounding "No." We need to decide what belongs in the standard and what doesn't; and a method for addressing and communicating what does not (MH). (9) ASIS - "reluctantly votes YES." Raised philosophical issues for future discussions. Don't expect changes in current v3 documentation. But, what should remain in standards doc and what belongs elsewhere? Where is elsewhere? How do we reference it? We want to make the doc available as hypertext with links to supporting docs; just don't know when (RD). Maybe we're making a mistake sticking to print format (MH). We need to modularize the standard the way we modularize code (CL). What are the removable, reusable contents (MH)? Issue of backward compatibility: is it part of the cause of the complexity of v3? Whether or not, we need to make a "substantive engineering decision" about backward compatibility (CL). Currently it's difficult to know when you're implementing v2 and when v3; we need a clear break between the two (JK). No, there's no good reason to make the versions substantially different; must go to v3 with ASN.1, otherwise it's good to have no clear distinction, i.e., add the complexity you need as you go (DL). Conclusion: we'll develop a list of implementation differences between v2 and v3, but wewon't change the standard (RD). (10) GEAC - Vote "yes with comments." Scan doesn't take into account the differences between handling indexes (search form) and displays (display form), e.g., want thesaurus terms that users don't see. There isn't always a 1-to-1 relationship between search form and display form. AlternativeTerm is inadequate. (NOTIS concurs.) Want more services or features in Browse facility in v4. Maybe mention in the Foreward that additional services may be added in the future. Need clear statement of problem and proposal for solution (MH, DL, AO, MN, RD). Added to ZIG agenda for Friday. Technical changes can go into v3 _IF_ they're solution to problems raised in ballot comments. Suggestion to treat all ballot comments to Scan together to understand scope of problems (LW). 6. OIW SIGLA MEETING OIW = Open System Environment Implementors Workshop, where OSI (Open Systems) standards get profiled. SIGLA = Special Interest Group on Library Applications, responsible for profiling Z39.50 and ILL. Have produced 3 profiles: Cliff's RFC, GILS profile, WAIS profile (how to do WAIS-type searching in Z39.50 v2). The thesaurus profile didn't happen because there were no implementations. 3 regional workshops: OIW is one (in the U.S.), plus European and Asian workshops. Profiles are to go among the workshops to be internationalized (EP). Working at level of implementors agreements (profiles), not ISPs (RL). Plan to move GILS from profile to ISP; need someone to do the non-trivial mechanical and paper work for this (RL, JZ, RD). Meeting at ZIG because of overlapping profile issues that ZIG needs to be aware of and contribute to (RL). Agenda: 1. Bib-1 PROFILE No bib-1 profile has been produced yet. Overlaps with earlier discussion of OPAC profile, which is major subset of bib-1 attribute set. This profile would specify (include) minimum requirements for bib-1 attribute combinations that would be mandatory; would not disallow other combinations. Goal is to enhance interoperability. Need to know how to search authors, titles, subjects. Will deal with normalizations, e.g., personal names. Will use AACR-2 rules. May deal with punctuation. Name un-normalized is 1003; personal name, normalized is 1004. Discussion: Big burden to have to normalize personal names using AACR-2 rules. Many systems do personal names and normalization without using AACR-2 rules (MH, SR). "Normalized" means "as construed by the target"; the profile indicates how the target is to construe it (RD). The set of rules is to be abstracted from AACR (by CP) and placed into client (?!) -- difficult work! In the current model, the client submits text that is normalized at the server; the problem is that the new model changes this by requiring the client to do normalization (BM). Big difference of opinion here among ZIG and ZIG bib-1 subgroup members (MH, DL, LS, RD, RL). Attempt to disentangle this: servers that follow this profile interpret queries in this way (CL). To meet the interoperability requirement of DRA, moving from the current chaos to 4 specific categories is a radical shift (MH). The profile can't preclude the development of dumb clients or servers. Profile should clearly define "normalize" and the way to specify whether the client has normalized or not. Server should be able to handle normalized or not, e.g., server says "I don't do normalized" (CL). Big, semi-ugly debate; lots of double-timing (i.e., people talking at the same time and hoping the other one will drop out -- he who talks loudest and longest wins?). Servers must support author, title and subject use attributes, BUT particular database may or may not have author, title, subject access points. If databasae doesn't have these things, it should return a diagnostic related to that database, not a result set with 0 results. T Group is all talked out (do you believe it!?). Will resume discussion of "ATS profile" (another tentative name--AuthorTitleSubject) tomorrow evening. Very political closing statements...more disagreement and discussion. Goal of this ZIG: first draft of profile, not final profile (RD wanted final profile this ZIG). Will re-visit at April ZIG (unless we remove MH as chair). Meanwhile OIW will proceed. 2. GENERAL INTEROPERABILITY ISSUES Message to DRA: ZIG has taken action to get profile done by SIGLA OIW, but admittedly this is not good enough for DRA to change "no" vote (BM). We still need (a) clear problem statement, (b) clear statement of problem domain, and (c) good understanding of customer base. DRA is holding the standard hostage (MH, RL, RD). Considerable tension between progress (good profile) and concern for implementors and current implementations, e.g., CARL. The profile will "say" to the public that some (commercial) clients are better than others. Minutes 1-12-95 CONTINUE DISCUSSING BALLOT COMMENTS: (1) CONTINUE DISCUSSING RLG COMMENTS (see day.1 minutes, Resolving the Issues, number 4) - RD will draft conformance clause and submit to RLG NISO voting members. ZIG will also review conformance clause because it has implications for implementation. Because of timing, review will be on the list, not at the next ZIG meeting. RLG also requested a summary table of features to delineate clearly v2 and v3. DIGRESSIONS: Question about v2 conformance 1992 or 1994 (BC). V2 compliance requires support for Type-1 queries; a server that supports only Type 101 (Z39.58) is not v2 compliant. V3 has new (different) ASN.1; if turn on v3 bit, must use new ASN.1 and be prepared to receive queries for multiple databases, etc. Concern about expanding conformance to include profiles (MH). Ambiguity of term "profile": vendors (sites) have profiles of their individual implementations (delivered to customers upon request); now we're talking about profiles as part of conformance to the standard to insure interoperability across sites. The OIW should do the work on interoperability profiles, not the ZIG (RD). Discussion of pro forma and how and what we document about our implementations, e.g., general implementation info or per-database info? Problem statement: how do customers negotiate interoperability, how can they get a handle on particular product functionality to decide what to buy? How can we help the community figure out what's going on (MH)? Need a sub-committee to design a form for documenting this information. The sub-committee should do the work on the list; if traffic gets too heavy, we'll move the discussion to a separate list (MH). Sub-committee posts to the list should include an acronym or other identifier for the committee at the beginning of the subject line (CP, MH). Should work closely with the European community, e.g., EWOS, on this because they do lots of work on profiles (RD). Could use SR document as starting point (FT). Perhaps use outline (numbered sections) of standards doc as outline for form (LW). That would not get at all the pertinent information, e.g., case sensitivity (RL). Propose that we start with something small and general, and then grow it to the level of detail required by the market (MH). Heh--what's our purpose; we're not here to do or prevent marketing, we're here to solve implementation problems (DL). But--we need a way for people to evaluate products or the standard won't survive; it's part of improving implementation and interoperability (MH). Creating a common way to desribe common capabilities does fall within the domain of the ZIG. People who provide clients and servers should do this (LS). Perhaps people should post their implementations to the list, then someone should gather and edit this information into something useful. We tried this before with little success, but we can try again (RD). Client and server implementations should be addressed separately. BM will post information about database and application abilities to facilitate this work. We've defined the problem, identified the forum (the list), so we need to move on...(MH). [Note: A sub-committee was assigned to do this work, but no real people were identified as members of this sub-committee and no milestones were set.] RETURN TO RLG COMMENTS: We need a summary table to distinguish v2 and v3. The table should be cross referenced in the conformance statement. What follows are notees on RLG's editorial comments, referenced by section numbers in the standard: 3.1.7. Extended services: Reduce number of items in bulleted list, move examples (last two paragraphs) to 3.2.9., and rename section. 3.1.7. "Model of Extended Services." [Note: page numbers below refer to post ballot draft] ERR.2 (pg 83): The identifier will be changed from "stronger" to "alternative." REC (pg 84): No reference for GRS-0. GRS-0 will retain curren t objectidentifier (historical status), but mention of it will be removed from the current version of the standard. REC.1: (a) (pg 84-85): Comments typically follow parameters, but, if the comment applies to several parameters, it precedes the parameters. This is confusing. Clarify with term "follows," e.g., "Key elements follow." In addition, comments that follow parameters are indented to begin mid-page; comments that precede parameters are only slightly indented. (b) (pg 85): Concern about "Other esns are defined (below) as needed." (c) (pg 89): Will consistently state "mandatory in full record" where applicable throughout standard. Will also add comment that some optional parameters may be mandatory in full records and are so indicated. Other editorial comments from RLG will be handled as RD suggested in his response. LS (for RLG) thanks RD for good work. (2) ACS COMMENTS - Votes "yes with comments." (a) (Referenced as T1 on paper comments.) Problem statement (LW): Scan Status does not handle all valid cases, p articularly partialresults. Suggetion to use the "tough love" approach, i.e., return failure when, for example, scan succeeds for two of the three databases requested (JZ). Should the server do what it can and return a message about what it can't do, _or_ should it return a message about what it can't do and ask client if it should proceed with what it can do? ACS preference is to return what the server can along with a diagnostic about what it can't (LW). Second part of the problem: can't return both partial results and a diagnostic, even if we grant partial status (MH). What's wrong with the approach that lets the client know that one or more databases does not support this request (RD)? ACS wants "success," "failure," and "partial," wth ASN.1 allowing both high level diagnostic and useful information (e.g., partial results). RL has similar problem with Scan; wants to send informative diagnostic because partials are not sufficient for current needs. Agreed: ListEntries changed to SEQUENCE (pg. 57) and make Entries with tag 7 I MPLICIT; preserves bit compatability. This means that existing clients will have problems when both diagnostic and partial results are returned. But everyone who implemented 1994 features before it was ballotted knew it could change before or during ballot process (MH). Well, maybe not agreed. Two camps here: change it (MH, LW, RL) vs don't change it (RD, JZ, others). JZ has a problem with the problem, not with the proposed solution. How about adding neutral partial [don't remove other partials] that says results are partial and here's qualifying diagnostic (LW)? Does proposed change introduce further ambiguity into the standard? What if client doesn't want partial results? Could pack into AdditionalScanInfo a note from the client that if you can't do it all, don't do anything (MH); RL disagrees. Question: If we add partial-6, qualified success, to Scan, can we do the same for Present (JG)? ZIG response: resounding "no." Must address beginning-of-list and end-of-list diagnostic case (raised by RL, reiterated by BC). Propose two new surrogate diagnostics, i.e., beginning and end of index list, to solve the problem (RL). RL will propose new diagnostics on Z39.50 list. LW will also post some new diagnostics that pertain to Scan. RD rolled over _somewhat_. Agreed to change ListEntries to SEQUENCE (pg. 57) and make Entries with tag 7 IMPLICIT. Did not agree to add new (neutral) partial. (b) (Referenced as T2 on paper comments.) Most serious problem for ACS (almost voted "no" because of it). Section 4.1 (pg. 48), last paragraph: ACS wants CHOICE of "single-ASN1-type" or "octet string" for performance reasons. Disagreement. Don't want to weaken the standard; either leave as is or take it out (SD). BER standard says use any of the three encodings (DL). MH proposes removing restriction to "single-ASN1-type." Agreed. (c) (Referenced as T6 on paper comments.) RSC.2: Also handles agenda item 11: INT UNITS USE FOR CURRENCIES (MD). Real project right now depends on interoperable way to handle currency units in resource reports (LW, MD). ACS proposes adding OPTIONAL ScaleFactor to Estimate structure to handle meaningful currency amounts. Proposal: if expressing currency, then IntUnit takes the following values (RD). (d) (Referenced as T7 on paper comments.) ACS proposes adding an OPTIONAL defaultTagSetId parameter to eSpec-1. No one (exept ACS?) has implemented eSpec, so doing this won't break anything. Debated this many times before; point of contention (RD). Implementing eSpec-1 at ACS showed problematic levels of indirection in the current version to understand tags (LW). Tags are defined in schema, but schema aren't dynamically interpretable. Therefore implementation is cumbersome. We have no convention for listing the default tag type. Counter-proposal: not a defaultTagSetId but a defaultTagType (DL). Anything included in the schema, e.g., defaultTagSet, should be in Explain. But what if you want to use a default other than that listed in the schema? ACS preference is OID for TagSet, not TagType; TagType would be second choice. Can use eSpec-1 without schema (LW). Two sides of this: Add OID instead of TagType, then you have to register the TagSet. On the other hand, if you use integer instead of OID, your forced to use schema (RD). One TagType per TagSet. Created concept of schemas to identify context; initially schema was a concept, not a thing (MH). How identify context without schema? With an OID -- hence the current proposal. Agreed: RD will add defaultTagSetId with OID. Included in eSpec-1. BUT, further discussion about this occurred over lunch.... Would an integer be better than an OID? FINAL proposed change: defaultTagType as integer, rather than defaultTagSet with OID (RD). Unless someone gripes. LW agreed (reluctantly?). (e) (Referenced as T11 on paper comments.) ACS wants Export Extended Services to be able to export more than result set records (e.g., saved queries) and to have email added to the list of export devices. Pg. 111: change to fax, file transfer, print device and add email (omit X.400, FTAM, UUCP, FTP). Extended Services is a database; periodic / persistent queries are saved as records in the ES database, so they can be exported as ES database result set records (MH, DL). How do you specify what you want to export if you don't retrieve it as a database record (LW)? "This is not the right thing to do" (RD). This is "the camel's nose in the tent" approach (RL) [or what in rhetoric is called "argument from contagion" (DT)]: this need for more and more will spread, e.g., then you'll want sort and then you'll want... (RL). What LW wants changes the model too drastically and can't be done at this point in the game (MH, DL). LW's argument is "fruitless" and "esoteric" (RD). We already have a mechanism to do what ACS wants. LW can live without it (LW). (f) (Referenced as T12 on paper comments.) Need functions (public registration mechanism) for Final Delivery Notice and Usage Accounting Report to facilitate interoperability. We need a stage between a private implementors' agreement and something included in the standard doc, e.g., an HTML page (DL). Maybe instead of just OID 1000 for private classification, we need OID 2000 for "officially recognized ZIG experiments," "which buys central coordination (RL). RD agrees to OID 2000 and to add section OID.7 (pg. 73) to briefly describe OID 2000. This provides a mechanism for finding out about the official ZIG experiments and tracking their evolution. [Sorry, I missed some point from BW about reserving 0 for something having to do with Explain and schema.] SUMMARY (BC) Still outstanding from ballot comments: DRA ATS profile RLG conformanc e statement GEAC search vs display format for scan 7. Z39.50 COMPILER FRIENDLY ASN.1 ZIG will prepare a "compiler friendly" ASN.1, i.e., an unofficial version that will compile but won't be in the standard. DL will do first pass at this. 8. FAQ (BW) BW is revising his previous FAQ. Would be willing for someone else to do this.... Current FAQ posted to list. Please read and send comments to BW. He'll post to the list when he starts revising. 9. REGISTRATION OF NEW ATTRIBUTES MD posted to list. Could not map all the indexes they want to the bib-1 attributes in Z39.50-1992 (v2). Their list is about 5000 attributes. Two issues: (1) 1992 standard is unclear about what the attributes mean. Current subgroup is working on semantics for the attributes. Hope is that they don't focus strictly on USMARC and English language. (2) They have at least 30-40 attributes with semantics that are not availale in 1994 bib-1 list, e.g., date or place of conference, language of abstract, etc. Also need relation attributes Explode and Synonym. Dutch libraries now have subject codes that must also be handled. They can either: (a) propose their list to ZIG for inclusion in bib-1 (b) define their own attribute set, e.g., bib-2 (which would require a maintainer and a way to make it available for interoperability) or (c) propose them for inclusion in STAS. Did option (c): their attributes are included in STAS. Could move to bib-1 in the future. What does ZIG recommend? MD will post the semantics for their attributes to the list for discussion (at RD's request). JZ has hundreds of additional attributes. We need rules for how we add attributes to bib-1 (LS). Yes, for example, language of abstract is not bibliographic info (RL). What does MD do with things that are not accepted into bib-1 (RL)? Is it acceptable to take some of MD's attributes but not others (RD)? Wanted to avoid a discussion of whether or not they were really bib-1 attributes (MD). Maybe language is orthogonal and needs to be a different attribute type (MH). We already have attributes in bib-1 that aren't really bibliographic (BW, RD). This discussion pertains to v2, not v3; v3 has provisions for handling this (BW). Do we still have the philosophy that ultimately somewhere down the road when we're all doing v3 that we're going to use this feature of mixing attribute sets within a query (RD)? Yes. Migration problem. Putting them in STAS for v2 implementations is acceptable temporary solution while we study which ones should be moved to bib-1; don't like the idea of putting attributes in bib-1 that are not bibliographic (RD). Is it the philosophy that each large project that comes along will be encouraged to define their own attribute sets, or will orientation be towards each discipline, e.g., science-tecnology or business, developing its own attriute set (LW)? The goal is discipline-specific attribute sets, but doing this is non-trivial (SD, LW). It's a lot of work but we have to do it, even if after the fact, e.g., doing it with bib-1 now (MH). If it's inherently bibliographic, it belongs in bib-1, but w hat process do we use to add things to bib-1 (MH)? MD will post new attributes and semantics to the list and see what happens. Meanwhile they are included in STAS; see STAS WEB page. Another issue here: Not concerned about large numbers of use attributes, but relation attributes are trickier to define and understand. Regard non-use-attributes as needing more careful scrutiny (CL). Should current library codes, e.g., coden, be separated out to identify the authority of the code (BC, LW)? A lot of the explosion of attributes is due to the inability of use attributes to handle multiple dimensions, e.g., patents, codes (MH). Adding dimensions to attributes expands the semantic space (LW?). Perhaps a hierarchy of uses would work instead of dimensions (MH). Hierarchies were treated in the1991 doc (LS). Maybe we need a paradigm shift away from enumerating the attributes, e.g., move to string attributes (MH). That would be an interoperability nightmare (JZ). There is a class of attributes that it might make sense to treat as strings, e.g., relation attributes could continue as enumerated list, but some of the use attributes could be string attributes (MH). What's the difference between the well-known strings and the well-known numbers (TS)? Need to list them both. Character sets complicates the issue of string attributes (BW, MN). It's premature to have this discussion until we see MD's attribute set (RD). JZ's 245 additional use attributes are almost all in the MARC record, therefore bibliographic; also need 1 truncation attribute and 1 structure attribute. Would like them to be added to bib-1 or could maintain them as a private set (JZ). JZ will post to the Z39.50 list either his list of attributes or a pointer to the list of attributes (available via anonymous ftp). What about adding an authority attribute type, which would be the registered specifier of code space for resolving terms (BC)? All code issues would go into authority as the source of the coding. [ZIG worn out. Discussion ended for the day.] Minutes 1-13-95 10. NEXT ZIG MEETINGS (1) April, Amsterdam, sponsored by PITA Monday, April 24 through Thursday, April 27 - ZIG meeting in Amsterdam; tutorial on Monday. Friday, April 28 - ISO meeting in Leiden, with reception in PITA offices, c. 4:00. ISO meeting may not be open; contact Sally McCallum (?) if you want to attend. IFOBS (International Forum on Open Bibliographic Systems) meeting is open. MD will post hotel details on list next week. Don~t plan to leave Saturday (holiday = Queen~s Day). (2) September, Washington D.C., sponsored by Library of Congress Monday, Sept. 25 through Wednesday, Sept 27, ZIG meeting at the Library of Congress. (3) February, Gainesville, FL February 7-9, 1996, ZIG meeting at FCLA. 11. BIB-1 ATTRIBUTE SEMANTICS There will be an ATS profile (response to DRA's "no" vote) that will not go into the standard. Still have to resolve where profile goes, e.g., through OIW (RD). OIW can vote stable implementors' agreement at any time (RL). RD will talk to DRA, NISO, etc. next week. New version of bib-1 doc will be out soon, incorporating changes from MH and JZ (BC). LS will send additional comments to be incorporated into doc before it's made available. A new attribute called "author-title-subject" was assigned a number; it returns either an author or a title or a subject (models old union catalog). Problems with current bib-1 doc (BW): (1) "Any" means only bib-1 attributes. Want Any to mean all available access points. RD will remove the reference (note) to Any as bib-1 from the doc. (2) Why does server choice default to single attribute? BW wants bib-1 reference removed from server choice too. "Server choice" was once called "default"; changed to "server choice" because it more clearly indicates that it's what the server wants to do (LS). Agreed: change single use attribute to "server selects one or more access points." (3) "Anywhere." The record is selected if it occurs anywhere in the text (even if not indexed info). Confusion between Any and Anywhere (LS). Anywhere created in response to BW's request at Sept. ZIG, but BW doesn't like it. Anywhere is useful, i.e., search the entire thing rather than just indexed access points (LW). In contrast, Any gets only at indexed access points. LS wants to delete notes in the bib-1 doc about Anywhere. Will continue discussion at bib-1 group meeting this afternoon or on the group list. Charge: (a) resolve confusion about Any, Anywhere, and Server Choice (b) agree on scope of doc and missing items (what remains to be done) (c) resolve comments Notice that these three attributes (Any, Anywhere, and Server Choice) are not specifically bibliographic (BrW). Worth mentioning this in the bib-1 doc (DL), but since we need these in the standard and bib-1 is all we have, here we are (RD). We need to clarify the difference between use attribute, index and access point, but may never come to closure on this because it's colored by the implementation (BC). What's the future of the bib-1 doc? Need further discussion on group list and possibly a follow-up meeting before publishing the doc (LS). Urgent to complete this in the next couple months. Propose separating ATS profile from bib-1 doc (LS). "Modest proposal" by CL, MH: "Long and enthusiastic" discussion about interoperability problems last night (after ZIG). Proposal to add prose in bib-1 attribute set definitions suggesting that, at least in v2, if you don't support an attribute ("reasonably closely"--whatever that means), return a diagnostic saying you don't do this, rather than being creative. This will eliminate problems that make people queasy about Z39.50, e.g., why am I getting these "insane" (CL) or "inexplicable" (MH) results. (V3 has some controls to help with this, e.g., do only what I asked.) Will this approach require more use attributes and therefore further impede interoperability (RL)? Nah. Lots of judgment calls here for server designers, but this addresses much of what DRA wants (CL). Can put this proposal in the standard or in the bib-1 doc. Suggested wording: "Servers implementing bib-1 with version 2 of Z39.50 should return appropriate diagnostic [insert specific diagnostic here] in cases where they do not support a bib-1 use attribute with a reasonable degree of precision" (CL). MD proposes slight modification to CL's wording: return diagnostic if server "cannot map use attribute to sensible choice at server." Does this apply to other attribute sets and things like completeness (TS)? Be cautious until we get the bib-1 doc done (CL). The principle should be applied to the other attribute types, not just use attributes (LS). Getting testy now. "Change today, break your system tomorrow" kind of talk. Not clear whether the above statement in some form goes into the standard. Concern about existing version 2 implementations. Is this a recommendation or a prescription (LW)? MH suggests recommendation or we make existing systems nonconformant. Don't want v2 1992 to have different requirements from v2 1994. The fundamental problem is whether we're requiring the server to take the client seriously (JZ). LW recommends applying this proposal (statement above) to v2 and v3: if the origin sends a value for an attribute in the absence of any other semantic information, the origin should be believed; if, on the other hand, the origin doesn't send a value for an attribute, the target can do what it wants. If you don't send a semantic action, does that mean (if you're v3) that you've implicitly stated that you don't need to be believed? ZIG response: resounding "no." The default behavior should be v2 behavior. Agreed: recommendation in v2; prescription in v3. When using v2 or using v3 without specifying a semantic action, (see statement above). The text is for the bib-1 doc, not the standard. 12. IETF URL COMMENTS JK took ZIG URL proposal to IETF (Internet Engineering Task Force) meeting in hope of becoming IFC. After a brief discussion, the proposal was accepted. Noncontroversial. Several outstanding issues: (1) IETF suggested that we bring the use of special characters (ampersand and question mark, possibly plus sign) into "modern usage." We're not sure what that means. Still investigating. JK to ask for clarification. We're using the special characters the same as HTML/HTTP. (2) What do we refer to in the reference section, v2 or v3? Answer: refer to standard Z39.50 1992 and 1994. If we must choose one, we choose 1994. (3) What does it mean when a retrieval (fetch) URL is truncated just after the database name? It's illegal in the retrieval URL; host, database and docID are required (MH, RD). It's acceptable in a session URL to learn about a database. Our URLs will be incorporated into IETF draft (separate doc). 13. INTEROPERABILITY TESTBED After the last ZIG, CL thought about the structure of an interoperability testbed and the difficulties of orthogonal and optional features. Proposes that we don't need a testbed to focus on core changes to Search and Present (will sort itself out without explicit testbed activity). But testbed will (a) be an incentive to implement and (b) provide a documentation trail (MH, BM). We need a group to do a minimal set of changes and turn on the v3 bit. Then move on and focus on Explain, which is the most experimental and complicated thing in v3 and important to a broad set of users. But what about Item Order, Scan and Sort, which also got high votes at last ZIG. CL doesn't want to run four testbeds. BW not sure that what we learn from an Explain testbed will generalize. At least top level info will generalize (SR, MH). What about "testbed 1994" to keep it open to v2 and v3, to test backward compatibility? Propose 3 steps (LS): (1) v3 bit, Search and Present; must use or at least accept (handle) new diagnostics (2) v3 Explain (3) v3 backward compatibility with v2 Still need significant testing of Scan (SR). Not enough (no?) IOLS vendors, besides NOTIS, who have implemented Scan (SR). Maybe SR should head up Scan testbed. What does the market want (RL, SR)? What about Item Order and other Extended Services testbed (BW)? Do we have enough suppliers in ZIG to do Item Order testbed? Yes, 5 of us are interested. A testbed needs a "border collie" and no one is willing to run Item Order testbed (MH). Item Order folks will figure this out anyway and customize as needed; it's bigger than Z39.50, e.g., $$ charges (CL). Informal poll: There will be some v3 clients and servers by Sept 1995, more by Jan 1996. Only two v3 servers right now: BW and LW. CL will sketch schedule for Fall testbed, PDU switchover. SR will do something on Scan. Item Order will wait for market; possibly RL, DL, BW and LS will do Item Order. 14. DISPLAYS It's after lunch and MH told me to put this in the minutes because I was very confused about what happened in the last few minutes before the lunch break: "BW brought up his usual discussion about display languages and we ignored him because we think display languages will never be compatible. BW can do whatever he wants." (Aside: BW, please don't shoot the messenger.) 15. GRS-1 WITHOUT SCHEMAS IN V2 CLIENTS In v2, how do you handle databases with multiple schemas, e.g., GILS and WAIS? Use different element set names (LW). 16. LATE EXPLAIN CHANGES Not an item now. We thought we would be further developing Explain right up until the standard was finalized, that late changes would go into the standard, etc. We have different view now. In reality, we'll have approval of the standard before we make meaningful changes to Explain, but are open to suggestions (RD). LW has questions and suggestions about Explain; will post them to the list after the meeting. Here's some of the questions (rough notes): (1) Currently there is no information about support for variants in Explain. Are variants simply to be discovered (LW)? RD answers: didn't have time to look into it previously. Is this a proposal for a new category? To discover information about an element, you don't use Explain; you use the normal retrieval facilities (RD). DL and MH disagree; they see a need for a new category. (2) Question about element information. Do we want to make data type Optional or add unspecified option (LW)? Answer: none of the above (RD, LS). It will be useful to add an "unspecified" (LW). Reasonable proposal. Will resolve it later (DL). (3) TagSet information, under elements: perhaps add Optional data type and perhaps add Optional element nickname (LW). No place to carry this info right now. Theory (which may be wrong, investigate later) is that TagSet is simply to define the tags, not the data types; if this is wrong, then the ASN.1 based on that understanding is also wrong (DL). (4) Pg 88 attribute description: Request to add an Optional nickname (LW). We can specify string or numeric attribute value. Would be useful to be able to specify both (LW). Discussed this at last meeting: What's the purpose of string attributes? Does not do much good to be able to reference a particular attribute by string and number (RD). We talked about why even have string attributes. To facilitate understandi ng.... Would be more meaningful as strings than numbers. LW wants string and numeric values in Explain, not one or the other. Would make Explain more flexible. (5) Pg 91 structure issue: per element details. Suggest consider per element details being at record level. With current structure, records become huge. Would be helpful to break up per element details to have a record per element to get details (LW). (6) Supporting string and numeric tags in per element details would be helpful (LW). (7) Pg 93: Are network address and port flexible enough (LW)? Must you specify port? Yes, when you make a connection. Should it be optional in this structure? No (DL, RL). Don't want to use domain resolution service. (8) Question about units. Want ability to explain what units are supported. Does this fall into the same category as variants (LW)? No, because it's not a category in itself (RD). Yes, it is in the sense that there's no reason that it shouldn't be (DL). [We're having fun now. :-)] (9) Pg. 95 cost structure: Want sequence of type and charge (LW). OK, reasonable, work out the details later (DL). (10) Didn't we use to have an Other Information structure for each parameter (LW)? Yes, but we decided as a group to take it out (DL). Other Info is not helpful in Explain; instead create new category record (MH). Two purposes for Other Info: extensibility of (a) public records and (b) private stuff; create your own per element details record for private stuff (RL). Other Info in here would take up space and not facilitate interoperability since you already need out of ban agreement. Can't you put your other info in the Present response (RD)? Different impact on the client (LW). Philosophically, Explain is "a different beast" and all clients and servers must agree on the record types (MH). Client must know what it's asking for when it asks for an Explain record (RD). (11) Need index or access points that we can learn about attribute type and value pairs (DB). Use TermListInfo, which lists all term lists for that database; TermListDetails needs a display name (DL). OK. (12) Attribute combinations: Is TermListDetails for all or each term list? Each (DL). Then why have sequence of combinations (DB)? Because ...[sorry, lost it; the note taker couldn't keep up] (DL). (13) Can we make string list an attribute value (DB)? Might be better to do this as string list than attribute value (DL). Do we need a way to specify broader and narrower attribute combinations (MH)? DL will investigate. (14) It's a mistake that schema info has no way to specify default attribute combinations. We need a way to specify "send me an integer or something else" (DL). [lost it again, something about icons, but according to DL it was an excellent idea -- the minute taker should be fired, yes, definitely fired before Amsterdam :-)] Omit blurb about icon pixels as x bits high, etc. This blurb preceded the discussion about body type (RD). Original bit map structure defined by BW; need to discuss with him (RD). If we need to keep it, it should be registered as Z39.50 type (MH). Nuke the choice (DL). Is one icon sufficient or do you need a sequence of icon objects, e.g., pg. 85 (RL)? Is the intent here that there's one icon that can be represented different ways, or is there more than one icon (RD)? One icon, a sequence of different representations for one icon. Distinguisher is body type, e.g., gif, tiff, 32 bit, 16 bit (RL). Need sequence of whole structure. May want different icons for different platforms (MH); too hard (DL). Agreed: icon will be sequence of body type and icon. Delete whole business about it maps (?); Z39.50 is not a definition of image formats (DL). 17. Z39.50 PAPERS Paul Over is gone (left ZIG before end of day Friday). He's leading this effort. He's talked to everyone who agreed to write a paper except Kevin. About 12 papers forthcoming. Abstracts are due February 1. Reminders will be posted to the list. Papers due May 1. Publication Summer1995. PO and RD will edit papers. Maintenance Agency will provide access to papers. If NIST is going to profit from papers, not sure... (RL). NIST will make large number of copies available free; after that, is this a revenue generating thing? Doubtful (RD). Would we also publish these papers on the list, on BW home page, etc. (RL)? Yes (RD). 18. ITEM ORDER MODELS AND RELATIONSHIP TO ILL How do we give guidance to people and have consistent view of this (MD)? Can't answer question without investigating models of ILL, e.g., ordering copy of article from doc supplier is different from ordering ILL. FT wrote paper on different models. Must be careful that everyone doesn't define their own externals, which would interfere with interoperability. Thought we had reached a compromise: to do ILL things vs ordering non-returnables, then item request external would be ILL PDU definition from ISO standard (MH). ILL request PDU (ASN.1) is massive, so ZIG picked what was required from ILL PDU and what wasn't. Guiding principle: trying to use all of intellectual effort that went into meaningful data elements in ILL PDU, but could not agree on what precise form replication of ILL PDU would take (RD). Decided that external would be ILL request PDU or something else (RD). Developments in past few months: what is model for Item Order when specifying a result set item? No discussion about requested item (as opposed to item request). Target either puts into task package an ILL request or nothing (RD). No, it includes whatever it needs (MH). Concern is using access control or something else for additional info not available from result set. BW uses prompt-1, but FT doesn't like that. Additional info could be submitted in ILL PDU; use supplimental info in ILL request. When do you use ILL or Item Order (FT)? What's the model? What if you want something delivered electronically (RD)? That's not ILL or Item Order. FT will work on profile for bibliographic information; FT will work with MD (and SR?). Send FT comments on her docs. Will profile address both item request and requested item (SR)? If additional messaging is required (other than Item Order), then use ILL. If no additional messages are required, can use Item Order for returnable item. Two things (1) order from doc supplier, (2) initiation of ILL request (SR). Can we map data elements in ILL message to X.12 purchase order (JZ)? Further discussion will occur on list. Names don't match: pg 109 table of parameters refers to requested item; no requested item on pg 115-116 ASN.1 (LS). Needs to be corrected or commented. Item request is ILL PDU. Origin supplies ILL parameter; target translates that into another parameter and puts it in the task package. Target assumes responsibility for supplying query in task package (RD). 19. SCAN Probably need a second service within scan (SR). Two issues: (1) Display headings - what you index is different from the heading, but you want to return the full display heading, e.g., strip punctuation in index, but want to display with punctuation. Issue of subfield T, which is title in author field, part of heading. Case of many to one. Not every subfield is indexed in an author field. How do you know what to display if you haven't indexed it (RL)? Three choices: (a) keep display heading separately, (b) use algorithm to reconstruct display heading, (c) resort to database record to get display form. Need to be able to send index and display version in Present response. Concerned about creating new service to handle this; we should have done this right in the first place (MH). SR can live with current implementation and handle this in Other Info parameter, but we'll have to revisit this later.... (2) Cross references, e.g., see, see also, narrower than, broader than - could identify attributes to handle this relationship (SR). What about scope notes, earlier heading notes, etc.? Can we distinguish these different kinds of notes in the Other Info parameter? Do we need a Scan profile for bibliographic info (MH)? One approach is to profile instead of changing the service, but how do you discover the profile? Not making any changes to Scan right now, but we understand the issues now. Related item: Terms that are returned as scan list are not in fact the most efficient way to search those headings (JZ). Want to return display form of name with a magic cookie that can do the most efficient search. Searching the display form costs more than searching the index form. So, Entry should be a sequence of list entry (MH). We'll resolve this for the next version (RD). Won't change v3, but will add new Scan stuff to v4, with profiles or something in between. Is someone writing a paper on implementing Scan? RL putting API in public domain; API will include Scan. RL's paper will address Scan in minimalist way. LW's paper may include Scan. If alternate terms are returned, how do we tie Other Info with the right term (SR)? Other Info is carried at three different levels of the structure, e.g., term, attributes associated with the term, other info associated with those terms (LW). Need sequence of term info, which would break all existing implementations. Should be added to v4 (MH). [That's all folks!]