[CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B) / Backward compatibility?

Mario.Merri at esa.int Mario.Merri at esa.int
Tue Aug 9 12:43:08 UTC 2016


OK Erik,

just be careful that clause c is valid for both Ascii Time Code A and B. 
Therefore my proposed text needs to be expanded to cover also the Time 
Code A (in particular the part dealing with "Allowed subsetting of 
'calendar' subset are ...").

Ciao

__Mario



From:   "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>
To:     "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>, 
"Mario.Merri at esa.int" <Mario.Merri at esa.int>
Cc:     "cesg at mailman.ccsds.org" <cesg at mailman.ccsds.org>
Date:   09/08/2016 03:45
Subject:        RE: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code 
B) / Backward compatibility?



Thank you to all the CESG members who have replied.    I believe the 
examples and wording worked out between Mario and Peter is quite good and 
can indeed be the basis for a corrigendum.  I propose to produce the 
corrigendum text unless any other CESG member has further comment.   If 
there are further comments, inputs by Monday, 15 August 2016 will be much 
appreciated.  I further propose to review the corrigendum at the next CESG 
Webex on September 7th. 
 
Best regards,
-Erik
 
From: CESG [mailto:cesg-bounces at mailman.ccsds.org] On Behalf Of Shames, 
Peter M (312B)
Sent: Monday, August 08, 2016 10:12 AM
To: Mario.Merri at esa.int
Cc: cesg at mailman.ccsds.org
Subject: Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B) / 
Backward compatibility?
 
Hi Mario,
 
I would recommend leaving the “one the LEFT” and “on the RIGHT” language 
alone.  I think taking these out makes it less clear.  That said, I agree 
that adding in the “calendar” and “time” references, as you proposed, does 
make it clearer, and your examples of allowed subsets are also clear.
 
I think the optional “Z” terminator is fine as it is.  The logic, in my 
mind, is this: if there is just an hh:mm:ss string there is no ambiguity 
and a blank, in all these cases, is an acceptable token terminator for a 
parser.  If there is an hh:mm:ss.d→d string there is still no ambiguity 
since a blank character is still an acceptable token terminator.  However, 
anyone wishing to add an explicit terminator can use the “Z”.  It’s not 
really needed, since a blank works, but it’s available as an option.
 
If everyone else on this email trail concurs I propose that we create a 
corrigendum to that effect.
 
Regards, Peter
 
 
From: Mario Merri <Mario.Merri at esa.int>
Date: Monday, August 8, 2016 at 1:15 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B) / 
Backward compatibility?
 
Peter, 

I am trying to help to make the specs clearer. I try below to put the 
point I raised in my email into a concrete proposal for changing clause c 
(wording can certainly be improved), which in my opinion is unambiguous 
(changes in red): 

===start proposal==== 
Calendar or time subsets may contain all the defined subfields, or may be 
abbreviated 
to the span of interest by deleting the unneeded subfields, either on the 
left or on the 
right. However, when 'calendar' subfields are deleted on the LEFT, all 
separators that had 
delimited the deleted subfields must be retained (except for the ‘T’ 
which, by rule b, 
is dropped if the subset is used alone.) When 'time' subfields are deleted 
on the RIGHT, the 
separators that had delimited the deleted subfields are dropped. 

Allowed subsetting of 'calendar' subset are: 
YYYY-DDD 
-DDD 

Allowed subsetting of 'time' subset are: 
hh:mm:ss.d→d 
hh:mm:ss 
hh:mm 
hh 

Any allowed 'calendar' subset can be joined to an allowed 'time' subset by 
means of the 'T' separator. 

EXAMPLES: 
YYYY-DDDThh:mm:ss 
-DDDThh:mm 
hh:mm:ss.d→dZ 
YYYY-DDD 
===end proposal==== 

I also raised a point on the fact that the separator 'Z' is optional, 
which went unanswered. 

Ciao 

__Mario 


From:        "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov> 
To:        "Mario.Merri at esa.int" <Mario.Merri at esa.int> 
Cc:        "Gian.Paolo.Calzolari at esa.int" <Gian.Paolo.Calzolari at esa.int>, 
"cesg at mailman.ccsds.org" <cesg at mailman.ccsds.org> 
Date:        07/08/2016 21:18 
Subject:        Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code 
B) / Backward compatibility? 




In English this is what we call “a tempest in a teapot”.  This is all in 
one spec, in three clauses, one of which has six sub-clauses.  Various of 
us seem to have: 
a)       Not read all three clauses 
b)       Only quoted parts of one sub-clause, not even the whole of it 
c)       And this leads to confusion … 
  
As with all CCSDS specs you do need to read, understand, and comply with 
all normative parts of the spec.  At least here the ASCII Segmented Time 
Code is stated in 2.5 pages of one rather modest spec and does not require 
a stack of three dense specs to get to an understanding of what is 
required.  And it is a spec that has been around and in successful use 
since 1987.  It just cannot be a huge problem or source of confusion or it 
would have surfaced years ago. 
  
My concrete suggestion for “fixing” this was to add a few non-normative 
examples so that the meaning of the spec is made even more clear.  I 
provided what I thought was a reasonable set of example that touch upon 
the major inflection points where valid subsets can be created. 
  
If anyone has an alternative concrete suggestion, please offer it up so we 
can all return to more substantive issues. 
  
Thanks, Peter 
  
  
  
From: Mario Merri <Mario.Merri at esa.int>
Date: Saturday, August 6, 2016 at 11:52 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>
Cc: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>, CCSDS Engineering 
Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B) / 
Backward compatibility? 
 
It is so clear that we have been discussing a week ...

__Mario 

On 6 Aug 2016, at 02:17, Shames, Peter M (312B) <
peter.m.shames at jpl.nasa.gov> wrote: 
I think the standard is quite clear enough as it is if you read all the 
clauses, just like most of our specs.  However, I would support the 
addition of a non-normative corrigendum that provides some examples.  I do 
not think that that can be an exhaustive set of examples because in spite 
of there being clear rules there are too many possible combinations.  I 
only showed a subset of the possible ones. 
  
Regards, Peter 
  
  
From: Gian Paolo Calzolari <Gian.Paolo.Calzolari at esa.int>
Date: Friday, August 5, 2016 at 3:08 AM
To: Mario Merri <Mario.Merri at esa.int>
Cc: Peter Shames <peter.m.shames at jpl.nasa.gov>, CCSDS Engineering Steering 
Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B) / 
Backward compatibility? 
 
Mario, you are basically repeating my proposal; i.e. working on section 
3.5.1.3 instead of adding the optional field in section  3.5.1.2. :-) 



If we can do that just adding a NOTE we might go for an editorial 
corrigendum as the addition would be non normative. 



I go back to rest now 



Gippo 
 


Sent from my iPhone 

On 05 Aug 2016, at 09:45, Mario.Merri at esa.int wrote: 
Peter, 

my proposal would be: 

1. No change is needed to accommodate Erik's request as this is already 
foreseen by the standard 
2. Improve the text in the standard to make the rules for subsetting 
clearer. 

For 2. for instance, it is implicit and possibly open to interpretation 
that, regardless whether one removes subsets from the left or from the 
right, this must be done on contiguous subsets and one cannot take out for 
example "mm" and have YYYY-DDDThh:ss (although I admit not very 
meaningful). In other words to the left or to the right of what? I know, 
it is a little bit pedantic, but CCSDS should strive for fully unambiguous 
text. My proposal here is to further refine the text of clause c and add 
the exhaustive list of allowed subset formats. 

I am also a little bit puzzled by the fact that the "Z" terminator is 
declared optional. I guess the logic is that the parser will consider the 
time code finished when it encounters a character different from a 
numerical digit. What if, to save bits, the next field that happens to be 
numeric is collapsed to the time code? Wouldn't be cleaner to make "Z" 
terminator mandatory if the time subset is present? 

Regards, 

__Mario 




From:        "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov> 
To:        "Mario.Merri at esa.int" <Mario.Merri at esa.int>, "Barkley, Erik J 
(3970)" <erik.j.barkley at jpl.nasa.gov> 
Cc:        "cesg at mailman.ccsds.org" <cesg at mailman.ccsds.org> 
Date:        04/08/2016 23:42 
Subject:        Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code 
B) / Backward compatibility? 





Hi Mario, 
 
I’m not clear what you are proposing.  In one paragraph you say that the 
standard is “ok”.  In the next paragraph you say that the standard forces 
use of ICDs because it is ambiguous.  Which is it?  And, if you think it 
is a problem, just what would you propose to change? 
 
I agree that this could probably be stated even more clearly, but, as you 
point out, it does provide both a clear specification of the full set of 
sub-fields and rules for dropping sub-fields if they are not needed.  If 
you had quoted the complete text of sec 3.5.1.3.c you would see the 
following: 
 
c)  Calendar or time subsets may contain all the defined subfields, or may 
be abbreviated to the span of interest by deleting the unneeded subfields, 
either on the left or on the right. However, when subfields are deleted on 
the LEFT, all separators that had delimited the deleted subfields must be 
retained (except for the ‘T’ which, by rule b, is dropped if the subset is 
used alone.) When subfields are deleted on the RIGHT, the separators that 
had delimited the deleted subfields are dropped. ? 
Between this rule (and the other three in Sec 3.5.1.3), the explicit use 
of required separators and the rules for keeping or dropping them, it is 
possible to construct a simple but robust parser that will not have any 
ambiguities.  In fact, any parser that is supposed to be compliant with 
this spec that has a problem with parsing any truncated calendar, or time, 
or combined “calendarTtime” format would have to be judged non-compliant 
with the spec. 
 
According to the rules any of the following constructs should be 
acceptable: 
 
YYYY-DDDThh:mm:ss.d→dZ 
YYYY-DDDThh:mm:ss.d→d 
-DDDThh:mm:ss 
-DDDThh:mm 
hh:mm:ss.d→dZ 
YYYY-DDD 
Perhaps a non-normative set of examples like this would have helped? 
 
Thanks, Peter 
 
 
From: CESG <cesg-bounces at mailman.ccsds.org> on behalf of Mario Merri <
Mario.Merri at esa.int>
Date: Thursday, August 4, 2016 at 1:52 AM
To: Erik Barkley <erik.j.barkley at jpl.nasa.gov>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
Subject: Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B) / 
Backward compatibility? 
 
Hi Erik, 

I believe your proposed change is not needed as it is already covered by 
the standard, in particular by clause 3.5.1.3.c. In fact, there it is 
clearly stated that: 
[...] time subsets [...] may be abbreviated to the span of interest by 
deleting the unneeded subfields, either on the left or on the right. This 
implies that one can delete the "d→d" subfield 
When subfields are deleted on the RIGHT, the separators that had delimited 
the deleted subfields are dropped. This implies that one can delete the 
decimal dot
·  
For the decimal dot I believe the current solution is OK. Robust 
implementations should parse the time code string until they find the "Z". 
If they find a "." before, then the time has decimal fraction of second. 

On the other hand, clause 3.5.1.3.c provides full flexibility to eliminate 
any subfield. This seems to me not clean and not in the spirit of 
standardisation as it results in the proliferation of different time 
formats, which require specific ICDs to make them unambiguous. 

Regards, 

__Mario 



From:        "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov> 
To:        "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov> 
Cc:        "CESG -- CCSDS-Engineering Steering Group\(
cesg at mailman.ccsds.org\)\(cesg at mailman.ccsds.org\)" <
cesg at mailman.ccsds.org> 
Date:        04/08/2016 05:04 
Subject:        Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code 
B) / Backward compatibility? 
Sent by:        "CESG" <cesg-bounces at mailman.ccsds.org> 






I agree.  I think clause 3.5.1.3.c covers this case (and even the hh:mm 
case).  I just hope that implementations are robust enough to handle it 
correctly. 

Peter 

Sent from Peter's iPhone 6 

Everything should be made as simple as possible, 
but not simpler. 

~Albert Einstein 

On Aug 3, 2016, at 6:34 PM, Barkley, Erik J (3970) <
erik.j.barkley at jpl.nasa.gov> wrote:

Gippo, 

I too noted that it might be possible to interpret 3.5.1.3 as already 
allowing removal of the decimal fraction/sub-second. 

CESG members, 

What is your taking/reading on this?  Does this already allow fractional 
seconds to be optional?  If not, why not? 

Best regards, 
-Erik 

From: Gian.Paolo.Calzolari at esa.int [mailto:Gian.Paolo.Calzolari at esa.int] 
Sent: Monday, July 25, 2016 2:26 AM
To: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Cc: CESG -- CCSDS-Engineering Steering Group (cesg at mailman.ccsds.org) (
cesg at mailman.ccsds.org) <cesg at mailman.ccsds.org>
Subject: Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B) / 
Backward compatibility? 

Erik, 
     from a purist point of view I think that it would be incorrect 
stating that the change is backward compatible as a former implementation 
would expect to find always the "Decimal fraction of second" and would 
most likely crashes when that field is absent. 
Conversely a constant setting to 0 when not used would be fully backward 
compatible. 

However it is also true that despite section 3.5.1.2 "ASCII TIME CODE B, 
Year/Day of Year Calendar Variation" defines only one optional field (i.e. 
the time code terminator) section 3.5.1.3 "SUBSETS OF THE COMPLETE TIME 
CODES" basically allows many fields to be optional so I wonder whether it 
would be more correct working on section  3.5.1.3 instead of adding the 
optional field in section  3.5.1.2. 
In other words, the part of 3.5.1.3 clause (c) stating that the code "may 
be abbreviated to the span of interest by deleting the unneeded subfields" 
does already allow removing the Decimal fraction of second subfield? 

My cent....... 

Gian Paolo 

PS It looks to me that the sentence "the need to accommodate the upcoming 
century rollover in only 11 years" was somehow wrong in 2010 as it is now  
:o) 




From:        "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov> 
To:        "CESG -- CCSDS-Engineering Steering Group (
cesg at mailman.ccsds.org) (cesg at mailman.ccsds.org)" <cesg at mailman.ccsds.org> 

Date:        22/07/2016 01:44 
Subject:        [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B) 
Sent by:        "CESG" <cesg-bounces at mailman.ccsds.org> 







CESG Colleagues, 

Attached is the proposed pink sheet for Time Code B which makes the time 
code more suitable for such applications as publishing a standardized 
schedule of services for which mandatory fractional seconds is 
meaningless.  (By the way does anyone know what the original rationale was 
for requiring, at a minimum, 1/10 of second time statements?)  The 
proposed change is the addition of “(optional)” which is in keeping with 
the method by which optional is designated for the “Z” character in the 
recommendation.  I believe the “.” subfield separator disappears of by 
application of 3.5.1.3 clause (c).    If this change is made to Time Code 
B, we likely should apply it to Time Code A.   

Best regards, 
-Erik 

[attachment "301x0b4e1-ProposedPinkSheet.docx" deleted by Gian Paolo 
Calzolari/esoc/ESA] _______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg

This message and any attachments are intended for the use of the addressee 
or addressees only. 
The unauthorised disclosure, use, dissemination or copying (either in 
whole or in part) of its 
content is not permitted. 
If you received this message in error, please notify the sender and delete 
it from your system. 
Emails can be altered and their integrity cannot be guaranteed by the 
sender. 

Please consider the environment before printing this email. 
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg
_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg

This message and any attachments are intended for the use of the addressee 
or addressees only. 
The unauthorised disclosure, use, dissemination or copying (either in 
whole or in part) of its 
content is not permitted. 
If you received this message in error, please notify the sender and delete 
it from your system. 
Emails can be altered and their integrity cannot be guaranteed by the 
sender. 
 
Please consider the environment before printing this email. 
This message and any attachments are intended for the use of the addressee 
or addressees only. 
The unauthorised disclosure, use, dissemination or copying (either in 
whole or in part) of its 
content is not permitted. 
If you received this message in error, please notify the sender and delete 
it from your system. 
Emails can be altered and their integrity cannot be guaranteed by the 
sender. 
  
Please consider the environment before printing this email. 
This message and any attachments are intended for the use of the addressee 
or addressees only. 
The unauthorised disclosure, use, dissemination or copying (either in 
whole or in part) of its 
content is not permitted. 
If you received this message in error, please notify the sender and delete 
it from your system. 
Emails can be altered and their integrity cannot be guaranteed by the 
sender. 
  
Please consider the environment before printing this email. 
This message and any attachments are intended for the use of the addressee 
or addressees only. 
The unauthorised disclosure, use, dissemination or copying (either in 
whole or in part) of its 
content is not permitted. 
If you received this message in error, please notify the sender and delete 
it from your system. 
Emails can be altered and their integrity cannot be guaranteed by the 
sender. 
  
Please consider the environment before printing this email. 
This message and any attachments are intended for the use of the addressee 
or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in 
whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete 
it from your system.
Emails can be altered and their integrity cannot be guaranteed by the 
sender.
 
Please consider the environment before printing this email.


This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20160809/480043ce/attachment.html>


More information about the CESG mailing list