Back to OASIS Member's-Only Registry and Repository Technical Committee Home Page
Many functional requirements for the software that supports a repository are general, and not specific to a repository for XML-related entities. This document lists requirements determined in discussion by the OASIS Registry and Repository Technical Committee, particularly at a face-to-face meeting on 21 September 1999, in two sections: requirements prioritized at that meeting and additional generic requirements.
1 = must have in initial implementation 2 = would be nice to have in initial implementation 3 = not needed in initial implementation but needed later on === USER ACCESS 1 Access to the system shall be available through a Web browser interface that supports direct access based on unique ID, and also navigation and searching. 1 Searching must be enabled on metadata. 2 Searching shall be enabled on the content of registered items, and on a combination of both metadata and content. 1 The system must be capable of providing and maintaining information about items associated with registered items, such as documentation, and version information about such items. 2-3 The system must be able to discover and display information about what other items an item is used in, and conversely, what items use a registered item. 1 The system must be capable of notifying users browsing the metadata that a more recent version is available. 3 The system must be capable of handling subscription and notification of changes in repository content (by subject) and of new versions of registered items (by ID). 1 The system must be capable of presenting registration-related metadata (such as that specified by ISO/IEC 11179, see requirement to record such info under "Operations"). 1 The system must be capable of presenting a typed list of links of related items (documentation, style sheets). 1 The system must capable of displaying a subset of any of the taxonomies applied to registered items, corresponding to those taxons actually used for registered items (the view for browsing the content). 1 The system must capable of displaying the entirety of any of the taxonomies used (the view for browsing the taxonomy to determine what taxon to use for classifying a submission). 1 The system must enable i18n and localization, whether they're done in the first version or not. === INTEGRITY 1 The system must not register an item under an already registered identifier. 1 The system must maintain data integrity. === SECURITY 1 The system must have security controls based on roles, rights, access controls, which must be scaleable within reason. [An LDAP-based directory with management utilities is a possible solution.] 1 The system may provide authentication and authorization services, but these may be implemented out-of-band; access to the repository by persons or entities other than the repository operator may be forbidden. 1 Access for registered items and their metadata shall be limited to registrants (in 11179 terms, Submitting Organizations and Maintenance Organizations) and the Registrar. ==== PLATFORM 1 Access to the system must not require use of a particular browser. [additional reqs to be added] ==== ==== OPERATIONS 1 The system must be functional 24 x 7 (adjust as desired). 1 The system must have the usual data protection facilities, such as backup and restore capabilities. 2 The system must be capable of storing complete life-cycle history for registered items. 2 The system must be capable of archiving items that are no longer to be served to the public. 1 The system must support access to registered items using the following identification schemes: URN, URL, FPI, PI (format of request to be determined, but we are strongly leaning toward THTTP revised (RFC no 2483). 1 The system must be capable of recording a set of metadata for registered items (such as that specified by ISO/IEC 11179, see http://www.sdct.itl.nist.gov/~ftp/l8/11179/) supplied by the registrant in an XML format to be specified by the OASIS Regrep TC. 1 The system must maintain information on versions of registered items and the relations among versions. 1 The system must be capable of maintaining taxonomic information about registered items along at least three axes: subject, genre (book, article, etc.), related items (documentation, style sheets, etc.). Several small taxonomies, such as registration status, are used in the registry-specific info. 3 Respondents to the RFP must define an open API for complex rep-to-rep request. 1 The system must support a Web-based interface for the submission of items and their metadata. 3 The system must support means of submitting items and their metadata aside from the use of a Web-based interface, particularly submission of multiple entities that share common metadata. 2-3 The system must enable automation of business processes associated with submissions. 1 The system must be capable of providing acknowledgements for submissions (functional and registry-specific). 1 The system needs to be able to record and maintain relations among items in the system, across language and other versions. A taxonomy of relations is to be provided by the OASIS Regrep TC; they include "is documentation for" and the like.
To add to these functional requirements from the F2F, Una Kearns supplied the following:
Y2K Compliance: All client and server software must be Y2K compliant Supported Client platforms: Repository access shall be available through a Web Client Supported server platform: Do we care? e.g Solaris, AIX, etc.. Replication/Distribution: The repository shall support either replication of data in a read access mode or/and full distribution Note: This may or may not be a requirement -- but some type of staging of data must be supported. Language requirements: Character Sets: The UTF8 character set shall be supported. Administration: Documentation Full administrative documentation must be supplied with the product. Core maintenance tools The system must provide a set of tools to aid in creation and maintenance including, but not limited to, the following: * creation/maintenance of databases * creation/maintenance of log files * creation/maintenance of users * creation/maintenance of groups * archiving * log viewing * repository optimization Transaction logs The system must maintain transaction log files which include information such as: * user login * object accessed * type of access * date/time stamp API: API documentation: The API must be completely documented. The documentation must identify all syntax as well as expected return values. The documentation must also contain programming examples. The API must be complete -- provide full access to repository functionality The API must be acessible through standard programming languages (C++ and Java).
Back to OASIS Member's-Only Registry and Repository Technical Committee Home Page