OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Clarification required for "!!timestamp" type in YAML


Currently the spec (1.3, but before that, too) shows all examples of timestamps as strings. E.g. in 5.3.7.3.1:

properties:
 description:
 evaluation_period: Evaluate a service for a 5-day period across time zones
  type: TimeInterval
  start_time: 2016-04-04-15T00:00:00Z
  end_time: 2016-04-08T21:59:43.10-06:00

But the spec also states that we use YAML's "!!timestamp" format. So if we follow the spec as it is we should really be writing this as follows:

properties:
 description:
 evaluation_period: Evaluate a service for a 5-day period across time zones
  type: TimeInterval
  start_time: !!timestamp 2016-04-04-15T00:00:00Z
  end_time: !!timestamp 2016-04-08T21:59:43.10-06:00

If we don't do so, then the YAML parser would evaluate the value as a string with no special validation, and the TOSCA parser would then need to parse this string and validate that is in the accepted timestamp format.

I would think we would all agree that requiring "!!timestamp" is unnecessarily verbose and specific for the purposes of TOSCA, and that we would want to accept strings as well. There's actually a further issue with "!!timestamp": I've found that YAML parsers do not consistently parse according to the YAML format, which is actually not quite standard. For example, I've found that not all YAML parsers would succeed in parsing the space-separated format: "2001-12-14 21:59:43.10 -5". It's too easy and lazy to just use the language's (Python, Ruby, Go, etc.) internal time parser. (This should be considered a bug in your YAML parser, so please report it if you find it!)

If we agree about allowing strings, as I am suggesting, then we must be explicit about this in the spec. Either way this needs to be clarified.

Furthermore, for those of us implementing TOSCA parsers, I recommend that you test that you can indeed support both "!!timestamp" and strings and that you get the same results in both cases. In my case (Puccini) I have implemented my own timestamp parser exactly for this use case, but also have a separate codepath to check for the internal Go type used by the YAML parser (time.Time).



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]