Sorry for the delay in responding to you, Saašha.

Thank you for your recommended corrections to the METS schema documentation.  We will make the recommended changes in the next (currently unscheduled) release of METS.

Your concerns regarding the use of "xmlData" were brought up on the list almost exactly 2 years ago, and were discussed by the METS Board. I quote my response to the list on behalf of the METS Board in full below:

Brian passed your note of concern regarding a possible violation of
the xml specification posed by the mets "xmlData" element on to the
full METS Editorial Board. The Board has reviewed the XML
specification requirements and at this point has no plans to rename
the element.  While it is true that passage you cite in the xml
specification suggests that names beginning with "xml" are reserved,
this guideline is qualified by the XML namespace recommendation which
states at

   Though they are not themselves reserved, it is inadvisable to use
prefixed names whose LocalPart begins with the letters x, m, l, in any
case combination, as these names would be reserved if used without a

While advising against the use of LocalPart names that begin with
"xml", this passage also clearly indicates that such names are not

Presumably the intent of the specifications requirements and advice in
this matter is to prevent the possibility of name conflicts between
names established by the XML standard and names established in local
applications of the standard.  However, especially since METS declares
a target namespace, and every mets element and attribute in an
instance document is governed by this namespace, we feel that the
likelihood of a conflict occurring with the "xmlData" element name is
extremely remote.  And because it is so remote, we cannot justify
making a non-backwards compatible change to the name of an element
that is already widely in use by the METS community. 
There are currently some preliminary discussions underway about a possible version 2 of the METS schema.  If a version 2 materializes, then it is likely that the Board may wish to reconsider the "xmlData" issue.  However, any change to "xmlData" would not be backwards compatible and could only be made in a version 2 of the schema.  The Board's thinking on the issue as stated above still holds at present.

Thanks again for your interest in and comments on METS.


Rick Beaubien
Technical Chair
METS Editorial Board

On 1/24/2011 6:26 PM, Saašha Metsärantala wrote:
[log in to unmask]" type="cite">Hello!

I noticed a few things about the mets XML Schema. I try to explain them below.

The xsd:sequence is a sequential model group. At the W3C, we can read the following explanation:

"(sequence) correspond, in order, to the specified {particles};"

But, the order in which the elements structLink and structMap occur in the xsd:documentation element within the xsd:annotation for the metsType declaration is not the same as that in which they occur in the schema. Both are in the file

Furthermore, in the same documentation line, the fileGrp element is described as a child of metsType, whereas in the schema it is a child to the fileSec element, that is a descendant of the metsType.

In the same file, I noticed something about the name of the element xmlData. According to the XML 1.0 specifications at the w3c,

"names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are reserved for standardization in this or future versions of this specification"

"Names beginning with the string "xml", or with any string which would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or future versions of this specification."

The same applies also for XML 1.1 at and

I wonder the reasons for choosing the element name "xmlData".