$)C<font size=2 face="Arial">Peter,</font>
<br>
<br><font size=2 face="Arial">my proposal would be:</font>
<br>
<br><font size=2 face="Arial">1. No change is needed to accommodate Erik's
request as this is already foreseen by the standard</font>
<br><font size=2 face="Arial">2. Improve the text in the standard to make
the rules for subsetting clearer.</font>
<br>
<br><font size=2 face="Arial">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.</font>
<br>
<br><font size=2 face="Arial">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?</font>
<br>
<br><font size=2 face="Arial">Regards,</font>
<br>
<br><font size=2 face="Arial">__Mario</font>
<br>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Shames, Peter
M (312B)" <peter.m.shames@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">"Mario.Merri@esa.int"
<Mario.Merri@esa.int>, "Barkley, Erik J (3970)" <erik.j.barkley@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"cesg@mailman.ccsds.org"
<cesg@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">04/08/2016 23:42</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">Re: [CESG] CCSDS
301.0-B-4 propsed pink sheet (Time Code B) / Backward compatibility?</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 face="Calibri">Hi Mario,</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">I!/m not clear what you are proposing.
In one paragraph you say that the standard is !0ok!1. 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?</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">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:</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=4>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. </font><font size=3 face="MS Mincho">?</font>
<br><font size=2 face="Calibri">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 !0calendarTtime!1
format would have to be judged non-compliant with the spec.</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">According to the rules any of the following
constructs should be acceptable:</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=4>YYYY-DDDThh:mm:ss.d</font><font size=4 face="Calibri">!f</font><font size=4>dZ
</font>
<br><font size=4>YYYY-DDDThh:mm:ss.d</font><font size=4 face="Calibri">!f</font><font size=4>d
</font>
<br><font size=4>-DDDThh:mm:ss </font>
<br><font size=4>-DDDThh:mm</font>
<br><font size=4>hh:mm:ss.d</font><font size=4 face="Calibri">!f</font><font size=4>dZ
</font>
<br><font size=4>YYYY-DDD</font>
<br><font size=2 face="Calibri">Perhaps a non-normative set of examples
like this would have helped?</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Thanks, Peter</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri"> </font>
<br><font size=3 face="Calibri"><b>From: </b>CESG <cesg-bounces@mailman.ccsds.org>
on behalf of Mario Merri <Mario.Merri@esa.int><b><br>
Date: </b>Thursday, August 4, 2016 at 1:52 AM<b><br>
To: </b>Erik Barkley <erik.j.barkley@jpl.nasa.gov><b><br>
Cc: </b>CCSDS Engineering Steering Group - CESG Exec <cesg@mailman.ccsds.org><b><br>
Subject: </b>Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B)
/ Backward compatibility?</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Arial">Hi Erik,</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
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:</font><font size=3 face="Times New Roman"> </font>
<ul>
<li><font size=2 face="Arial">[...] time subsets [...] may be abbreviated
to the span of interest by deleting the unneeded subfields, either on the
left or on the right. </font><font size=2 color=blue face="Arial">This
implies that one can delete the "d!fd" subfield</font><font size=3 face="Times New Roman">
</font>
<li><font size=2 face="Arial">When subfields are deleted on the RIGHT,
the separators that had delimited the deleted subfields are dropped. </font><font size=2 color=blue face="Arial">This
implies that one can delete the decimal dot</font></ul><font size=3 face="Symbol">!$</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
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.</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
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.</font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Arial"><br>
Regards,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
__Mario</font><font size=3 face="Times New Roman"> <br>
<br>
<br>
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
From: </font><font size=1 face="sans-serif">"Shames,
Peter M (312B)" <peter.m.shames@jpl.nasa.gov></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
To: </font><font size=1 face="sans-serif">"Barkley,
Erik J (3970)" <erik.j.barkley@jpl.nasa.gov></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Cc: </font><font size=1 face="sans-serif">"CESG
-- CCSDS-Engineering Steering Group\(cesg@mailman.ccsds.org\)\(cesg@mailman.ccsds.org\)"
<cesg@mailman.ccsds.org></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Date: </font><font size=1 face="sans-serif">04/08/2016
05:04</font><font size=3 face="Times New Roman"> </font><font size=1 color=#5f5f5f face="sans-serif"><br>
Subject: </font><font size=1 face="sans-serif">Re:
[CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B) / Backward compatibility?</font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="sans-serif"><br>
Sent by: </font><font size=1 face="sans-serif">"CESG"
<cesg-bounces@mailman.ccsds.org></font><font size=3 face="Times New Roman">
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="Times New Roman"><br>
<br>
<br>
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. <br>
<br>
Peter <br>
<br>
Sent from Peter's iPhone 6 <br>
<br>
Everything should be made as simple as possible, <br>
but not simpler. <br>
<br>
~Albert Einstein <br>
<br>
On Aug 3, 2016, at 6:34 PM, Barkley, Erik J (3970) <</font><a href=mailto:erik.j.barkley@jpl.nasa.gov><font size=3 color=blue face="Times New Roman"><u>erik.j.barkley@jpl.nasa.gov</u></font></a><font size=3 face="Times New Roman">>
wrote:<br>
</font><font size=2 color=#004080 face="Calibri"><br>
Gippo,</font><font size=3 face="Times New Roman"> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 color=#004080 face="Calibri"><br>
I too noted that it might be possible to interpret 3.5.1.3 as already allowing
removal of the decimal fraction/sub-second. <br>
</font><font size=3 face="Times New Roman"> </font><font size=2 color=#004080 face="Calibri"><br>
CESG members,</font><font size=3 face="Times New Roman"> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 color=#004080 face="Calibri"><br>
What is your taking/reading on this? Does this already allow fractional
seconds to be optional? If not, why not? <br>
</font><font size=3 face="Times New Roman"> </font><font size=2 color=#004080 face="Calibri"><br>
Best regards,</font><font size=3 face="Times New Roman"> </font><font size=2 color=#004080 face="Calibri"><br>
-Erik</font><font size=3 face="Times New Roman"> </font><font size=2 color=#004080 face="Calibri"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><b><br>
From:</b> </font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=2 color=blue face="Calibri"><u>Gian.Paolo.Calzolari@esa.int</u></font></a><font size=2 face="Calibri">
[</font><a href=mailto:Gian.Paolo.Calzolari@esa.int><font size=2 color=blue face="Calibri"><u>mailto:Gian.Paolo.Calzolari@esa.int</u></font></a><font size=2 face="Calibri">]
<b><br>
Sent:</b> Monday, July 25, 2016 2:26 AM<b><br>
To:</b> Barkley, Erik J (3970) <</font><a href=mailto:erik.j.barkley@jpl.nasa.gov><font size=2 color=blue face="Calibri"><u>erik.j.barkley@jpl.nasa.gov</u></font></a><font size=2 face="Calibri">><b><br>
Cc:</b> CESG -- CCSDS-Engineering Steering Group (</font><a href=mailto:cesg@mailman.ccsds.org><font size=2 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=2 face="Calibri">)
(</font><a href=mailto:cesg@mailman.ccsds.org><font size=2 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=2 face="Calibri">)
<</font><a href=mailto:cesg@mailman.ccsds.org><font size=2 color=blue face="Calibri"><u>cesg@mailman.ccsds.org</u></font></a><font size=2 face="Calibri">><b><br>
Subject:</b> Re: [CESG] CCSDS 301.0-B-4 propsed pink sheet (Time Code B)
/ Backward compatibility?</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Arial"><br>
Erik,</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
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 "</font><font size=3 face="Times New Roman">Decimal
fraction of second</font><font size=2 face="Arial">" and would most
likely crashes when that field is absent.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
Conversely a constant setting to 0 when not used would be fully backward
compatible.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
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.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
In other words, the part of </font><font size=2 face="Calibri">3.5.1.3
clause (c)</font><font size=2 face="Arial"> 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?</font><font size=3 face="Times New Roman">
</font><font size=2 face="Arial"><br>
<br>
My cent.......</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
Gian Paolo</font><font size=3 face="Times New Roman"> </font><font size=2 face="Arial"><br>
<br>
PS It looks to me that the sentence "</font><font size=2 face="Times New Roman">the
need to accommodate the upcoming century rollover in only 11 years</font><font size=2 face="Arial">"
was somehow wrong in 2010 as it is now :o)</font><font size=3 face="Times New Roman">
<br>
<br>
<br>
</font><font size=1 color=#5f5f5f face="Arial"><br>
<br>
From: </font><font size=1 face="Arial">"Barkley,
Erik J (3970)" <</font><a href=mailto:erik.j.barkley@jpl.nasa.gov><font size=1 color=blue face="Arial"><u>erik.j.barkley@jpl.nasa.gov</u></font></a><font size=1 face="Arial">></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="Arial"><br>
To: </font><font size=1 face="Arial">"CESG
-- CCSDS-Engineering Steering Group (</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue face="Arial"><u>cesg@mailman.ccsds.org</u></font></a><font size=1 face="Arial">)
(</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue face="Arial"><u>cesg@mailman.ccsds.org</u></font></a><font size=1 face="Arial">)"
<</font><a href=mailto:cesg@mailman.ccsds.org><font size=1 color=blue face="Arial"><u>cesg@mailman.ccsds.org</u></font></a><font size=1 face="Arial">></font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="Arial"><br>
Date: </font><font size=1 face="Arial">22/07/2016
01:44</font><font size=3 face="Times New Roman"> </font><font size=1 color=#5f5f5f face="Arial"><br>
Subject: </font><font size=1 face="Arial">[CESG]
CCSDS 301.0-B-4 propsed pink sheet (Time Code B)</font><font size=3 face="Times New Roman">
</font><font size=1 color=#5f5f5f face="Arial"><br>
Sent by: </font><font size=1 face="Arial">"CESG"
<</font><a href="mailto:cesg-bounces@mailman.ccsds.org"><font size=1 color=blue face="Arial"><u>cesg-bounces@mailman.ccsds.org</u></font></a><font size=1 face="Arial">></font><font size=3 face="Times New Roman">
</font>
<div align=center>
<hr noshade></div>
<br><font size=3 face="Times New Roman"><br>
<br>
</font><font size=2 face="Calibri"><br>
<br>
CESG Colleagues,</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Calibri"><br>
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 !0(optional)!1 which is in keeping with the method by
which optional is designated for the !0Z!1 character in the recommendation.
I believe the !0.!1 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. </font><font size=3 face="Times New Roman">
<br>
</font><font size=2 face="Calibri"><br>
Best regards,</font><font size=3 face="Times New Roman"> </font><font size=2 face="Calibri"><br>
-Erik</font><font size=3 face="Times New Roman"> <br>
</font><font size=2 face="Calibri"><br>
[attachment "301x0b4e1-ProposedPinkSheet.docx" deleted by Gian
Paolo Calzolari/esoc/ESA] </font><font size=2 face="Courier New">_______________________________________________<br>
CESG mailing list</font><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href=mailto:CESG@mailman.ccsds.org><font size=2 color=blue face="Courier New"><u>CESG@mailman.ccsds.org</u></font></a><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg"><font size=2 color=blue face="Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg</u></font></a><font size=3 face="Times New Roman"><br>
</font><font size=2 face="Courier New"><br>
This message and any attachments are intended for the use of the addressee
or addressees only.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
The unauthorised disclosure, use, dissemination or copying (either in whole
or in part) of its</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
content is not permitted.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
If you received this message in error, please notify the sender and delete
it from your system.</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
Emails can be altered and their integrity cannot be guaranteed by the sender.</font><font size=3 face="Times New Roman">
</font><font size=2 face="Courier New"><br>
</font><font size=3 face="Times New Roman"> </font><font size=2 face="Courier New"><br>
Please consider the environment before printing this email.</font><font size=3 face="Times New Roman">
<br>
_______________________________________________<br>
CESG mailing list</font><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href=mailto:CESG@mailman.ccsds.org><font size=3 color=blue face="Times New Roman"><u>CESG@mailman.ccsds.org</u></font></a><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg"><font size=3 color=blue face="Times New Roman"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg</u></font></a><font size=2 face="Courier New">_______________________________________________<br>
CESG mailing list<br>
CESG@mailman.ccsds.org</font><font size=3 color=blue face="Times New Roman"><u><br>
</u></font><a href="https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg"><font size=2 color=blue face="Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg</u></font></a><font size=2 face="Courier New"><br>
</font>
<br><font size=2 face="Courier New">This message and any attachments are
intended for the use of the addressee or addressees only.</font>
<br><font size=2 face="Courier New">The unauthorised disclosure, use, dissemination
or copying (either in whole or in part) of its</font>
<br><font size=2 face="Courier New">content is not permitted.</font>
<br><font size=2 face="Courier New">If you received this message in error,
please notify the sender and delete it from your system.</font>
<br><font size=2 face="Courier New">Emails can be altered and their integrity
cannot be guaranteed by the sender.</font>
<br><font size=2 face="Courier New"> </font>
<br><font size=2 face="Courier New">Please consider the environment before
printing this email.</font>
<br>
<br><PRE>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.
</PRE>