METS Documentation Errors List
hideMETS Primer and Reference Manual
| Description of Error, Question, or omission | Location | Date Noted | Contact email, for questions | Date Corrected |
| LABEL attribute described as "Is a simple a title string" | PDF, p. 15 | 15 Mar 2009 | yahoo for brettz9 | Issue not clear |
| "xmlns:xsi=”z:schemaLocation=”" in sample code at top of page non-well-formed XML | PDF, p. 17 | 15 Mar 2009 | yahoo for brettz9 | 2009-09-28 |
| Under the Attributes descriptions: Reference to "dateType" but not defined in document or used in schema (as opposed to dateTime which is built-in) | PDF, p. 17, 30 | 15 Mar 2009 | yahoo for brettz9 | Should be dateTime. Fixed 2009-09-28 |
| ALTERNATIVE IDENTIFIERS: "allows on to use" should be "allows one to use" | PDF, p. 18 | 15 Mar 2009 | yahoo for brettz9 | 2009-09-28 |
| DESCRIPTIVE METADATA ELEMENTS: "within the METS document point" needs a comma after "document" | PDF, p. 20 | 15 Mar 2009 | yahoo for brettz9 | 2009-09-28 |
| The page image information obscures or otherwise is different from the hidden text behind it. | Final Version PDF, pgs 23, 28, 36, 58 | 04 Feb 2008 | Robert_Scholes@brown.edu | |
| Under TECHNICAL METADATA, "by wrapping or referring" should be "by wrapping or referencing" | PDF, p. 24 | 15 Mar 2009 | yahoo for brettz9 | Not an issue in reworded documentation |
| "(e.g., OCR< TEI, etc.,)to needs a space and removal of comma | PDF, p. 26 | 15 Mar 2009 | yahoo for brettz9 | 2009-09-28 |
| Example 1 at top has "virsu" instead of "virus" inside <oclcprov:virsuCheckStatus> tag | PDF, p. 27 | 15 Mar 2009 | yahoo for brettz9 | 2009-09-28 |
| Example 2 has mismatch in capitalization with <ingestValidatorOutput> tag (others are capitalized, so it should be too) | PDF, p. 27 | 15 Mar 2009 | yahoo for brettz9 | 2009-09-28 |
| LOCTYPE is missing "URL" and "LOCATION" should not be there | PDF, p. 31 | 15 Mar 2009 | yahoo for brettz9 | 2009-09-28 |
| FILE CONTENT -- ATTRIBUTES ID is described as identifying "the internal encoding of the contents of the file" which seems incorrect | PDF, p. 32 | 15 Mar 2009 | yahoo for brettz9 | 2009-09-28 |
The following corrections need to be made to the coding example for FContent: 1) FContent is not an empty element, i.e., it should not have a forward slash at the end of the tag (line 12) 2) binData needs to be namespaced, i.e., mets:binData (line 13) |
PDF, p. 32 | 18 Mar 2009 |
Mark Jordan, |
2009-09-28 |
| OWNERID's description seems to me to need a bit more clarification (as it does on p. 30) as far as who determines the ID | PDF, p. 33 | 15 Mar 2009 | yahoo for brettz9 | current description seems adequate |
| The example has all three of the <mets:FLocat>'s LOCTYPE's followed by a URL without being in an attribute (presumably should be xlink:href) | PDF, p. 33 | 15 Mar 2009 | yahoo for brettz9 | 2009-09-28 |
| The <mets:stream> in the example has STREAMTYPE="XML_WAV" though the bulleted list above says it has an MP3 audio file | PDF, p. 33 | 15 Mar 2009 | yahoo for brettz9 | example doesn't seem to make sense and needs review. |
| Although the next section refers to IDREFs, I think it would be more clear if the sentence at the bottom of the page referring to "might provide a link" would indicate that this is with TRANSFORM-BEHAVIOR | PDF, p. 33 | 15 Mar 2009 | yahoo for brettz9 | I believe this is adequately clarified by the attribute description |
| <mets:transformFile> has text inside which needs to be escaped in a CDATA section (or use entities); the documentation also does not explain that such element text content is allowed for <mets:transformFile> and how it can be used | PDF, p. 34 | 15 Mar 2009 | yahoo for brettz9 | transformFile example in Primer shouldn't have content at all. Example corrected. |
| The very bottom of the page gives a sample hierarchy of book/chapter/page which raises the unanswered question to me of how things could be encoded if a chapter begins in the middle of a page (TEI might solve this hierarchical problem with next/prev attributes) | PDF, p. 37 | 15 Mar 2009 | yahoo for brettz9 | no change made. Can be done with <area> element and its attributes as is described later. |
| I think DMDID should say "identify the <dmdSec> or its sub-sections" (adding "its"); same with ADMID describing <amdSec/> | PDF, p. 38 | 15 Mar 2009 | yahoo for brettz9 | 2009-09-28 |
| Might mention be made under ORDER that lack of an ORDER attribute might or should be interpreted by processing applications as following document order | PDF, p. 38 | 15 Mar 2009 | yahoo for brettz9 | I don't think that METS can safely specify the meaning of an absent ORDER attribute. |
| On p. 39, 42, and 47 reference is made to DIDL DII, but it is only defined on p. 42. Add to glossary or define in each place? I think the description should also clarify whether this is just a generic term for external identifiers, or whether it must follow certain standard conventions | PDF, p. 39, 42, 47 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-01 Now defined in each location. |
| 2nd par from bottom says "all attributes supported...appear below." whereas it should be those that appear "above" | PDF, p. 39 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-02 |
| FILEID says "the responsibility for pointing to the relevant <file> elements falls to the descendants of the <fptr>, i.e., the <file> elements"; I think the "i.e.," portion is not correct or redundant | PDF, p. 42 | 15 Mar 2009 | yahoo for brettz9 | Already fixed in reworked documentation |
| The 2nd paragraph under METS POINTER refers to "section on external linking above" and "See chapter 4", though it seems to me the order of these should be switched, since it is FLocat that is described above and external linking in general discussed in Chapter 4. | PDF, p. 44 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-02 |
| I think OTHERLOCTYPE might clarify that it is strongly recommended when OTHER is used--just to be extra clear. | PDF, p. 44 | 15 Mar 2009 | yahoo for brettz9 | Already fixed in reworked documentation. |
| Under SHAPE, "integral" is misspelled as "intergal" | PDF, p. 46 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-02 |
| Under EXTTYPE, "byte count" is divided with multiple spaces apparently | PDF, p. 47 | 15 Mar 2009 | yahoo for brettz9 | OK in reworked documentation |
| Under PARALLEL FILES, mention is made of files that must be played or displayed simultaneously. How about "transformed", for example XSL (or would that be <seq/>)? | PDF, p. 50 | 15 Mar 2009 | yahoo for brettz9 | Don't understand objection. |
| Under Example 1, the text says: "The <structLink> element might contain <div> notation as follows for the two pages:" It appears to me, though, that the <div> elements should be within the <structMap> element. | Final version PDF, p. 55 | 02 Nov 2007 | Mike Pullin, mpullin@unt.edu |
2009-10-02 |
| xlink:label is incorrectly capitalized in the example code | PDF, p. 55 (2 times), 57 (6 times), | 15 Mar 2009 | yahoo for brettz9 | 2009-10-02 |
| The last line of the METS snippet below the sentence above is: <mets:div> fptr FILEID=....>. Is that not missing the first part of the <fptr> element? Maybe "<mets:fptr FILEID=....>"? | Final version PDF, p. 55 | 02 Nov 2007 | Mike Pullin, mpullin@unt.edu | 2009-10-02 |
| The chart has empty checkbox-type characters whose purpose seems unclear. | PDF p. 56 | 15 Mar 2009 | yahoo for brettz9 | I'm not clear on the meaning of these either |
| The 2nd to last smLink on the page should lead (as do the others) to an xlink:label="page113" instead of to an ID="page113" (2nd division from top of page) | PDF, p. 57 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-02. Also fixed incorrect XLINK:LABEL (->xlink:label) |
| End of beginning paragraph says "These behaviors may operate on any part of the METS document", but they seem confined to operate on the <structMap/> or <div/> level (the <area/> of file level might be nice). | PDF, p. 58 | 15 Mar 2009 | yahoo for brettz9 | Section reworded to reflect fact that a behavior can be applied to |
| Right before "ATTRIBUTES OF THE BEHAVIOR SECTION", says behaviorSec used to group individual behaviors by association with a <div/>, but <behaviorSec> itself does not possess STRUCTID | PDF, p. 58 | 15 Mar 2009 | yahoo for brettz9 | already fixed |
| ID attribute says XML ID is to allow for cases where <interfaceDef> can be obtained from <mechanism/>, but that section doesn't make clear whether the ID should be targeted by <mechanism>'s xlink:href, etc. | PDF, p. 59 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-02. Statement is incorrect as applied to the ID attribute. It's the <interfaceDef> itself that's optional for the stated reason. |
| First example specifies LOCTYPE as "URN", but the xlink:href is a URL. | PDF, p. 61 | 15 Mar 2009 | yahoo for brettz9 |
2009-10-02 |
| Second example has two STRUCTID's which point to "top", but neither the <structMap> nor <div> have that ID as the documentation for STRUCTID suggests it should be. Instead it is on <fptr/>'s FILEID; if that is allowed, the docs for STRUCTID ought to indicate so; Page 66 makes reference to the ID being on <div/> | PDF, p. 61 | 15 Mar 2009 | yahoo for brettz9 |
2009-10-02 |
| Says at the top "The XML ID, IDREF and IDREFS values are used to identify specific elements both internally as well as in external structured text documents.", which makes it seem like these can all refer also to external research papers and documents, whereas, IDREF is limited in XML to an XML Name (see http://www.w3.org/TR/xml11/#idref ) which would exclude URLs. Maybe the intention is just the mechanism of using FILEID to refer to an external file, but I think it would better to clarify here. | PDF, p. 62 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-02 |
| Context 4 states, "The <behaviorSec> in the example indicated that both the “disp1” and “auth1” behavior mechanisms should operate when the <div> element identified by the ID value “top” is activated..." I think ""The <behaviorSec> in the example indicated that..." (example on p. 61) is misleading as it seems like it is saying that the <behaviorSec/> tag had some attributes to point to "disp1" and "auth1" (instead of the fact that it is merely enclosing them) and that, as mentioned above, the STRUCTID attributes to the associating. I think dropping that portion or changing it to something like "The <behavior/> elements identified by "disp1" and "auth1" should have their mechanisms operate when..." would be more clear. | PDF, p. 66 | 15 Mar 2009 | yahoo for brettz9 | If I understand the point, I disagree with it. since "disp1" and "auth1" are the ID values that identify the <behavior> elements in question, I see no problem in referring them by the ID values. |
| The example section mentions that the <area/> associates the <div/> with the TEI element identified by the "ID attribute value 'entry1'" and ending with "the TEI element identified by the ID attribute value 'entry1end'". Now TEI is using xml:id, so maybe it should be clarified that that qualifies as an IDREF. | PDF, p. 67 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-02 |
| XPTR is misspelled as "XTPR" in the first paragraph of the section beginning "USE OF ID VALUES..." | PDF, p. 67 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-02 |
| The last line of the first complete paragraph has MDSECTYPE capitalized whereas it should be "mdSecType" | PDF, p. 68 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-11 |
| There is a space missing between LABEL and DMDID on the last nested div in the example | PDF, p. 70 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-11 |
| The closing tag </METS:METS> runs into the heading PROVISIONS FOR LINKING VIA XLINK ATTRIBUTES | PDF, p. 70 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-11 |
| METS <XMLDATA> ELEMENTS section has "namespace" misspelled as "namespaace" in the first sentence | PDF, p. 72 | 15 Mar 2009 | yahoo for brettz9 | 2009-10-11 |
| Explain what restrictions (if any) there are on XPTR schemes supported. | PDF, p.20 |
10 |
yahoo for brettz9 | 2009-10-11. Changed in description of the XPTR attribute in the mdRef element. Should probably also be changed in the schema. |
| Clarify the purpose/application of nested file element support. | PDF, p.29-30 | 10 June 2009 | yahoo for brettz9 | 2009-10-11 |
| Clarify when USE might be expressed at the fileGrp level, file level, and/or FLocat level. Give an example | 10 June 2009 | yahoo for brettz9 | Already done in revised documentation | |
| Explain what xlink:embed would mean in the context of a METS file. | PDF, p.44 | 10 June 2009` | yahoo for brettz9 | The meaning of xlink:embed is defined by xlink, and the meaning of it's use in a particular METS context would be application dependent. No change made. |
| Give an example of the use of both xlink:role and xlink:arcrole | 10 June 2009 | yahoo for brettz9 | same as above | |
| Several examples in the primer make an apparent reference to the file protocol in the xlink:href attribute. Is this appropriate and correct? | 10 June 2009 | yahoo for brettz9 | Needs discussion | |
| Clarify the documentation of mets/@OBJID clearly to indicate whether it pertains to the entire object represented by the METS document, or just to the METS document itself. Consensus seems to be for the former. |
14 |
rbeaubie@library.berkeley.edu | Already done |
METS Schema (Annotations within the Schema)
| Description of Error or Question | Location | Date Noted | Contact email, for questions | Date Corrected |
| In Element mdRef, 'MDTYPE: a required attribute specifying the yype of metadata being pointed at (e.g., MARC, EAD, etc.). It must have one of the following values:' 'yype' should be 'type | In Element mdRef, MDTYPE | 18 Feb 2008 | Wei Yang, yangwei95@gmail.com* | done |
| Revise mets/@OBJID attribute documentatioclearly to indicate whether it pertains to the entire object represented by the METS document, or just to the METS document itself. Consensus seems to be for the former. | mets | 14 July 2009 | rbeaubie@library.berkeley.edu | done |
METS Schema Documentation (HTML generated from the Schema)
| Description of Error or Question | Location | Date Noted | Contact email, for questions | Date Corrected |
