It looks like this regex comes from default-media-type in the RAML 0.8 spec:
A custom type that conforms to the regular expression, "application\/[A-Za-z.-0-1]*+?(json|xml)"
As you mentioned in raml-spec#133, this regular expression is not valid as written.
I think the intention of this regex is to allow structured syntax stuffixes from RFC6839, and the + is pretty clearly intended to be a literal +. Also, the range .-0 doesn't make sense, and I believe the intention is to allow literal .- characters, which are explicitly permitted in RFC6838, along with a few others. I rearranged this bit so that it is interpreted by re the way the spec author appears to have intended.
The RAML 0.8 spec also says:
The property's value MAY be a single string with a valid media type
MAY … [means] that an item is truly optional … [a vendor] may omit the same item
…so I would interpret this as:
a RAML 0.8 parser would be compliant if the value of mediaType was not validated in any way
RAML 0.8 markup with a mediaType of any arbitrary value could be considered either valid or invalid by a compliant 0.8 parser
This is obviously bad, so it makes sense that RAML 1.0 changed the definition of default-media-type to something more sensible:
The value of the mediaType property MUST be a media type string conforming to the media type specification in RFC6838.
I suggest replacing all of the existing media type value validation with a simpler validator that just matches this, which should satisfy both 0.8 and 1.0 simultaneously.
It looks like this regex comes from default-media-type in the RAML 0.8 spec:
As you mentioned in raml-spec#133, this regular expression is not valid as written.
I think the intention of this regex is to allow structured syntax stuffixes from RFC6839, and the
+
is pretty clearly intended to be a literal+
. Also, the range.-0
doesn't make sense, and I believe the intention is to allow literal.-
characters, which are explicitly permitted in RFC6838, along with a few others. I rearranged this bit so that it is interpreted byre
the way the spec author appears to have intended.The RAML 0.8 spec also says:
RFC2119 says MAY is:
…so I would interpret this as:
This is obviously bad, so it makes sense that RAML 1.0 changed the definition of default-media-type to something more sensible:
I suggest replacing all of the existing media type value validation with a simpler validator that just matches this, which should satisfy both 0.8 and 1.0 simultaneously.
What do you think?