Perfil METS Docuten eArchiving v1.0

METS Profile Docuten eArchiving v1.0

1. Propósito / Purpose

Este perfil extiende el estándar E-ARK CSIP v2.2 con restricciones adicionales específicas del servicio Docuten eArchiving. Es el documento normativo que los ficheros METS.xml generados por el sistema deben cumplir.

Corrección (D-06, fase 05.1.1). Este documento afirmaba que el atributo PROFILE de cada METS.xml producido por el sistema referencia la URI de este perfil. Era incompatible con la conformidad oficial: el schematron de CSIP exige en mets/@PROFILE la URL del perfil METS del estándar, y un valor propio hace que el paquete sea rechazado (requisito SIP2/su equivalente AIP). Se resuelve a favor de la conformidad oficial, que es el core value del producto:

• mets/@PROFILE = https://earkaip.dilcis.eu/profile/E-ARK-AIP-v2-2-0.xml (valor normativo, emitido por EARKAIP de commons-ip2).
• Este perfil propio sigue siendo normativo como documento — las elevaciones MAY/SHOULD→MUST de §2 y §3 siguen vigentes y son exigibles —, pero se referencia por otra vía (related_profile, esta tabla y el docs/governance/mets-profile.xml), no por mets/@PROFILE.
• Declarar además el perfil propio dentro del METS (p. ej. metsHdr/altRecordID) para que el AIP siga siendo autodescriptivo respecto a esas elevaciones queda como trabajo futuro explícitamente no descartado; requiere validar la construcción elegida contra el schematron.

This profile extends the E-ARK CSIP v2.2 standard with additional restrictions specific to the Docuten eArchiving service. It is the normative document that all METS.xml files generated by the system must comply with.

Correction (D-06, phase 05.1.1).* This document used to state that the PROFILE attribute of each METS.xml produced by the system references this profile's URI. That was incompatible with official conformance: the CSIP schematron requires mets/@PROFILE to hold the URL of the standard's METS profile, and a proprietary value causes the package to be rejected. Resolved in favour of official conformance: mets/@PROFILE = https://earkaip.dilcis.eu/profile/E-ARK-AIP-v2-2-0.xml (normative value). This profile remains normative as a document* — its MAY/SHOULD→MUST elevations in §2 and §3 still apply — but is referenced by other means (related_profile, the metadata table above and docs/governance/mets-profile.xml), not through mets/@PROFILE. Declaring the proprietary profile inside the METS (e.g. metsHdr/altRecordID) remains explicitly-not-discarded future work.

2. Estructura de carpetas requerida / Required folder structure

* Elevado a MUST por DOCUTEN-EARK-STR-01 (ver §3) ** Elevado a MUST por DOCUTEN-EARK-STR-02 (ver §3); aplica a paquetes AIP únicamente *** Elevado a MUST por DOCUTEN-EARK-STR-03 (ver §3); aplica a paquetes AIP únicamente **** Elevado a MUST por DOCUTEN-EARK-STR-04 (ver §3); aplica a paquetes AIP únicamente

3. Requisitos propios / Project-specific requirements

3.1 Elevaciones de nivel / Level elevations

DOCUTEN-EARK-STR-01 — /metadata/ obligatoria

Justificación técnica: La carpeta /metadata/ DEBE estar presente en todos los paquetes de información. Elevación de SHOULD a MUST por decisión de diseño interna. Motivación: simplificación operativa y validación determinista. La ausencia de /metadata/ impide la localización unívoca de metadatos por herramientas automatizadas, introduciendo variabilidad incompatible con los requisitos de auditoría QTSP.

Technical justification: The /metadata/ folder MUST be present in all information packages. Elevated from SHOULD to MUST by internal design decision. Rationale: operational simplification and deterministic validation. The absence of /metadata/ prevents unambiguous location of metadata by automated tools, introducing variability incompatible with QTSP audit requirements.

Evidencia de implementación: earchiving-core/src/main/java/com/docuten/earchiving/core/pack/PackageGenerator.java — Files.createDirectories(root.resolve("metadata")) se invoca en todas las rutas de creación de paquetes sin condición.

DOCUTEN-EARK-STR-02 — /metadata/preservation/ con PREMIS 3.0 obligatoria

Justificación técnica: La subcarpeta /metadata/preservation/ con metadatos PREMIS 3.0 DEBE estar presente en todos los paquetes AIP. Elevación de MAY a MUST por decisión de diseño interna. Motivación: trazabilidad eIDAS 2.0 (Art. 45j Reg. (UE) 2024/1183) y cadena de custodia. Los metadatos PREMIS en /metadata/preservation/ son la única fuente verificable de los eventos de preservación (ingesta, cálculo de integridad, acceso) que exige la normativa de archivado electrónico cualificado.

Technical justification: The /metadata/preservation/ subfolder containing PREMIS 3.0 metadata MUST be present in all AIP packages. Elevated from MAY to MUST by internal design decision. Rationale: eIDAS 2.0 Art. 45j traceability and chain of custody requirements. PREMIS events in /metadata/preservation/ are the only verifiable source of preservation events (ingestion, integrity calculation, access) required by qualified electronic archiving regulations.

Evidencia de implementación: earchiving-core/src/main/java/com/docuten/earchiving/core/pack/PackageGenerator.java + earchiving-core/src/main/java/com/docuten/earchiving/core/premis/PremisLibrary.java — PremisLibrary genera el PREMIS.xml por representación; PackageGenerator lo escribe en /metadata/preservation/ como parte del ciclo de empaquetado de AIPs.

DOCUTEN-EARK-STR-03 — /representations/ con al menos una representación

Justificación técnica: La carpeta /representations/ DEBE contener al menos una representación en todos los paquetes AIP. Elevación de SHOULD a MUST por decisión de diseño interna. Motivación: un AIP sin al menos una representación no puede satisfacer los requisitos de preservación, ya que la representación es el contenido que se preserva. Un paquete de preservación vacío no tiene valor archivístico ni legal.

Technical justification: The /representations/ folder with at least one representation MUST be present in all AIP packages. Elevated from SHOULD to MUST by internal design decision. Rationale: an AIP without at least one representation cannot satisfy preservation requirements, as the representation is the content being preserved. An empty preservation package has no archival or legal value.

Evidencia de implementación: earchiving-core/src/main/java/com/docuten/earchiving/core/pack/PackageGenerator.java — AipDescriptor.Builder.build() valida explícitamente que representations no está vacío antes de permitir la creación del paquete; lanza excepción si no hay representaciones.

DOCUTEN-EARK-STR-04 — /schemas/ con la clausura transitiva de los XSD

Procedencia de la base CSIP, para que nadie tenga que re-derivarla. CSIPSTR15 es el requisito estructural que gobierna la carpeta schemas/: «We recommend including all XML schema documents for any structured metadata within package. These schema documents SHOULD be placed in a sub-folder called schemas within the Information Package root folder and/or the representation folder», nivel SHOULD. Verificado contra la dependencia pineada del propio proyecto —org.roda-community:commons-ip2:2.11.2, clase org.roda_project.commons_ip2.validator.constants220.ConstantsCSIPspec, constantes VALIDATION_REPORT_SPECIFICATION_CSIPSTR15_DESCRIPTION y ..._LEVEL—, cuyo paquete constants220 es el juego de CSIP v2.2.0, la versión que este proyecto declara en producción. Se descartó CSIPSTR8 explícitamente: es «If any other metadata are available, they MAY be included in separate sub-folders, for example an additional folder named other», nivel MAY, y no habla de schemas/. El RELATEDMAT de mets-profile.xml cita el mismo CSIPSTR15; que los dos ficheros coincidan lo vigila MetsProfileRequirementParityTest.

Criterio. /schemas/ transporta la clausura transitiva de los XSD necesarios para validar los ficheros XML del paquete sin acceso a red. Es decir: no solo los esquemas que el xsi:schemaLocation del METS.xml referencia, sino también aquellos de los que estos dependen por <xs:import>, recursivamente, hasta cerrar la cadena.

Criterion: /schemas/ carries the transitive closure of the XSDs required to validate the package's XML files without network access — not merely the schemas referenced by the METS.xml's xsi:schemaLocation, but also those they depend on via <xs:import>, recursively.

Por qué no basta el criterio anterior. Hasta la Phase 05.3 el criterio era «los esquemas que el xsi:schemaLocation del METS referencia siempre». El dc.xml que genera este producto no lleva ningún xsi:schemaLocation, de modo que bajo aquel criterio no calificaba ni siquiera su propio oai_dc.xsd: el único XML del paquete con metadatos del cliente se quedaba sin esquema con el que validarse. El criterio de clausura transitiva lo resuelve y, de paso, hace el paquete autosuficiente para un validador offline.

Contenido actual (7 ficheros). Cuatro del estándar E-ARK/METS (DILCISExtensionMETS.xsd, DILCISExtensionSIPMETS.xsd, mets1_12.xsd, xlink.xsd) y tres de la cadena Dublin Core: oai_dc.xsd → simpledc20021212.xsd → xml.xsd. Todos con su fixity SHA-256 declarada en el METS.xml.

Nota para el auditor / Note for auditors. El xml.xsd empaquetado conserva intacto su DOCTYPE oficial (<!DOCTYPE xs:schema PUBLIC "-//W3C//DTD XMLSCHEMA 200102//EN" "XMLSchema.dtd">), tal y como lo publica el W3C. En consecuencia, un validador externo y offline que corra con load-external-dtd habilitado (el valor por defecto de Xerces) intentará resolver esa XMLSchema.dtd y no la encontrará dentro del paquete: deberá deshabilitar esa opción o aportar la DTD por su cuenta. No es un requisito de la validación XSD —las herramientas estándar omiten ese DOCTYPE sin incidencias, y un validador con red lo resuelve solo—, pero se documenta aquí para que nadie tenga que descubrirlo a ciegas. Las DTD se dejan deliberadamente fuera del paquete: la necesidad de una copia local es una propiedad de los validadores endurecidos, no del paquete.

The bundled xml.xsd keeps its official DOCTYPE intact. An external offline validator running with load-external-dtd enabled (Xerces' default) will try to resolve XMLSchema.dtd and will not find it inside the package: it must either disable that option or supply the DTD itself. This is not an XSD-validation requirement — standard tooling skips it — but it is documented so nobody has to discover it blind.

Evidencia de implementación: earchiving-core/src/main/java/com/docuten/earchiving/core/metadata/DublinCoreSchemaValidator.java — declara la cadena transitiva y la resuelve 100% del classpath; InformationPackageCreatedTaskletTest#aipBundlesTheThreeDublinCoreSchemasVerbatimWithRealFixity abre el ZIP del AIP construido y comprueba, byte a byte, que schemas/ transporta las 7 entradas con su SHA-256 real declarado en el METS — no los tamaños, los bytes.

3.2 Restricciones criptográficas / Cryptographic restrictions

DOCUTEN-EARK-CRYPTO-01 — SHA-256 obligatorio para fixity

Justificación técnica: Todos los checksums de integridad (atributo CHECKSUM en la fileSec del METS) DEBEN usar el algoritmo SHA-256. SHA-512 está permitido como alternativa de mayor seguridad. SHA-384, MD5 y SHA-1 están PROHIBIDOS para cualquier uso de fixity. Esta restricción es irrevocable y aplica globalmente a todos los paquetes del sistema.

Este requisito es la aplicación a la fixity del METS de la política criptográfica de Docuten eArchiving, publicada en https://docs.docuten.com/earchiving/crypto-policy/v1 (documento docs/governance/crypto-policy-v1.md). Esa política es la fuente única: fija su alcance —todo uso con valor probatorio, no solo la fixity— y contiene la tabla de contraste con ACM-ECCG, la referencia que designa el anexo del Reg. de Ejecución (UE) 2025/2532. Este perfil no duplica su texto.

Technical justification: All file fixity checksums (CHECKSUM attribute in METS fileSec) MUST use SHA-256 algorithm. SHA-512 is permitted as a higher-security alternative. SHA-384, MD5, and SHA-1 are PROHIBITED for any fixity use. This restriction is irrevocable and applies globally to all system packages.

This requirement applies to METS fixity the Docuten eArchiving cryptographic policy, published at https://docs.docuten.com/earchiving/crypto-policy/v1 (document docs/governance/crypto-policy-v1.md). That policy is the single source: it sets its scope — every use with evidentiary value, not only fixity — and holds the comparison table against ACM-ECCG, the reference designated by the annex of Implementing Regulation (EU) 2025/2532. This profile does not duplicate its text.

Evidencia de implementación: earchiving-core/src/main/java/com/docuten/earchiving/core/pack/PackageGenerator.java — MessageDigest.getInstance("SHA-256") es la única instancia de cálculo de checksum en el motor de empaquetado; no existe código que instancie MD5, SHA-1 o SHA-384.

3.3 Clasificación de los metadatos del AIP / AIP metadata classification (EVID-10)

Origen. REQ-9.3-02 de CEN/TS 18170 —citado a través del Excel de Umbus, porque la norma de pago no se ha adquirido— dice que otros metadatos pueden categorizarse en una de tres familias amplias: «descriptivos», «administrativos» o «técnicos», y pone como ejemplo de metadato técnico el MIME type de un fichero. Este perfil usa exactamente ese vocabulario (D-18) y no introduce ninguna otra etiqueta de familia. La clasificación no es un requisito nuevo: describe dónde está cada familia en el AIP que el sistema ya genera, para que un auditor sepa dónde mirar.

Origin. REQ-9.3-02 of CEN/TS 18170 — quoted through the Umbus spreadsheet, because the paid standard has not been purchased — states that other metadata may be categorised into one of three broad families: "descriptive", "administrative" or "technical", giving a file's MIME type as an example of technical metadata. This profile uses exactly that vocabulary (D-18) and introduces no other family label. The classification is not a new requirement: it describes where each family sits in the AIP the system already produces, so an auditor knows where to look.

Una familia por fila. Las rutas y las secciones METS están verificadas contra docs/governance/sip-aip-inventory-rules-v1.md (§3 y §6) y contra InformationPackageCreatedTasklet (PRESERVATION_REFS, que fija los ID digiprov-1 a digiprov-4).

La metadata de representación del productor (representations/<r>/metadata/**, INV-R06) llega al AIP byte a byte y se clasifica por la subcarpeta CSIP en la que la depositó el productor: descriptive como descriptivo, technical como técnico, y preservation, source y rights como administrativo.

One family per row; paths and METS sections verified against the inventory rules (§3, §6) and the InformationPackageCreatedTasklet. Descriptive: dc.xml and the producer's metadata/other. Technical: the PREMIS objects (format with PUID, size, fixity), schemas/** and the METS files themselves — the last one is a Docuten interpretation, since the paid standard has not been purchased and the structMap has no family of its own in the standard's vocabulary. Administrative: PREMIS events, agents and rights, the origin attestation, the DSS report, the AIP timestamp, the producer's preservation metadata and documentation/package-profile.xml. representations/<r>/data/** is the content, not metadata. Producer representation metadata is classified by its CSIP sub-folder.

Hueco declarado, no cerrado (B-04). Queda fuera el contenido administrativo que depende del acuerdo de depósito. Hoy PremisRights lleva por defecto la base «contrato de servicio», que es declarativa (docs/governance/service-conditions-v1.md §3); el acuerdo de depósito como fuente de los «derechos de acceso» llegará con B-04. Esta clasificación sitúa los derechos en la familia administrativa, pero no cierra ese hueco.

Declared gap, not closed (B-04). Administrative content that depends on the deposit agreement is out of scope. PremisRights currently carries the default basis "contrato de servicio" (service contract), which is declarative (service-conditions-v1.md §3); the deposit agreement as the source of "access rights" arrives with B-04. This classification places rights in the administrative family but does not close that gap.

4. Artefacto XML / XML artifact

El fichero docs/governance/mets-profile.xml es el perfil formal conforme al schema LoC METS Profile v2, referenceable desde el atributo PROFILE del METS.xml de cada paquete generado por el sistema.

The file docs/governance/mets-profile.xml is the formal profile conforming to the LoC METS Profile v2 schema, referenceable from the PROFILE attribute of each package's METS.xml file generated by the system.

URI del perfil / Profile URI: https://docs.docuten.com/earchiving/mets-profile/v1 (identificador estable en el dominio de los perfiles de eArchiving, docs.docuten.com. PRE-07 lo publica en esa dirección y la resolución la confirma DevOps; el estado de cada URI consta en docs/governance/published-uris.md. Ningún consumidor debe depender de que resuelva para validar un paquete, y no es el valor de mets/@PROFILE — ver §1. Alineado en la fase 06.3, cierra DI-05.4-05. Es la URI que cita el elemento metsProfile del package profile de cada AIP.)

(Stable identifier. PRE-07 publishes it at that address and DevOps confirms that it resolves; the status of each URI is recorded in docs/governance/published-uris.md. No consumer may depend on it resolving in order to validate a package, and it is not the value of mets/@PROFILE.)

El XML se encuentra en estado provisional (STATUS="provisional", REGISTRATION="unregistered") hasta que DevOps confirme la resolución de la URI y el servicio esté en producción.

The XML remains provisional until DevOps confirms that the URI resolves and the service is in production.

5. Historial de cambios / Change history