[Smwg] action item 2018-1211-01, Clarify constraints on presence of payload and metadata files in an XFDU packages

Fri Jan 18 18:15:38 UTC 2019

Hi, Serge. As Claudia may have already told you, the working group was made aware of your response only this past Tuesday (15 January) due a combination of an apparent failure of the mailing list submission approval mechanism, illness, and possibly the holidays. In any case, Claudia forwarded your comments to the WG on Tuesday and my responses to your comments are interleaved below in red. I have also uploaded an updated version of the book to the CWE at    https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Terrestrial%20Generic%20File%20Transfer/White%20Book/Drafts/927x01w0_09%20-%20Terrestrial%20Generic%20File%20Transfer%20-%20Working-JVP%2020190118.doc?Web=1

Note that I also fixed some cross references that had been broken (but overlooked until now) when the file-naming rules were restructured.

Please look through these responses and let me know if they satisfy your concerns.

Best regards,

John

From: Serge Lacourte <serge.lacourte at scalagent.com>
Sent: Tuesday, December 18, 2018 3:50 AM
To: CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>
Subject: Re: [Smwg] action item 2018-1211-01, Clarify constraints on presence of payload and metadata files in an XFDU packages

Hi everyone,

The change in section 4.2.6.3.1 makes sense. It will require changing the implementation and the related test.

The new requirements 4.5.4 and 4.5.5 remove the ambiguity that was raised about possible additional files in the package. 4.5.5 is actually more precise than 4.5.4, and I believe that 4.5.4 could be removed. In other words I cannot see a case where 4.5.5 would be respected and 4.5.4 would not be.

I think that you are correct about being able to delete 4.5.4 and just keep 4.5.5. For everyone else’s reference the two requirements in question are:

4.5.4. “Other than the XFDU Manifest file, the TGFT XFDU package shall not contain any files that do not have either (a) a corresponding dataObject element in the XFDU manifest or (b) a corresponding metadataObject element in the XFDU manifest for which the metadataReference element has an href value that begins “file:”.

and

4.5.5. “Other than the XFDU Manifest, each file in the TGFT XFDU package shall correspond to one and only one of either (a) a dataObject element in the XFDU manifest or (b) a metadataObject element in the XFDU manifest for which the metadataReference element has an href value that begins “file:”.

I cannot now see where a situation would exist in which an erroneous condition would “pass” 4.5.5 and only be caught by 4.5.4. I think that I was trying to tighten down the constraints from multiple directions and arrived at essentially-redundant requirements. So I am okay with deleting 4.5.4, and I have done so in the updated draft of the White Book.

The lesser issue of validating the assertions 4.2.7.1 and 4.2.8.1 is still unresolved. The definitions of payload data files and metadata files that John added are essentially subjective. A tool could not find a payload data file from a metadata file based on those definitions. Actually I know that a file from the XFDU package is a payload data file because it is described by a dataObject element. In other words 4.2.8.1 is more a definition than an assertion to be checked. So I would rephrase it as:
The dataObjectSection element contains dataObject elements which define and describe the payload data files in the XFDU Package.

I agree that as currently phrased 4.2.8.1 (and 4.2.7.1) cannot be objectively tested and/or enforced. However, there *is* a requirement (mandated by the schema itself) that the dataObjectSection contain at least dataObject element. So I propose to limit the mandatory statement to this structural aspect and turn the informative aspect into a following Note as follows:
4.2.8.1  The dataObjectSection element shall contain one or more dataObject elements.

NOTE - Each dataObject element defines and describes a payload data file in the XFDU Package.

[This approach also conforms with CCSDS’s publication style requirements, which restrict where and how information material may be interleaved within normative sections of the document.]

Similarly I have rewritten 4.2.7.1 as:

4.2.7.1  The metadataSection element shall contain zero or more metadataObject elements.

NOTE - Each metadataObject element defines and describes a metadata file that is associated with one or more of the payload data file(s) being transferred in the XFDU Package.

Is that acceptable to you?

The same holds for 4.2.7.1. I know that another file from the XFDU package is a metadata file because it is described by a metadataObject element. I would also rephrase it as:
The metadataSection element contains metadataObject elements which define and describe the metadata files associated with the payload data file(s) being transferred in the XFDU Package.
As a final remark, John introduced a new constraint in 1.5.2:
A metadata file may be contained within and XFDU Package only when it associated with one or more payload data files within that XFDU Package.
See above

I would recall it in a new assertion after 4.2.7.2.1.a:
This ID attribute shall be referred to from at least one anyMdID attribute in a contentUnit element.

Good catch! I have inserted a new bullet 4.2.7.2.1.b):

4.2.7.2.1.b) The ID attribute shall be referred to by at least one anyMdID attribute in a contentUnit element (see 4.2.6.3.1.e)) within the same XFDU Manifest.

Best regards

--

Serge Lacourte

Directeur general

ScalAgent Distributed Technologies SA

tel. +33 4 76 29 79 81

mobile. +33 6 86 47 41 06

www.scalagent.com<http://www.scalagent.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20190118/0a86ccd5/attachment-0001.html>