-
Notifications
You must be signed in to change notification settings - Fork 18
Description
I'm very happy to see the work @bracken put into the JSON schema. They are awesome! (I'm referring to the ones currently in json_schema/schema_1_1 on the json_schema branch.)
https://github.com/1EdTech/caliper-spec/tree/json_schema/json_schema/schema_1_1
However, the regular expression values used for pattern properties cause problems with validation of JSON. For example, consider two instances of pattern in json_schema/schema_1_1/Agent.json…
-
On line 115, for
@context…"pattern": "^http://purl.imsglobal.org/ctx/caliper/v1p1$"
That regex is invalid. (See: https://regex101.com/r/ZeE6Gk/1) The "
/" and "." characters need to be escaped because they have special meaning in a regex. Depending on which regex engine is used during the validation, the JSON input may always be marked as invalid, even when the value of its@contextproperty ishttp://purl.imsglobal.org/ctx/caliper/v1p1. -
On line 109, for
type…"pattern": "^Agent$"
The regex is valid, but this is an inefficient use of regex. Additionally, I found that using some JSON schema tools to generate JSON based on the schema would set the value of
typeto the literal string,"^Agent$". (True, that's mostly a problem with the tool I used, but the use of regex here is unnecessary.)
In each of those cases, the problems could be avoided by using const instead of pattern properties in the JSON schema. That applies to almost all the uses of pattern in the all of the JSON schema files. The only places you may need to use regexes are…
- UUID value of
idinCaliperData.json. (Although there may now be auuidJSON schema type available.) - URL value of
@contextinAggregateMeasure.json,AggregateMeasureCollection.json,Collection.json,Link.json,LtiLink.json, andToolLaunchEvent.json. In those cases, it looks like the intention is to allow the optional-extensionat the end of the URL. However, the "/" and "." characters in the first part of the regexes make them invalid.