[Smwg] SoS XML Schema does not quite match time code B?
Barkley, Erik J (3970)
erik.j.barkley at jpl.nasa.gov
Wed Jun 8 16:55:02 UTC 2016
Thanks for the inputs. We also have this statement:
“As many ‘d’ characters to the right of the period as required may be used to obtain the required precision.”
I suppose this then reads as 1..* rather than “as many…as required…” meaning 0..*
I will follow up on this.
From: John Pietras [mailto:john.pietras at gst.com]
Sent: Tuesday, June 07, 2016 8:53 AM
To: Barkley, Erik J (3970) <erik.j.barkley at jpl.nasa.gov>
Cc: CCSDS Service Mgmt WG <smwg at mailman.ccsds.org>; Holger.Dreihahn at esa.int
Subject: RE: SoS XML Schema does not quite match time code B?
I think that the pattern is as correct as-is, due to the specification “d→d = Decimal fraction of second in one- to n-character subfield”, which specifies that the decimal fraction field have a minimum of one character.
But I admit that there is indeed an inconsistency here, one that should probable be cleaned up in the time code book itself. As you allude to in your note, one-tenth-of-a-second precision may not be needed, but in that case the specification of the decimal fraction field should be changed to “d→d = Decimal fraction of second in zero- to n-character subfield”.
From: Barkley, Erik J (3970) [mailto:erik.j.barkley at jpl.nasa.gov]
Sent: Wednesday, May 11, 2016 3:35 PM
To: John Pietras
Cc: CCSDS Service Mgmt WG
Subject: SoS XML Schema does not quite match time code B?
I realize you are on vacation, but when you come back…
As part of the ESTRACK/DSN schedule exchange work ongoing, a question about time representation has arisen. I have taken a look and my conclusion is that the schema that we have for Time code B does not quite match the Time code B definition in the book. Certainly a more "relaxed" definition with regard to sub seconds is in order for reporting things like schedules which often (although perhaps not exclusively) don't need anything stated below a second resolution.
Here is what the CCSDS recommendation on Time codes says about T.C. B says about it:
188.8.131.52 ASCII TIME CODE B, Year/Day of Year Calendar Variation:
The format for ASCII Time Code B is as follows:
where each character is an ASCII character using one octet with the following meanings:
YYYY = Year in four-character subfield with values 0001-9999
DDD = Day of year in three-character subfield with values 001-365 or -366
T = Calendar-Time separator
hh = Hour in two-character subfield with values 00-23
mm = Minute in two-character subfield with values 00-59
ss = Second in two-character subfield with values 00-59
(-58 or -60 during leap seconds)
d→d = Decimal fraction of second in one- to n-character subfield
where each d has values 0-9
Z = time code terminator (optional)
The hyphen (-), colon (:), letter ‘ T’ and period (.) are used as specific subfield separators,
and that all subfields must include leading zeros.
As many ‘d’ characters to the right of the period as required may be used to obtain the
An optional terminator consisting of the ASCII character ‘Z’ may be placed at the end of the
And here is the key line in the XML schema that defines the pattern
Note that the CCSDS book says “..As many ‘d’ characters to the right of the period as required may be used to obtain the
required precision”. I take this to mean that “as many” could in fact be 0 (zero).
Given that, I think the XML schema line should read:
With this definition which I think is consistent with the definition of Time code B implementations are not required to state at least a 10th of a second for timestamps.
I propose that we update the schema accordingly which I think makes the schema more useful to our implementing organizations, consistent with time code B definition, while still allowing for the subsecond expression if needed.
Forget previous vote<https://filter.gst.com/canit/b.php?i=01QR7yT9f&m=dc17bf9e890a&c=f>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SMWG