SOLICITATION NOTICE
99 -- VALIDATION TOOL FOR COMPLIANCE TESTING OF DIGITAL TALKING BOOKS
- Notice Date
- 1/15/2003
- Notice Type
- Solicitation Notice
- Contracting Office
- Library of Congress, Contracts Services, Contracts Section, 101 Independence Ave SE LA-325, Washington, DC, 20540-9411
- ZIP Code
- 20540-9411
- Solicitation Number
- RFQ0301261
- Archive Date
- 2/6/2003
- Point of Contact
- Valda Murfree-Fleming, Contract Specialist, Phone 202-707-0468, Fax 202-707-8611,
- E-Mail Address
-
vmur@loc.gov
- Description
- The Library of Congress intends to negotiate on a sole-source basis with Daisy Consortium as follows: C. Description/Specifications/Work Statement C.1 Background The National Library Service for the Blind and Physically Handicapped (NLS) led a group of international partners to develop the American National Standard ANSI/NISO Z39.86-2002 Specifications for the Digital Talking Book (Z39.86). This standard is beginning to be used in the United States and abroad and is expected to be widely adopted by libraries for the blind around the world. The standard designates NLS as the maintenance agency responsible for its upkeep, and an NLS staff member is the current chair of the advisory committee for the standard. Therefore, NLS has a special responsibility for ensuring that the standard is supported. A variety of specialized software tools are required to produce digital talking books (DTBs) in accordance with Z39.86. Some of these tools will be produced by for-profit firms for sale to DTB-producing agencies. One tool, however, must be developed and maintained by the community of agencies who developed and support Z39.86. That tool is a validator, a software suite running on a personal computer, which checks a finished DTB against the requirements set by the standard. This validation tool must be under the control of the community using the standard, so that it is developed and maintained in a fair and open manner that is not prejudicial for or against any agency or firm operating in the Z39.86 realm. C.2 Scope of Work The contractor shall develop a software suite (called the Z39.86 DTB Validator) for testing the compliance of digital talking books with ANSI/NISO Z39.86-2002. C.3 Work Statement/Tasks to be Performed C.3.1 High Level Requirements and Objectives C.3.1.1 Functionality Objectives The contractor shall develop a Z39.86 DTB Validator which shall perform a series of structural, syntactic and relational tests based on the requirements of ANSI/NISO Z39.86-2002 and associated specifications. All tests that have been run and have failed shall be identified by the validator, thus providing the user with data to detect non-conformant DTBs, and assist in the repair of the anomaly. The validator developed under this contract shall only test for conformance of Type 1 (audioOnly) and Type 2 (audioNCX) books, as defined in section 13 of ANSI/NISO Z30.86-2002. Later versions of the validator will test conformance of other DTB types. C.3.1.2 Design objectives The contractor shall design the validator in accordance with the following objectives: 1. The Z39.86 DTB Validator should be designed with longevity and simple maintenance in mind. 2. The design should allow for logical and scope extensions over time with minimal effort. 3. The design should allow for easy customization and adaptation, and specifically provide the ability to append local/agency-specific/content-specific tests 4. The design should make use of standardized and non-proprietary programming languages, processors and methods to the largest extent possible. C.3.1.3 Validator Components The validator shall consist of the following components: 1. Test Map A Test Map, which is a document that identifies all tests performed by the validator. The Test Map shall be machine-readable and human-readable, and each test therein must be clearly and unambiguously identified and explained. 2. Test Performing Objects A set of Test Performing Objects, such as XML DTDs, RELAX NG schemas, XSLT documents, and computer code classes. These objects are the core of the validator and perform the tests that determine the validity of a DTB. These are referenced by the test map regarding unique identification and purpose/test scope. 3. Sample Implementation A Sample Implementation that uses the Test Map and the Test Performing Objects to form an application. This application presents an interface to the user that allows them to select the target of the test, the tests to be performed, and the output format desired, and to initiate the tests. 4. Documentation Documentation for the Test Map, the Test Performing Objects and the Sample Implementation. This documentation allows those responsible for maintaining the validator to more easily correct bugs, implement enhancements, etc. C.3.1.4 User Group Requirements The Test Map and the Test Performing Objects shall be designed so that they provide a functionality that meets the needs and requirements of the following user groups. An implementation may choose to focus on a subset of them. Content producers. Organizations creating DTBs need a tool for quality control purposes. For these users, the tool should provide clear, non-technical reports of what is wrong with a DTB and, perhaps, how it might be repaired. Distribution environments. Organizations that distribute DTBs need a tool to certify that the product to be delivered is fully functional, and to effectively diagnose DTBs that are identified by users as defective. Production tool developers. Companies developing systems whose output is DTBs need a validation tool in order to verify that their systems function properly. For these users, the tool should provide clear, technical reports of what is wrong with a DTB, with as much detail as possible (such as file names, line numbers, markup element IDs, etc.). Playback system developers. Companies developing playback systems for DTBs need a validation tool in order to verify the validity of content used during debugging and testing. These users have similar needs to those of production tool developers. Conformance testing. Conformance testing agencies such as the DAISY OK team need a validation tool in order to complete the work of conformance testing for production tools, as well as to validate test content used in conformance testing of playback systems. For this purpose, the tool should generate clear, detailed reports, and should reference the appropriate specification sections for reference. C.3.2 Sample Implementation Design Requirements C.3.2.1 Input Requirements The Sample Implementation shall as one session support: ? validation of a single-volume DTB ? validation of a multi-volume DTB ? validation of one single-content data set member ? validation of a multi-DTB volume ? validation of a specified subset of tests in any of the above C.3.2.2 Output Requirements After validating a DTB or part thereof, the Sample Implementation shall, if at all possible, output the following data: ? the locus of the occurrence depicted as exactly as possible (path, filename, line, column). ? a description of the type/nature of the occurrence. This should be provided in several versions (technical, non-technical, abbreviated, extensive) to better suit differing use cases. ? a statement on whether the occurrence represents a warning or an error state. ? a pointer to the specification/specification fragment, where the occurrence is defined in its expected/correct state. C.3.2.3 User Interface Requirements The user interface of the application should be: ? simple enough to use by users without extensive technical knowledge ? allow the user to save a report as a machine-readable and/or human-readable document ? allow the user to cancel the validation whilst in operation ? allow the user to select a subset of tests to perform ? be accessible to users that are blind or otherwise visually impaired ? translatable to other languages (this shall also be true for the report) C.3.2.4 Platform Support Requirements The sample implementation must run on any of the following operating systems: ? Windows 2000 SP3 or later ? Windows XP SP1 or later ? Linux 2.4 kernel or later ? Mac OS9 or later C.4 Deliverables The deliverables shall be: 1. Alpha version 1 (prototype). This prototype shall consist of: ? preliminary test map ? preliminary versions of key test performing objects ? design and preliminary version of sample implementation ? outline of documentation for test performing objects and sample implementation 2. Beta version 1 (engine with core set of tests), consisting of: ? completed test map ? operational test performing objects ? operational sample implementation ? preliminary documentation for test performing objects and sample implementation 3. Version 1.0 (engine and core tests debugged and verified), consisting of: ? final test map ? debugged and verified test performing objects ? debugged and verified sample implementation ? final documentation for test performing objects and sample implementation C.5 Licensing of Deliverables All deliverables mentioned above will be licensed under an Open Source License, as the validator is being jointly developed by NLS and the DAISY Consortium. To allow for commercial products to integrate and make use of any of the Z39.86 DTB Validator deliverables, a license such as the GNU Lesser General Public License will be utilized. C.6 Contractor Requirements The contractor must possess the following skills and experience: Intimate knowledge of ANSI/NISO Z39.86-2002 Extensive experience building software tools implementing ANSI/NISO Z39.86-2002 or DAISY 2.0, 2.01, or 2.02, on which Z39.86 was based Experience building successful validation tools for standards of similar complexity to ANSI/NISO Z39.86-2002 Extensive XML experience, including the creation and implementation of RELAXNG schemas and XSLT documents Extensive JAVA programming experience C.7 Period of Performance The period of performance of this contract is to begin with date of award and continue until all deliverables have been received and accepted by NLS, estimated to be approximately six months. C.8 Delivery Schedule Deliverable Complete on or before-- Alpha version 1 14 weeks from date of award Beta version 1 18 weeks from date of award Version 1.0 22 weeks from date of award NO PHONE CALLS PLEASE. INTERESTED PARTIES MAY RESPOND ON OR BEFORE THE ABOVE-LISTED CLOSING DATE VIA FAX, OR EMAIL, INCLUDING QUESTIONS. PROPOSALS WILL BE ACCEPTED ON OR BEFORE THE ABOVE-LISTED CLOSING DATE VIA FAX, OR EMAIL. NOTE: THIS NOTICE WAS NOT POSTED TO FEDBIZOPPS.GOV ON THE DATE INDICATED IN THE NOTICE ITSELF (15-JAN-2003). IT ACTUALLY FIRST APPEARED ON THE FEDBIZOPPS SYSTEM ON 16-JAN-2003. PLEASE CONTACT fbo.support@gsa.gov REGARDING THIS ISSUE.
- Record
- SN00241367-W 20030118/030116214729 (fbodaily.com)
- Source
-
FedBizOpps.gov Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |