[Smwg] RE: Teleconference notes, 13 January 2015

[Barkley, Erik J (3970)]

John,

from the better late than never department, your recollection of events is probably better than mine on this topic.  I don't specifically recall that agreement but your suggestion makes a lot of sense to me. I propose that we quickly revisit this one at our teleconference next week -- especially so as Colin was going to take a little time to mull over whether or not the approach made sense.

Best regards,

-Erik

From: John Pietras [mailto:john.pietras at gst.com]
Sent: Monday, January 26, 2015 8:23 AM
To: Barkley, Erik J (3970); CCSDS Service Mgmt WG
Subject: RE: Teleconference notes, 13 January 2015

Erik and CSSMWG colleagues ---
Regarding item 4(b)(ii) (Finalization of SOS book: Common request header: "Re Table 3-2, agreed that table should only introduce parameter defined, not repeat definitions (similar to Blue-1 approach in this regard)".  I'm not quite sure that this describes my recollection of what transpired - it may, but the wording is a bit ambiguous.  Here's  how I think the discussion and decision went.

During the discussion, I had suggested that we consider making the tables for derived subclasses contain only those parameters that are either:

a)      parameters specific to the derived class (i.e., extension parameters), or

b)      parameters whose definitions or content are modified by the derived class (e.g., that add an additional enumerated value, or change the definition to one that is more specific to the use of the parameter in the context of the derived class).

My reference to Blue-1 was actually as an example of something that turned out to a minor document configuration management headache: many tables in which the great majority of parameters were defined as "See tables XYZ" (with the concurrent need to make sure that the "XYZ"s were always correct). My suggestion was to more fully leverage the concepts of class inheritance and *not* repeat the parameters of the parent class (except in the case mentioned above, where the derived class somehow modifies the inherited parameter).

My recollection is that this proposed approach was met with tentative approval. Colin was also open to it of it but wanted to think about it a bit more.

If we are in agreement that the above is an accurate description of the discussion and decision, I propose substituting the following for 4(b)(ii) in the meeting notes:
"Regarding the tables describing the parameters of classes that are derived from other classes (e.g., the tables for Information Entity-specific classes derived from the standard SrvMgtHeader, SrvMgtInfotEntity, and SrvMgtData classes), each such derived subclass table will contain parameter entries for

a)      parameters specific to the derived class (i.e., extension parameters), or

b)      parameters whose definitions or content are modified by the derived class (e.g., that add an additional enumerated value, or change the definition to one that is more specific to the use of the parameter in the context of the derived class).
Parameters that are inherited from the parent class and that are unmodified by the derived class are not listed in the table for derived class."

Talk to you all tomorrow.

Best regards,
John


From: smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org> [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Barkley, Erik J (3970)
Sent: Tuesday, January 13, 2015 8:53 PM
To: CCSDS Service Mgmt WG
Subject: [Smwg] Teleconference notes, 13 January 2015

CSSM Colleagues,

Attached are the notes from the teleconference on 13 January 2015. Corrections appreciated.  The notes have also been uploaded to the teleconference folder on CWE.

Our next telecon is scheduled for 27 January 2015.


Best regards,

-Erik

________________________________

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