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

Shames, Peter M (312B) peter.m.shames at jpl.nasa.gov
Mon Aug 8 17:11:33 UTC 2016


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<mailto: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<mailto:Gian.Paolo.Calzolari at esa.int>>
Date: Friday, August 5, 2016 at 3:08 AM
To: Mario Merri <Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>
Cc: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>, CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto: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<mailto: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<mailto:peter.m.shames at jpl.nasa.gov>>
To:        "Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>" <Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>, "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>
Cc:        "cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>" <cesg at mailman.ccsds.org<mailto: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<mailto:cesg-bounces at mailman.ccsds.org>> on behalf of Mario Merri <Mario.Merri at esa.int<mailto:Mario.Merri at esa.int>>
Date: Thursday, August 4, 2016 at 1:52 AM
To: Erik Barkley <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>
Cc: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto: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<mailto:peter.m.shames at jpl.nasa.gov>>
To:        "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>
Cc:        "CESG -- CCSDS-Engineering Steering Group\(cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>\)\(cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>\)" <cesg at mailman.ccsds.org<mailto: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<mailto: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<mailto: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> [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<mailto:erik.j.barkley at jpl.nasa.gov>>
Cc: CESG -- CCSDS-Engineering Steering Group (cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>) (cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>) <cesg at mailman.ccsds.org<mailto: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<mailto:erik.j.barkley at jpl.nasa.gov>>
To:        "CESG -- CCSDS-Engineering Steering Group (cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>) (cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>)" <cesg at mailman.ccsds.org<mailto: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<mailto: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<mailto: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<mailto:CESG at mailman.ccsds.org>
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg_______________________________________________
CESG mailing list
CESG at mailman.ccsds.org<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20160808/2a9bf2d2/attachment.html>


More information about the CESG mailing list