LTDP SAFE

GMV S.A.U.

During the SRR process it was decided to identify possible standard alternatives to XFDU for data packaging to be used in SAFE. This alternative would be adopted just in case it is identified a clear benefit in any of the proposed candidates.

The attached document “Data Packaging Formats Trade-off” (PDGS-SAFE-GMV-TN-12-0073) provides the analysis and conclusions reached on this topic. This document reveals that there are no substantial improvements on adopting a different alternative to XFDU. Therefore it is still recommended to use the same standard (XFDU) for the new SAFE format specification.

Current topic discussion and the analysis included in the attached document are devoted to reach a consensus before the PDR-C because the final solution may imply a change in the format design that has to be considered for the SAFE Core Specification update.

All your comments will be appreciated.

Adrián Sanz (GMV)
LTDP SAFE Project Manager

GMV S.A.U.

Some feedback has been provided by Stephan Zinke (EUMETSAT Panel member) supporting the conclusions provided by GMV.

The attached memorandum includes additional details.

Hi Adrián,

From my side, I fully endorse your conclusions for this trade-off.

Just a few comments without an impact on the overall conclusion:

- I think the standardisation aspect could be more detailed rather than just attributing 3 points for standardised languages and 0 for those not standardised. In particular, the body which has standardised a language is important and I think it's a bit unfair to XFDU to be considered at the same level as METS in this regard, because the former is an ISO standard while the latter is a U.S. (non-European, single nation) standard. SAFE is for Europe and this is an ESA project, so this is relevant.

- The open-source aspect is over-simplified, on the one hand because open-source and free are different things and one does not imply the other, and there are also two types of free (gratis/beer vs. libero/libre/freedom); on the other hand because the licensing issue is also separate. Different licenses (which can be free, open-source, both or none) will allow you to do different things. A more exhaustive analysis (outside our scope) would be necessary to examine the licensing for each language and the corresponding materials.

- I am slightly worried about the complexity you identify in XFDU especially when compared to METS. Complexity is not something desirable here and it will hinder acceptance of the standard. For this reason, METS seemed to be a decent candidate, although the objection in my first point remains and in any case I don't think it would be wise to depart from XFDU at this stage.

Maria de los Angeles Dominguez Duran

Dear Adrian and Hector,

We agree the analysis and conclusions reached in doc 0073 and also Paulo’s comments about it. We think that on an equal basis, it would not be wise to start a new solution. Besides this, XFDU is standardized by the CCSDS and it is fully OAIS compliant while METS is standardized by the U.S. Library of Congress.

A bit out of this scope, do not forget to take into account that the formatted manifest should avoid contents like a detail of the tie-points of the full pass as it is the case for NOAA and SeaWiFS specializations.