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
.
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.