-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathpuid.fmt.120.xml
104 lines (104 loc) · 6.91 KB
/
puid.fmt.120.xml
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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<PRONOM-Report xmlns="http://pronom.nationalarchives.gov.uk">
<report_format_detail>
<SearchCriteria>Criteria</SearchCriteria>
<FileFormat>
<FormatID>769</FormatID>
<FormatName>DROID File Collection File Format</FormatName>
<FormatVersion>1.0</FormatVersion>
<FormatAliases>
</FormatAliases>
<FormatFamilies>
</FormatFamilies>
<FormatTypes>
</FormatTypes>
<FormatDisclosure>Full</FormatDisclosure>
<FormatDescription>The DROID File Collection File format is a format for storing the results of file format identifications generated by the DROID software tool. It was developed by The National Archives of the UK. A DROID File Collection File is an XML document, comprising a 'FileCollection' element, which describes the version of DROID and Signature File version number used to perform the identifications number, and date on which the identifications were generated. This element contains a 'File' element for each file being identified. A File Collection File may either be generated prior to identification, in which case each 'File' element simply contains the fully-qualified pathname of the file, or it can be generated after identification, in which case each 'File' element additionally contains the identification result.</FormatDescription>
<BinaryFileFormat>Text</BinaryFileFormat>
<ByteOrders>
</ByteOrders>
<ReleaseDate>17 Sep 2005</ReleaseDate>
<WithdrawnDate>
</WithdrawnDate>
<ProvenanceSourceID>1</ProvenanceSourceID>
<ProvenanceName>Digital Preservation Department / The National Archives</ProvenanceName>
<ProvenanceSourceDate>11 Oct 2005</ProvenanceSourceDate>
<ProvenanceDescription>
</ProvenanceDescription>
<LastUpdatedDate>11 Oct 2005</LastUpdatedDate>
<FormatNote>
</FormatNote>
<FormatRisk>
</FormatRisk>
<TechnicalEnvironment>
</TechnicalEnvironment>
<FileFormatIdentifier>
<Identifier>fmt/120</Identifier>
<IdentifierType>PUID</IdentifierType>
</FileFormatIdentifier>
<FileFormatIdentifier>
<Identifier>text/xml</Identifier>
<IdentifierType>MIME</IdentifierType>
</FileFormatIdentifier>
<Document>
<DocumentID>64</DocumentID>
<DisplayText>Brown, A, 2005, Automatic format identification using PRONOM and DROID, Digital Preservation Technical Paper, 1, The National Archives</DisplayText>
<DocumentType>Authoritative</DocumentType>
<AvailabilityDescription>Public</AvailabilityDescription>
<AvailabilityNote>
</AvailabilityNote>
<PublicationDate>17 Sep 2005</PublicationDate>
<TitleText>Automatic format identification using PRONOM and DROID</TitleText>
<DocumentIPR>
</DocumentIPR>
<DocumentNote>
</DocumentNote>
<DocumentIdentifier>
<Identifier>www.nationalarchives.gov.uk/aboutapps/fileformat/pdf/automatic_format_identification.pdf</Identifier>
<IdentifierType>URL</IdentifierType>
</DocumentIdentifier>
</Document>
<ExternalSignature>
<ExternalSignatureID>765</ExternalSignatureID>
<Signature>xml</Signature>
<SignatureType>File_extension</SignatureType>
</ExternalSignature>
<InternalSignature>
<SignatureID>176</SignatureID>
<SignatureName>DROID File Collection File</SignatureName>
<SignatureNote><FileCollection>…<DROIDVersion> elements. {0-50} < F I l e C o l l e c t I o n {0-100} < D R O I D V e r s I o n > {1-10} < / D R O I D V e r s I o n > - NB. The signature byte sequence is currently massaged to steer around the known PRONOM bug in the are of the left fragment matching when the longest fragment is not nearest BOF. The last fragment in the BOF byte sequence has been shortened by 2 bytes to ensure that the first fragment is the longest. This abbreviation does not reduce the overall signature strength too much and so will hopefully not result in any false positive identification. When the PRONOM bug has been fixed, "0D0A" should be appended to the BOF byte sequence and this note reduced.</SignatureNote>
<ByteSequence>
<ByteSequenceID>209</ByteSequenceID>
<PositionType>Absolute from BOF</PositionType>
<Offset>0</Offset>
<MaxOffset>
</MaxOffset>
<IndirectOffsetLocation>
</IndirectOffsetLocation>
<IndirectOffsetLength>
</IndirectOffsetLength>
<Endianness>
</Endianness>
<ByteSequenceValue>{0-50}3C46696C65436F6C6C656374696F6E20{0-100}3C44524F494456657273696F6E3E{1-10}3C2F44524F494456657273696F6E3E</ByteSequenceValue>
</ByteSequence>
</InternalSignature>
<FidoSignature>
<FidoSignatureID>28</FidoSignatureID>
<FidoSignatureName>DROID File Collection File</FidoSignatureName>
<FidoSignatureNote><FileCollection>â¦<DROIDVersion> elements. {0-50} < F I l e C o l l e c t I o n {0-100} < D R O I D V e r s I o n > {1-10} < / D R O I D V e r s I o n > - NB. The signature byte sequence is currently massaged to steer around the known PRONOM bug in the are of the left fragment matching when the longest fragment is not nearest BOF. The last fragment in the BOF byte sequence has been shortened by 2 bytes to ensure that the first fragment is the longest. This abbreviation does not reduce the overall signature strength too much and so will hopefully not result in any false positive identification. When the PRONOM bug has been fixed, "0D0A" should be appended to the BOF byte sequence and this note reduced.</FidoSignatureNote>
<FidoPrioritize>true</FidoPrioritize>
<Pattern>
<PatternID>209</PatternID>
<Position>BOF</Position>
<Regex>(?s)\A.{0,50}<FileCollection .{0,100}<DROIDVersion>.{1,10}</DROIDVersion></Regex>
</Pattern>
</FidoSignature>
<RelatedFormat>
<RelationshipType>Has_priority_over</RelationshipType>
<RelatedFormatID>638</RelatedFormatID>
<RelatedFormatName>Extensible Markup Language</RelatedFormatName>
<RelatedFormatVersion>1.0</RelatedFormatVersion>
</RelatedFormat>
</FileFormat>
</report_format_detail>
</PRONOM-Report>