On Monday, May 5, 2014, Colin Gross <[log in to unmask]> wrote:
The METS schema itself does not appear to disallow replicate xlink:href values.  The sample provided appears to be valid as each entry has a unique ID.  However, it appears to violate the intent of the fileSec as it is described:

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.

I would not expect a parser that validates using the schema to flag this as an error.  It is syntactically and structurally correct according to the schema.  

However, this does look like a logical error.  Having multiple entries for the same item in an inventory is generally a bad plan.  This would be the sort of error that a purpose build validator for your profile could be designed to flag.

/* Colin Gross
 * Application Programmer
 * Digital Library Production Service
 * University of Michigan Library

On Mon, May 5, 2014 at 12:23 PM, Lydia Motyka <[log in to unmask]');" target="_blank">[log in to unmask]> wrote:

We’ve encountered a situation in METS files that passes validation against the METS schema but perhaps shouldn’t:  METS files that contain duplicate FLocat elements.  In other words, multiple FLocat elements within a fileSec that refer to the same file.  For example:



<METS:fileGrp USE="archive" >

<METS:file GROUPID="G1" ID="TIF1" MIMETYPE="image/tiff">

<METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="1.tif" />


<METS:file GROUPID="G1" ID="TIF1.2" MIMETYPE="image/tiff">

<METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="1.tif" />


<METS:file GROUPID="G1" ID="TIF1.3" MIMETYPE="image/tiff">

<METS:FLocat LOCTYPE="OTHER" OTHERLOCTYPE="SYSTEM" xlink:href="1.tif" />




Shouldn’t this be considered invalid METS?