Why is the list of allowed formats for datetime so restrictive?

[KevinMitchell]

I was trying to define a trait for caching control. The date for the Expires header must be in RFC 1123 format. Unfortunately it looks like the allowed datetime formats are just rfc3339 and rfc2616. Is there a reason for restricting the allowed formats to such a small set? At present I presume I'd have to type the Expires header just using a string with an associated pattern. But it would seem neater to specify it as a datetime with rfc1123 as the format. Alternatively, if you do want to only support a small set of formats, then perhaps at least allow a pattern to be defined as an alternative to provide an "escape route" for dates in other formats.

[sichvoge]

Couldn't you define a string type and define that using the pattern facet?

[KevinMitchell]

Yes, that was what I mentioned in the issue, and you could do that for all date formats. The spec quite rightly decided that dates and times were worth handling specially. But if we go to the trouble of distinguishing datetimes from strings in the specification then it seems rather restrictive to only support two formats, with all other datetimes having to be represented simply as strings. Even if we didn't want to unduly complicate the spec with a long list of potential formats we could just specify that there are two standard formats that tools must be able to handle, but allow other formats to be specified. Tooling would then be free to raise an error if asked to validate examples in an unrecognised format.

[sichvoge]

You mean you could do something like:

If-Modified-Since:
    type: datetime
    format: rfc1123

And you suggest to change to phrasing to:

The additional facet format MUST be available only when the type equals datetime, and the value MAY be either rfc3339 or rfc2616. However, the format facet is an open string-valued facet, and can have any value to support documentation needs.

Is that correct?

[KevinMitchell]

It's presumably not just for documentation needs. For example, I'm writing a custom generator to produce server code from the spec, and I'd like to provide support for formats such as rfc1123, in addition to rfc3339 and rfc2616, when it comes to generating validation code for example. So I agree there should be a small set of formats that should be supported by all tooling, but there should be some flexibility for those groups wanted to support a richer set of formats in their tooling.

[sichvoge]

We can work on the phrasing later, but the essential part is that there are two standard format which are going to be used by the spec, and for anything else; the format facet is an open string-valued facet which can have any value. Its up to the tooling / validator to support them.

[KevinMitchell]

Precisely. That way it doesn't break any of the existing specs, and is more flexible. But it will require some of the existing tooling, such as the editors, to relax their checking in this area.

[sichvoge]

Its definitely a functional change. I will move it to "Idea".

In summary, the idea is to change format to be an open string-valued facet which can have any value. Although, RAML will support rfc3339 and rfc2616. We would need to work a little bit on the wording, but the initial draft could be:

The additional facet format MUST be available only when the type equals datetime, and the value MAY be either rfc3339 or rfc2616. However, the format facet is an open string-valued facet, and can have any value to support other needs.

[sichvoge]

@KevinMitchell any possibility to get in touch with you offline? Like to connect a bit more with you. You can send me an email to christian dot vogel at mulesoft dot com