The content repository must be able to store objects in any
+
+Karl Goldstein (karlg\@arsdigita.com
+)
+Revision History
+
The content repository must be able to store objects in any format, both text and binary. MIME types provide a standard set of codes for identifying the file format of each content item. For the purpose of data integrity, the repository must have a canonical -list of MIME types that may be assigned to content items.
A content type is characterized by a set of attributes +list of MIME types that may be assigned to content items.
+ +A content type is characterized by a set of attributes that may be associated with a text or binary content object. Attributes are stored separately from their associated content object, and as such may be indexed, searched, sorted and retrieved independently. For example, attributes of a press release may -include a title, byline, and publication date.
The data model must support storage of descriptive information -for each content type:
+include a title, byline, and publication date. ++ +The data model must support storage of descriptive information +for each content type:
+10.10 Content types must be associated with unique keyword identifiers, such as press_release, so they can be @@ -45,13 +53,17 @@ see_also. Each type of relationship may include a minimum and/or maximum number of relationships of this type that are required for an item to be published.
-Items are the fundamental building blocks of the content +
Items are the fundamental building blocks of the content repository. Each item represents a distinct text or binary content object that is publishable to the web, such as an article, report, message or photograph. An item my also include any number of attributes with more structured data, such as title, source, byline -and publication date.
Content items have the following persistent characteristics -which the data model must support:
+and publication date. ++ +Content items have the following persistent characteristics +which the data model must support:
+20.10 Content items must have a simple unique identifier so they can be related to other objects in the system.
@@ -91,10 +103,13 @@ 20.95 Each item may be associated with any number of related objects. The type and number of relationships must be constrained by the content type of the item (See 10.70 above).
-As mentioned above, each content item may be associated with any +
As mentioned above, each content item may be associated with any number of revisions. The data model for revisions must support the -following:
+following: +30.10. A revision consists of the complete state of the item as it existed at a certain point in time. This includes the @@ -103,8 +118,10 @@ 30.20. The data model must be extensible so that revisions for all content types (with any number of attributes) may be stored and retrieved efficiently.
-40.0 Organization of -the Repository
++40.0 Organization of +the Repository
+-40.10. The data model must support the hierarchical organization of content items in a manner similar to a file @@ -148,19 +165,26 @@ label, which may be different from the title or label of the target item.
The content repository should provide a means of storing and + +
+The content repository should provide a means of storing and managing the templates that are merged with content items to render output in HTML or other formats. Templates are assumed to be text files containing static markup with embedded tags or code to incorporate dynamic content in appropriate places. The data model requirements for templates are a subset of those for content -items.
Because they typically need to reference a specific attributes, +items.
+Because they typically need to reference a specific attributes, a template is typically specific to a particular content types and -its subtypes.
100.10 MIME Types
Since a MIME type is a required attribute of each content item, +its subtypes.
+100.10 MIME Types
+Since a MIME type is a required attribute of each content item, the repository must be capable of managing a list of recognized MIME types for ensuring appropriate delivery and storage of -content.
+content. ++100.10.10. Register a MIME type
100.10.20. Set the description of a MIME type
@@ -169,22 +193,29 @@ binary
100.10.50. Get a list of registered MIME types
100.10.60. Unregister a MIME type
-It is important to note that the role of MIME types in the +
It is important to note that the role of MIME types in the content repository is simply to describe the general file format of each content item. Neither the data model nor the API support the full range of allowed parameters for the general MIME types such as -text/plain.
100.20 Locales
The repository must have access to a list of recognized locales +text/plain.
+100.20 Locales
+The repository must have access to a list of recognized locales for the purpose of publishing content items in multiple languages -and character sets.
All content in the repository is stored in UTF-8 to facilitate +and character sets.
+All content in the repository is stored in UTF-8 to facilitate searching and uniform handling of content. Locales may be specified as user preferences to configure the user interface in the -following ways:
Functional requirements for locales include:
+
Functional requirements for locales include:
+100.20.10. Register a locale, including language, territory and character set.
@@ -197,7 +228,9 @@ locale (character set).
100.20.50. Get a list of registered locales.
100.20.60. Unregister a locale.
-
100.30 Content Types
++
100.30 Content Types
+100.30.10. Create a content type, optionally specifying that it inherits the attributes of another content type. Multiple @@ -226,7 +259,9 @@ object, specifying a token or name for the relationship type as well as a minimum and/or maximum number of relationships of this type that are required for the item to be published.
-
100.40 Content Items
++
100.40 Content Items
+100.40.10. Create a new item, specifying a parent context or the root of the repository by default.
@@ -261,9 +296,12 @@ modifying user, date modified and comments.
100.40.95. Revert to an older revision (create a new revision based on an older revision).
-
100.50 Content Folders
The repository should allow for hierarchical arrangement of + +
100.50 Content Folders
+The repository should allow for hierarchical arrangement of content items in a manner similar to a file system. The API to meet -this general requirement focuses primarily on content folders:
+this general requirement focuses primarily on content folders: ++100.50.10. Create a folder for logical groups of content items and other folders. The folder name becomes part of @@ -286,13 +324,19 @@ versioning, since they are solely containers and do not have any content other than the items they contain.
100.50.90. Delete a folder if it is empty.
-Note that folders are simply a special type of content item, and +
Note that folders are simply a special type of content item, and as such may receive the same object services as items, (namely access control and workflow). In addition to the file-system analogy afforded by folders, any type of content item may serve as -a contain for other content items (see below).
The repository must offer integration with a workflow package -for managing the content production process.
100.60 Categorization
The repository must support a common hierarchical taxonomy of -subject classifications that may be applied to content items.
+a contain for other content items (see below). ++Workflow
+The repository must offer integration with a workflow package +for managing the content production process.
+100.60 Categorization
+The repository must support a common hierarchical taxonomy of +subject classifications that may be applied to content items.
+100.60.10. Create a new subject category.
100.60.20. Create a new subject category as the child of @@ -302,11 +346,19 @@ 100.60.40. Remove a subject category from an item.
100.60.50. Get the subject categories assigned to a content item.
-Search
The repository must have a standard means of indexing and -searching all content.
Access Control
The repository must have a means of restricting access on an -item-by-item basis.
VI.C Requirements: Presentation Layer API
The presentation layer must have access to a subset of the +
The repository must have a standard means of indexing and +searching all content.
+The repository must have a means of restricting access on an +item-by-item basis.
+The presentation layer must have access to a subset of the stored procedure API in order to search and retrieve content -directly from the repository if desired.
| Author | Date | Description |
|---|---|---|
| Karl Goldstein | 21 September 2000 | Add requirements for relationships among content items and other objects. |