Container Catalog
[cntct0200-eadoc]
Revision: 2
In case of joint engineering efforts it is necessary to synchronise the engineering data bases. This document specifies a container and in particular the metadata used for such an exchange.
Note that this document is not perfect [image] . It is the result of a meeting where the participiants tried to harmonize various catalog approaches.
This document must be accompanied by use case specific documentation.
Especially the following information is still missing:
  • Examples
  • something more which is left as an execise to the reader.
be glad that there are page numbers


I. Document management

Container Catalog
I. Document management

team members
Name | Company
Bernhard Weichel | MSR MEDOC
Oliver Rumpf | MSR MEDOC
Roman Reimer, XI-Works | MSR MEDOC
version overview
Date | Publisher
2002-02-07 | Roman Reimer, XI-Works
12.7.2000 | Bernhard Weichel
modifications
Change | Related to
Erstellen von Indexen, Technischen Begriffen und Querverweisen. Konvertieren nach MSRREP V210 XML. Reason: Aufbereitung für Abschlußdokumentation | Content
Working draft cicrulated within MSR-MEDOC Reason: as scheduled by MEDOC steering comitee | Content
modifications included
Date | Chapter | Change | Related to
2002-02-07 | Gesamt | Erstellen von Indexen, Technischen Begriffen und Querverweisen. Konvertieren nach MSRREP V210 XML. Reason: Aufbereitung für Abschlußdokumentation | Content
12.7.2000 | Gesamt | Working draft cicrulated within MSR-MEDOC Reason: as scheduled by MEDOC steering comitee | Content


1. Introduction

Container Catalog
1. Introduction

This document describes the container catalog which is part of a generic approach for exchange of engineering data and its configuration. The container comprises of
  • Engineering objects such as source codes, documentation, compiled objects etc.
  • Metainformation about the exchanged object such as creator, name, version info and configuration.
The catalog as described in the following sections is inspired by the RDF (Ressource Data Framework) as published by the World Wide Web Consortioum. RDF describes thing by making statements about it. These statements, called "assertions" are the basic concepts of the catalog.
The statements are given in <ablock> which itself comprises of metadata and the "things" istself resp. a pointer to a file containing the "things".
Like RDF, the catalog is an application of XML as described by the world wide web consortium (www.w3c.org).
This document describes in general the container catalog dtd. The dtd provides a metadata scheme. It is expected, that the reader is informed about XML.
The particulare application of this scheme must be documented separately.


1.1. General approach to the Catalog

In general, the catalog is setup by the following items:
Figure 1: Overall structure of the catalog
<catalog>
This is the root of the catalog. As of SGML/XML a valid resp. a well formed document must have one and only one root element.
<ablock>
This is the assertion about one particular "work item" or exchange item. This item can either be a file, a set of fields, or a specific configuration which is comprised by <aref>.
The primary identification of an <ablock> is the combination of [class] and [name]. This reflects to the fact that a work item in an engineering process may have a particular role in the process (denoted by [class]) and a name.
For ease of processing in SGML/XML-tools catalog also supports the identification by [id].
<aref>
This is used to establish a relationship between configuration items and particular exchange items. As an example, a program kit is setup as a set of particular files. This fact is expressed within the <ablock> describing the program by referencing (via <aref>) the <ablock> describing the particular files.
Note that this reference can be expressed using SGML's ID/IDREF or by using [class] and [name] or both. If both mechanisms are use, they must be in sync.
<metadata>
This structure receives all metadata formally specified in the catalog. This is mainly a descriptive name delivered in multiple languages and revision information.
<fields>
This is a generic structure allowing to transmit any kind of fields. The application domain of a field set can be denoted in [class] within <field-set>. For an example see 2. Using the catalog for transmitting a revision history.
For further details refer to the element and attributes documentation in 2.2. Elements and attributes.


1.2. Incremental data exchange

The catalog can be used for full fledged as well as for incremental data exchange. In both cases, all metadata have to be transmitted. In case of incremental exchange the unchanged physical files can be omitted.
In order to keep all references valid within the catalog the appropriate <ablock>s must be provided. Therefore, the [upd] attribute allows to give information about the contents:
NEW | The object is newly introduced in the system. Therefore the contents file must be in the catalog (in particular, an <file> element must occur within <ablock>) [image] .
REUSED | The object is introduced in the system at former time. Like NEW it is not in the reference catalog. Therefore the contents file must be in the catalog (in particular, an <file> element must occur within <ablock>).
UNUSED | The object is no longer used. The <ablock> is there in order to indicate, that the object can be removed in the configuration on the receiver's site. The <ablock> does not reference anything within the actual catalog [image] . This is used to support the update procedure on the receiver's site [image] .
UNCHANGED | The object is unchanged. Therefore it must already be available on the receiver's site. Therefore it is possible to omit the file itself.
CHANGED | The object is changed. Therefore the contents file must be in the catalog (in particular, an <file> element must occur within <ablock>).
MOVED | The object is unchanged but in different Groups. Therefore it must already be available on the receiver's site. So it is possible to omit the file itself. The object is changed and in different Groups. In this case it will be changed.

The reference catalog must be identified by local means and is not defined in the actual catalog.
There ist no value "deleted" because versioned data is not deleted in order to track the full history.
This cannot be determined by comparing catalogs since the full exchange history is necessary which must be kept in the process data management system


1.3. Syntactical hints

The general format of the container catalog is SGML. The structure of the container catalog is therefore defined as an SGML DTD. The following specifics apply as they are adjusted in the SGML declaration:
  • the concrete reference syntax is used (refer to the widely available SGML material (e.g http://www.oasis-open.org).
  • It is possible to parse a catalog as well formed xml which is without using a DTD. In this case it is recommended to have the following xml declaration in the first line of the container:
    Note that well formed parsing does not check names, ids, reserved attribute values.
  • Names resp. nmtoken (as shown in the attribute tables below, eg. Attributes for CATALOG) are limited to 256 characters, must start with a letter, and may consist of letters, digits, and the characters "-", "_", ".".
  • As of March 2000 the DTD is provided in both, XML and SGML form. Instances following the SGML DTD are not case sensitive with respect to element names, attribute names and ids.
    Instances of the XML DTD are case senstitive. Since SGML tools usually deliver uppercase identifiers, the XML version of the DTD uses uppercase element identifiers also.
For further details see the SGML declaration given in 2.3. The recommended SGML declaration.


2. Using the catalog for transmitting a revision history

Container Catalog
2. Using the catalog for transmitting a revision history

In order to document change history of subjects, the following approach is recommended:
  • Insert one <ablock> for each particular revision of a file or a group.
  • Use different file names for each version. In particular, it is recommended to code the revision label into the file name such as myfile-01-07.txt.
  • Place the version information into <metadata> as pointed out in this document.
  • Add a <field-set class="revision-history"> to each <ablock> and populate it with a <field name="comment"> to submit the version comment.
<CATALOG NAME="ARMD" CATALOG-CLASS="History-overview"
                     VERSION="1.0"
                     MODIFICATION-DATE="Fri Mar 03 19:39:38 2000">
<ABLOCK NAME="ARMD"  LABEL="10.30">
  <FIELDS>
     <FIELD-SET CLASS="Revision-history">
        <FIELD NAME="comment">
           This is the coment for Revision 10.30
        </FIELD>
     </FIELD-SET>
  </FIELDS>
  <FILE>fkt-armd-10.30-0.pdf</FILE>
</ABLOCK>
<ABLOCK NAME="ARMD"  LABEL="10.40">
  <FIELDS>
     <FIELD-SET CLASS="Revision-history">
       <FIELD NAME="comment">
        this is the coment for Revision 10.40
       </FIELD>
     </FIELD-SET>
    </FIELDS>
  <FILE>fkt-armd-10.40-0.pdf</FILE>
</ABLOCK>
</CATALOG>


2.1. Proposal for general utility routines

In order to handle the catalog, it might be appropriate to implement a with some utility rotines.


2.1.1. Check - Parser and checker

This routine will run the SGML-parser and apply a generic check routine which checks the constraints mentioned above such as:
  • format of attributes such as (date)
  • references
  • values of attributes


2.1.2. CheckXML - Parse in XML and check

This routine runs the XML-parser and applay the generic check routine as mentioned in 2.1.1. Check - Parser and checker.


2.1.3. Indent

This routine generates an indented version of the catalog. This is merely for the case that the catalog was written by a tool which did not perform pretty printing.


2.1.4. Compare

This routine compares the catalog with a reference catalog files and generates an updated version attributes for incremental data exchange (see 1.2. Incremental data exchange) are populated. The basic principles are:
  • the result is a combination of both catalogs, esp. the <ablock>s of both catalogs appear in order to show the now unused objects.
  • the sequence of the objects is not taken into account when comparing the catalogs.
  • the <fields> are not taken into account when comparing the catalogs since there is no mean to handle the results.
  • The following strategy can be used to determine the [upd] attribute.
    NEW
    The object is newly introduced in the system. Therefore the contents file must be in the catalog (in particular, an <file> element must occur within <ablock>).
    Detect
    Check for all <ablock>s in the catalog: There is no <ablock> in reference catalog with the same [name] attribute.
    referenced objects
    NEW, MOVED, REUSED
    REUSED
    The object was introduced in the system at former time but like NEW it is not in the reference catalog. Therefore the contents file must be in the catalog (in particular, an <file> element must occur within <ablock>).
    Detect
    Check for all <ablock>s in the catalog: There is no <ablock> in reference catalog with the same [name] attribute.
    referenced objects
    REUSED, MOVED, CHANGED
    UNUSED
    The object is no longer used. The <ablock> is there in order to indicate, that the object can be removed in the configuration on the receiver's site. The <ablock> does not reference anything within the actual catalog.
    Detect
    Check for all <ablock>s in the reference catalog: There is no <ablock> in the catalog with the same [name] attribute. For the result, copy the <ablock> from the reference catalog, populate [upd] and drop all contents execpt <metadata>.
    referenced objects
    no referenced objects
    UNCHANGED
    The object is unchanged. Therefore it must already be available on the receiver's site. Therefore it is possible to omit the file itself.
    Detect
    Check for all <ablock>s in the catalog: The same <ablock> appears with the same version information in the reference catalog.
    referenced objects
    UNCHANGED
    CHANGED
    The object is changed. Therefore the contents file must be there (in particular, an <file> element) must occur within <ablock>.
    Detect
    Check for all <ablock>s in the catalog: The same <ablock> appears in the reference catalog but in another version.
    referenced objects
    CHANGED, UNCHANGED, REUSED, UNUSED, MOVED
    MOVED
    The object is unchanged but in different Groups. Therefore it must already be available on the receiver's site. Therefore it is possible to omit the file itself.
    The object is changed and in different Groups. In tis case it will be changed.
    Detect
    Check for all <ablock>s in the catalog: The same <ablock> appears with the same version information in the reference catalog but was referenced from different <ablock>.
    referenced objects
    MOVED
The following hints apply:
  • The simple approach described here requires, that the name of objects is globally unique and that no two revisions of such an object appear simulatneously in the catalog. If this is not the case, much more complicated algorithms are required.
  • If synchroneous versioning applies (using multiple <cri> elements), then obvously the revsion info of one particular company must be taken into account. The company is given as a runtime argument of the procedure.
    It could also be determined by a runtime argument, if the revision info of the <metadata> or the revision info in <ablock> is used.
  • <ablocks> without revision information shall be flagged as errors.

The reference catalog must be identified by local means and is not defined in the actual catalog.


2.1.5. Inspect

This invokes a graphical utility to inspect the catalog. Requirements are such as:
  • The window has two panes, one for a catalog tree, and one for information about the actual node.
  • The catalog is expanded, that is all <ablock>s are replaced by the referenced contents.
  • It is possible to display the attributes of an ablock, the metadata or to invoke a tool displaying the contents of the referenced <file>.
Perhaps the other routines mentioned above can be invoked from this tool also.


2.1.6. copy - copy all files referenced in the catalog

This routine copies all files in the catalog to a directory specified as argument. It is invoked using the command:
mfl -a ctl -j copy {inputfile} -- --dir {output-directory}
The routine provides the following features:
  • The output-directory is checked to be a directory
  • The output-directory does not exist, it will be created
  • The files in the catalog are checked to exist and to be plain files (no directories)
  • If there are duplicates, a running number is added to the extension
  • The messages are logged into the file copy-mmx.log in the current directory of the catalog
  • If the catalog does not contain a doctype declaration, a information message is submitted.

If the directory is readonly, then a system message may occur, since this is not checked.


2.1.7. Import catalog into Data Management System

tbd


2.2. Elements and attributes

Contents of this chapter:
  • 2.2.1. ABLOCK ... AREF
  • 2.2.2. CATALOG ... CRI
  • 2.2.3. FIELD ... FILE
  • 2.2.4. L-4 ... LONG-NAME
  • 2.2.5. METADATA ... METADATA
  • 2.2.6. OWNER ... OWNER
  • 2.2.7. REVISION ... REVISIONS
  • 2.2.8. USABLE-FOR-VARIANT ... USABLE-FOR-VARIANTS
  • 2.2.9. V ... V


2.2.1. ABLOCK ... AREF

Contents of this chapter:
  • 2.2.1.1. ABLOCK
  • 2.2.1.2. AREF
  • 2.2.1.3. AREF-MOVED


2.2.1.1. ABLOCK

Figure 2: DTD-diagram for ABLOCK
Child elements | <metadata> <fields> <aref> <file>
parent elements | <catalog>
Attributes for ABLOCK
Name | Type | Class | Value | Remark
[CLASS] | name | implied |  | This denotes the class of the object. This class must be agreed upon for various applications.
[DATE] | cdata | implied |  | This reflects the date the object was last modified. This is for reference purpuses only. It is useful, if the catalog is the only database used for metadata. Usually this attribute is omitted. The value must follow the patterns given in 2.2.7.1. REVISION
[ID] | id | implied |  | This is a unique identifer of the object in the catalog. This must be used to refer to a particular version, if more than one version of the object is mentioned in the catalog.
[LABEL] | cdata | implied |  | This is the revision label string. It should be used, if the two step revisioning scheme provided by [rev] and [var] is not applied. The syntax of this attribute must be aggreed upon the involved parties.
[NAME] | cdata | required |  | This denotes the name of the object. As a rule, [name] and [class] must be unique within the catalog file [image] . This is the name of the object in the process e.g. the base name of a C-Module.
[REV] | cdata | implied |  | This specifies the revision of the object if the two layer revisioning scheme mentioned above is used.
[STATE] | cdata | implied |  | This denotes the status of the object such as "released", "tested". The content must be agreed upon the involved parties. It is primarily intedend to be used if the catalog is the primaray database.
[UPD] | nmtkgrp | implied | NEW UNUSED UNCHANGED CHANGED REUSED MOVED | The specifies the update status if incremental data exchange is performed using the catalog.
[VAR] | cdata | implied |  | This specifies the variant of the object if the two layer revisioning scheme mentioned above is used.
This represents assertions about a particular object. It comprises of metadata, fields. and the physical representation of the object itself.
The content of the object can be:
  • a set of references (<aref>) to other objects thus establishing a configuration tree.
  • a set of physical files referenced by <file> representing the object. This set may comprise of different file types with the same contents or the fact that the object is distributed across multiple files. Another method to achieve this, would be to pack these files using compressed archives such as ZIP.
  • a set of database fields (<field-set>) containing the data for the object. Note that the database fields can be there in additon to the contents mentioned above.
Note that for compatibility reasons there is no wrapper around the elements representing the contents of the ablock.
The version infomation for an <ablock> can be given on two different ways:
  • implicitly by using attributes such as [rev], [var] etc. This is bound for use cases where all participiants are using the same versioning scheme.
  • explicitly by using <metadata> which among others allows to use separate versioning schemes for each participiant.
Although possible, it is not intended to use both methods at the same time.

if this is not possible, the objects must be referred to using the ID attribute.


2.2.1.2. AREF

Figure 3: DTD-diagram for AREF
Child elements | none
parent elements | <ablock> <catalog>
Attributes for AREF
Name | Type | Class | Value | Remark
[CLASS] | name | implied |  | This is the class of the referenced <ablock>.
[IDREF] | idref | implied |  | This identifies the related <ablock> by its [id].
[SEQUENCE] | cdata | implied |  | This can take a sequence number which is used to express configurations where the sequence of elements is relevant (e.g. for documentation-fragments)
[VIEW] | nmtokens | implied |  | This allows to conditionalize the usage of the referenced ablock. As an example this could be used to distinguish different figures with respect to the intended audience (as it is done by ASCET).
This refers to another object (<ablock>). The reference can be done on two differents mechanisms:
  • [idref] pointing to an <ablock> identified by <id>.
  • [class] in conjunction with the content of ablock pointing to an <ablock> identified by [class] and [name].
It is not intended to use both mechanisms simultaneously. If however both methods are used at the same time, they must both point to the same object. A reader must flag contradictions as an error, and may continue using ID/IDREF.
The ID based mechanism is there to support exchange of multiple versions of the same object.


2.2.1.3. AREF-MOVED

Figure 4: DTD-diagram for AREF-MOVED
Child elements | none
parent elements | <ablock>
Attributes for AREF-MOVED
Name | Type | Class | Value | Remark
[CLASS] | name | implied |  | This is the class of the referenced <ablock>.
[IDREF] | idref | implied |  | This identifies the related <ablock> by its [id].
[VIEW] | nmtokens | implied |  | This allows to conditionalize the usage of the referenced ablock. As an example this could be used to distinguish different figures with respect to the intended audience (as it is done by ASCET).
This refers to another object which has been part of the actual ablock in a previous version (<ablock>). This specific reference is there to provide means to indicate changes within a configuration in greater detail. Otherwise a group can be marked with [upd] as changed but all components of this group are unchanged because one component is moved to somewhere else.
The reference can be done on two differents mechanisms:
  • [idref] pointing to an <ablock> identified by <id>.
  • [class] in conjunction with the content of ablock pointing to an <ablock> identified by [class] and [name].
It is not intended to use both mechanisms simultaneously. If however both methods are used at the same time, they must both point to the same object. A reader must flag contradictions as an error, and may continue using ID/IDREF.
The ID based mechanism is there to support exchange of multiple versions of the same object.


2.2.2. CATALOG ... CRI

Contents of this chapter:
  • 2.2.2.1. CATALOG
  • 2.2.2.2. CRI


2.2.2.1. CATALOG

Figure 5: DTD-diagram for CATALOG
Child elements | <metadata> <aref> <ablock>
parent elements | none
Attributes for CATALOG
Name | Type | Class | Value | Remark
[CATALOG-CLASS] | name | implied |  | This specifies the particular use case for the catalog.
[CREATOR] | cdata | implied |  | This denotes the tool (incl. version) which created the actual catalog.
[MODIFICATION-DATE] | cdata | implied |  | This denotes the date, the catalog was last modified. If the catalog is generated from scratch it is the creation date. If the catalog is the primary database, the date of the last modification is given. The value must follow the patterns given in 2.2.7.1. REVISION
[NAME] | cdata | required |  | This is the name of the catalog. It can be used for reference purposes.
[PUBID] | cdata | fixed | -//MSR//DTD container catalog 2.0 CNTCTL0200.DTD//EN | This gives the public identifier of the catalog. A creator must place it according to the DTD.
[STATE] | cdata | implied |  | This denotes the state of the contents of the catalog if the catalog is the only database.
[VERSION] | name | implied |  | This denotes the version of the catalog structure. If omitted, it is 2.0
This is the root of the catalog. It comprises of metadata and assertion blocks. The metadata are related to the catalog itself.
If an entire system is transferrred, the root of the configuration can be denoted in the <aref> of <catalog>.
The use case of the catalog is denoted in [catalog-class] as:
program-kit | used to exchange entire program kits.
tool-kit | used to exchange tool kits
History-overview | used to exchange an history overview of one particular work item.
The [pubid] attribute must have the value:
-//MSR//DTD container catalog 2.0 CNTCTL0200.DTD//EN


2.2.2.2. CRI

Figure 6: DTD-diagram for CRI
Child elements | none
parent elements | <revision>
Attributes for CRI
Name | Type | Class | Value | Remark
[COMPANY] | nmtoken | implied |  | This denotes the company for which the revision information is valid.
[LABEL] | cdata | implied |  | This is the label of the revision. Details see 2.2.1.1. ABLOCK
[LABEL-P1] | cdata | implied |  | This is the label of the previous revision on the main line. Details see 2.2.1.1. ABLOCK
[LABEL-P2] | cdata | implied |  | This is the label of the previous revision (secondary line) if the actual revision is the result of a merge process. Details see 2.2.1.1. ABLOCK
[PRIVATE] | cdata | implied |  | This allows to keep private information from the particular company. It is necessary, that a receiver stores this information and returns it to the sender in order to allow a resynchronization. As an example, this could be some object identifier in the sender's data management system system.
[REV] | cdata | implied |  | This is the revision number. Details see 2.2.1.1. ABLOCK
[REV-P1] | cdata | implied |  | This is the revision number of the previous version on the main line. Details see 2.2.1.1. ABLOCK
[REV-P2] | cdata | implied |  | This is the revision number of the previous version (secondary line) if the actual revision is the result of a merge process. Details see 2.2.1.1. ABLOCK
[STATE] | cdata | implied |  | This is the state of the revision. Details see 2.2.1.1. ABLOCK
[VAR] | cdata | implied |  | This is the variant designator. Details see 2.2.1.1. ABLOCK
[VAR-P1] | cdata | implied |  | This is the variant name of the previous version on the main line. Details see 2.2.1.1. ABLOCK
[VAR-P2] | cdata | implied |  | This is the variant name of the previous version (secondary line) if the actual revision is the result of a merge process. Details see 2.2.1.1. ABLOCK
<cri> is used to specify company specific revision information. This is used for synchronization, if the participiants of an exchange are using different versioning schemes.


2.2.3. FIELD ... FILE

Contents of this chapter:
  • 2.2.3.1. FIELD
  • 2.2.3.2. FIELD-SET
  • 2.2.3.3. FIELDS
  • 2.2.3.4. FILE


2.2.3.1. FIELD

Figure 7: DTD-diagram for FIELD
Child elements | none
parent elements | <field-set>
Attributes for FIELD
Name | Type | Class | Value | Remark
[NAME] | cdata | implied |  | This is the name of the field.
This is a particular field within a field set (see 2.2.3.2. FIELD-SET). Note that a particular field may also contain documentation information such as revision notes etc. For this purpose it is important to keep sure that the tools consider (and do not manipulate) white space [image] .

the behaviour should be the same as in a <pre> element in HTML.


2.2.3.2. FIELD-SET

Figure 8: DTD-diagram for FIELD-SET
Child elements | <field>
parent elements | <fields>
Attributes for FIELD-SET
Name | Type | Class | Value | Remark
[CLASS] | nmtoken | required |  | This denotes the particular use case for the field-set. As a rule it is the name of the application creating this set.
This is a set of application specific fields. This is intended to transmit arbitrary data which are kept in database records rather than in particular files. It is possible to submit multiple field sets to support multi tier applications where the catalog is read by more than one application.
The particular application is denoted in [class].


2.2.3.3. FIELDS

Figure 9: DTD-diagram for FIELDS
Child elements | <field-set>
parent elements | <ablock>
This allows to submit data which are not transferred as separate files. As of july 1999 it is intentionally not possible to define hierarchical data in order to keep it simple.


2.2.3.4. FILE

Figure 10: DTD-diagram for FILE
Child elements | none
parent elements | <ablock>
Attributes for FILE
Name | Type | Class | Value | Remark
[CREATION-DATE] | cdata | implied |  | This is the creation date of the file for reference purposes. It is not intended, that a container unpack routine must make sure that the files finally receive this time stamp. Usually this attribute is omitted [image] . The value must follow the patterns given in 2.2.7.1. REVISION
[CREATOR] | cdata | implied |  | This denotes the createor of the file. The values must be agreed upon the involved participiants.
[ROLE] | nmtkgrp | implied | PRIMARY SECONDARY | The specifies the role of the particular file. Primary means, that this is the file being maintained. Secondary means this file is derived from the primary file. If this attribute is not there, all files are treated as primary.
[TYPE] | name | implied |  | This denotes the type of the file. The values must be agreed upon the involved participiants.
This points to the contents of the object represented as a physical file. The file is identified by the contents of <file>. It can be interpreted as simple file relative to the position of the catalog itself. It can also be interpreted as a universal ressource identifier.
If more than one <file> is there, all mentioned files belong to the ablock.
The attribute [ROLE] separates the primary files from those being derived from the primary files.

If a Version Management System is used, checkout date is attachec to the files checked out. So Creation-date cannot be used as a time stamp.


2.2.4. L-4 ... LONG-NAME

Contents of this chapter:
  • 2.2.4.1. L-4
  • 2.2.4.2. LONG-NAME


2.2.4.1. L-4

Figure 11: DTD-diagram for L-4
Child elements | none
parent elements | <long-name>
Attributes for L-4
Name | Type | Class | Value | Remark
[L] | cdata | implied |  | This denotes the language of the contents.
This is a language specific text. The language is given in the attribute [l]:
de | german
en | englisch
fr | french
it | italian


2.2.4.2. LONG-NAME

Figure 12: DTD-diagram for LONG-NAME
Child elements | <l-4>
parent elements | <metadata>
This specifies the long name of the object.


2.2.5. METADATA ... METADATA

Contents of this chapter:
  • 2.2.5.1. METADATA


2.2.5.1. METADATA

Figure 13: DTD-diagram for METADATA
Child elements | <long-name> <owner> <revisions> <usable-for-variants>
parent elements | <ablock> <catalog>
Attributes for METADATA
Name | Type | Class | Value | Remark
[IDENT] | nmtoken | implied |  | This is used to reidentify the object within the system which created the catalog.
<metadata> is used to carry exhaustive metadata about the object such as synchronized version numbers, variant information etc. This is complementary to the implied versioning information within <ablock> provided by attributs such as [label].


2.2.6. OWNER ... OWNER

Contents of this chapter:
  • 2.2.6.1. OWNER


2.2.6.1. OWNER

Figure 14: DTD-diagram for OWNER
Child elements | none
parent elements | <metadata>
This specifies the legal owner of the object. This is used to prevent the information to be used in illegal contexts. As an example, if the function specification was provided by a particular company, it must not be used in the context of another company.


2.2.7. REVISION ... REVISIONS

Contents of this chapter:
  • 2.2.7.1. REVISION
  • 2.2.7.2. REVISIONS


2.2.7.1. REVISION

Figure 15: DTD-diagram for REVISION
Child elements | <cri>
parent elements | <revisions>
Attributes for REVISION
Name | Type | Class | Value | Remark
[DATE] | cdata | implied |  | This denotes the date, when the revision was issued. The value must follow the patterns given below.
This specifies revision information to the particular object. There may also be information about previous revisions in order to support resynchronization. In this case, the most actual revision information is the one for the actual object. The actual information can be identified using the attribute [DATE].
[DATE] must follow one of the patterns in oder to provide a sequenctial order by performing simply a lexical sort.
<YYYY>-<MM>-<DD>[T<hh>:<mm>:<ss>]

<YYYY>.<MM>.<DD>[T<hh>:<mm>:<ss>]

<YYYY>/<MM>/<DD>[T<hh>:<mm>:<ss>]
The last pattern is the most preferred one, since it reflects a common use in US.


2.2.7.2. REVISIONS

Figure 16: DTD-diagram for REVISIONS
Child elements | <revision>
parent elements | <metadata>
This is the explicit versioning (revisioning) information. It my comprise of the revision metadata of predecessors as well as of the actual object. The revision info of the actual object ist the one with the latest date denoted in [date] within <revision>.


2.2.8. USABLE-FOR-VARIANT ... USABLE-FOR-VARIANTS

Contents of this chapter:
  • 2.2.8.1. USABLE-FOR-VARIANT
  • 2.2.8.2. USABLE-FOR-VARIANTS


2.2.8.1. USABLE-FOR-VARIANT

Container Catalog
2. Using the catalog for transmitting a revision history
2.2. Elements and attributes
2.2.8. USABLE-FOR-VARIANT ... USABLE-FOR-VARIANTS
2.2.8.1. USABLE-FOR-VARIANT

Figure 17: DTD-diagram for USABLE-FOR-VARIANT
Child elements | <v>
parent elements | <usable-for-variants>
Attributes for USABLE-FOR-VARIANT
Name | Type | Class | Value | Remark
[NAME] | cdata | implied |  | This is the name of the variant characteristic in question.
This specifies the possible values of the variant-criterium denoted by [name] the object in question can be applied to.


2.2.8.2. USABLE-FOR-VARIANTS

Container Catalog
2. Using the catalog for transmitting a revision history
2.2. Elements and attributes
2.2.8. USABLE-FOR-VARIANT ... USABLE-FOR-VARIANTS
2.2.8.2. USABLE-FOR-VARIANTS

Figure 18: DTD-diagram for USABLE-FOR-VARIANTS
Child elements | <usable-for-variant>
parent elements | <metadata>
This denotes all the variants, the object in question can be used for.


2.2.9. V ... V

Contents of this chapter:
  • 2.2.9.1. V


2.2.9.1. V

Figure 19: DTD-diagram for V
Child elements | none
parent elements | <usable-for-variant>
This is the particular value of the variant characteristic.


2.3. The recommended SGML declaration

The catalog can be used with XML and with SGML. In the second case, the following declaration is recommended.
<!SGML "ISO 8879:1986"

-- ********************************************************************* --
-- FILE: msrsgml.dec

     NOTE: This file is the SGML Declaration for all MSR DTDs.

     SPONSOR: MSR (a group of german vehicle manufacturer and suppliers)

     CONTACT ADDRESS: If you want to order the MSR DTDs and their documentation
                      please don't hesitate to contact to

                      C+L Unternehmensberatung
                      M. Krause
                      New-Yorker-Ring 13
                      D-22297 Hamburg
                      Germany

                      phone: (+)49 (0)40 6378 2191
                      fax:   (+)49 (0)40 6378 1020
                      email:  martin_krause@de.coopers.com

     COPYRIGHT: Copyright 1994-98 MSR-Consortium, Germany
                All rights reserved.

     PERMISSION TO USE, COPY, MODIFY AND DISTRIBUTE THIS DTD AND
     ITS ACCOMPANYING DOCUMENTATION FOR ANY PURPOSE AND WITHOUT FEE IS
     HEREBY GRANTED IN PERPETUITY, PROVIDED THAT THE ABOVE COPYRIGHT
     NOTICE AND THIS PARAGRAPH APPEAR IN ALL COPIES.  THE COPYRIGHT
     HOLDERS MAKE NO REPRESENTATION ABOUT THE SUITABILITY OF THE DTD FOR
     ANY PURPOSE.  IT IS PROVIDED "AS IS" WITHOUT EXPRESSED OR IMPLIED
     WARRANTY.

     IF YOU MODIFY THE DTD IN ANY WAY, EXCEPT FOR ADDITIONAL NOTATIONS,
     LABEL YOUR DTD AS A VARIANT OF THIS DTD.

     AUTHOR:    Klein / TZKom GmbH

     VERSION:   1.1.0a / 19.02.98
                13.07.99 Weichel manipulated for container catalog

--

CHARSET
BASESET "ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0"
DESCSET                0    9   UNUSED
                       9    2   9
                      11    2   UNUSED
                      13    1   13
                      14   18   UNUSED
                      32   95   32
                     127    1   UNUSED
BASESET   "ISO Registration Number 100//CHARSET ECMA-94 Right Part of Latin Alphabet Nr. 1//ESC 2/13 4/1"
DESCSET              128   32   UNUSED
                     160   96   32
CAPACITY      SGMLREF
TOTALCAP      175000
GRPCAP        100000
ATTCAP        50000
SCOPE         DOCUMENT
SYNTAX        SHUNCHAR
CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
         18 19 20 21 22 23 24 25 26 27 28 29 30 31 127
BASESET  "ISO 646-1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0"
DESCSET       0   128      0
FUNCTION      RE           13
              RS           10
              SPACE        32
              TAB SEPCHAR  9
NAMING        LCNMSTRT     ""
              UCNMSTRT     ""
              LCNMCHAR     "-._"
              UCNMCHAR     "-._"
              NAMECASE     GENERAL        YES
              ENTITY       NO
DELIM         GENERAL      SGMLREF
                           SHORTREF       NONE
NAMES         SGMLREF
QUANTITY      SGMLREF      LITLEN         2048
                           NAMELEN        256
                           ATTCNT         80
                           GRPCNT         80
FEATURES
MINIMIZE      DATATAG      NO  OMITTAG    YES   RANK         NO     SHORTTAG    YES
LINK          SIMPLE       NO  IMPLICIT   NO    EXPLICIT     NO
OTHER         CONCUR       NO  SUBDOC     NO    FORMAL       YES
APPINFO       NONE

-- **********  end of SGML Declaration  ********** --

>


Technical Terms

Container Catalog
Technical Terms


Code

CHANGED | 1.2. 2.1.4.
copy-mmx.log | 2.1.6.
de | 2.2.4.1.
en | 2.2.4.1.
fr | 2.2.4.1.
History-overview | 2.2.2.1.
ID/IDREF | 1.1.
it | 2.2.4.1.
MOVED | 1.2. 2.1.4.
myfile-01-07.txt | 2.
NEW | 1.2. 2.1.4.
program-kit | 2.2.2.1.
REUSED | 1.2. 2.1.4.
tool-kit | 2.2.2.1.
UNCHANGED | 1.2. 2.1.4.
UNUSED |


Organisations

world wide web consortium | 1.
www.w3c.org | 1.


Products

catalog dtd | 1.
RDF | 1.
SGML | 1.1. 2.3.
SGML DTD | 1.3.
XML |


SGML Attributes

CATALOG-CLASS | 2.2.2.1.
class | 1.1. 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.3.2.
COMPANY | 2.2.2.2.
CREATION-DATE | 2.2.3.4.
CREATOR | 2.2.2.1. 2.2.3.4.
DATE | 2.2.1.1. 2.2.7.1.
id | 1.1. 2.2.1.2. 2.2.1.3.
IDENT | 2.2.5.1.
IDREF | 2.2.1.2. 2.2.1.3.
L | 2.2.4.1.
LABEL | 2.2.1.1. 2.2.2.2.
LABEL-P1 | 2.2.2.2.
LABEL-P2 | 2.2.2.2.
MODIFICATION-DATE | 2.2.2.1.
name | 1.1. 2.1.4. 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.8.1.
PRIVATE | 2.2.2.2.
PUBID | 2.2.2.1.
rev | 2.2.1.1.
REV-P1 | 2.2.2.2.
REV-P2 | 2.2.2.2.
ROLE | 2.2.3.4.
SEQUENCE | 2.2.1.2.
STATE | 2.2.1.1. 2.2.2.1. 2.2.2.2.
TYPE | 2.2.3.4.
upd | 1.2. 2.1.4. 2.2.1.3.
var | 2.2.1.1.
VAR-P1 | 2.2.2.2.
VAR-P2 | 2.2.2.2.
VERSION | 2.2.2.1.
VIEW |


SGML Elements

ablock | 1. 1.1. 1.2. 2. 2.1.4. 2.1.5. 2.2.1.1. 2.2.1.2. 2.2.1.3. 2.2.2.1. 2.2.3.3. 2.2.3.4. 2.2.5.1.
ablocks | 2.1.4.
aref | 1.1. 2.2.1.1. 2.2.2.1.
catalog | 1.1. 2.2.1.1. 2.2.1.2. 2.2.2.1. 2.2.5.1.
cri | 2.1.4. 2.2.2.2. 2.2.7.1.
field | 2.2.3.2.
field name="comment" | 2.
field-set | 1.1. 2.2.1.1. 2.2.3.1. 2.2.3.3.
field-set class="revision-history" | 2.
fields | 1.1. 2.1.4. 2.2.1.1. 2.2.3.2.
file | 1.2. 2.1.4. 2.1.5. 2.2.1.1. 2.2.3.4.
id | 2.2.1.2. 2.2.1.3.
l-4 | 2.2.4.2.
long-name | 2.2.4.1. 2.2.5.1.
metadata | 1.1. 2. 2.1.4. 2.2.1.1. 2.2.2.1. 2.2.4.2. 2.2.5.1. 2.2.6.1. 2.2.7.2. 2.2.8.2.
owner | 2.2.5.1.
revision | 2.2.2.2. 2.2.7.2.
revisions | 2.2.5.1. 2.2.7.1.
usable-for-variant | 2.2.8.2. 2.2.9.1.
usable-for-variants | 2.2.5.1. 2.2.8.1.
v | 2.2.8.1.


Tools

ASCET | 2.2.1.2. 2.2.1.3.
data management system | 2.2.2.2.


Untitled

There ist no value "deleted" because versioned data is not deleted in order to track the full history.


Untitled

The reference catalog must be identified by local means and is not defined in the actual catalog.


Untitled

If the directory is readonly, then a system message may occur, since this is not checked.


Untitled

if this is not possible, the objects must be referred to using the ID attribute.


Untitled

If a Version Management System is used, checkout date is attachec to the files checked out. So Creation-date cannot be used as a time stamp.


Untitled

This cannot be determined by comparing catalogs since the full exchange history is necessary which must be kept in the process data management system


Untitled

the behaviour should be the same as in a <pre> element in HTML.