Updates for Rosetta METS XSD pertaining to multiple file IDs
We discovered that our initial METS file lacked unique file IDs in the structMaps for the preservation master and modified master representations because of a mistake in one of our input files that generates the METS during a recent batch of deposits (for more information, see case 00477041 from the Getty). Just the same file ID from the access file representation was being repeated.
For some reason, there was no METS validation error when we checked against the Rosetta XSD both before and after deposit. However, as a result, the structMaps with the duplicate file IDs did not list any files in the Rosetta METS. Each file was imported correctly since the fileIDs in the fileSec were legitimate; nevertheless.
Is it possible to tighten the METS XSD to mandate that each structMap's file ID be distinct? If the XSD implemented the rule that using the same file ID across different representations with the same structMap type is against Rosetta's data model, it would make sense.
67 clicker,
Emily Jensen
shared this idea
-
Sultan Ali commented
This behavior is expected because the current Rosetta METS XSD does not enforce uniqueness of fileID values across different structMap sections — it only validates syntax and structural compliance, not logical data relationships. In other words, the XSD ensures the XML is well-formed and adheres to the defined schema, but it doesn’t validate whether each fileID is distinct across representations.
To achieve the type of validation you’re describing (ensuring that each fileID within or across structMaps is unique), you’d need to implement a custom validation layer outside of Rosetta’s standard XSD validation. This could be done by:
Writing a custom pre-ingest script or transformation to detect and flag duplicate file IDs before deposit.
Using an XML validation tool (like Schematron) in addition to the XSD, which allows rule-based validation — for example, asserting that no duplicate fileID values exist within a given METS document.
Currently, the Rosetta product’s data model assumes that fileID uniqueness is handled upstream, during the METS generation process. The lack of an XSD validation error in your case is consistent with that design.
If you believe this should be enforced natively, it might be worth submitting a feature request to Ex Libris for future versions of Rosetta, asking them to consider adding stricter validation or a configuration option for enforcing fileID uniqueness within structMaps.
https://sites.google.com/view/mileswest/home
https://docs.google.com/document/d/e/2PACX-1vQwegAah8waLvlpuB9CzjXOy7XmqfIfyT3Ev6lVp1s1-mOqo09H7soqVU9ogbXv8d3JuKNpfhj9sNP3/pub
https://docs.google.com/spreadsheets/d/1iLoKss81kifsLMs2J_xe0-Bs-Gu1M-DAft_gUtHWZfk/edit?pli=1&gid=0#gid=0