OASIS Registry Technical Specification

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

OASIS–Organization for the Advancement of Structured Information Systems

Copyright © 2000 by OASIS–Organization for the Advancement of Structured Information Systems

04 August 2000

Revision History

Revision 0.1, 15 June 1999, TA
Initial version.
Revision 0.1.5, 5 July 1999, TA
Added material on RFC 2169 and RFC 2483, suggestion that we use RDF. Added Michael Mealling to list of contributors. Added mention of TA's essay in taxonomy. Added "User Preferences Among Registries and Repositories" section. Deleted personal names in scenarios. Added section on typology s.v. "Interface", warning not to link to interface. Added section on usage of registry documents.
Revision 0.2, 16 August 1999, TA
Added pointer to IETF WEBDAV page. Adjusted references to DASL I-D, which is now renamed. Added an awful lot of input from face-to-face meeting. Extracted some material formerly in this document and put it in others. Renamed to refer to registry only.
Revision 0.2.1, 8 September 1999, TA
Added remark about XML Schema in a repository.
Revision 0.3, 19 October 1999, TA
Updated, reduced scope, included references to DTDs and sample documents
Revision 0.4, 17 November 1999, TA
Made it clear what is normative and nonnormative in submission section.
Revision 0.9, 9 April 2000, TA
revised per comments by Lisa Carnahan and edited generally; moved some func reqs into this document; folded in request by identifier, design principles.
Revision 0.95 July 2000, TA
The objective and principles were changed. The design principles and scenarios were revised. Section 6 - Registry of the previous version has been removed. Section 6 now contains an Information Model . Section 7 - Submission Semantics has been removed. Section 7 now contains XML defintions and protocols that relate to the Information Model. The remaining sections are unchanged.
Abstract

The OASIS Registry and Repository Technical Committee of OASIS, the Organization for the Advancement of Structured Information Standards (formerly SGML Open), seeks to specify the interfaces of a registry for some set of or XML-related entities, including but not limited to DTDs and schemas, with appropriate interfaces, that enable searching on the contents of a repository of those entities. The registry and repository shall interoperate and cooperate with other registries and repositories compliant with this specification and respond to requests for entities by their identifiers. This document deals primarily with the registry, although some scenarios and requirements for the repository are included.


Table of Contents

1. Overview
2. Design Principles
3. Scenarios
3.1. Obtaining a DTD Automatically
3.2. Depositing an XML-Related Entity
3.3. Registering an XML-Related Entity without Deposit
3.4. Browsing or Searching for a DTD
4. Basic Functional Requirements
5. In Scope But Not Specified
6. Information Model
6.1. Concepts
6.1.1. Registry Item
6.1.2. Association
6.1.3. Related Data
6.1.4. Organization
6.1.5 Contact
6.1.6 Classification
6.1.7 Classification Scheme
6.1.8 Package
6.1.9 Alternate Name
6.1.10 Alternate Description
6.1.11 Submission
6.1.12 Query
6.1.13 Request
6.1.14 Impact
6.2. Registy Model
6.2.1. Public View
6.2.2. Contact View
6.2.3. Classification View
6.2.4. Administration View
6.2.5 Enumeration View
6.3. Classifications
6.4. Attribute Types
6.5. Enumeration Entities
6.6. Entity Semantics
7. XML Definitions and Protocols
7.1. Entity Elements
7.2. XML Data Type Definitions
7.3. Request Elements
7.4. XML Entity Definitions
7.5. Request By Unique Identifier
8. Conformance
9. Normative Policy Requirements
9.1. Intellectual Property Notices
9.2. Integrity
9.3. Security
9.4. Disaster Recovery
9.5. Persistence
9.6. Retraction
9.7. Privacy
9.8. Quality Control
9.9. Limitation of Legal Liability
9.10. Notice of Quality of Service
10. Appendix: Terminology and Relevant Specifications

Editorial Note

Comments welcome, to lisa.carnahan[at]nist.gov.

This document was marked up in Norm Walsh's Simplified Docbook XML DTD, and converted to HTML with the aid of his XSL style sheet. Output in RTF and other formats can be obtained by using James Clark's XT and XP tools and Norm Walsh's DSSSL style sheets for Docbook.

Please be sure to cite the version of the specification along with relevant section title when making comments.

The words “must,” “must not,” “shall,” “shall not,” and “may,” in this document are to be interpreted as described in RFC 2119.

1. Overview

As XML comes into use on the Web, DTDs, schemas, style sheets, and reuseable public text will be referred to by identifier, rather than being packaged with actual documents. It is critically necessary to be able to retrieve the referred-to entities, and in the Web context, it is preferrable to be able to do this automatically. And it is vital for users to be able to locate DTDs and schemas for the document types they want to create by consulting an interface to metadata about those DTDs and schemas.

Objective and Deliverables. The objective of the OASIS Registry and Repository Technical Committee is to develop a specification for interoperable registries and repositories for SGML- and XML-related entities, including but not limited to DTDs and schemas, with an interface that enables searching on the contents of a repository of those entities, and to construct a prototype registry and repository. The registry and repository are to be designed to interoperate and cooperate with other registries and repositories compliant with this specification. The prototype is intended to serve as a model for an extensible and distributed network of registries and repositories; the specification is viewed as the primary deliverable.

Contributors. The chairman of the OASIS Registry and Repository Technical Committee is Lisa Carnahan of the U.S. National Institute of Standards and Technology (NIST). Norbert Mikula of DataChannel is the OASIS Chief Technical Officer. The members of the Technical Committee are: Nagwa Abdelghfour (Sun Microsystems), Terry Allen (Commerce One), Lisa Carnahan (U.S. NIST), Robin Cover (ISOGEN) Úna Kearns (Documentum), Norbert Mikula (DataChannel), Yutaka Yoshida (Sun Microsystems), Jaime Walker, Boeing, and Priscilla Walmsley (XMLSolutions). Ron Daniel (Metacode) is an invited expert. Other individuals who have contributed to the development of the specification include Joe Alfonso (Sun Microsystems), Murray Altheim (Sun Microsystems), Bryan Caporlette (Sequoia Software), Len Gallagher, (U.S. NIST), Eduardo Gutentag (Sun Microsystems), Michael Mealling (Network Solutions), Ron Schuldt (UDEF), and Norm Walsh (Arbortext),

2. Design Principles

The following design principles have been agreed to:

  1. The Registry Technical Specification shall employ existing standards and specifications where possible, avoiding specifications that are not stable.

  2. The normative part of the Registry Technical Specification shall be as small as reasonable.

  3. The normative part of the Registry Technical Specification shall be complete enough that registries and repositories conformant to it can interoperate in an extensible and distributed network.

  4. The normative part of the Registry Technical Specification shall be extensible; in particular, it shall be possible to extend the registration information schema or DTD without inhibiting interoperability among registries. (This point is called out because the registration information schema or DTD is likely to be a normative part of this specification).

  5. The Registry Technical Specification shall be vendor-neutral.

  6. The Registry Technical Specification shall use XML by preference for encoding of information and documents.

  7. The Registry Technical Specification shall assume the use of HTTP.

  8. The registry and repository shall be scaleable.

3. Scenarios

These scenarios (or use cases, if you believe that use cases aren't scenarios) involve both users retrieving something from the repository and contributors registering something in the registry, which may involve depositing something in the repository. The OASIS Registry and Repository Technical Committee does not intend to specify solutions to all of thees scenarios, especially those that involve services built on top of registries. The OASIS Registry and Repository Technical Committee intends to add scenarios to this list only when they affect the data model proposed for the registry and repository.

3.1. Obtaining a DTD Automatically

A user or user agent retrieves an XML-related entity such as a DTD automatically over the Web, as a result of some use of it in an XML context.

Motivation. Unless everything needed for parsing and displaying a document under all circumstances is packaged with the document itself, the document must refer to something (DTD, style sheet, public text) by identifier. It is necessary to be able to retrieve the referred-to entity, and in the Web context, it is preferrable to be able to do this automatically.

Example A. A user is sent a document the DOCTYPE declaration of which refers to a DTD by unique identifier (URN, PI, or FPI). His parser tells him it can't find the DTD, so he goes out and retrieves it manually from a repository (he doesn't need the registry interface because he has a unique ID but he does need to know where to find the repository).

Example B. A user clicks on a link to the stockmarket news and his browser receives an XML document the DOCTYPE declaration of which refers to a DTD by unique identifier; his browser, which has no copy locally, retrieves it automatically from the repository.

3.2. Depositing an XML-Related Entity

A creator of a resource deposits it, possibly along with related data, for service to the public, at some range of accessibility from archival (retrieval rate could be slow) to utility (retrieval rate must be fast, large number of connections must be supported, round-the-clock uptime with failover, etc.).

Motivation. Many creators of resources lack the facilities to serve them reliably; even those that can do so may not wish to deal with the burden.

Example A. An IETF working group decides that a DTD that is part of their specification, but which the IETF has no facilities to serve, must be available from a public Web server with high bandwidth, and doesn't want to have to maintain the server. It sends the DTD to a registry and repository services, which serves it, as in the first scenario.

Example B. A nonprofit publisher wishes its resources to be available for inspection and display. It deposits the resources in a repository and provides appropriate metadata for the repository's registry. The owner of the repository undertakes to make them available (but not with a high guaranteed quality of service).

Example C. Rosetta Net, a (real life) consortium of hardware vendors and suppliers, develops UML models, DTDs, and sets of text values used in their content, all expected to be in heavy demand, the text values to change frequently. It deposits the UML models, DTDs, and the initial set of text values in a repository, contracts for a regular update schedule and the highest available quality of service, and the repository undertakes to serve them, update them as agreed, push updates to subscribers, and maintain high quality of service for retrieval requests. Rosetta Net doesn't need a registry interface for this purpose because everything is to happen automatically, but it provides appropriate registry metadata so that the DTDs can be browsed and searched.

Example D. The Air Transport Association, which maintains important DTDs but make them available only to its members, wishes to offload the work of supplying those DTDs. It deposits the DTDs in a repository, contracts for service as in Example C, and in addition arranges that the DTDs are listed in the registry interface but are available only when an appropriate credential is presented in connection with a request for them. (This is an application of access control.)

3.3. Registering a Resource without Deposit

The owner of a resource, or another repository, registers the resource in the registry, but does not deposit the resource itself.

Motivation. Registries can interoperate to increase useability, but the actual storage location of a resource alone must not restrict the content of a registry.

Example A. A special-purpose registry wishes to makes its content visible in another registry, while maintaining that content in its own repository. It submits appropriate registry documents to the registry, including a pointer to its repository, and agrees with the registry that it will supply timely update information and that the registry will update its records and interface in a timely manner.

3.4. Browsing or Searching for a DTD

A user ready to compose an XML document searches for a DTD that covers the subject of the document.

Motivation. Every day in newsgroups and e-mail discussion lists such as comp.text.sgml, comp.text.xml, and xml-dev people ask whether there is a DTD for some subject area or functional purpose. The number of such queries will grow if XML is widely adopted. Somehow they have to be answered if wheel reinvention is to be minimized.

Example A. A user is about to write his resume, and wants to use XML. He goes to a registry and looks in a subject hierarchy (or taxonomy) to find a resume DTD (this is browsing, not searching). The subject hierarchy interface displays three appropriate listings, he chooses among them on the basis of their descriptions, downloads the DTD he chose from the repository, manually adds it to his SO catalog, and sets to work with vi and SP.

Example B. A user is about to write his resume, and wants to use XML. He goes to a registry and uses its search engine to find a resume DTD (this is searching, not browsing). The search interface returns three hits, he chooses among them on the basis of their descriptions, downloads from the repository the DTD he chose, and loads it into his XML writing tool. The interface also provides a time-to-live value, showing him how long he can expect his resume DTD to be served by the repository.

Example C. A homeowner is about to advertise his house for sale, and opens his verboprocessor. He says "take a memo: real estate for sale" and the verboprocessor automatically contacts a registry to find an appropriate XML DTD for the homeowner's jurisdiction. He dictates the text of his ad, and the verboprocessor sends it to all real estate listing services it can locate. (In this scenario the verboprocessor uses a registry to find something in a repository and queries the repository with more than one query parameter.)

Example D. An XML application designer needs a component to represent the list of names of French provinces, so he consults a registry. The registry interface indicates that the list is available as a tab-delimited list in ASCII, as an XML schema datatype declaration, and as a parameter entity declaration in DTD syntax. He chooses the parameter entity declaration format by clicking something in the interface, and the repository returns it.

4. Basic Functional Requirements

On the basis of the registry and repository scenarios, the following functional requirements have been identified:

5. In Scope But Not Specified

The OASIS Registry and Repository Technical Committee has omitted to specify how to provide certain functionality that it is agreed is needed:

6. Information Model (normative)

6.1. Concepts

Each registered object is associated with two pieces of information: 1) an electronic file consisting of a specific digital instance of the registered object, and 2) metadata for naming, describing, and locating the registered object and identifying its associations and relationships with other objects. The metadata for a registered object is maintained by a Registry, and the file containing a registered object is maintained by a Repository. The Registry and Repository are tied together in that the metadata for a registered object in the Registry includes a globally unique locator for a file, in some Repository, that contains the registered object.

If the registered object is a free, publicly available object, then the locator is an anonymous URL or FTP reference that can be used to retrieve the file containing the object; otherwise, the locator may need to be supplemented with payment or password information before the file containing the object can be retrieved. Some Registries may distinguish themselves by also being the Repository for any free, publicly available objects described in the Registry.

The metadata for a registered object is represented by several general structures, described conceptually in the following sections.

6.1.1. Registry Item

A Registry Item contains information that identifies, names, and describes each registered object, gives its administrative and payment status, defines its persistence and mutability, classifies it according to pre-defined classification categories, declares its file representation type, and identifies the submitting and responsible organizations. A registry item is a root entity in a Registry in the sense that many other metadata items in the Registry are directly dependent on it. For example, deletion of a registry item results in deletion of all other metadata items that depend on it.

Each registry item has a non-public, local identifier created by the Registration Authority. This identifier is used to maintain relationships of this item with other items in the same registry. In the Registry Information Model, this identifier is said to be of type REGISTRY_ITEM. In addition, each registry item has both a common name and a global name. The common name is intended for use by humans and is not necessarily unique except in some local human context. The global name is intended for use both by humans and by software systems; it is unique within all registries that claim conformance to the OASIS specification. In order to avoid ambiguities in presentation of information, the local identifier and the global name must be in a one-to-one correspondence with one another.

Each registry item is classified by a primary classification, and an optional sub-classification, each defined by the sponsoring organization. For example, for OASIS the primary classification identifies the registered object as either: an XSGML definition, an XSGML instance, a Package of registered objects, or some Other document type. The OASIS sub-classification identifies the specific XSGML type of the object if it a definition, or the type it conforms to if it is an instance, e.g. DTD, schema, element, etc. The details and constraints of these and other information items for a Registry Item are given in the Entity Semantics section below.

6.1.2. Association

An Association maintains pairwise relationships among registry items. One item in the pair is called the given item and the other item in the pair is called the associated item. The given item is a registry item in the same Registry as the association instance. The associated item is a registry item in any conformant Registry, possibly one not managed by the same Registration Authority. The associated item is uniquely referenced by its global name. If an associated item is also a registry item in the same Registry as the association instance, then the association instance holds the value of its local identifier.

Each pairwise relationship identifies the role played by the given item in relationship to the associated item. Initially the OASIS specification supports uses, supersedes, contains, and related roles.

The details and constraints of associations and roles for the OASIS specification are given in the Entity Semantics section below.

Examples:

  1. A registered XML document uses the registered XML DTD that defines its structure.
  2. A registered XML DTD uses a registered XML element or attribute that the DTD references by the global name of the associated element or attribute.
  3. A registered XML DTD uses a registered package consisting of other registered XML DTD's and their associated documentation and style sheets if it references the package by its global name and references package contents by their common names.
  4. A registered XML element supersedes another registered XML element if it has the same common name but a different version ID and thus a different global name.
  5. A registered diagram of some MIME type is related to a registered XML DTD if the diagram is a graphic visualization of the DTD.

6.1.3. Related Data

Related Data is a conceptual notion used to collect together references to data objects that are related to a registered object. This category of metadata is reserved for things like graphic visualizations, example sets, white papers, usage scenarios, extended documentation, etc. Sometimes related data objects will be very important, e.g. usage documentation, and will themselves be registered objects. At other times, related data objects will be less important support information for a registered item and will not themselves be registered.

In most cases, related data objects will not be registered, so their own metadata will not be maintained be a registration authority. Yet they are valuable supplements to a registered object and should be optionally available. In these cases the registration authority will only keep a list of the name and type of the related data object, with just enough additional information so that they can be presented as options on a web page. The related objects and their associated metadata will be created, held, and maintained by the submitting organization.

If a related data instance is not registered, then an instance of it consists of a human readable name, a URL, a standardized classification as a supporting object, a MIME file representation type, and a short human readable comment.

If a related data instance is registered, then its full documentation is carried as metadata in the Registry, including its MIME filetype and its standardized classification as a related data object. As with any registered item, its associations and relationships with other objects will be maintained by the Registry. In particular, its related role to some other item will be captured by an association instance.

6.1.4. Organization


The Organization concept identifies all organizations that have some relationship to a registered object. This includes a Submitting Organization (SO), a Responsible Organization (RO), and a Registration Authority (RA). An organization wishing to become a Submitting Organization must first make an application to a recognized Registration Authority. The process of application and approval is not defined is this specification, but the end result is that a Submitting Organization and responsible contacts within that organization are known to each Registration Authority to which they intend to make submissions.

Similarly, each Registration Authority and responsible contacts within that authority must be known to some central accrediting authority before that organization can be recognized as a legitimate Registration Authority. Once an organization has been accredited as a Registration Authority, then under proper authentication that organization will be trusted by other Registration Authorities for the sharing of Registry or Repository data.

Finally, a Responsible Organization is the organization responsible for creation and revision of the registered object. In many cases, the Responsible Organization will be an accredited standards development organization (e.g. as defined by ISO or ANSI), but it may also be some Submitting Organization. Every Responsible Organization should be able to supply a set of development and voting procedures whereby an initial specification gets approved, as well as development and voting procedures for corrections, amendments, revisions, and withdrawals. The Registration Authority is responsible for additions and changes to the metadata associated with a registered object, and for ensuring that revisions and withdrawals of registered objects abide by initial stability and persistence declarations.

Each organization has a non-public local identifier created by the Registration Authority that is used to maintain relationships among organizations, contacts, and registered objects. In the Registry Information Model, this identifier is said to be of type ORGANIZATION. In addition, each organization has both a common name and a global name. The common name is intended for use by humans and is not necessarily unique except in some local human context. The global name is intended for use both by humans and by software systems; it is unique within all registries that claim conformance to the OASIS specification. In order to avoid ambiguities in presentation of information, the local identifier and the global name must be in a one-to-one correspondence with one another.

6.1.5. Contact

A Contact is the identification of a person, role, or other entity within an organization that has some relationship to a registered object. A contact will consist of a common name, used to identify the contact within an organization, and some specific contact information such as telephone number and email.

Each contact instance has a non-public, local identifier created by the Registration Authority that is used to maintain relationships among organizations, contacts, and registered objects. In the Registry Information Model, this identifier is said to be of type CONTACT. Each contact includes a mandatory reference to some organization. It is not necessary to maintain a global, unique name for contacts because the global name for the organization together with the common name for the contact will be sufficient to uniquely identify the contact.

6.1.6. Classification

A classification is a partition of a given collection of items into mutually exclusive and collectively exhaustive sub-collections. A classification depends upon a pre-existing specification of a hierarchy of values, names, and codes called a classification scheme. Registry items in a Registry may be classified by as many classification schemes as deemed appropriate by the Submitting Organization.

6.1.7. Classification Scheme

A classification scheme is a hierarchy of values that can be referenced by a classification. A classification scheme can vary from a simple set of values to a complex multi-level hierarchy. An example of a simple single-level classification is the set {Freshman, Sophomore, Junior, Senior} used to partition a collection of students. An example of a more complicated classification scheme is one based on the hierarchy of all living things with named levels for Kingdom, Phylum, Class, Order, Family, Genus and Species. The Classifications section below defines the various types of classification schemes. The representation of classifications and classification schemes as XML documents for defining and exchanging classification schemes, and classification of items dependent upon those schemes, is given in another part of this specification.

6.1.8. Package

A Package is a conceptual notion used to identify a set of registered objects. It is defined to be a registered object that is a set of pointers to other registered objects. Using this definition, a package can represent a hierarchy of registered objects, where non-terminal nodes of the hierarchy are other packages and terminal nodes are package or non-package objects. A package is a terminal node in a package hierarchy if and only if the package is empty. A registered object may be pointed to by several different packages. A package relationship between a registered package and some other registered object pointed to by a package element is represented by the contains role in an association instance.

Since the representation of a registered object is defined to be a file, the file representing a package object is an XML document that conforms to the OASIS XML Package element defined elsewhere in this specification. Only the owner of a package can modify its contents. Rules for package definition and package maintenance are given in the Entity Semantics section below.

6.1.9. Alternate Name

Alternate Name is a conceptual category used to group together alternate names used for local or global reference to a registered object. Especially significant are names used in special circumstances or contexts, e.g. short names consisting of all visible characters from a limited character set for local identifiers in a specific programming language context, or globaly unique qualified names that satisfy the hierarchical qualification structure of a specific context. Alternate names can also be used for names in different human languages with characters encoded in unusual character sets.

An alternate name instance consists of the alternate name, a context for using that name, and a human readable comment that further explains how the name should be used. An alternate name instance is tagged with a language code and a character set code that apply to all other information in that instance.

6.1.10. Alternate Description

Alternate Description is a conceptual category used to group together alternate descriptions, in different human languages, of a registered object. The intent is that each alternate description is a direct translation of the initial description in a registry item instance. An alternate description instance is tagged with a human language code and a character set code that apply to the text of the description.

6.1.11. Submission

A submission is a collection of requests, in the form of a message, sent from a Submitting Organization to a Registration Authority. For administrative accountability the Registration Authority logs each submission into the Registry information model, timestamps it with the date and time received, and stores it for potential subsequent scrutiny. Any Registry entities created, deleted, or modified by a submission should be traceable back to the submission instance and to its Submitting Organization.

Each submission instance has a non-public local identifier created by the Registration Authority that is used to maintain its relationships among organizations, registry items, contacts, and other registry entities. In the Registry information model, this identifier is said to be of type SUBMISSION. Each submission includes a mandatory reference to a submitting Organization and to some Contact within that organization.

6.1.12. Query

A query is a message from a public user of a registry database to a registry, asking that certain information be returned. A request is generally sent in the form of an XML document that validates to one of the XML query DTD's defined elsewhere in this specification. The response to a query will validate to the associated XML response DTD.

A public user only has access to public information in the registry. This includes all of the information in the Public View of the registry, portrayed by the diagram in Section 6.2.1, as well as the Contact, Organization, and Impact information presented in Section 6.2.2, the classification hierarchy information presented in Section 6.2.3, and the code information presented in Section 6.2.5. It does not include the administrative information maintained by the registration authority for its own purposes.

6.1.13. Request

A request is a message sent from a Submitting Organization to a Registration Authority asking that certain additions or modifications be made to the Registry. A request is generally sent in the form of an XML document that validates to one of the XML request elements defined elsewhere in this specification. A request instance will consist of a request code to identify the type of request as well as the XML content of a specific request.

The kinds of requests that will supported by an OASIS conformant Registry are still under development, but will likely include the following:

6.1.14. Impact

An impact is a many-to-many relationship between Requests and Registry Items. Each request may have an impact on one or more registered objects. For example, a supersede request impacts both the superseded item and the new item that supersedes it. The addition of an association impacts both the given item and the associated item.

The Impact concept will maintain a historical record of all SO-initiated modifications of a registry item from first creation to final deletion.

6.2. Registry Model

The OASIS Registry information model is an Entity-Attribute-Relationship (EAR) model that defines the logical structure of an OASIS Registry. Other parts of the OASIS specification, especially query messages sent to a Registry and answer responses from a Registry, will be defined in terms of this model. Unless otherwise indicated, each concept described above is an Entity in the model, each information item associated with a concept is an Attribute, and each association between concepts is a Relationship.

In the figures of this section, a rectangle represents an entity and lines between entity rectangles represent relationships. The attributes that define an entity are listed as rows within the entity rectangle. For each attribute, the first column of the row is its name, the second column is its datatype, and the third column is an indication of whether or not it is mandatory.

Each entity in the EAR model represents both the data structure of a single entity instance and a container that holds a collection of persistent entity instances. The attributes of an entity determine the structure of a single instance and the relationships between entities determine pairwise associations among individual entity instances as well as constraints on collections of persistent instances.

Every relationship is bi-directional, always interpretable as from one entity to another, and vice versa. Each direction can have a cardinality of zero-to-many, one-to-many, zero-to-one, or one-to-one. We do not allow relationships to be many-to-many; instead, we define a new entity with two different relationships that satisfy the simpler assumptions, e.g. the Association entity. A zero-to-one or zero-to-many cardinality of a directional relationship indicates optionality, i.e. an instance at the from-side may not map to any instance at the to-side. In the diagrams, a small circle at the to-side of a directional relationship represents such optionality, as does the notation [0,1] or [0,n] at the from-side. A zero-to-many or one-to-many cardinality of a directional relationship indicates multiplicity, i.e. an instance at the from-side may map to multiple instances at the to-side. In the diagrams, triple feet at the to-side of a directional relationship represent such multiplicity, as does the notation [0,n] or [1,n] at the from-side. If a directional relationship is one-to-many, then an instance at the from-side requires the existence of one or more instances at the to-side. If a directional relationship is one-to-one, then an instance at the from-side requires exactly one instance at the to-side; this means that the from-side instance has a dependency on that to-side instance.

Dependency can be handled in several different ways. Suppose x and y are entity instances and that y has a dependency on x. If x is deleted, what happens to y? If y is also deleted, then we say that the dependency has a cascade delete effect. If the deletion of x is prohibited, then we say that the dependency has a cascade restrict effect. If y is somehow modified to remove its dependency on x, then we say that the relationship has a cascade modify effect. In the diagrams, a triangle at the from-side of a directional relationship represents a dependency with a cascade delete effect.

Underlined Attributes indicate uniqueness. If an entity is not dependent upon any other entity, then the underlined attributes uniquely determine an instance of that entity. If an entity is dependent upon some other entity, then for each instance of the other entity, the underlined attributes determine a unique instance of the given entity.

This restricted use of the Entity-Attribute-Relationship model ensures that its usage is simple enough to be consistently transferable to representations in a number of other data modeling paradigms, including relational, object-oriented, UML, or MOF. The diagrams on the next few pages give a high-level view of the EAR model of the OASIS Registry. Later sections add more detail to attribute types and specify the Semantic Rules that must be satisfied.

6.2.1. Registry Model - Public View

A diagram showing the public view of the Registry Model

6.2.2 Registry Model - Contact View

A diagram showing the enumeration view of the Registry Model

6.2.3 Registry Model - Classification View

A diagram showing the classification view of the Registry Model

6.2.4. Registry Model - Administration View

A diagram showing the administrative view of the Registry Model

6.2.5. Registry Model - Enumeration Entity View

A diagram showing the enumeration entity view of the Registry Model

6.3. Classifications

A discussion of classification schemes is found in classifications.html.

The diagram in Section 6.2.3, "Classification View", presents the information model for representing classification schemes and classifications. The CLASSIFICATION entity holds the classifications for any registered item. Each classification will identify a classification scheme by a SchemeURN, even though that URN may be from some other registry. Since each classification scheme referenced by a classification is registered in the local registry, the URN should identify an instance of the ALTERNATE_NAME entity, which points to a unique instance of REGISTRY_ITEM, which in turn identifies a unique instance of CLASSIFICATION_SCHEME. The description of the scheme and all of its metadata can then be retrieved from the registry.

The CLASSIFICATION_LEVEL entity identifies each level of the classification scheme. If it is a simple 1-level scheme, then there is only one level and its LevelName is unimportant. By default, the level name and level code of the single level of a simple classification scheme is "leaf", since each value will represent a leaf node in the 1-level hierarchy. Similarly, if no level names are defined for a multi-level coded classification scheme, then default level names will be Level1, Level2, etc., and the default level codes will be the same as the level numbers, i.e. 1,2,3, etc. If a single ItemValue is sufficient to identify the whole path leading from the root node to the identified node, then the keyword "leaf" can be used as an alias for whatever the assigned level code of that item might be. For example, in the newspaper article example above, the 3rd level leaf value "15052003" could be transmitted as the triple ("NewsArticle", "leaf", "15052003") and the three associated level names could be derived from the scheme definition.

The CLASSIFICATION_ITEM entity identifies each node in the classification hierarchy. Since the item names need not be unique, the local registry will define a local ItemId for each node, so that the child-to-parent relationships of the nodes can be easily represented. Then given a "leaf" node value, and no other information, the registry can follow the child-to-parent hierarchy from the given node to the root of the hierarchy to retrieve the entire name sequence for that node. A constraint on classifications is that each referenced classification scheme must identify a registered item in the same Registry as the classification instance. Then the locator of the identified registry item for the classification scheme can be used to locate a specific, OASIS conformant classification hierarchy in this or in some other Repository. The classification hierarchy must be defined by and transmitted by an XML document that validates to the XML ClassificationScheme DTD defined elsewhere in this specification.

6.4. Attribute Types

Attribute values in the information model will be one of the following types:

Some attribute values will be references to entity instances and some will be primitive types representable as character strings, numbers, dates, or dates and times. Entity references are one of the following types:
REGISTRY_ITEM
ORGANIZATION
CONTACT
SUBMISSION
Enumeration Entities defined in Section 6.5.
The following are the
base types that will be used in this specification:
CodeText
ShortName
LongName
EmailText
TelephoneText
AddrLineText
CommentText
DefinitionText
Date
Date Literal
Datetime
Datetime Literal
SmallInt
URNref
URLref
FTPref
FILEref
MIMEtype
LanguageId
CharEncoding

6.5. Enumeration Entities

Many of the attributes declared to be of type CodeText will have an additional constraint that the CodeText value match a specific value from a pre-defined list of values. The Registry information model represents such lists as entities with a fixed number of entity instances. We define such entities to be enumeration entities. The following enumeration entities have defined content.

AssociationType
ContactAvailability
ContactRole
DefinitionSource
RegistryImpact
NameContext
OrganizationRole
PaymentStatus
PrimaryClassification
RegistrationStatus
RegistryRequest
RelatedDataType
SubClassification
Stability

6.6. Entity Semantics

For each entity below there is a defined structure and semantic rules. All entity structures and semantics can be found at http://www.nist.gov/itl/div897/ctg/regrep/specification/entitysemantics.htm.

RegistryItem Entity
Association Entity
RelatedData Entity
Classification Entity
Organization Entity
Contact Entity
AlternateName Entity
AlternateDescription Entity
Submission Entity
Request Entity
Impact Entity
ClassificationScheme Entity
ClassificationLevel Entity
ClassificationItem Entity
Repository Entity

7. XML Definitions and Protocols

The OASIS Information Model specifies the logical structures of an OASIS Registry/Repository in terms of an Entity-Attribute-Relationship data model. The XML definitions specified herein, and the semantic rules associated with them, are defined in terms of the entities and attributes of that data model.

These ELEMENTs and DTDs are intended to be the basis of communication between a Submitting Organization and an OASIS conformant registry/repository, or between two conforming registry/repositories. The slightly different versions of each element provide an appropriate structure for each purpose. There are at most three versions of each important entity, one for use in a submission of that entity from a submitting organization to a registry, one for representation of that entity in a nested XML document for registry-to-registry exchange, and one for representation of a set of entities in a flat file. The flat file representations generally require identifiers for each entity and pointers among entities to represent their relationships, whereas the submission and nested forms represent the relationships in the structured nesting of elements.

7.1. Entity Elements

The XML Elements defined in this section correspond to the Entities of the Entity-Attribute-Relationship model defined by Section 6.6, "Entity Semantics", of the OASIS Information Model. The attributes of those Entities are represented either as XML elements or as XML attributes, whichever seems most appropriate.

NOTE: The authors of this section do not feel confident about when it is best to represent something as an XML element and when it is better to represent it as an XML attribute. It will be straight-forward to do the right thing after some good discussions.

RegistryItem Elements
Association Elements
RelatedData Elements
Classification Elements
Organizaton Elements
Contact Elements
AlternateName Elements
AlternateDescription Elements
SubmissionInstance Element
Request Elements
Impact Element
ClassifSchemeInstance Element
ClassificationLevel Elements
ClassificationItem Elements
RegistryMetadata Elements
Repository Element

7.2. XML Data Type Definitions

Submission DTD
Query DTD
ClassificationScheme DTD
RegistryContentFlat DTD
RegistryContentNested DTD

7.3. Request Elements

AddAlternateDescription
AddAlternateName
AddAssociation
AddClassification
AddRelatedData
CertifySubmittingOrg
DefineClassificationScheme
DefinePackage
DeleteAlternateDescription
DeleteAlternateName
DeleteAssociation
DeleteClassification
DeleteRelatedData
ModifyClassificationScheme
ModifyPackage
ModifyRegistryItem
RegisterObject
ReplaceRegisteredObject
SupersedeRegisteredObject
WithdrawRegisteredObject

7.4. XML Entity Definitions

assocTypeList
contactAvailList
contactRoleList
defnSourceList
impactCodeList
nameContextList
orgRoleList
payStatusList
primaryClassList
regStatusList
relatedTypeList
requestCodeList
subClassList
stabilityList

7.5. Request by Unique Identifier

An interoperable network of registries requires at least one agreed-upon protocol for obtaining resources and their metadata. Fortunately, such a protocol was specified in the course of URN development work in the IETF.

Resolution of requests by URL and URN are discussed in RFC 2483, URI Resolution Services Necessary for URN Resolution. This an experimental specification appears to be well suited to the purposes of the OASIS Registry and Repository Technical Committee. Its typology of requests, results, errors, and security considerations is well considered.

As the OASIS Registry and Repository Technical Committee is willing to limit the protocols supported to HTTP, the syntax proposed in RFC 2169, “A Trivial Convention for using HTTP in URN Resolution” (THTTP) is specified here, with revisions to bring it in line with the later RFC 2483, to wit, replacement of the L2* and N2* requests with a generic I2* request. Thus emended, section 2.0 of RFC 2169 reads:

The general approach used to encode resolution service requests in THTTP is quite simple:

       GET /uri-res/<service>?<uri>  HTTP/1.0

For example, if we have the URN "urn:foo:12345-54321" and want a URL, we would send the request:

       GET /uri-res/I2L?urn:foo:12345-54321 HTTP/1.0

The request could also be encoded as an HTTP 1.1 request. This would look like:

       GET /uri-res/I2L?urn:foo:12345-54321 HTTP/1.1
       Host: <whatever host we are sending the request to>

Responses from the HTTP server follow standard HTTP practice. Status codes, such as 200 (OK) or 404 (Not Found) shall be returned. The normal rules for determining cachability, negotiating formats, etc. apply.

To use this syntax in general, one would follow the pattern (cast as a URL rather than a full HTTP request):

 http://someregistry.org/<function>?argument

To obtain an entity such as the Docbook DTD (the URN is imaginary):

 http://someregistry.org/I2R?urn:x-oasis:dtds:Docbook-v3.1

To obtain the composite metadata document for the Docbook DTD (the URN is again imaginary):

 http://someregistry.org/I2C?urn:x-oasis:dtds:Docbook-v3.1

RFC 2483 defines an “I2C” request (section 4.5), for resolution of a URL or URN to a description of a resource (URC). As this is a generic request, the OASIS Registry and Repository Technical Committee chooses not to require registries conformant with this specification to return an entity's registration document in response to this request; registries are free to supply whatever their preferred metadata is, which may extend that specified here. (An RA may set its own policy with respect to what metadata it will accept beyond that specified here.) Instead, an additional request, I2X, is specified as returning the entity's registration document as defined here. Some information, such as personal contact information, may be withheld by the RA, perhaps on the basis of the identity of the requestor, if such is its policy.

The “I2CS” request, section 4.6, allows a request for multiple documents; in the absence of agreement on XML packaging, it is not clear that it would be useful to implement it at the present time.

8. Conformance

Conformance requirements go here. As ISO/IEC 11179 is specified in ordinary language, conformance to it in its present form can be tested only by reading that standard in parallel with this specification.

9. Normative Policy Requirements

This specification declares the need for certain policies, but does not specify their contents.

9.1. Intellectual Property Notices

The registry and repository shall have published policies relating to their provision of intellectual property notices for entities in the repository; that is, whether the interface to the registry or repository warns of the existence of copyright notices, asserted licenses, or other intellectual property restrictions or encumbrances, or leaves it to the user to discover them.

9.2. Integrity

The registry and repository shall have published policies relating to their use of methods to guarantee the integrity of entities in repository and metadata in the registry; for example, does the repository employ digital signatures to ensure against corruption? if transformations of registered entities are served are they signed as well?

9.3. Security

The registry and repository shall have security policies sufficient to engender confidence in the registry and repository.

9.4. Disaster Recovery

The complete content of both the registry and repository shall be backed up offsite, and the backup tested. Some plan shall be made for reconstituting the registry and repository from the backup should the original site be rendered inoperable.

9.5. Persistence

The registry and repository shall have published policies relating to its plans for continuing in operation and the outcomes to be expected should it cease operation or should business relationships with the owners of its content change. A point of departure for describing archival longevity is the “Reference Model for an Open Archival Information System” (OAIS) which is a draft ISO standard.

It shall be possible for an SO to request that an entity be kept available for a given length of time, also that it be withdrawn after a given length of time. TO DO: devise the semantics for this, perhaps in a DTD fragment.

9.6. Retraction

It shall be possible for an SO to request the retraction of an entity.

9.7. Privacy

The registry and repository shall have published policies relating to the privacy of users and the sale or other distribution of usage information.

9.8. Quality Control

ISO/IEC 11179 defines a data element status value, “certified” (Part 6, p. 9) for a “recorded data element [that] has met the quality requirements specified in this and other parts of ISO/IEC 11179.”

If the registry provides this or other quality control checking, it shall provide metadata about what specifications an entity conforms to and who did the testing to determine that conformance. (XML validity vs. well-formedness falls under this heading.)

9.9. Limitation of Legal Liability

A registry shall have a statement of limitation of legal liability (disclaiming responsibility for the use of information in the repository, for example).

9.10. Notice of Quality of Service

A registry shall have a statement of the quality of service it can be expected to provide.

10. Appendix: Terminology and Relevant Specifications

Glossed here are relevant terms, including acronyms, with entries for some specifications relevant to the registry and the repository.

FPI

Formal Public Identifier, defined in the SGML Standard, ISO/IEC 8879, section 10.2, and further in ISO/IEC 9070.

ISO/IEC 8879

The SGML Standard, “Information processing—Text and office systems—Standard Generalized Markup Language (SGML)”.

ISO/IEC 9070

Further specifies PIs and FPIs, first defined in the SGML Standard, “Information technology—SGML support facilities—Registration procedures for public text owner identifiers”.

ISO/IEC 11179

ISO/IEC 11179 is online at http://www.sdct.itl.nist.gov/~ftp/l8/11179/ . The home page of the relevant committee is http://sdct-sunsrv1.ncsl.nist.gov/~ftp/l8/sc32wg2/projects/11179content/content-home.htm with a link to an HTML representation of the stanadard. It is proposed to replace Part 3 of 11179 with ANSI X3.285, “Metamodel for the Management of Shareable Data”, which you can find in HTML at http://www.lbl.gov/~olken/X3L8/drafts/Metamodel/MetaModel_ToC.html and in Word and PDF format (filenames beginning dpX3-285) at ftp://sdct-sunsrv1.ncsl.nist.gov/x3l8/x3l8docs/x3.285/docs/ .

OAIS

“Reference Model for an Open Archival Information System”, a draft ISO standard.

PI

Public Identifier, defined in the SGML Standard, ISO/IEC 8879, section 10.1.6, and further in ISO/IEC 9070.

RA

Registration Authority (ISO/IEC 11179).

Repository

a location or set of distributed locations where documents pointed at by a registry reside, and from which they can be retrieved by conventional (http, ftp) means, perhaps with an additional authentication/permissions layer.

RO

Responsible Organization (ISO/IEC 11179).

SO

Submitting Organization (ISO/IEC 11179).

UML

Unified Modelling Language, an Object Management Group specification for visual modelling of object-oriented systems, see UML Resource Page.

URC

Uniform Resource Characteristics, a general term for any metadata about a resource identified by a URL or URN.

URL

Uniform Resource Locator.

URN

Uniform Resource Name. This is a list of IETF (and other) documents relating to URNs, originally drawn up by Murray Altheim of Sun Microsystems and updated by Terry Allen. The documents he thinks most important are marked with an asterisk.

Charter of the current IETF WG

Some history

Requests For Comments

*Uniform Resource Identifiers (URI): Generic Syntax (RFC 2396)

*URN syntax

*Resolution of Uniform Resource Identifiers using the Domain Name System (RFC 2168)

A Trivial Convention for using HTTP in URN Resolution (RFC 2169)

Architectural Principles of Uniform Resource Name Resolution (RFC 2276) (expresses the author's point of view, which is not consensus)

Using Existing Bibliographic Identifiers as Uniform Resource Names (RFC 2288)

Internationalized Uniform Resource Identifiers (IURI)

*URI Resolution Services Necessary for URN Resolution (RFC 2483)

*A URN Namespace for IETF Documents (RFC 2648)

Internet Drafts

*Resolution of Uniform Resource Identifiers using the Domain Name System

*The Naming Authority Pointer (NAPTR) DNS Resource Record

URN Namespace Definition Mechanisms

Requirements for Human Friendly Identifiers

An Architecture for Supporting Human Friendly Identifiers

XMI

XML Metadata Interchange, an Object Management Group specification of XML formats for interchange of UML models, see UML Resource Page.

XML

Extensible Markup Language, an application profile (that is, an application) of SGML, specified by the W3C, Extensible Markup Language (XML) 1.0.

XML-related entity

In this document, “XML-related entity” means any XML or SGML entity necessary for the processing of an XML document, or documentation of such an entity.