OASIS Repository Functional Requirements

Back to OASIS Member's-Only Registry and Repository Technical Committee Home Page

Revision History

Revision 0.2 , 16 August 1999 , TA
Broken out from draft tech spec.
Revision 0.2.1 , 22 August 1999 , TA
Added remark about carrying unique id in HTTP.
Revision 0.3 , 21 October 1999 , TA
extracted thttp info, added results of 21 Sept F2F, and recast the document entirely
Revision 0.4 , 12 March 2000 , TA
edits re comments from Lisa Carnahan

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