[Smwg] RE: SOS prototype test report finilization
Marcin.Gnat at dlr.de
Marcin.Gnat at dlr.de
Tue Jan 13 08:08:58 UTC 2015
Well your confusion is understandable, because I put the text block into report on purpose being "soft & fluffy" (just for the case we want to leave report as it is and do not perform any further prototyping), whereas my concerns are rather in the matter "I'm not sure, but I let me be convinced".
Depending if I have enough time today before telecon, I will try to collect changes and make one or two pages in PowerPoint.
From: Barkley, Erik J (3970) [mailto:erik.j.barkley at jpl.nasa.gov]
Sent: Montag, 12. Januar 2015 22:07
To: Gnat, Marcin; smwg at mailman.ccsds.org
Subject: SOS prototype test report finilization
Happy New Year to you as well.
Re prototype test report, I am a bit confused. On the one hand you say that there were a few small changes, on the other hand you ask to us to admit that a lot has changed. I think a couple of steps will help to sort this out:
1) Cataloging the changes from prototype version to final version
2) Assessing what is truly a significant semantic difference for each change
In performing the assessment I believe we need to keep in mind that the main point of the prototype interoperation is to prove the technical feasibility of being able to exchange information per the specification and that this does not pose a risk with respect to being unimplementable by member agencies, etc. My sense is that from a semantic point of view there really isn't that much that has changed and it's really more a matter of having moved things around a bit in the data format definition and allowing for nesting of additional (implementation specific) parameters. I'm quite confident that modern-day computers can handle the adjustments to the schema and the ability to following nested set of parameters -- in other words if the set of changes are confined to this type of change I am not particularly worried that it poses an implementation problem for our agencies. On the other hand if you see some sort of issue whereby it could get semantically confused etc. that's certainly needs to be brought forward. In any case I look forward to discussing this at the teleconference tomorrow.
From: smwg-bounces at mailman.ccsds.org<mailto:smwg-bounces at mailman.ccsds.org> [mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of Marcin.Gnat at dlr.de<mailto:Marcin.Gnat at dlr.de>
Sent: Friday, January 02, 2015 7:40 AM
To: smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>
Subject: [Smwg] Action Items
First of all, HAPPY NEW YEAR!
Below summary of some AI's which have been assigned to me.
Create a diagram to be included in the Simple Schedule introduction to clarify the context of the document (possibly by using the life-cycle diagram)
Update the diagram according to CNES RID JMS11
Include in test report that we will not prototype the nesting of AdditionalParameter
Look up the frequency for UHF and VHF for the SoS
Clarify the note to indicate the information bookmarking function in the case of the antenna free time in para 18.104.22.168. See NASA RID Antenna Freetime
The 2014-1110-06 and 2014-1111-04 may be closed. I presented the updated diagram on last telecon, beside of my text which was somewhat messy, the diagram should be okay. I also saw that Colin did corrected the text afterwards, so now should be okay.
Also the 2014-1111-03 -> I saw Colin did added some definitions for VHF and UHF and as far as I could research for that, this may be a good selection. As always there are different definitions for different frequencies, so I think we do not need to spend more effort.
Regarding 2014-1110-02, see attached presentation. I also uploaded it plus the Visio original drawing to the CWE.
Finally, to the 2014-1111-01. I added the required text:
As of finalization of this report, some small changes have been introduced into the schema of the Simple Schedule Data Format. This includes nesting additional parameters. Analysis of this showed that it is not required to perform additional prototyping which would include nested additional parameters, as this would not add any new knowledge (in terms of interface, if there are just "flat" additional parameters or nested ones, it does not matter). Of course the respective implementation needs to support such nesting, but this is out of the scope of this prototyping.
however when looking at the current version of the SoS-Schema, I rather tend to say we may need prototyping-reloaded. I hoped it will be not like that, but you must admit, a lot of things changed. I'm sure it is possible to exchange files in the newer format the same as the one before RID's, but our Yellow Book does not cover that! I mean, if someone looks into the Yellow Book, he will not find any test which is matching the Blue Book now 1:1. So, this someone may say - "how did you prove it works?". Let's discuss that during next telecon.
The updated Report:
Thanks again to Colin for helping me out with some AI's.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SMWG