Conversation
| When storing an xAPI Profile: | ||
| * a Profile Server MUST NOT add any properties (not defined in this document) to the Profile | ||
| * a Profile Server MAY add JSON-LD keywords (or aliases thereof) to a Profile anywhere they are legal in JSON-LD | ||
| * a Profile Server MUST reject any Profiles that contain any properties not defined in this document (excluding correctly used JSON-LD keywords or aliases thereof) |
There was a problem hiding this comment.
shouldn't we use SHALL and SHALL NOT to align with IEEE style ?
There was a problem hiding this comment.
Profile Server Version handling, what are the requirements for releasing a new version. Does the author of the profile manage / maintain the profile versions or is that solely a responsibility of the profile server.
-> Initial thoughts, profile server shouldn't be the only place that handles versioning, authors should be expected to include the version info in their profiles so that the version information is not lost on upload to a profile server.
-> Profile server may offer publish mechanics which applies publishes changes to a profile as a new version
There should / will be a Profile Server subgroup that gets into the details of what the Profile Server requirements are. The requirements added here were in relation to the additional properties requirement change.
| * All properties that are not JSON-LD keywords (or aliases thereof) MUST expand to absolute IRIs during processing as defined in the JSON-LD specification. | ||
| * All properties that are not JSON-LD keywords (or aliases thereof) and not described by this specification MUST be expressed using compact IRIs or absolute IRIs. | ||
| * JSON-LD keywords (or aliases thereof) that are not specified as properties in this document MAY be included anywhere they are legal in JSON-LD. | ||
| * A Profile MUST only include properties defined in this document and JSON-LD keywords (or aliases thereof). |
There was a problem hiding this comment.
Same as previous comment
Addresses: #3