[Smwg] TGFT yellow book

Wed Jan 3 17:03:47 UTC 2018

All,
I am working through Claudia's comments (at least, those that pertain to the XFDU) and will have some responses before the WebEx on the 16th.

John

From: Barkley, Erik J (3970) [mailto:erik.j.barkley at jpl.nasa.gov]
Sent: Tuesday, January 02, 2018 5:55 PM
To: Ciocirlan Claudia; Colin.Haddow at esa.int; John Pietras
Cc: CCSDS Service Mgmt WG
Subject: RE: TGFT yellow book

Bonjour Claudia et Bonne Année!,

It seems like you have a good set of questions.  I think we can put this on the agenda for the webex of  January 16th.   It strikes me that the bulk of the questions are best addressed by either John or Colin.

With regard to the draft test plan/report, it looks to be off to a very good start.   My sense is that its best to prioritize addressing the question over reviewing the test plan at the webex.  With regard to the test plan I have two suuggestions:

1)      if we plan to use a CCSDS defined data format standards that we indicate that - for example, perhaps the NW utilization schedule could via SSF (Simple Schedule Format), and/or the trajectory data could be via CCSDS ODM/NDM?

2)    The process discussion in the reporting does not really need to be in the document (ie., submission to CESG, followed by CMC, etc).  The rationale is that statement of the test results is essentially independent of whatever process CCSDS is following and if people really want to know the process, they can refer to the CCSDS procedures manual (which is formally maintained for these kind of things).

Colin, John,

If possible, perhaps it will help to provide some responses to Claudia's questions prior to the January 16th webex.

Best regards and Happy New Year to everyone,
-Erik

From: SMWG [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Ciocirlan Claudia
Sent: Friday, December 22, 2017 6:39 AM
To: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>; Colin.Haddow at esa.int<mailto:Colin.Haddow at esa.int>; CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>) <smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>>
Subject: [Smwg] TGFT yellow book

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?

TGFTXFDUschema.xsd
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 4.2.5.4.1) but not in the schema. It could be. The specificationVersion element shall have the value "1.0".
The specification (section 4.2.7.2.2) 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 4.2.8.2.2) 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 4.2.5.1.a)
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 4.2.5.5.2)
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.

MetadataObject
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 4.2.7.3.1.c.2).

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 4.5.4.2 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 4.2.8.4.1.c. 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 4.2.5.1.a). 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?

Size
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

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

________________________________

Spam<https://filter.gst.com/canit/b.php?c=s&i=01URyU5uu&m=a8fbe527a869>
Not spam<https://filter.gst.com/canit/b.php?c=n&i=01URyU5uu&m=a8fbe527a869>
Forget previous vote<https://filter.gst.com/canit/b.php?c=f&i=01URyU5uu&m=a8fbe527a869>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20180103/f8da9472/attachment.html>