[Smwg] TGFT yellow book

Ciocirlan Claudia Claudia.Ciocirlan at cnes.fr
Fri Dec 22 14:38:49 UTC 2017

Dear all,

I know I am early on planning but I would like to propose you a first draft of the TGFT yellow book. It will be simpler to discuss over it in January.

*        I know it is not what we agreed on, but it is only a proposal for the cross validation. Maybe by seeing it on paper it makes more sense than explaining. This can easily be changed.

I have a couple of questions that my contractor mentioned and as I do not have the answer I am addressing his questions and remarks to you. As the comments address to various books and John example I rather prefer laying them in an email, but I can integrate them in the documents is needed.

Could it be possible to add this on the agenda of the 16th of January?

This schema is defined but it is not used in the example manifest sent by John. The standard XFDUschema is used instead. Is there any reason for this?
The value of this attribute of the volumeInfo element is declared fixed in the specification (section but not in the schema. It could be. The specificationVersion element shall have the value "1.0".
The specification (section requires a metadataReference element in a metadataObject, however this is declared in the schema with minOccurs="0".The metadataObject element shall contain a metadataReference element that identifies the location of the corresponding metadata file.
The specification (section requires a single byteStream element in a dataObject, however the schema specifies an unbounded number. The dataObject element shall contain one byteStream element.

Standard white book 927x1w0.02
PackageHeader ID (section
The remark below relates to the use of "shall" in the specification. Shall has a strong meaning as a conformance requirement. However in the cases below, this requirement may be changed by the TGFT-using services, and thus not respected. A different wording without shall would be preferable.
The ID attribute of the packageHeader element shall have the default value of "pkgHdr". However, TGFT-using service may define their own values for the ID attribute.

SequenceInformation (section
This is similar to the previous remark, with the use of a shall. The sequencePosition attribute shall contain the numerical position of the XFDU in the XFDU sequence. The semantics of this attribute are deferred to the specification of the service.
The sequenceSize attribute shall contain size of the XFDU sequence to which this SFDU belongs. The semantics of this attribute are deferred to the specification of the service.

A requirement in section 4.5.3 looks inconsistent with the rest of the document. The TGFT XFDU package shall contain one enclosed metadata files for every metadataObject element in the metadataSection of the XFDU manifest. A metadata file may not be included in the XFDU package (cf for example section

Naming rules
Inconsistencies exist in the naming rules (section 4.5.4.*) and their example usages (Annex E). In the annex the XFDU zip file is named dss_25_validated_tdm_xfdu_package-2017- 058T23-15-46Z.zip. When the timestamp part defined in is removed, the servicespecific part should remain as defined in 4.5.4. The service-specific part should then be dss_25_validated_tdm_xfdu_package- and not dss_25_validated_tdm_xfdu_package as shown in the example. Nothing is said in 4.5.4 about adding a dash in between.

Manifest file
Few rules apply to the naming of the XFDU manifest file. However, looking at the examples, I wonder if one rule could be added concerning the location of this file. I expected it to be found at the top level in the archive, however it has been set in the first level directory.

Annex E
The name of the file (dss_25_validated_tdm-2017-058T19-35-24Z.xml) does not conform to the naming rule in section 3.2.1. The upper case letters are forbidden. The Zulu time exception described in the specification only concerns the name of the archive itself, not the files inside it.
The reference to the file (href attribute) does not conform either to the specification as defined in section The Zulu time part of the archive name should be removed from the directory part of the href. The href attribute shall contain the URL of the file, which shall be of the form "file:"+<XFDU Package file name service-specific part> + "/" + <payload file name (with extension>

TGFT/XFDU manifest
XFDU version
The version attribute is declared while it should not be (cf section 4.2.3.b). The optional version attribute shall be absent when the XFDU schema defined in Issue 1 (September 2008) of reference [9] is used as the schema for TGFT XFDUs.

PackageHeader ID
This attribute is set to "PkgHdr" instead of "pckHdr" (cf section The ID attribute of the packageHeader element shall have the default value of "pkgHdr". However, TGFT-using service may define their own values for the ID attribute. File naming The file names include upper case letters which are forbidden by the specification (cf section 3.2.1). This remark may lead to reconsider this rule. One of the  files in the example package is the XSD schema. Its name is TGFTXFDUschema.xsd, and this name could/should be included in the xml files that conform to the schema. If we rename the file to tgft_xfdu_schema.xsd for example, to conform to the specification, then the XML file will loose its reference to its model.
Similar issues are very likely to occur in the TGFT use cases, as the example in Annex E shows. Are these issues been identified? Has a proper handling procedure been suggested?

The size attributes provided in the example do not match the actual size of the files as I see them on my PC (Windows). Is this just an update issue of the values, or is there something more?

Wish you all  Merry Christmas and a veyyrryyyy happpyyyy new year!

Best regards,

Claudia Ciocirlan CNES/DNO/OP/SSO
Mission Operations Ground Segment
phone : +33 (0)5 61 28 17 11
email : claudia.ciocirlan at cnes.fr<mailto:claudia.ciocirlan at cnes.fr>
P Save a tree ! Think before printing

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20171222/91a5ede9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 82594 bytes
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20171222/91a5ede9/attachment.docx>

More information about the SMWG mailing list