[Smwg] TGFT file naming inconsistency
john.pietras at gst.com
Mon Apr 2 13:56:35 UTC 2018
Again, thank you for discovering these inconsistencies and errors. Even though you used W-0.02 as your reference, they still exist in W-0.03.
1. Regarding the inconsistencies between the original package name part and the use of that name in the “path” names for the files contained within the XFDU Packages, what you have pointed out is there are really *three* components of the name of a transferred XFDU Package file name:
a. What I will call (at least for now) the package folder name;
b. The compressed folder file extension type; and
c. The timestamp part.
The package folder name is the name of the folder (subdirectory) that contains all of the files contained within the XFDU Package: the manifest file, any payload data files, and any contained metadata files. The compressed folder file extension type is the extension that specifies which compression method (“.zip” or “.tar”) has been used to compress the folder into a single file for transmission. package_folder_name.compressed_folder_file_extension_type is what is currently called the “original package name part”, and is a legitimate file name on its own. The timestamp part is as it is currently defined.
In forming the “path” names for the files contained within the XFDU Packages, it is just the package folder names that are used, not the (larger) original package name part.
There are two different ways that I can write this up:
(1) As three parts from the start (package folder name, compressed folder file extension type and timestamp part), or
(2) As the (current) two parts (original package name part and timestamp part) and subsequently further break done the original package name part into the package folder name, compressed folder file extension type subparts. I’d like to discuss this at the meeting next week to see what approach seems to make more sense and is easier to understand.
Also, at one point there was some question as to whether putting the time of transmission timestamps on as suffixes to the (compressed folder) file names was the best approach. Have we resolved those issues? Again, a topic for discussion next week.
2. Regarding the varying names in the example in Annex E – yes, there are inconsistencies that must be corrected. The ones that you point out were the result of my changing the timestamp for the TDM file from CSDS time code B to xsd:datetime format but not propagating the change throughout the example (2017-058 and 2017-02-27 are both 27 Feb 2017). I also got the name of the as-transferred XFDU Package file name wrong, with the “.zip” extension at the end rather than before the timestamp part. These will all be corrected.
From: Ciocirlan Claudia [mailto:Claudia.Ciocirlan at cnes.fr]
Sent: Tuesday, March 20, 2018 2:17 AM
To: John Pietras <john.pietras at gst.com>; Colin Haddow/esoc/ESA <Colin.Haddow at esa.int>; CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>
Subject: [Smwg] TGFT file naming inconsistency
It seems that there is still an inconsistency remaining in the white book concerning the file names. My reference is CCSDS 927.1-W-0.02-JVP-rev2-180129.
In the example in Annex E, the XFDU package file is named dss_25_validated_tdm_xfdu_package.zip-2017-058T23-15-46Z.
According to section 18.104.22.168, the "original package name part" is then dss_25_validated_tdm_xfdu_package.zip, excluding the hyphen and the timestamp part.
* Note that the "original package name part" includes the file_type suffix .zip, as it is confirmed in section 22.214.171.124.1.1.
In the example again the data file (TDM file) is named dss_25_validated_tdm-201702-27T19-35-24Z.xml.
According to section 126.96.36.199.1, the href describing this data file should be: “file:”+<XFDU Package original package name part> + ”/” + <payload file name (with extension)>, that is file:dss_25_validated_tdm_xfdu_package.zip/dss_25_validated_tdm-201702-27T19-35-24Z.xml
However it is set to file:dss_25_validated_tdm_xfdu_package/dss_25_validated_tdm-2017-058T19-35-24Z.xml.
* the .zip part has been removed, which is natural but not conform to the specification.
* the timestamp part of the data file differs from what was stated before
There is also another error in the expanded manifest below (table E-1), where the href is set to file:dss_25_validated_tdm_xfdu_package-2017-058T23-15-46Z/dss_25_validated_tdm-2017-02-27T19-35-24Z.
What is the correct way to use it ? I am sorry I haven’t noticed this before.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SMWG