[Smwg] SoS XML Schema does not quite match time code B?

Wed Jun 8 16:55:02 UTC 2016

John,

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.

Best regards,
-Erik
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?

Erik,
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”.

John

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?

John,

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:

“….
3.5.1.2 ASCII TIME CODE B, Year/Day of Year Calendar Variation:
The format for ASCII Time Code B is as follows:
YYYY-DDDThh:mm:ss.d→dZ

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
required precision.

An optional terminator consisting of the ASCII character ‘Z’ may be placed at the end of the
time code.
EXAMPLE: 1988-018T17:20:43.123456Z
….”

And here is the key line in the XML schema that defines the pattern

<xsd:pattern value="\d{4}-\d{3}T\d{2}:\d{2}:\d{2}\.\d+Z?"/>

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:
<xsd:pattern value="\d{4}-\d{3}T\d{2}:\d{2}:\d{2}\.\d*Z?"/>

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.

Best regards,
-Erik

________________________________

Spam<https://filter.gst.com/canit/b.php?i=01QR7yT9f&m=dc17bf9e890a&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01QR7yT9f&m=dc17bf9e890a&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01QR7yT9f&m=dc17bf9e890a&c=f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20160608/90d78101/attachment.html>