Open samuelsenj opened 3 years ago
Hello,
One way to account for this limitation is via usage of Statement Template rules which target the extension (location
) and then usage of any
, all
and/or none
to control the generated values.
{"location" : "$.context.extensions['extension-iri'].rank",
"any" : [-1.0 -0.5 0.0 0.5 1.0],
"presence" : "included"},
{"location" : "$.context.extensions['extension-iri'].medal",
"any" : ["gold", "silver", "bronze"],
"presence" : "included"}
This solution isn't ideal but it will produce data in the expected shape with consistent values. JSON schema based generation is expected to be improved in a future release.
Thank you for the explanation on how to use Statement Template rules to produce data with values as expected. I look forward to the future release where JSON schema based statement generation will be improved.
Hello,
I am currently developing an xAPI profile. As a means of profile validation I have been using DATASIM (CLI) to generate xAPI statements that conform to the profile.
I have tried adding an extension to the profile, using the
"inlineSchema"
property to specify data type and some additional restrictions with JSON schema, but mostly DATASIM does not seem to be able to reflect the additional restrictions in the xAPI statements generated.For instance I tried adding a (slightly modified) example JSON schema from the xAPI profiles specification (GitHub) to the extension in the profile:
"inlineSchema": "{ \"type\": \"object\", \"properties\":{ \"rank\": {\"type\": \"number\"},\"medal\":{\"type\": \"string\"}}, \"required\": [\"rank\", \"medal\"]}"
.When generating statements based on the profile with an extension having such an
inlineSchema
, the value of the xAPI statement extension is not as expected anobject
with propertiesrank
(value of type number) andmedal
(value of type string), but rather the extension value varies betweenstring
(e.g. '1X6m9L94OQR'),number
(e.g. 1.2574462890625), emptyobject
({}) and emptyarray
([]).Another example is that when setting the profile extension data type to
string
, and specifying either aformat
(e.g. uri, date-time) orpattern
(regular expression), I experienced that formats and patterns are not reflected in the generated xAPI statements.In the future it would be great if the generated xAPI statements could reflect the full JSON schema for extensions (and document resources) that are specified in a profile.