|
|
|
|
|||||||||
|
VERS STORY | STANDARD | ASSESSMENT | PROJECTS | DIGITAL ARCHIVE | TRAINING | TOOLKIT | PUBLICATIONS | |
|
|||||||||
|
|||||
|
3.4 Document structure In Version 2, Documents within a record can be structured. That is, a Document can contain other Documents. This feature is optional and a VERS-compliant system does not have to support it. An example of the use of structured Documents is the record of an email message. A received email consists of header information, one or more alternate email bodies, and, optionally, one or more attachments. The header information contains information about the email. This includes the familiar 'Subject', 'From' and 'To' fields. It also includes more technical information describing which machines handled the email in the transmission from the sender to the receiver. The alternate email bodies are intended to represent the same email message using different formatting commands. For example, an email may include a HTML version of the message and a plain text version. The email program should display the HTML version, if it is capable of doing so, otherwise it will display the plain text version. The attachments are supplementary information that are not interpreted by the email program itself, but are detached or viewed by applications on the receiving computer. When an email program presents an email to a user, only part of the information in the email is actually displayed. First, the email program selects and displays some of the email headers (typically the 'Subject', 'From', 'To' and 'Cc' fields). Second, it selects one of the alternate email bodies and displays it. Finally, the client indicates that attachments are present, but the user has to explicitly act to open them. When capturing a record of an email it is often not sufficient to simply capture the actual email message. This is because the user actually saw very little of the actual email message. The user saw a subset of the headers, one of the alternate bodies, and may not have viewed any of the attachments. Using structured Documents it is possible to capture a record both of what the user actually saw and what was sent. A possible record of an email, created using structured Documents, is shown in Figure 5. The key Document within the record is a facsimile of the email message that was actually presented to the user. This would be formatted to reflect how the email body was displayed when the user saw it, including the headers actually displayed and the icons indicating any attachments. The use of this Document clearly differentiates between what the receiver of the email saw when they read the email, and the alternative bodies and additional headers that the user did not see. Attachments to the email can then be included as sub-Documents beneath the email body Document, clearly differentiating between the body and the attachments (which the user may not have opened). Finally, additional Documents can be used to represent the remaining header information not presented to the user (this information shows how the email was transmitted and may be critical in demonstrating the integrity and authenticity of the email).
Figure 5. A record containing structured Documents 3.4.1 Method of indicating the structure within records In VERS, the Documents within a record are indicated by attributes contained in the vers:Document (M114) element. Another implementation option would have been to define a Structured Document element which could contain Documents or other Structured Documents. This approach would have been much cleaner, but would have meant that Version 1 VERS systems would not be capable of recognising Documents in a Version 2 VEO. The structuring information is represented by three attributes that may be contained within a Document (M114) element.
Figure 6 shows a diagram of the record in Figure 5 illustrating the use of these three attributes.
Figure 6. The structured record shown in Figure 5 represented diagrammatically as a VEO. Expressed as XML, the email record is as follows (note that elements not relevant to this discussion have been omitted): <vers:SignedObject vers:VEOVersion="2.0"> 3.4.2 Organising Documents within records When organising Documents to appear in a VERS record, the first document must be the topmost Document. The remaining Documents may be in any order, but it is recommended that the Documents are ordered via a depth-first traversal of the document tree. A depth-first traversal is one where the descendants of a Document appear before its siblings appear. The depth-first traversal of the email example (Figure 5) is shown in Figure 7.
Figure 7. The depth-first traversal of the Documents shown in Figure 5. Note that the descendants of the email body (the two attachments) are visited before its sibling (the email headers) is visited. VERS systems that do not implement document structuring (i.e. Version 1 systems and Version 2 systems that do not implement document structuring) will present the documents in the order that they appear in the VEO. 3.4.3 Non-leaf documents need not contain encodings A non leaf Document need not contain any Encodings. A non-leaf Document is any Document that does not have subordinate Documents (i.e. contains a vers:subordinateDocuments attribute). In the email example the email and email body Documents are non-leaf Documents. The email (topmost Document) exists simply to provide part of the structure and does not contain any content. If the example XML given in section 3.4.1 is examined, the reader will note that Document 1 (the topmost document) does not contain an Encoding element. 3.4.4 Additional structural attributes In addition to the three structuring attributes, the Document (M114) element contains two other attributes (these are not shown in Figure 6):
| |||||
 |
 |
|
