[Smwg] updated draft TGFT on CWE

Wed May 30 17:05:21 UTC 2018

Dear Serge,

I think what you have proposed is fine.  It is a more structured way to handle the distinctions between what is extended relative to TGFT itself and that which is not directly within the purview of the TGFT.

CSSM Colleagues,
Does anyone have any further comments on this?  I propose that we include review of the latest TGFT updates for the June 12 teleconference.

Best regards,
-Erik

From: Serge Lacourte <serge.lacourte at scalagent.com>
Sent: Thursday, May 24, 2018 1: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/20180530/1d6160a1/attachment.html>