Case - additional data fields needed

[woodkri]

For CFDocuments/{sourcedId}:

Additional required data fields for this page: "creator" and "lastChangeDateTime".

I believe it will also need to be capable of supplying these data fields: "officialSourceURL", "publisher", "description", "subject", "language", "version", "adoptionStatus", "statusStartDate", "statusEndDate", "licenseURI", and "notes". Based on this line from the compliance specs - "They must be capable of supplying all of the optional data fields in the JSON payloads (conformance testing requires ALL data fields to be populated)".

The specs also state "They must not provide extension data fields in the JSON payloads". If this means there cannot be any data fields outside those defined in their model, then we will need to remove "@context" and "type".

For CFPackages/{sourcedId}:

Optional field of CFRubrics needed, can be an empty array. Under CFDefinitions, "CFSubject" should be "CFSubjects".

Additional required data fields for the CFItems on this page: "lastChangeDateTime". Additional optional fields we need to supply for CFItems on this page: "alternativeLabel", "humanCodingScheme", "listEnumeration", "abbreviatedStatement", "conceptKeywords", "conceptKeywordsURI", "language", "educationLevel", "licenseURI", "statusStartDate", "statusEndDate". I don't believe type or the CFDocumentURI object are needed in the CFItems array.

The CFDocument object under the CFPackages page also needs the same required and optional fields as stated up top for the CFDocuments page, but on this page the CFPackageURI is not needed.

[woodkri]

I also just noticed these need to be ordered lists. CFPackages/id is already in the right order (plus CFRubrics as the last field at the bottom of the page). Within that page, CFDocument should have fields in the following order:

identifier{1..1} ! uri{1..1} ! creator{1..1} ! title{1..1} ! lastChangeDateTime{1..1} ! officialSourceURL{0..1} ! publisher{0..1} ! description{0..1} ! subject{0..} ! subjectURI{0..} ! language{0..1} ! version{0..1} ! adoptionStatus{0..1} ! statusStartDate{0..1} ! statusEndDate{0..1} ! licenseURI{0..1} ! notes{0..1}

Also within CFPackages/id page, CFItems should have fields in the following order:

identifier{1..1} ! fullStatement{1..1} ! alternativeLabel{0..1} ! CFItemType{0..1} ! uri{1..1} ! humanCodingScheme{0..1} ! listEnumeration{0..1} ! abbreviatedStatement{0..1} ! conceptKeywords{0..} ! conceptKeywordsURI{0..1} ! notes{0..1} ! language{0..1} ! educationLevel{0..} ! CFItemTypeURI{0..1} ! licenseURI{0..1} ! statusStartDate{0..1} ! statusEndDate{0..1} ! lastChangeDateTime{1..1}

CFDocumentURI within CFItems should have fields in the following order:

title{1..1} ! identifier{1..1} ! uri{1..1}

CFDocuments page should have fields in the following order:

identifier{1..1} ! uri{1..1} ! creator{1..1} ! title{1..1} ! lastChangeDateTime{1..1} ! officialSourceURL{0..1} ! publisher{0..1} ! description{0..1} ! subject{0..} ! subjectURI{0..} ! language{0..1} ! version{0..1} ! adoptionStatus{0..1} ! statusStartDate{0..1} ! statusEndDate{0..1} ! licenseURI{0..1} ! notes{0..1} ! CFPackageURI{1..1}

CFPackageURI has fields in the correct order.

[Lomilar]

Unsure about the field ordering. OpenSALT doesn't have the given ordering.

http://opensalt.opened.com/ims/case/v1p0/CFPackages/7184d8cc-02aa-11e8-b2e3-afcff7af25c6

It may also be prudent to wait for access to the validation suite and test these. Given we can't validate this until sometime during 0.5, let's pend this work.

[woodkri]

You're right, https://caseregistry.imsglobal.org doesn't have that field ordering either.