-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathmets.xsd
1854 lines (1790 loc) · 135 KB
/
mets.xsd
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
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace="http://www.loc.gov/METS/" xmlns="http://www.loc.gov/METS/" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xsd:import namespace="http://www.w3.org/1999/xlink" schemaLocation="http://www.loc.gov/standards/xlink/xlink.xsd"/>
<xsd:annotation>
<xsd:documentation xml:lang="en">
METS: Metadata Encoding and Transmission Standard
This document is available under the Creative Commons CC0 1.0 Universal Public Domain Dedication (http://creativecommons.org/publicdomain/zero/1.0/).
The Digital Library Federation, as creator of this document, has waived all rights to it worldwide under copyright law, including
all related and neighboring rights, to the extent allowed by law. For the full text see http://creativecommons.org/publicdomain/zero/1.0/legalcode.
Prepared for the Digital Library Federation by Jerome McDonough, New York University,
with the assistance of Michael Alexander (British Library), Joachim Bauer (Content Conversion Specialists, Germany),
Rick Beaubien (University of California), Terry Catapano (Columbia University), Morgan Cundiff (Library of Congress),
Susan Dahl (University of Alberta), Markus Enders (State and University Library, Göttingen/British Library),
Richard Gartner (Bodleian Library at Oxford/King's College, London), Thomas Habing (University of Illinois at Urbana-Champaign),
Nancy Hoebelheinrich (Stanford University/Knowledge Motifs LLC), Arwen Hutt (U.C. San Diego),
Mark Kornbluh (Michigan State University), Cecilia Preston (Preston & Lynch), Merrilee Proffitt (Research Libraries Group),
Clay Redding (Library of Congress), Jenn Riley (Indiana University), Richard Rinehart (Berkeley Art Museum/Pacific Film Archive),
Mackenzie Smith (Massachusetts Institute of Technology), Tobias Steinke (German National Library),
Taylor Surface (OCLC), Brian Tingle (California Digital Library) and Robin Wendler (Harvard University),
Robert Wolfe (Massachusetts Institute of Technology), Patrick Yott (Brown University).
October, 2019
Version 1.12.1
</xsd:documentation>
<xsd:documentation xml:lang="en">
Change History
April 23, 2001: Alpha Draft completed
June 7, 2001: Beta completed
6/7/2001 Beta Changes:
1. add 'Time' as a possible time code value, as well as TCF.
2. Make dmdSec ID attribute required; make ID attribute optional on MDRef/MDWrap.
3. Add 'Label' attribute to StructMap, along with 'Type'.
4. Add DDI and FGDC as potential metadata schemes to enumeration.
5. Enable an "otherMDtype" attribute for MDWrap/MDRef and any other element where
there's an 'other' in the enumerated possibilities.
6. Add a "profile" attribute to METS element.
7. Revised mptr declaration so that it's like FLocat/MDRef (and not like XLink)
8. Extend internal documentation of <area> attributes.
9. Add "other" to the possible set of LOCTYPEs.
10. Change ADMIDS to ADMID on FileGrp.
11. Change "N" to "Order" on <div> element.
12. Change "Number" to "order label" on <div> element
13. Add createdate and lastmoddate attributes to mets element.
14. Allow <div> and <area> elements to link to administrative metadata sections.
15. Normalize attribute pointing facilities for file element and mdRef.
16. Provide a LOCTYPE of "other" and an "otherloctype" attribute for pointing to external files.
17. Drop PDI from enumeration of LOCTYPES.
18. Make MDTYPE required in mdRef and mdWrap.
19. Rename preservationMD to digiprovMD.
20. Add optional CHECKSUM attribute to FContent element.
21. Modularize declarations of fileGrpType and mdSecType attributes and enumerations to
simplify maintenance.
22. Add TYPE attribute to structMap.
23. Declare structMap element using structMapType rather than direct declaration.
24. Add area element as possible subelement to <div>, along with par and seq.
25. Change mdSec model to ALL, to enable differing order of mdRef/mdWrap elements.
26. Extend documentation on <par> and <seq> elements.
</xsd:documentation>
<xsd:documentation xml:lang="en">
October 22, 2001: Gamma completed
10/22/2001 Gamma changes:
1. Added optional fileSec element beneath METS root element to contain fileGrps.
2. Created subsidiary schema file xlink.xsd for XLink attributes, restored XLink attributes
to mptr element, and added XLink support to mdRef and FLocat.
3. Created new element metsHdr to handle metadata regarding METS document
itself (analogous to TEI Header). Moved CREATEDATE and LASTMODDATE attributes
to metsHdr, and added new RECORDSTATUS attribute. Added new subsidiary elements
agent and altRecordID to metsHdr.
4. Made CREATEDATE and LASTMODDATE attributes type xsd:dateTime to allow more precise
recording of when work was done.
5. Changed all attributes using data type of xsd:binary to xsd:base64Binary to conform to final
W3C schema recommendations.
6. Cleaned up annotations/documentation.
</xsd:documentation>
<xsd:documentation xml:lang="en">
December 19, 2001: Epsilon and PROTOFINAL completed
12/19/2001 Epsilon changes:
1. Changed sequence operator for StructMap so that only 1 root div element is permitted.
2. Add new roles to agent element's role attribute and support for extensible 'other' role.
3. Add support for extensible 'other' type attribute on agent element.
4. Yet more documentation clean up.
5. Relocate CHECKSUM attribute from FContent to File element.
6. Change the file element's CREATED attribute and fileGroup's VERSDATE attribute to
a type of xsd:dateTime
7. Change attribute name DMD for div element to DMDID for consistency's sake.
8. Added new behaviorSec for support of referencing executable code from METS object
</xsd:documentation>
<xsd:documentation xml:lang="en">
February 8, 2002: Zeta bug fix to final
2/8/2002 Zeta changes
1. Eliminated redundant VRA in metadata type enumeration.
2. Changed mdWrap content model, adding xmlData element to eliminate
ambiguous content model
</xsd:documentation>
<xsd:documentation xml:lang="en">
June 3, 2002: Version 1.1
6/3/2002 v1.1 changes:
1. Add new structLink section for recording hyperlinks between media represented by structMap nodes.
2. Allow a <par> element to contain a <seq>
</xsd:documentation>
<xsd:documentation xml:lang="en">
Dec. 27, 2002: Version 1.2
12/27/2002 v1.2 changes:
1. Add “USE” attribute to FileGrp, File, FLocat and FContent;
2. Make FLocat repeatable;
3. Have FContent mimic mdWrap in using separate binData/xmlData sections;
4. Copyright statement added;
5. Allow both FLocat and Fcontent in single file element;
6. Allow behaviorSec elements to group through GROUPID attribute;
7. allow descriptive and administrative metadata sections to be grouped through GROUPID attribute;
8. allow <file> element to point to descriptive metadata via DMDID attribute;
9. allow descriptive metadata and all forms of administrative metadata to point to administrative metadata via ADMID attribute;
10. CREATED and STATUS attributes added to all desc. and adm. metadata sections; and
11. clean up documentation in elements to reflect reality.
</xsd:documentation>
<xsd:documentation xml:lang="en">
May 8, 2003: Version 1.3
05/05/2003 v1.3 changes:
1. Change “2. OBJID: a primary identifier assigned to the original source document” to “2. OBJID: a primary identifier assigned to the METS object.”
2. Add MODS to MDTYPEs.
3. Modify <file> attributes so that instead of just CHECKSUM we have CHECKSUM and CHECKSUMTYPE, where CHECKSUMTYPE is a controlled vocabulary as follows:
HAVAL, MD5, SHA-1, SHA-256, SHA-384, SHA-512, TIGER, WHIRLPOOL
4.Alter BehaviorSec to make it recursive, and add a new behavior element to wrap mechanism and interfaceDef elements.
</xsd:documentation>
<xsd:documentation xml:lang="en">
May 1, 2004: Version 1.4
05/01/2003 v1.4 changes:
1. Moved attribute documentation out of element documentation
(thank you, Brian Tingle).
2. New CONTENTIDS attribute (and URIs simpleType) added to div, fptr,
mptr and area elements for mapping MPEG21 DII Identifier values
3. XLink namespace URI changed to conform with XLink recommendation.
4. ID Attribute added to FContent.
5. ID Attribute addedt to structLink.
6. ID Attribute added to smLink.
7. "LOM" added as metadata type.
</xsd:documentation>
<xsd:documentation xml:lang="en">
April 12, 2005: Version 1.5
04/12/2005 v1.5 changes:
1. Made file element recursive to deal with PREMIS Onion Layer model and
support XFDU-ish unpacking specification.
2. Add <stream> element beneath <file> to allow linking of metadata to
subfile structures.
3. Modify structLink TO and FROM attributes to put them in XLink namespace.
4. Make processContents "lax" for all xsd:any elements.
</xsd:documentation>
<xsd:documentation xml:lang="en">
October 18, 2006: Version 1.6
10/18/2006 v1.6 changes:
1. add ID to stream and transformFile
2. add ADMID to metsHdr
3. make smLink/@xlink:to and smLink/@xlink:from required
</xsd:documentation>
<xsd:documentation xml:lang="en">
October 16, 2007/ Jan 20, 2008: Version 1.7
10/16/2007 01/30/2008 v 1.7 changes:
1. create parType complex type to allow a seq to contain a par
2. create FILECORE attribute group with MIMETYPE, SIZE, CHECKSUM, CHECKSUMTYPE;
change fileType, mdWrapType and mdRefType use the attribute group, so mdType and mdRef end
up with new SIZE, CHECKSUM, and CHECKSUMTYPE attributes (file does not change)
20080130
2a. CREATED added to FILECORE
3. PREMIS:OBJECT PREMIS:AGENT PREMIS:RIGHTS PREMIS:EVENT added to MDTYPE value enumeration
</xsd:documentation>
<xsd:documentation xml:lang="en">
April 2009: Version 1.8
Version 1.8 changes:
1. Add CRC32, Adler-32, MNP to the enumerated values constraining CHECKSUMTYPE to align with MIX messageDigestAlgorithm constraints.
2. Add TEXTMD and METSRIGHTS to the enumeration values constraining MDTYPE.
3. Add an MDTYPEVERSION attribute as a companion to the MDTYPE attribute in the mdRef and mdWrap elements.
4. ID and STRUCTID attributes on the behavior element made optional. Depending on whether the behavior applies to a transformFile element or div elements in the structMap, only one or the other of the attributes would pertain.
5. Documentation aligned with the METS Primer, and corrected.
6. xml:lang="en" atttribute value added to every <documentation> element
7. xlink:extendedLink support added to the <structLink> element by means of a new <smLinkGrp> element, and its child <smLocatorLink> and <smArcLink> elements.
</xsd:documentation>
<xsd:documentation xml:lang="en">
2010: Version 1.9
Version 1.9 Changes:
1. Added a <metsDocumentID> element to the <metsHdr> for recording a unique identifier for the METS document itself where this is different from the OBJID, the identifier for the entire digital object represented by the METS document.
2. Added "ISO 19115:2003 NAP" to the enumerated values for the MDTYPE attribute in the METADATA attribute group.
3. Added "XPTR" to the enumerated values for the BETYPE attribute on the areaType data type
4. Added BEGIN, END and BETYPE attributes to the <file> and <stream> elements for specifying the location of a nested file or a stream within it's parent file.
</xsd:documentation>
<xsd:documentation xml:lang="en">
March 2012: Version 1.9.1
Version 1.9.1 Changes:
1. Added 'EAC-CPF' as potential metadata scheme to MDTYPE enumeration
EAC-CPF = Encoded Archival Context - Corporate Bodies, Persons, and Families
http://eac.staatsbibliothek-berlin.de/eac-cpf-schema.html
</xsd:documentation>
<xsd:documentation xml:lang="en">
July 2013: Version 1.10
Version 1.10 Changes:
1. Added 'LIDO' as potential metadata scheme to MDTYPE enumeration
LIDO = Lightweight Information Describing Objects
http://network.icom.museum/cidoc/working-groups/data-harvesting-and-interchange/lido-technical/specification/
2. Added xsd:anyAttribute with namespace ##other and processContents lax to these METS elements:
mets
metsHdr
dmdSec
amdSec
techMD
rightsMD
sourceMD
digiprovMD
fileSec
fileGrp
file
structMap
fptr
structLink
behaviorSec
This will allow arbitrary new attributes to be added to these elements to support local needs.
</xsd:documentation>
<xsd:documentation xml:lang="en">
January 2015: Version 1.10.1
Version 1.10.1 Changes:
1. Fixed bug: The anyAttribute declaration was inadvertently added to the FLocat element when it should have been on the file element. This
has been corrected in this version.
</xsd:documentation>
<xsd:documentation xml:lang="en">
May 2015: Version 1.11
Version 1.11 Changes:
1. Added new attributes, ORDER, ORDERLABEL, and LABEL, to these METS elements:
par
seq
area
2. Also added xsd:anyAttribute with namespace ##other and processContents lax to these elements. This will allow arbitrary new attributes to be added to these elements to support local needs.
</xsd:documentation>
<xsd:documentation xml:lang="en">
May 2018: Version 1.12
Version 1.12 Changes:
1. Added xsd:anyAttribute with namespace ##other and processContents lax to these elements:
agent/note
This will allow arbitrary new attributes to be added to this element to support local needs. The original use case was to identify the type of the note.
</xsd:documentation>
<xsd:documentation xml:lang="en">
October 2019: Version 1.12.1
Version 1.12.1 Changes:
1. Move comments with version history to xsd:documentation elements
This allows tools that generate documentation from schemas to include the change history in the generated documentation.
</xsd:documentation>
</xsd:annotation>
<xsd:element name="mets">
<xsd:annotation>
<xsd:documentation xml:lang="en">METS: Metadata Encoding and Transmission Standard.
METS is intended to provide a standardized XML format for transmission of complex digital library objects between systems. As such, it can be seen as filling a role similar to that defined for the Submission Information Package (SIP), Archival Information Package (AIP) and Dissemination Information Package (DIP) in the Reference Model for an Open Archival Information System. The root element <mets> establishes the container for the information being stored and/or transmitted by the standard.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="metsType"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="metsType">
<xsd:annotation>
<xsd:documentation xml:lang="en">metsType: Complex Type for METS Sections
A METS document consists of seven possible subsidiary sections: metsHdr (METS document header), dmdSec (descriptive metadata section), amdSec (administrative metadata section), fileGrp (file inventory group), structLink (structural map linking), structMap (structural map) and behaviorSec (behaviors section).
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="metsHdr" minOccurs="0">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The mets header element <metsHdr> captures metadata about the METS document itself, not the digital object the METS document encodes. Although it records a more limited set of metadata, it is very similar in function and purpose to the headers employed in other schema such as the Text Encoding Initiative (TEI) or in the Encoded Archival Description (EAD).
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="agent" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">agent:
The agent element <agent> provides for various parties and their roles with respect to the METS record to be documented.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="name" type="xsd:string">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The element <name> can be used to record the full name of the document agent.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="note" minOccurs="0" maxOccurs="unbounded" >
<xsd:annotation>
<xsd:documentation xml:lang="en">
The <note> element can be used to record any additional information regarding the agent's activities with respect to the METS document.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:anyAttribute namespace="##other" processContents="lax"></xsd:anyAttribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="ROLE" use="required">
<xsd:annotation>
<xsd:documentation xml:lang="en">ROLE (string/R): Specifies the function of the agent with respect to the METS record. The allowed values are:
CREATOR: The person(s) or institution(s) responsible for the METS document.
EDITOR: The person(s) or institution(s) that prepares the metadata for encoding.
ARCHIVIST: The person(s) or institution(s) responsible for the document/collection.
PRESERVATION: The person(s) or institution(s) responsible for preservation functions.
DISSEMINATOR: The person(s) or institution(s) responsible for dissemination functions.
CUSTODIAN: The person(s) or institution(s) charged with the oversight of a document/collection.
IPOWNER: Intellectual Property Owner: The person(s) or institution holding copyright, trade or service marks or other intellectual property rights for the object.
OTHER: Use OTHER if none of the preceding values pertains and clarify the type and location specifier being used in the OTHERROLE attribute (see below).
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="CREATOR"/>
<xsd:enumeration value="EDITOR"/>
<xsd:enumeration value="ARCHIVIST"/>
<xsd:enumeration value="PRESERVATION"/>
<xsd:enumeration value="DISSEMINATOR"/>
<xsd:enumeration value="CUSTODIAN"/>
<xsd:enumeration value="IPOWNER"/>
<xsd:enumeration value="OTHER"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="OTHERROLE" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">OTHERROLE (string/O): Denotes a role not contained in the allowed values set if OTHER is indicated in the ROLE attribute.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="TYPE" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">TYPE (string/O): is used to specify the type of AGENT. It must be one of the following values:
INDIVIDUAL: Use if an individual has served as the agent.
ORGANIZATION: Use if an institution, corporate body, association, non-profit enterprise, government, religious body, etc. has served as the agent.
OTHER: Use OTHER if none of the preceding values pertain and clarify the type of agent specifier being used in the OTHERTYPE attribute
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="INDIVIDUAL"/>
<xsd:enumeration value="ORGANIZATION"/>
<xsd:enumeration value="OTHER"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="OTHERTYPE" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">OTHERTYPE (string/O): Specifies the type of agent when the value OTHER is indicated in the TYPE attribute.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="altRecordID" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The alternative record identifier element <altRecordID> allows one to use alternative record identifier values for the digital object represented by the METS document; the primary record identifier is stored in the OBJID attribute in the root <mets> element.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="TYPE" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">TYPE (string/O): A description of the identifier type (e.g., OCLC record number, LCCN, etc.).
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="metsDocumentID" minOccurs="0">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The metsDocument identifier element <metsDocumentID> allows a unique identifier to be assigned to the METS document itself. This may be different from the OBJID attribute value in the root <mets> element, which uniquely identifies the entire digital object represented by the METS document.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:string">
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="TYPE" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">TYPE (string/O): A description of the identifier type.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="ADMID" type="xsd:IDREFS" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ADMID (IDREFS/O): Contains the ID attribute values of the <techMD>, <sourceMD>, <rightsMD> and/or <digiprovMD> elements within the <amdSec> of the METS document that contain administrative metadata pertaining to the METS document itself. For more information on using METS IDREFS and IDREF type attributes for internal linking, see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="CREATEDATE" type="xsd:dateTime" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">CREATEDATE (dateTime/O): Records the date/time the METS document was created.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="LASTMODDATE" type="xsd:dateTime" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">LASTMODDATE (dateTime/O): Is used to indicate the date/time the METS document was last modified.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="RECORDSTATUS" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">RECORDSTATUS (string/O): Specifies the status of the METS document. It is used for internal processing purposes.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="dmdSec" type="mdSecType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">
A descriptive metadata section <dmdSec> records descriptive metadata pertaining to the METS object as a whole or one of its components. The <dmdSec> element conforms to same generic datatype as the <techMD>, <rightsMD>, <sourceMD> and <digiprovMD> elements, and supports the same sub-elements and attributes. A descriptive metadata element can either wrap the metadata (mdWrap) or reference it in an external location (mdRef) or both. METS allows multiple <dmdSec> elements; and descriptive metadata can be associated with any METS element that supports a DMDID attribute. Descriptive metadata can be expressed according to many current description standards (i.e., MARC, MODS, Dublin Core, TEI Header, EAD, VRA, FGDC, DDI) or a locally produced XML schema.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="amdSec" type="amdSecType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The administrative metadata section <amdSec> contains the administrative metadata pertaining to the digital object, its components and any original source material from which the digital object is derived. The <amdSec> is separated into four sub-sections that accommodate technical metadata (techMD), intellectual property rights (rightsMD), analog/digital source metadata (sourceMD), and digital provenance metadata (digiprovMD). Each of these subsections can either wrap the metadata (mdWrap) or reference it in an external location (mdRef) or both. Multiple instances of the <amdSec> element can occur within a METS document and multiple instances of its subsections can occur in one <amdSec> element. This allows considerable flexibility in the structuring of the administrative metadata. METS does not define a vocabulary or syntax for encoding administrative metadata. Administrative metadata can be expressed within the amdSec sub-elements according to many current community defined standards, or locally produced XML schemas. </xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="fileSec" minOccurs="0">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The overall purpose of the content file section element <fileSec> is to provide an inventory of and the location for the content files that comprise the digital object being described in the METS document.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:sequence>
<xsd:element name="fileGrp" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">
A sequence of file group elements <fileGrp> can be used group the digital files comprising the content of a METS object either into a flat arrangement or, because each file group element can itself contain one or more file group elements, into a nested (hierarchical) arrangement. In the case where the content files are images of different formats and resolutions, for example, one could group the image content files by format and create a separate <fileGrp> for each image format/resolution such as:
-- one <fileGrp> for the thumbnails of the images
-- one <fileGrp> for the higher resolution JPEGs of the image
-- one <fileGrp> for the master archival TIFFs of the images
For a text resource with a variety of content file types one might group the content files at the highest level by type, and then use the <fileGrp> element’s nesting capabilities to subdivide a <fileGrp> by format within the type, such as:
-- one <fileGrp> for all of the page images with nested <fileGrp> elements for each image format/resolution (tiff, jpeg, gif)
-- one <fileGrp> for a PDF version of all the pages of the document
-- one <fileGrp> for a TEI encoded XML version of the entire document or each of its pages.
A <fileGrp> may contain zero or more <fileGrp> elements and or <file> elements.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="fileGrpType"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="structMap" type="structMapType" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The structural map section <structMap> is the heart of a METS document. It provides a means for organizing the digital content represented by the <file> elements in the <fileSec> of the METS document into a coherent hierarchical structure. Such a hierarchical structure can be presented to users to facilitate their comprehension and navigation of the digital content. It can further be applied to any purpose requiring an understanding of the structural relationship of the content files or parts of the content files. The organization may be specified to any level of granularity (intellectual and or physical) that is desired. Since the <structMap> element is repeatable, more than one organization can be applied to the digital content represented by the METS document. The hierarchical structure specified by a <structMap> is encoded as a tree of nested <div> elements. A <div> element may directly point to content via child file pointer <fptr> elements (if the content is represented in the <fileSec<) or child METS pointer <mptr> elements (if the content is represented by an external METS document). The <fptr> element may point to a single whole <file> element that manifests its parent <div<, or to part of a <file> that manifests its <div<. It can also point to multiple files or parts of files that must be played/displayed either in sequence or in parallel to reveal its structural division. In addition to providing a means for organizing content, the <structMap> provides a mechanism for linking content at any hierarchical level with relevant descriptive and administrative metadata.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="structLink" minOccurs="0">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The structural link section element <structLink> allows for the specification of hyperlinks between the different components of a METS structure that are delineated in a structural map. This element is a container for a single, repeatable element, <smLink> which indicates a hyperlink between two nodes in the structural map. The <structLink> section in the METS document is identified using its XML ID attributes.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="structLinkType"/>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<xsd:element name="behaviorSec" type="behaviorSecType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">
A behavior section element <behaviorSec> associates executable behaviors with content in the METS document by means of a repeatable behavior <behavior> element. This element has an interface definition <interfaceDef> element that represents an abstract definition of the set of behaviors represented by a particular behavior section. A <behavior> element also has a <mechanism> element which is used to point to a module of executable code that implements and runs the behavior defined by the interface definition. The <behaviorSec> element, which is repeatable as well as nestable, can be used to group individual behaviors within the structure of the METS document. Such grouping can be useful for organizing families of behaviors together or to indicate other relationships between particular behaviors.</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="OBJID" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">OBJID (string/O): Is the primary identifier assigned to the METS object as a whole. Although this attribute is not required, it is strongly recommended. This identifier is used to tag the entire METS object to external systems, in contrast with the ID identifier.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="LABEL" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">LABEL (string/O): Is a simple title string used to identify the object/entity being described in the METS document for the user.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="TYPE" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">TYPE (string/O): Specifies the class or type of the object, e.g.: book, journal, stereograph, dataset, video, etc.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="PROFILE" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">PROFILE (string/O): Indicates to which of the registered profile(s) the METS document conforms. For additional information about PROFILES see Chapter 5 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
<xsd:complexType name="amdSecType">
<xsd:annotation>
<xsd:documentation xml:lang="en">amdSecType: Complex Type for Administrative Metadata Sections
The administrative metadata section consists of four possible subsidiary sections: techMD (technical metadata for text/image/audio/video files), rightsMD (intellectual property rights metadata), sourceMD (analog/digital source metadata), and digiprovMD (digital provenance metadata, that is, the history of migrations/translations performed on a digital library object from it's original digital capture/encoding).
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="techMD" type="mdSecType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">
A technical metadata element <techMD> records technical metadata about a component of the METS object, such as a digital content file. The <techMD> element conforms to same generic datatype as the <dmdSec>, <rightsMD>, <sourceMD> and <digiprovMD> elements, and supports the same sub-elements and attributes. A technical metadata element can either wrap the metadata (mdWrap) or reference it in an external location (mdRef) or both. METS allows multiple <techMD> elements; and technical metadata can be associated with any METS element that supports an ADMID attribute. Technical metadata can be expressed according to many current technical description standards (such as MIX and textMD) or a locally produced XML schema.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="rightsMD" type="mdSecType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">
An intellectual property rights metadata element <rightsMD> records information about copyright and licensing pertaining to a component of the METS object. The <rightsMD> element conforms to same generic datatype as the <dmdSec>, <techMD>, <sourceMD> and <digiprovMD> elements, and supports the same sub-elements and attributes. A rights metadata element can either wrap the metadata (mdWrap) or reference it in an external location (mdRef) or both. METS allows multiple <rightsMD> elements; and rights metadata can be associated with any METS element that supports an ADMID attribute. Rights metadata can be expressed according current rights description standards (such as CopyrightMD and rightsDeclarationMD) or a locally produced XML schema.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="sourceMD" type="mdSecType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">
A source metadata element <sourceMD> records descriptive and administrative metadata about the source format or media of a component of the METS object such as a digital content file. It is often used for discovery, data administration or preservation of the digital object. The <sourceMD> element conforms to same generic datatype as the <dmdSec>, <techMD>, <rightsMD>, and <digiprovMD> elements, and supports the same sub-elements and attributes. A source metadata element can either wrap the metadata (mdWrap) or reference it in an external location (mdRef) or both. METS allows multiple <sourceMD> elements; and source metadata can be associated with any METS element that supports an ADMID attribute. Source metadata can be expressed according to current source description standards (such as PREMIS) or a locally produced XML schema.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="digiprovMD" type="mdSecType" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">
A digital provenance metadata element <digiprovMD> can be used to record any preservation-related actions taken on the various files which comprise a digital object (e.g., those subsequent to the initial digitization of the files such as transformation or migrations) or, in the case of born digital materials, the files’ creation. In short, digital provenance should be used to record information that allows both archival/library staff and scholars to understand what modifications have been made to a digital object and/or its constituent parts during its life cycle. This information can then be used to judge how those processes might have altered or corrupted the object’s ability to accurately represent the original item. One might, for example, record master derivative relationships and the process by which those derivations have been created. Or the <digiprovMD> element could contain information regarding the migration/transformation of a file from its original digitization (e.g., OCR, TEI, etc.,)to its current incarnation as a digital object (e.g., JPEG2000). The <digiprovMD> element conforms to same generic datatype as the <dmdSec>, <techMD>, <rightsMD>, and <sourceMD> elements, and supports the same sub-elements and attributes. A digital provenance metadata element can either wrap the metadata (mdWrap) or reference it in an external location (mdRef) or both. METS allows multiple <digiprovMD> elements; and digital provenance metadata can be associated with any METS element that supports an ADMID attribute. Digital provenance metadata can be expressed according to current digital provenance description standards (such as PREMIS) or a locally produced XML schema.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
<xsd:complexType name="fileGrpType">
<xsd:annotation>
<xsd:documentation xml:lang="en">fileGrpType: Complex Type for File Groups
The file group is used to cluster all of the digital files composing a digital library object in a hierarchical arrangement (fileGrp is recursively defined to enable the creation of the hierarchy). Any file group may contain zero or more file elements. File elements in turn can contain one or more FLocat elements (a pointer to a file containing content for this object) and/or a FContent element (the contents of the file, in either XML or Base64 encoding).
</xsd:documentation>
</xsd:annotation>
<xsd:choice>
<xsd:element name="fileGrp" type="fileGrpType" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="file" minOccurs="0" maxOccurs="unbounded" type="fileType" >
<xsd:annotation>
<xsd:documentation xml:lang="en">
The file element <file> provides access to the content files for the digital object being described by the METS document. A <file> element may contain one or more <FLocat> elements which provide pointers to a content file and/or a <FContent> element which wraps an encoded version of the file. Embedding files using <FContent> can be a valuable feature for exchanging digital objects between repositories or for archiving versions of digital objects for off-site storage. All <FLocat> and <FContent> elements should identify and/or contain identical copies of a single file. The <file> element is recursive, thus allowing sub-files or component files of a larger file to be listed in the inventory. Alternatively, by using the <stream> element, a smaller component of a file or of a related file can be placed within a <file> element. Finally, by using the <transformFile> element, it is possible to include within a <file> element a different version of a file that has undergone a transformation for some reason, such as format migration.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="VERSDATE" type="xsd:dateTime" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">VERSDATE (dateTime/O): An optional dateTime attribute specifying the date this version/fileGrp of the digital object was created.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="ADMID" type="xsd:IDREFS" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ADMID (IDREF/O): Contains the ID attribute values of the <techMD>, <sourceMD>, <rightsMD> and/or <digiprovMD> elements within the <amdSec> of the METS document applicable to all of the files in a particular file group. For more information on using METS IDREFS and IDREF type attributes for internal linking, see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="USE" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">USE (string/O): A tagging attribute to indicate the intended use of files within this file group (e.g., master, reference, thumbnails for image files). A USE attribute can be expressed at the<fileGrp> level, the <file> level, the <FLocat> level and/or the <FContent> level. A USE attribute value at the <fileGrp> level should pertain to all of the files in the <fileGrp>. A USE attribute at the <file> level should pertain to all copies of the file as represented by subsidiary <FLocat> and/or <FContent> elements. A USE attribute at the <FLocat> or <FContent> level pertains to the particular copy of the file that is either referenced (<FLocat>) or wrapped (<FContent>).
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
<xsd:complexType name="structMapType">
<xsd:annotation>
<xsd:documentation xml:lang="en">structMapType: Complex Type for Structural Maps
The structural map (structMap) outlines a hierarchical structure for the original object being encoded, using a series of nested div elements.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="div" type="divType">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The structural divisions of the hierarchical organization provided by a <structMap> are represented by division <div> elements, which can be nested to any depth. Each <div> element can represent either an intellectual (logical) division or a physical division. Every <div> node in the structural map hierarchy may be connected (via subsidiary <mptr> or <fptr> elements) to content files which represent that div's portion of the whole document.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="TYPE" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">TYPE (string/O): Identifies the type of structure represented by the <structMap>. For example, a <structMap> that represented a purely logical or intellectual structure could be assigned a TYPE value of “logical” whereas a <structMap> that represented a purely physical structure could be assigned a TYPE value of “physical”. However, the METS schema neither defines nor requires a common vocabulary for this attribute. A METS profile, however, may well constrain the values for the <structMap> TYPE.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="LABEL" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">LABEL (string/O): Describes the <structMap> to viewers of the METS document. This would be useful primarily where more than one <structMap> is provided for a single object. A descriptive LABEL value, in that case, could clarify to users the purpose of each of the available structMaps.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:anyAttribute namespace="##other" processContents="lax"/>
</xsd:complexType>
<xsd:complexType name="divType">
<xsd:annotation>
<xsd:documentation xml:lang="en">divType: Complex Type for Divisions
The METS standard represents a document structurally as a series of nested div elements, that is, as a hierarchy (e.g., a book, which is composed of chapters, which are composed of subchapters, which are composed of text). Every div node in the structural map hierarchy may be connected (via subsidiary mptr or fptr elements) to content files which represent that div's portion of the whole document.
SPECIAL NOTE REGARDING DIV ATTRIBUTE VALUES:
to clarify the differences between the ORDER, ORDERLABEL, and LABEL attributes for the <div> element, imagine a text with 10 roman numbered pages followed by 10 arabic numbered pages. Page iii would have an ORDER of "3", an ORDERLABEL of "iii" and a LABEL of "Page iii", while page 3 would have an ORDER of "13", an ORDERLABEL of "3" and a LABEL of "Page 3".
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="mptr" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">
Like the <fptr> element, the METS pointer element <mptr> represents digital content that manifests its parent <div> element. Unlike the <fptr>, which either directly or indirectly points to content represented in the <fileSec> of the parent METS document, the <mptr> element points to content represented by an external METS document. Thus, this element allows multiple discrete and separate METS documents to be organized at a higher level by a separate METS document. For example, METS documents representing the individual issues in the series of a journal could be grouped together and organized by a higher level METS document that represents the entire journal series. Each of the <div> elements in the <structMap> of the METS document representing the journal series would point to a METS document representing an issue. It would do so via a child <mptr> element. Thus the <mptr> element gives METS users considerable flexibility in managing the depth of the <structMap> hierarchy of individual METS documents. The <mptr> element points to an external METS document by means of an xlink:href attribute and associated XLink attributes.
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attributeGroup ref="LOCATION"/>
<xsd:attributeGroup ref="xlink:simpleLink"/>
<xsd:attribute name="CONTENTIDS" type="URIs" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">CONTENTIDS (URI/O): Content IDs for the content represented by the <mptr> (equivalent to DIDL DII or Digital Item Identifier, a unique external ID).
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="fptr" minOccurs="0" maxOccurs="unbounded">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The <fptr> or file pointer element represents digital content that manifests its parent <div> element. The content represented by an <fptr> element must consist of integral files or parts of files that are represented by <file> elements in the <fileSec>. Via its FILEID attribute, an <fptr> may point directly to a single integral <file> element that manifests a structural division. However, an <fptr> element may also govern an <area> element, a <par>, or a <seq> which in turn would point to the relevant file or files. A child <area> element can point to part of a <file> that manifests a division, while the <par> and <seq> elements can point to multiple files or parts of files that together manifest a division. More than one <fptr> element can be associated with a <div> element. Typically sibling <fptr> elements represent alternative versions, or manifestations, of the same content
</xsd:documentation>
</xsd:annotation>
<xsd:complexType>
<xsd:choice>
<xsd:element name="par" type="parType" minOccurs="0">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The <par> or parallel files element aggregates pointers to files, parts of files, and/or sequences of files or parts of files that must be played or displayed simultaneously to manifest a block of digital content represented by an <fptr> element. This might be the case, for example, with multi-media content, where a still image might have an accompanying audio track that comments on the still image. In this case, a <par> element would aggregate two <area> elements, one of which pointed to the image file and one of which pointed to the audio file that must be played in conjunction with the image. The <area> element associated with the image could be further qualified with SHAPE and COORDS attributes if only a portion of the image file was pertinent and the <area> element associated with the audio file could be further qualified with BETYPE, BEGIN, EXTTYPE, and EXTENT attributes if only a portion of the associated audio file should be played in conjunction with the image.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="seq" type="seqType" minOccurs="0">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The sequence of files element <seq> aggregates pointers to files, parts of files and/or parallel sets of files or parts of files that must be played or displayed sequentially to manifest a block of digital content. This might be the case, for example, if the parent <div> element represented a logical division, such as a diary entry, that spanned multiple pages of a diary and, hence, multiple page image files. In this case, a <seq> element would aggregate multiple, sequentially arranged <area> elements, each of which pointed to one of the image files that must be presented sequentially to manifest the entire diary entry. If the diary entry started in the middle of a page, then the first <area> element (representing the page on which the diary entry starts) might be further qualified, via its SHAPE and COORDS attributes, to specify the specific, pertinent area of the associated image file.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="area" type="areaType" minOccurs="0">
<xsd:annotation>
<xsd:documentation xml:lang="en">
The area element <area> typically points to content consisting of just a portion or area of a file represented by a <file> element in the <fileSec>. In some contexts, however, the <area> element can also point to content represented by an integral file. A single <area> element would appear as the direct child of a <fptr> element when only a portion of a <file>, rather than an integral <file>, manifested the digital content represented by the <fptr>. Multiple <area> elements would appear as the direct children of a <par> element or a <seq> element when multiple files or parts of files manifested the digital content represented by an <fptr> element. When used in the context of a <par> or <seq> element an <area> element can point either to an integral file or to a segment of a file as necessary.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:choice>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="FILEID" type="xsd:IDREF" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">FILEID (IDREF/O): An optional attribute that provides the XML ID identifying the <file> element that links to and/or contains the digital content represented by the <fptr>. A <fptr> element should only have a FILEID attribute value if it does not have a child <area>, <par> or <seq> element. If it has a child element, then the responsibility for pointing to the relevant content falls to this child element or its descendants.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="CONTENTIDS" type="URIs" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">CONTENTIDS (URI/O): Content IDs for the content represented by the <fptr> (equivalent to DIDL DII or Digital Item Identifier, a unique external ID).
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:anyAttribute namespace="##other" processContents="lax"></xsd:anyAttribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="div" type="divType" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attributeGroup ref="ORDERLABELS"/>
<xsd:attribute name="DMDID" type="xsd:IDREFS" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">DMDID (IDREFS/O): Contains the ID attribute values identifying the <dmdSec>, elements in the METS document that contain or link to descriptive metadata pertaining to the structural division represented by the current <div> element. For more information on using METS IDREFS and IDREF type attributes for internal linking, see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="ADMID" type="xsd:IDREFS" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ADMID (IDREFS/O): Contains the ID attribute values identifying the <rightsMD>, <sourceMD>, <techMD> and/or <digiprovMD> elements within the <amdSec> of the METS document that contain or link to administrative metadata pertaining to the structural division represented by the <div> element. Typically the <div> ADMID attribute would be used to identify the <rightsMD> element or elements that pertain to the <div>, but it could be used anytime there was a need to link a <div> with pertinent administrative metadata. For more information on using METS IDREFS and IDREF type attributes for internal linking, see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="TYPE" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">TYPE (string/O): An attribute that specifies the type of structural division that the <div> element represents. Possible <div> TYPE attribute values include: chapter, article, page, track, segment, section etc. METS places no constraints on the possible TYPE values. Suggestions for controlled vocabularies for TYPE may be found on the METS website.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="CONTENTIDS" type="URIs" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">CONTENTIDS (URI/O): Content IDs for the content represented by the <div> (equivalent to DIDL DII or Digital Item Identifier, a unique external ID).
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute ref="xlink:label">
<xsd:annotation>
<xsd:documentation xml:lang="en">xlink:label - an xlink label to be referred to by an smLink element</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
<xsd:complexType name="parType">
<xsd:annotation>
<xsd:documentation xml:lang="en">parType: Complex Type for Parallel Files
The <par> or parallel files element aggregates pointers to files, parts of files, and/or sequences of files or parts of files that must be played or displayed simultaneously to manifest a block of digital content represented by an <fptr> element.
</xsd:documentation>
</xsd:annotation>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="area" type="areaType" minOccurs="0"/>
<xsd:element name="seq" type="seqType" minOccurs="0"/>
</xsd:choice>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attributeGroup ref="ORDERLABELS"/>
<xsd:anyAttribute namespace="##other" processContents="lax"></xsd:anyAttribute>
</xsd:complexType>
<xsd:complexType name="seqType">
<xsd:annotation>
<xsd:documentation xml:lang="en">seqType: Complex Type for Sequences of Files
The seq element should be used to link a div to a set of content files when those files should be played/displayed sequentially to deliver content to a user. Individual <area> subelements within the seq element provide the links to the files or portions thereof.
</xsd:documentation>
</xsd:annotation>
<xsd:choice maxOccurs="unbounded">
<xsd:element name="area" type="areaType" minOccurs="0"/>
<xsd:element name="par" type="parType" minOccurs="0"/>
</xsd:choice>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attributeGroup ref="ORDERLABELS"/>
<xsd:anyAttribute namespace="##other" processContents="lax"></xsd:anyAttribute>
</xsd:complexType>
<xsd:complexType name="areaType">
<xsd:annotation>
<xsd:documentation xml:lang="en">areaType: Complex Type for Area Linking
The area element provides for more sophisticated linking between a div element and content files representing that div, be they text, image, audio, or video files. An area element can link a div to a point within a file, to a one-dimension segment of a file (e.g., text segment, image line, audio/video clip), or a two-dimensional section of a file (e.g, subsection of an image, or a subsection of the video display of a video file. The area element has no content; all information is recorded within its various attributes.
</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="ID" type="xsd:ID" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">ID (ID/O): This attribute uniquely identifies the element within the METS document, and would allow the element to be referenced unambiguously from another element or document via an IDREF or an XPTR. For more information on using ID attributes for internal and external linking see Chapter 4 of the METS Primer.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="FILEID" type="xsd:IDREF" use="required">
<xsd:annotation>
<xsd:documentation xml:lang="en">FILEID (IDREF/R): An attribute which provides the XML ID value that identifies the <file> element in the <fileSec> that then points to and/or contains the digital content represented by the <area> element. It must contain an ID value represented in an ID attribute associated with a <file> element in the <fileSec> element in the same METS document.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="SHAPE" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">SHAPE (string/O): An attribute that can be used as in HTML to define the shape of the relevant area within the content file pointed to by the <area> element. Typically this would be used with image content (still image or video frame) when only a portion of an integal image map pertains. If SHAPE is specified then COORDS must also be present. SHAPE should be used in conjunction with COORDS in the manner defined for the shape and coords attributes on an HTML4 <area> element. SHAPE must contain one of the following values:
RECT
CIRCLE
POLY
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="RECT"/>
<xsd:enumeration value="CIRCLE"/>
<xsd:enumeration value="POLY"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="COORDS" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">COORDS (string/O): Specifies the coordinates in an image map for the shape of the pertinent area as specified in the SHAPE attribute. While technically optional, SHAPE and COORDS must both appear together to define the relevant area of image content. COORDS should be used in conjunction with SHAPE in the manner defined for the COORDs and SHAPE attributes on an HTML4 <area> element. COORDS must be a comma delimited string of integer value pairs representing coordinates (plus radius in the case of CIRCLE) within an image map. Number of coordinates pairs depends on shape: RECT: x1, y1, x2, y2; CIRC: x1, y1; POLY: x1, y1, x2, y2, x3, y3 . . .
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="BEGIN" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">BEGIN (string/O): An attribute that specifies the point in the content file where the relevant section of content begins. It can be used in conjunction with either the END attribute or the EXTENT attribute as a means of defining the relevant portion of the referenced file precisely. It can only be interpreted meaningfully in conjunction with the BETYPE or EXTTYPE, which specify the kind of beginning/ending point values or beginning/extent values that are being used. The BEGIN attribute can be used with or without a companion END or EXTENT element. In this case, the end of the content file is assumed to be the end point.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="END" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">END (string/O): An attribute that specifies the point in the content file where the relevant section of content ends. It can only be interpreted meaningfully in conjunction with the BETYPE, which specifies the kind of ending point values being used. Typically the END attribute would only appear in conjunction with a BEGIN element.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="BETYPE" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">BETYPE: Begin/End Type.
BETYPE (string/O): An attribute that specifies the kind of BEGIN and/or END values that are being used. For example, if BYTE is specified, then the BEGIN and END point values represent the byte offsets into a file. If IDREF is specified, then the BEGIN element specifies the ID value that identifies the element in a structured text file where the relevant section of the file begins; and the END value (if present) would specify the ID value that identifies the element with which the relevant section of the file ends. Must be one of the following values:
BYTE
IDREF
SMIL
MIDI
SMPTE-25
SMPTE-24
SMPTE-DF30
SMPTE-NDF30
SMPTE-DF29.97
SMPTE-NDF29.97
TIME
TCF
XPTR
</xsd:documentation>
</xsd:annotation>
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="BYTE"/>
<xsd:enumeration value="IDREF"/>
<xsd:enumeration value="SMIL"/>
<xsd:enumeration value="MIDI"/>
<xsd:enumeration value="SMPTE-25"/>
<xsd:enumeration value="SMPTE-24"/>
<xsd:enumeration value="SMPTE-DF30"/>
<xsd:enumeration value="SMPTE-NDF30"/>
<xsd:enumeration value="SMPTE-DF29.97"/>
<xsd:enumeration value="SMPTE-NDF29.97"/>
<xsd:enumeration value="TIME"/>
<xsd:enumeration value="TCF"/>
<xsd:enumeration value="XPTR"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
<xsd:attribute name="EXTENT" type="xsd:string" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">EXTENT (string/O): An attribute that specifies the extent of the relevant section of the content file. Can only be interpreted meaningfully in conjunction with the EXTTYPE which specifies the kind of value that is being used. Typically the EXTENT attribute would only appear in conjunction with a BEGIN element and would not be used if the BEGIN point represents an IDREF.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="EXTTYPE" use="optional">
<xsd:annotation>
<xsd:documentation xml:lang="en">EXTTYPE (string/O): An attribute that specifies the kind of EXTENT values that are being used. For example if BYTE is specified then EXTENT would represent a byte count. If TIME is specified the EXTENT would represent a duration of time. EXTTYPE must be one of the following values:
BYTE
SMIL
MIDI
SMPTE-25
SMPTE-24
SMPTE-DF30