ZIG Meeting

  Notes provided primarily by Les Wibberley.

Overview - Ray

• manifestations
• 1988 version - explain was referred to as a future service (singular)
• 1992 - future services (plural) mentioned
• 1995 - separate facility actually defined
• 1995 - explain facility
• explain database
• accessed via search and retrieval
• attribute set and syntax
• ISO SR roots of this in the form of Help (tasteless joke deleted)
• Rationale
• Denis lynch paper in 1997
• described concepts
• lots of complexity in explain thought necessary several years ago
• complexities
• access info , termlist associated DBs, sub DBs, per element details, processing details, etc.
• issues
• model
• complexities
• what information does a client need

"Bob's Perspective"
Bob Waldstein

• personal experience
• hundreds of databases with diverse design
• explain met the needs to be able to search all these databases
• use mostly attributes and element sets
• implemented other features
• have had a wide range of requests from outside the zig
• others are finding out databases using explain
• Explain is not really part of the protocol
• search and retrieval implementation
• much of it only explained in Denis's paper
• There is a core set of functions used
• Bob beginning to give up on it
• has had it up for about 7 years, but know of no one else interoperating with it
• will continue to use for internal use
• not sure about need for interoperability

Explain-Lite
Poul Henrik Jørgensen

• background
• ONe project charged to implement explain
• requires significant effort to implement at both client and server
• maintaining the explain database requires tools
• very few client request the explain data
• most clients use proprietary files from target
• lots of effort to implement, and not used much
• objectives
• define common extensible config. file for z clients
• much simpler to implement and maintain
• usable for both z clients and humans
• minimal impact on z profile
• solution
• xml structure with relevant config. information
• delivered in init response packet
• also presented via web servers with xsl style sheets
• specification:
• http://www.bibsys/z/explainlite.dtd ... will be put online with slides
• xml example
• xsl display resulting from style sheet
• summary
• explain lite developed as alternative to proprietary client config. files
• same info may be used as user info via the web
• should be aligned with emerging generals standards such as UDDI and WSDL (Web Services Description Language)

UDDI
Matthew Dovey

• Universal description, discovery, and integration
• motivation from the e-business community
• consortium of major computer system vendors
• not a new concept or technically rich
• lot of enthusiasm and support, which is more important for interoperability standard
• e-marketplace model
• businesses advertise services
• customers/clients locate services
• client software obtains protocol level information needed to connect and interact with the service (like explain)
• goal is that this happens automatically behind the scenes
• technical
• data are in xml model
• api specified via SOAP
• uddi over xml over SOAP over http over tcp/ip
• three reference implementations
• T-models specify a template for the contact information
• link to Tmodels is a windows-like link
• explain and uddi
• alternative mechanism for publishing explain and lite
• uddi frontend gateway to existing explain
• why? increased visibility of services
• asn.1 and WSDL
• ASN could be recast in WSDL
• could  produce the core spec better suited to xml encodings
• next generation tools would build soap/xp layers automatically on discovering the protocol from the uddi register
• raises the visibility of z39.50
• Matthew will be experimenting with this
• directories
•     z39.50 service registry?
• ill/ncip registry?
• perhaps as frontend to explain/ldap
• technical issues
• very poor search interface at this time - maybe use z39.50.
• metadata model is very naive
• issues of global distributed registry (replication)
•   related t-Model structure which is not very rich yet ( reflecting the relationship between protocol, attribute sets, profiles, and service specifics)
• But lots of interest and backing.  This is where to be seen to attract customers
• questions
• the api is used to interact with the registry and the information coming back are specified, the registry itself is not specified
• how to know where to start to find this
• there is a whole replication of uddi registries
• discussing interaction between this and ldap
• who is working on this?  plan to bring the specs to w3c, but for now group of major computer vendors (many major players)
• lots of companies already registering on the registry
• all information registered is public domain
• open architecture to add information
• repositories replicated or referred?

discussion

• explain issues
• do we need an interoperable explain?
• what parts of explain are needed? for what?
• example: drop support for things like negotiating extended services
• is the search and retrieval model correct?
• should it be part of the z39.50 protocol?
• Ralph: tried to do explain, and it was way too much work
• Lennie: agreed with Ralph's position
• But most clients are not flexible enough to dynamically react to discovering this on the fly within the session
• Mike and Joe agreed
• Joe indicated that they were now using Explain Lite, but a different flavor of it
• Is search/retrieve the right model for Explain?
• sending stuff in init for explain lite.
• but these various versions use different formats
• explain lite also gloms all the different databases together
• Explain doesn't solve the whole discovery problem
• perhaps consider use of UDDI as an alternative
• use of z39.50 search and retrieval model implies a boot-strap problem
• UDDI and Explain are two different ways of looking at the same information
• Mike: proposal for adding something new to Explain, from the Thesaurus project
• Ralph: tried to implement the full explain, and failed
• perhaps focus on identifying what is necessary and complete, and grow experience
• Ray:  Explain is a more controlled service, client has some control over what is returned, e.g., after certain date, for specified database; explain lite doesn't scale up well for large number of databases
• perhaps pare down existing explain and add explain-lite
• keep both of these as alternative approaches to explain
• Sebastian - perhaps cast explain lite as a new thing, pared down from explain
• consider explain-lite as the executive summary aspect of explain; augments it
• Bob: Alan Kent had a bunch of more new categories he was using
• there has never been any provision for getting explain intact without using explain syntax
• Sebastian: should be able to define an XML equivalent pretty easily
• extensibility of explain (Mike)
• Ray: there is the capability to add new categories via OID
• Bob: wrapup
• put out proposal on the list to get a single explain-lite definition, add new categories, support XML syntax
• Ray: propose new version of explain, with sections deleted, defined by explain-2 record syntax, create simpler subset
• Ralph: endorses profile view, rather than cutting sections out.  This is less disruptive.  Just focuses on the key things really needed
• Ray; make this a self-contained profile and not point to the original explain standard
• Bob will lead this effort