[Smwg] updated draft TGFT on CWE

Wed Jun 6 19:23:27 UTC 2018

Dear Serge,
Thanks for the explanation. I concur with your judgement that xmlData elements be prohibited from the environmentInfo element that contains the mandatory TGFT metadata extension  element. I have modified the affected paragraphs in section 4.2.5.6 as follows, where the new material is in red:
"4.2.5.6.1  One environmentInfo element shall contain one extension element for the TGFT XFDU extension parameters that are applicable to the XFDU Package as a whole. This environmentInfo element shall not contain any xmlData elements.

NOTE    -    The CCSDS-standard environmentInfo element contains zero or one extension elements and 0 to unbounded xmlData elements. Although other environmentInfo elements in the TGFT XFDU Manifest may contain TGFT-using-application-specific metadata in xmlData elements (see the NOTE under 4.2.5.6.3), xmlData elements are prohibited in the environmentInfo element that contains the mandatory TGFT XFDU extension parameters.

I've also tightened up the corresponding material in section F6.2.2, where the additional material is in red:
"For TGFT, at least one environmentInfo element is required, and that required element must contain an extension element that adds TGFT-specific metadata that applies to the XFDU as a whole (e.g., the originator of the XFDU). That required environmentInfo element is prohibited from containing any xmlData elements. The optional xmlData elements that are present in the environmentInfoType schema type are available for use in TGFT XFDUs only to carry TGFT-using-application-specific metadata, and only as elements of instances of the environmentInfo element other than the instance that carries the TFGT-specific metadata, as described below.

I hope that this satisfies your concerns.

I've posted the updated draft XFDU book (v0.5) on the CWE at URL
https://cwe.ccsds.org/css/docs/CSS-SM/CWE%20Private/Book%20Production/Blue/Terrestrial%20Generic%20File%20Transfer/White%20Book/Drafts/927x01w0.5%20-%20Terrestrial%20Generic%20File%20Transfer-180606.doc

Best regards,
John

From: Serge Lacourte [mailto:serge.lacourte at scalagent.com]
Sent: Thursday, May 24, 2018 4:30 AM
To: Ciocirlan Claudia <Claudia.Ciocirlan at cnes.fr>; John Pietras <john.pietras at gst.com>; Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>; CCSDS SMWG ML (smwg at mailman.ccsds.org) <smwg at mailman.ccsds.org>
Subject: Re: updated draft TGFT on CWE

Dear WG members,

thank you for adding me to the discussions about TGFT. As Claudia explained, I work on this subject on behalf of CNES.

I want to comment on the item 2 of the mail of John.

2.      The standard CCSDS XFDU provides two schema extension mechanisms as part of the environmentInfo element of the packageHeaderType: the xmlData element containing unstructured XML, and the extension element by which the XFDU schema can be extended through the use of an XML type. The TGFT XFDU formally specifies that the extension element is the specified mechanism for extensions to the schema for the base TGFT service, and that such extensions must be done through the TgftXfduExtensionType complex schema type. However, the TGFT XFDU specification does not forbid any user-application-specific use of the (unstructured) xmlData elements. Claudia suggested that the xmlData element be explicitly forbidden to be used in TGFT XFDUs.

In Gaithersburg, we discussed the difference between what additional metadata might be standard for *all* TGFT XFDUs and metadata that a TGFT-using application might need to add to the XFDU for its own application-specific purposes. Examples of extension metadata that is common to all TGFT XFDUs are originator, recipient, and creationDate, where originator and recipient are included in the TgftXfduExtensionType complex schema type because they apply to the whole XFDU Package, and creationDate is in the TgftContentUnitExtensionType because it applies to each individual Content Unit (i.e., payload data file) within the XFDU Package.

We agreed that (a) extension metadata that is common to all TGFT XFDUs (and thus part of the TGFT standard itself) must be contained in the TgftXfduExtensionType or TgftContentUnitExtensionType complex schema types, and (b) TGFT-using applications *may* use xmlData elements for adding application-specific metadata that applies to the XFDU Package as a whole. I agreed to review the description of this distinction in the TGFT book and clarify it if necessary. I have since looked at the relevant sections of the TGFT book and have concluded that it is indeed ambiguous and in need of clarification. As the result:

a)      I've reworded the text to state that the recommended extension mechanism for adding TGFT-using application-specific metadata that applies to the XFDU Package as a whole is through the addition of another environmentInfo element containing an extension element.

b)     I've added a NOTE that says that TGFT-using applications may also use xmlData elements, but any such usage is outside the scope of TGFT and must be documented as part of the specification of the TGFT-using application.
eb> That sounds reasonable to me. I'd like to get Claudia's take on your note as obviously this does not explicitly forbid the use of xmlData element.

As far as I understand, the proposed modification explains the specification but does not change it.

I will try to explain the purpose of the original remark that led to this discussion.

The environmentInfo element provides effectively two schema extension mechanisms with the xmlData element and the extension element. More precisely a single environmentInfo element may contain at most 1 extension element and any number of xmlData elements. The key point I want to discuss is the possibility to use both extension mechanisms in the same environmentInfo element.

The TGFT specification requires and specializes an environmentInfo element to describe generic TGFT metadata (section 4.2.5.6.1). To do this the "structured" extension mechanism has been chosen, and the specification requires the use of the extension element. I would like to prevent the simultaneous usage of the "unstructured" extension mechanism in that specific environmentInfo element. This could be expressed by the following:
4.2.5.6.1    One environmentInfo element shall contain one extension element for the TGFT XFDU extension parameters that are applicable to the XFDU Package as a whole. This element shall not contain any additional xmlData element.
Of course this would not prevent any TGFT using service from using the xmlData extension mechanisms, but this should be done in a separate environmentInfo element, not in the one dedicated to the generic TGFT metadata.

In order to help visualise the impact of the proposal, here is first what I would like to forbid in TGFT:

+ packageHeader
|----+ environmentInfo
|----|----+ extension
|----|----|----+ tgftXfduExtension
|----|----|----|---- originator
|----|----|----|---- recipient
|----|----+ xmlData
|----|----|---- any xml data

And here is form that could be used to convey the same content:

+ packageHeader
|----+ environmentInfo
|----|----+ extension
|----|----|----+ tgftXfduExtension
|----|----|----|---- originator
|----|----|----|---- recipient
|----+ environmentInfo
|----|----+ xmlData
|----|----|---- any xml data

I hope this is more clear.

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/20180606/90db47b7/attachment.html>