bath profile - vendor considerations page 1 the bath profile - vendor considerations rob bull

Bath Profile - vendor considerations

The Bath Profile - vendor considerations

Rob Bull


What vendors ?

• Bespoke system developers:– software houses– data providers

• Library cataloguing system vendors

• Suppliers of client packages/gateways

• Developers of other profiles

• Toolkit suppliers


Software Implications• To existing services/systems:

– Z39.50 components– database components– user interface components

• Consideration for new services/systems

• Maintenance/Administration• Toolkits/APIs• Decision for which functional area

and conformance level to achieve.


Existing Services/Systems• Need to look at which functional

area to fit into :– server side may be determined by

specifications of the database package

– client side may be determined by scope of user interface requirements

• Need to look at which conformance level to fit into :– decide if additional development is

necessary to raise current conformance level.


Existing Services/Systems• Z39.50 Scan Service:

– many systems do not support scan

• Record Retrieval:– many systems do not support GRS.1

or XML

• Holdings:– do any systems support the new

Holdings profile ?

• Character set and language negotiation:– very little implementation.


New Services/Systems• Look at requirements from

customers - see how they align to the profile.

• Make users/customers aware of the profile and its importance.

• Look at related national profiles, (e.g, Finnish, CENL, ONE-2, DanZig) for similar conformance.

• Will database support Character set and language negotiation ?.


Database Systems• Database functionality

determines much of the target functionality

• Will the database search capabilities support the profile attribute combinations ?

• Will the database support suitable indexing for the scan service ?


Maintenance/Administration• Client side:

– predictability of server behaviour– conformance to the profile should

reduce administration and the need to set up individual tables of attributes etc.

• Server side:– new indexes ?– supported search capability ?– Character sets ?


Functionality/Conformance• There is no easy way of

determining within the Z39.50 protocol the level of functionality or conformance supported by a client or server :– could be easily crafted on the Init

service using a simple XML definition

– use of XML is being tested in the ONE-2 project.


Toolkits• No new crafted ASN.1 in the

profile:– should not impact on popular

freeware Z39.50 toolkits, for example those of Crossnet and Index Data.

– vendors who use other Z39.50 toolkits will need to establish if there is support for GRS.1, character set and language negotiation etc.


Questions• Is this the big one... ?

– …or just another in a line of profiles, and should I wait to see what emerges next year ?

• Who is going to prove the profile is successful ?– ONE-2 project will address a

significant portion, but these are mainly bespoke systems and not COTS systems.


Questions• What about the new attribute

architecture being designed ?

• How do I create a companion profile for my community ?– CIMI is considering writing

guidelines for profile development.


Benefits• Conformance to a profile

ensures predictability to developers and users, – removes the syndrome: “code is

there because that’s how that system behaves”

• Provides a stable basis to extend in the future.


Drawbacks• At some time, the line of

profiles being developed has to stop to enable vendors the opportunity to catch up with their developments.

• Is a low level of conformance really just an opt-out escape clause, or should developers and vendors bite the bullet and aim for a higher conformance level.

bath profile - vendor considerations page 1 the bath profile - vendor considerations rob bull

Documents