Since the respective companies explode the interchange DTD into fragments and use it for the respective acquisition DTDs (perhaps in different departments), the administrative data
appears in many places in the DTD. Each of these places can be used as such a fragment(see below).
Figure 120: Support of DTD fragmentation through administrative data
The operating model is
The document respectively the fragment is written in a certain language which can be defined in the element
<
language
>
. This element can be used to control a SGML system, e.g. to set the correct prefix strings for elements.
The DTD can be configured for the multilingual operation. In this case
<
language
>
contains the language of the origin document. All languages used in a document have to be defined within
<
used-languages
>
, that is each language is defined with a
<
l-10
>
-element which contains the full language name and in the Attribute
[
l
]
the short language name (see
15.6. Multilinguality
).
The document (or the fragment) is handled in all companies participating in the project.
The data management in the various companies is different. For that reason, each participant can enter information about their document management facilities in
<
company-doc-info
>
:
<
doc-label
>
this is the label under which the document is managed in the company denoted by
<
company-ref
>
<
private-code
>
allows to transport company specific information in a private notation. This is the place, where for example
PDMS
(
Product Data Management System
s) can place pointers and document ids required to resynchronize after a document exchange.
<
entity-name
>
It might be the case that each participating company uses a different fragmentation strategy. In order to support this,
<
entity-name
>
can receive information useable by a
split utility
which creates the desired fragments out of the entire document.
If a new release of the document or the fragment is given, each participating site may use a specific scheme for revision numbers. For that reason, each
<
doc-revision
>
can receive
<
company-revision-info
>
which holds the participant specific information for the actual document revision.
It is up to a
semantical check utility
to keep sure that there is only one entry per company.
nevertheless, the actual revision is initiated by one individual denoted by
<
team-member-ref
>
at one certain point of time denoted by
<
date
>
.
Finally the modifications made in that revision are stored in
<
modifcations
>
where the actual
<
change
>
as well as the
<
reason
>
for that change is notified. If possible, the change can be located by
<
xref
>
.
For each
<
modifcation
>
the attribute
[
type
]
determines, if the change is made to the document only (
doc-related
) or to the subject of the document (
content-related
).