• 1EdTech Competencies and Academic Standards Exchange (CASE) Service Version 1.1
• 1EdTech Competencies and Academic Standards Exchange (CASE) Service Version 1.1: Conformance and Certification
• 1EdTech Competencies and Academic Standards Exchange (CASE) Service Version 1.1: REST/JSON Binding
• 1EdTech Competencies and Academic Standards Exchange (CASE) Service Version 1.1: OpenAPI Schema
• 1EdTech Competencies and Academic Standards Exchange (CASE) Service Version 1.1: JSON Schema

• 1EdTech Competencies and Academic Standards Exchange (CASE) Service Version 1.1: Information Model
• 1EdTech Competencies and Academic Standards Exchange (CASE) Service Version 1.1: Best Practices and Implementation Guide

[Graphical Representation & Explanation]

Here is the CASE structure for the Curriculum Map:

{
  "CFDocuments": [
    {
      "identifier": "nursing-program-001",
      "title": "Nursing Program Outcomes",
      "publisher": "Atlas University",
      "lastChangeDateTime": "2024-03-23T23:19:53"
    }
  ],
  "CFItems": [
    {
      "identifier": "program-outcome-1",
      "fullStatement": "Demonstrate effective communication skills in a variety of healthcare settings.",
      "CFDocumentURI": "https://curriculum.myUni.edu/uri/nursing-program-001",
      "CFItemType": "Program Outcome",
      "lastChangeDateTime": "2024-03-23T23:19:53"
    },
    {
      "identifier": "program-outcome-2",
      "fullStatement": "Apply evidence-based practices to enhance patient care quality.",
      "CFDocumentURI": "nursing-program-001",
      "CFItemType": "Program Outcome",
      "lastChangeDateTime": "2024-03-23T23:19:53"
    },
    // Courses as CFItems
    {
      "identifier": "course-001",
      "fullStatement": "Introduction to Medical Coding",
      "CFDocumentURI": "https://curriculum.myUni.edu/uri/nursing-program-001",
      "CFItemType": "Course",
      "lastChangeDateTime": "2024-03-23T23:19:53"
    },
    {
      "identifier": "course-002",
      "fullStatement": "Patient Care Informatics",
      "CFDocumentURI": "nursing-program-001",
      "CFItemType": "Course",
      "lastChangeDateTime": "2024-03-23T23:19:53"
    },
    // Additional CFItems for other courses...
  ],
  "CFAssociations": [
    // Associations between Courses and Program Outcomes
    {
      "identifier": "association-1",
      "originNodeURI": "https://curriculum.myUni.edu/uri/course-001",
      "destinationNodeURI": "program-outcome-1",
      "associationType": "covers",
      "lastChangeDateTime": "2024-03-23T23:19:53"
    },
    {
      "identifier": "association-2",
      "originNodeURI": "https://curriculum.myUni.edu/uri/course-002",
      "destinationNodeURI": "program-outcome-2",
      "associationType": "covers",
      "lastChangeDateTime": "2024-03-23T23:19:53"
    },
    // Additional CFAssociations for other course-program outcome coverages...
  ]
}

[Graphical Representation & Explanation]

Here is the CASE structure for the Curriculum Map:

{ "CFDocuments": [
    {
      "identifier": "nursing-program-001",
      "title": "Nursing Program Outcomes",
      "publisher": "Atlas University",
      "lastChangeDateTime": "2024-03-23T23:19:53"
    },
    {
      "identifier": "nursing-informatics-course-001",
      "title": "Nursing Informatics Course Outcomes",
      "publisher": "Atlas University",
      "lastChangeDateTime": "2024-03-23T23:19:53"
    }  ],
  "CFItems": [
    {
      "identifier": "program-outcome-1",
      "fullStatement": "Demonstrate mastery of specialized knowledge and skills in nursing informatics.",
      "CFDocumentURI": "https://curriculum.myUni.edu/uri/nursing-program-001",
      "lastChangeDateTime": "2024-03-23T23:19:53"   },
    {
      "identifier": "course-outcome-1",
      "fullStatement": "Differentiate database standard terminologies used by different health information systems.",
      "CFDocumentURI": "nursing-informatics-course-001",
      "lastChangeDateTime": "2024-03-23T23:19:53"
    },
    {
      "identifier": "course-outcome-2",
      "fullStatement": "Apply data management techniques to decision making in nursing practice.",
      "CFDocumentURI": "https://curriculum.myUni.edu/uri/nursing-informatics-course-001",
      "lastChangeDateTime": "2024-03-23T23:19:53"
    }
  ],
  "CFAssociations": [
    {
      "identifier": "association-1",
      "originNodeURI": "course-outcome-1",
      "destinationNodeURI": "https://curriculum.myUni.edu/uri/program-outcome-1",
      "associationType": "isRelatedTo",
      "lastChangeDateTime": "2024-03-23T23:19:53”},
    {
      "identifier": "association-2",
      "originNodeURI": "course-outcome-2",
      "destinationNodeURI": "https://curriculum.myUni.edu/uri/program-outcome-1",
      "associationType": "isRelatedTo",
      "lastChangeDateTime": "2024-03-23T23:19:53"
    }
    // Additional CFAssociations for other related course and program outcomes...
  ]}

[Shows Rubric aligned to Program Learning Outcomes (PLO) diagram]

Here’s the CASE for the Rubric:

{
  "CFDocument": {
    "identifier": "rubric-nursing-informatics-001",
    "title": "Rubric for Nursing Informatics Program Outcome",
    "publisher": "Atlas University",
    "lastChangeDateTime": "2024-03-23T23:19:53",
    "CFItems": [
      {
        "identifier": "program-outcome-communication",
        "fullStatement": "Demonstrate effective communication skills in a variety of healthcare settings.",
        "CFItemType": "Program Outcome",
        "lastChangeDateTime": "2024-03-23T23:19:53"
      }],
    "CFRubrics": [
      {
        "identifier": "rubric-communication-001",
        "title": "Communication Skills Assessment Rubric",
        "CFItemType": "Rubric",
        "description": "This rubric is designed to assess the student's ability to demonstrate effective communication skills in healthcare settings.",
        "CFRubricCriteria": [
          {
            "identifier": "criterion-1",
            "description": "Clarity of Communication",
            "qualityLevels": [
              {
                "level": "1",
                "description": "The student's communication is often unclear or confusing, lacking in organization and coherence."
              },
              {
                "level": "2",
                "description": "The student's communication is somewhat clear but may have occasional lapses in organization and coherence."
              },
              {
                "level": "3",
                "description": "The student communicates clearly and effectively, with well-organized and coherent messaging."
              },
              {
                "level": "4",
                "description": "The student excels in communicating with exceptional clarity, organization, and coherence, effectively engaging the audience."
              } ]  },
          {
            "identifier": "criterion-2",
            "description": "Use of Informatics Tools",
            "qualityLevels": [
              {
                "level": "1",
                "description": "The student demonstrates limited ability to use informatics tools to support communication."
              },
              {
                "level": "2",
                "description": "The student demonstrates basic ability to use informatics tools to support communication."
              },
              {
                "level": "3",
                "description": "The student demonstrates proficient use of informatics tools to enhance communication effectively."
              },
              {
                "level": "4",
                "description": "The student demonstrates advanced use of informatics tools to optimize communication and engage stakeholders."
              } ]  }
        ],
        "CFRubricLevelsOfMastery": [
          {
            "level": "1",
            "description": "Beginning",
            "performance": "The student is beginning to develop the skills necessary for effective communication."
          },
          {
            "level": "2",
            "description": "Developing",
            "performance": "The student is developing the skills and shows potential for effective communication."
          },
          {
            "level": "3",
            "description": "Mastery",
            "performance": "The student has mastered the skills necessary for effective communication."
          },
          {
            "level": "4",
            "description": "Exemplary",
            "performance": "The student performs at an exemplary level, surpassing the established standard for effective communication."
          } ]  }  ] } }

These can be added to any curriculum map package. Now, combined with CLR, you can have a truly “closed loop” between curriculum design, assessment, and a student’s learner records.

All CASE entity types, including CFDocuments, CFItems, and CFAssociations, include the following four properties:

{
    "uri": "https://case.example.edu/ims/case/v1p0/CFItems/36f20eee-46fa-11e7-a40f-c4215637b70a",
    "identifier": "36f20eee-46fa-11e7-a40f-c4215637b70a",
    "lastChangeDateTime": "2023-12-05T16:30:06-05:00",
    "CFItemType": "Content Standard",
    "humanCodingScheme": "6.3.1",
    "fullStatement": "This is the competency statement.",
    "extensions": {
        "diamNunc": "Lorem ipsum dolor sit amet, consectetur adipiscing elit.",
        "maximus": 99,
        "dapibusEnim": {
            "suscipit": "Pellentesque ornare ac neque sit amet cursus",
            "primis": "Nam consectetur metus nec eros suscipit",
        }
    }
}

Key properties of the CFDocument entity structure are given below (this is not a complete list of all properties; see [XXX])

• identifier (required): see above

• uri (required): see above

• lastChangeDateTime (required): see above

• extensions (optional): see above

• title (required): the title of the framework (e.g. Georgia’s K-12 Standards for English Language Arts (SY2025-2026))

• creator (required): the creator of the competency framework. For example, the creator for Georgia’s state ELA standards is the Georgia Department of Education.

• publisher (optional): the entity responsible for publishing this competency framework in CASE format. Note that the creator and publisher could be the same entity; or one entity may be publishing a CASE encoding of a framework originally created by another entity. For example, CASE Network currently includes many frameworks for whom the creator is a state department of education, but the publisher is Common Good Learning Tools, who has coded the state’s frameworks in CASE format.

• adoptionStatus (optional but recommended): the publication status for the document (e.g. Implemented). Though not required, best practice is to always include a value for this property. See here for current best practices for adoptionStatus values.

• language (optional): the “base language” for the framework (e.g. en for English or es for Spanish).

• officialSourceURL (optional): a link (url) to a website or document (often a PDF) where the framework and/or the competencies in the framework are described (e.g. https://www.gadoe.org/Curriculum-Instruction-and-Assessment/Curriculum-and-Instruction/Pages/English-Language-Arts-Program.aspx). For frameworks that were not originally authored in a CASE publishing system, this is often a link to the PDF that was used as the source for the CASE “translation” of the framework.

• subject / subjectURI (optional): One or more academic areas covered by the framework (e.g. ['English']). Note that both of these properties should be represented as arrays (despite the singular property names), and that the subject(s) may be specified in the subject array or the subjectURI array or both; best practice is that if both are included, they should not specify different lists of subjects :).

• description (optional): a human-readable description of the framework/document. May include markdown or LaTeX.

• notes (optional): a space for additional comments about the framework/document. May include markdown or LaTeX.

• version (optional): there is no established best practice around what values to use for this property. Some organizations simply enter the year the framework was first implemented; some organizations use a detailed scheme to track updates to the framework; many organizations simply leave the field blank.

• licenseURI (optional): if included, this should a reference to a CFLicense object in the CFLicences array of CFDefinitions, which gives a legal description (or link to such a description) of what consumers of the framework are allowed to do with the data in the framework. Many organizations choose to leave this blank.

• statusStartDate and statusEndDate (optional): as described here, the statusStartDate and statusEndDate fields can be used to specify the date a competency framework becomes “officially implemented” by the issuing agency, and the date the framework ceases to be officially implemented.

• frameworkType (optional): new in the CASE 1.1 spec; the vocabulary for frameworkType values is open, but see here for current best practices.

• caseVersion (required in CASE 1.1 and later): new in the CASE 1.1 spec. The caseVersion property must be included in the CFDocument and have the value 1.1 for frameworks published using the CASE 1.1 spec. Since the CASE 1.0 spec did not include this property, and the 1.0 spec does not allow for non-defined properties, caseVersion must not be specified in CASE 1.0 frameworks.

Key properties of the CFItem entity structure are given below (this is not a complete list of all properties; see [XXX])

• identifier (required): see above

• uri (required): see above

• lastChangeDateTime (required): see above

• extensions (optional): see above

• fullStatement (required): the fullStatement is the official statement of the competency, as defined by the issuing agency (creator). May include markdown or LaTeX.

• humanCodingScheme (optional): a “code” for the item that is easily referrable by humans, e.g. RL.5.1. Best practice is that no two CFItems in the same framework should have the same humanCodingScheme value unless the two items are exact copies of each other (see here. Also note that this field is optional, so CASE consumers should not assume that ever CFItem will have a humanCodingScheme value.

• notes (optional): a space for additional comments about the item. For example, many frameworks include “clarifying statements” in the notes field. May include markdown or LaTeX.

• CFItemType / CFItemTypeURI (optional): specifies what type of competency the CFItem represents. There is no fixed vocabulary for item types in CASE; each framework defines a classification scheme for the CFItems in the framework via the set of CFItemTypes it utilizes. Note that each CFItem may include either a CFItemType or a CFItemTypeURI, may include both fields, or may include neither field (in which case the item type is undefined). See here for more information.

• educationLevel (optional):

• language (optional): the language in which this CFItem’s statement is expressed. Note that if an individual CFItem does not include a language field, the item should be considered to “inherit” the language field specified in the framework’s document (if the document includes a language field).

• statusStartDate and statusEndDate (optional): As described here, the statusStartDate and statusEndDate fields can be used to specify the date a competency framework becomes “officially implemented” by the issuing agency, and the date the framework ceases to be officially implemented.

Key properties of the CFAssociation entity structure are given below (this is not a complete list of all properties; see [XXX])

• identifier (required): see above

• uri (required): see above

• lastChangeDateTime (required): see above

• extensions (optional): see above

• associationType (required): isChildOf associations define the “tree structure” of a competency framework. Other association types are used to specify relationships between items, or (new in CASE 1.1) relationships between a CFItem and some other entity. See here for more information.

• originNodeURI (required) and destinationNodeURI (required): these two properties specify the two entities involved in the associations. Each is itself an object, with identifier, uri, and title fields. For most associationTypes, both should refer to a CFItem, so the identifier and uri for each node should be the identifier and uri of the referee CFItem (while the identifier and uri values that are direct children of the CFAssociation object refer to the CFAssociation itself). If the best practice for uri values is followed, the full CFItem for each node can be retrieved by making a REST API call to the node’s uri; best practice is for the title to be a human-readable indicator of the item for use when the full CFItem is not retrieved. Note that the origin CFItem, the destination CFItem, or both could “reside” in the same framework where the CFAssociation is specified, or in a different framework.

• sequenceNumber (optional; recommended for isChildOf associations): this property is only relevant for isChildOf associations, where it specifies the sequence of child items of a given parent item.

• notes (optional; new in CASE 1.1): a space for additional comments about the association. May include markdown or LaTeX.

(e.g. GA Math):

• Create a new framework with new CFItems/GUIDs, ideally include exact match/related to associations back to the previous framework’s CFItems/GUIDs
• Set statusStartDate for the new framework's document to the date the new framework will become “official” (i.e. the date the adoptionStatus for the document becomes “implemented”)

• Create new CFItems/GUIDs in the existing framework for the new items
• Set lastChangeDateTime on each CFItem to the date/time the CFItem was created
• Set lastChangeDateTime on the CFDocument to the date/time the latest new CFItem was created
• Set statusStartDate to the date the item will become (or did become) officially implemented (which may be the date the item was created, or may be before or after the creation date)

DON’T delete the CFItem set statusEndDate to date the item is deprecated optionally add text (e.g. “[DEPRECATED]”) to fullStatement (and optionally alter humanCodingScheme, e.g. by adding “X”), but do not otherwise edit the CFItem properties optionally move CFItem(s) to a different "folder" (e.g. titled “Deprecated Items”) in the framework this preserves the CFItems as a permanent record of the now-deprecated competencies.

• Update the relevant CFItem properties
• DON’T change the identifier GUID
• Make sure lastChangeDateTime is updated

• Create a new CFItem/GUID, just like adding a new item
• Deprecate the old item but keep it in the framework, just like removing an item
• Ideally include a replacedBy association from the deprecated CFItem to the new CFItem (i.e. deprecated item is originNodeURI, new item is destinationNodeURI)

• To reiterate what has been noted above, a CFItem’s lastChangeDateTime should be updated when any change is made to the item.

• In addition, any time anything in a framework is changed (e.g. a CFItem or CFAssociation is changed in any way or moved in the hierarchy, a new CFItem/CFAssociation is added, or an existing CFItem/CFAssociation is removed) update the lastChangeDateTime of the CFDocument for the framework. This is needed because many consumers check the lastChangeDateTime of the CFDocument (e.g. via the “getAllDocuments” API) to know whether or not they need to re-pull the framework data.

• DON’T change or clear the statusStartDate for a CFItem after the specified statusStartDate has passed. This allows the statusStartDate to serve as a permanent record of when the item became “official”.

• It is acceptable to move the statusStartDate forward if the date hasn’t been reached (e.g. if there is a delay in when the item becomes official)

When creating a duplicate copy of a CFItem within the same framework, a CASE publishing/authoring tool should create a new CFItem for which all fields from the original CFItem are duplicated, except that:

• CFItem.identifier should be set to a newly-minted GUID.
• CFItem.uri should be set to a new URI value including the new GUID.
• CFItem.lastChangeDateTime should be set to the date/time the copy is being created.
• CFItem.extensions.sourceItemIdentifier should be set to the identifier (GUID) of the original CFItem -- unless the original CFItem itself includes an extensions.sourceItemIdentifier value, in which case the extensions.sourceItemIdentifier value from the original should be copied to the duplicate.
• Similarly, CFItem.extensions.sourceItemURI should be set to the original CFItem’s uri value, or the original’s extensions.sourceItemURI if it existed.
• For the original source-of-truth CFItem, CFItem.extensions.sourceItemIdentifier/CFItem.extensions.sourceItemURI may optionally be set to duplicate the item’s identifier/uri. This can serve as an indicator that this item is duplicated elsewhere in the framework.

Referencing the best practices stated earlier for changes to CFItems, if changes are made to the duplicate CFItem that do not, in the agency’s judgment, change the meaning of the standard, the sourceItemIdentifier value should remain pointing back to the original item.

However, if the duplicate CFItem is later changed substantially (in the judgment of the issuing agency), the sourceItemIdentifier/sourceItemURI values should be cleared from the duplicate item. Again, it is up to the agency to determine if/when a change merits breaking the link from the copy to the original. If the link is broken, the agency may choose to add an isRelatedTo association (or some other associationType) to retain a more tenuous connection from the copy to the original.

This best practice allows CFItems representing competencies that exist in multiple contexts within the framework to have a clear reference to the original source of truth of the competency (the sourceItemIdentifier) while also having a clear indicator of the unique context in which this version of the competency exists (the identifier). This in turn means that systems aligning resources to standards can use sourceItemIdentifier as a straightforward way to know when a resource aligned to one competency should probably be aligned to other identical competencies.

Example: California’s high school math standards are reswizzled in two alternative “pathways”, and are also included in the math framework organized by “conceptual category”, so many of the standards are instantiated in three different places in the framework. The “original” version of CFItem HSN-RN.A is coded as:

{
    "identifier": "7bb99e2f-d7cc-11e8-824f-0242ac160002",
    "uri": "https://satchelcommons.com/ims/case/v1p0/CFItems/7bb99e2f-d7cc-11e8-824f-0242ac160002",
    "humanCodingScheme": "HSN-RN.A",
    "fullStatement": "Extend the properties of exponents to rational exponents.",
    "CFItemType": "Cluster",
    "educationLevel": ["09","10","11","12"],
    "language": "en",
    "extensions": {
        "sourceItemIdentifier": "7bb99e2f-d7cc-11e8-824f-0242ac160002",
        "sourceItemURI": "https://satchelcommons.com/ims/case/v1p0/CFItems/7bb99e2f-d7cc-11e8-824f-0242ac160002"
    }
    "lastChangeDateTime": "2018-10-24T20:56:19+00:00",
}

and one of the duplicates is coded as:

{
    "identifier": "894e79b2-9014-49e1-a0fb-3683ad13c6b5",
    "uri": "https://satchelcommons.com/ims/case/v1p0/CFItems/c6487102-d7cb-11e8-824f-0242ac160002",
    "humanCodingScheme": "HSN-RN.A",
    "fullStatement": "Extend the properties of exponents to rational exponents.",
    "CFItemType": "Cluster",
    "educationLevel": ["09","10","11","12"],
    "language": "en",
    "extensions": {
        "sourceItemIdentifier": "7bb99e2f-d7cc-11e8-824f-0242ac160002",
        "sourceItemURI": "https://satchelcommons.com/ims/case/v1p0/CFItems/7bb99e2f-d7cc-11e8-824f-0242ac160002"
    },
    "lastChangeDateTime": "2024-01-18T17:11:28+00:00",
}

Now consider use cases where we wish to create a duplicate copy of a CFItem in a different framework — that is, we wish to include a duplicate CFItem from framework A (e.g. a state’s Science learning standards framework) in a different framework B and not changed in any way (e.g. in a school district’s local Science learning standards framework). The previous best practice of making new CFItems, with new GUIDs, in “derivative” frameworks such as these leads to two problematic issues:

• First, once there are multiple copies of a CFItem out there, how do we know which one should be considered the “source of truth” for the underlying competency?

• Second, consider a world down the road where all 100+ school districts in Georgia have created “derivative frameworks” from the GA Math state standards. In this world there are 100+ different GUIDs representing standard MP3. For a resource provider looking to align resources for all 100+ districts, it would be challenging (to say the least) to maintain alignments to all 100+ GUIDs.

The new best practice for this use case is to not create a new CFItem at all. Instead, framework B should “alias” the original items from framework A (with their original GUIDs) via isChildOf CFAssociations that reference those items from framework A in the associations’ originNodeURIs and/or destinationNodeURIs. This is diagrammed below.

Best practice is that the CFItems from framework A that are aliased in framework B should be included in the CFPackage for framework B, so that another system requesting the entire package for framework B via the getCFPackage API does not need to make separate requests for the aliased items. However, if the getCFItem API is called for an aliased item, the returned CFDocumentURI attribute should reference the item’s original framework (framework A).

An additional best practice is to include, for each isChildOf CFAssociation that references an aliased item in its originNodeURI, two extension properties: extensions.sourceDocumentIdentifier and extensions.sourceDocumentURI. These properties should point to the “source of truth” (i.e. framework A) for the originNodeURI CFItem.

Example: the original source-of-truth CFItem for Georgia’s science standard S8P1 is:

{
    "uri": "https://case.georgiastandards.org/uri/5e84a138-416e-11e7-9c16-f09b61c8dfdf",
    "identifier": "5e84a138-416e-11e7-9c16-f09b61c8dfdf",
    "humanCodingScheme": "S8P1",
    "fullStatement": "Obtain, evaluate, and communicate information about the structure and properties of matter.",
    "CFItemType": "Content Standard",
    "educationLevel": ["08"],
    "language": "en"
    "lastChangeDateTime": "2022-12-05T16:32:01-05:00",
}

Columbia County (GA)’s derived science framework includes standard S8P1. In this framework’s CFPackage, the CFItem for S8P1 is identical to the CFItem above. The CFAssociation for S8P1 is:

{
    "identifier": "f979ab3e-6254-4b16-8b0a-294ea709498b",
    "uri": "https://satchelcommons.com/uri/f979ab3e-6254-4b16-8b0a-294ea709498b",
    "associationType": "isChildOf",
    "originNodeURI": {
        "title": "S8P1 Obtain, evaluat…",
        "identifier": "5e84a138-416e-11e7-9c16-f09b61c8dfdf",
        "uri": "https://case.georgiastandards.org/uri/5e84a138-416e-11e7-9c16-f09b61c8dfdf"
    },
    "destinationNodeURI": {
        "title": "Physical Science",
        "identifier": "3f32c319-a308-4941-8055-c74dd21c1fbe",
        "uri": "https://satchelcommons.com/uri/3f32c319-a308-4941-8055-c74dd21c1fbe"
    },
    "extensions": {
        "sourceDocumentIdentifier": "27a08dc6-416e-11e7-ba71-02bd89fdd987",
        "sourceDocumentURI": "https://satchelcommons.com/ims/case/v1p0/CFItems/27a08dc6-416e-11e7-ba71-02bd89fdd987"
    },
    "lastChangeDateTime": "2023-02-09T20:49:53+00:00",
    "sequenceNumber": 2
}

Note here that:

• The destinationNodeURI (which refers to the “parent” of the aliased S8P1 item), as well as the CFAssociation itself, have uri values pointing to the satchelcommons.com CASE server, which is where Columbia County’s framework is published.
• The originNodeURI includes the identifier and uri of the CFItem from the Georgia science framework, and the sourceDocumentIdentifier/sourceDocumentURI values point to the Georgia science framework itself; note that these two uris point to the case.georgiastandards.org server, which is Georgia’s CASE publishing tool.

The Course Code framework is intended to provide a shared implementation of Course Metadata in K12 that can be shared between states, districts, and educational product vendors. The intent is to describe a basic framework that can be extended by implementers as needed.

{
  "CFDocument": {
    "uri": "https://casenetwork.imsglobal.org/uri/c1a5ce8d-5843-56e0-a93f-1bc555bf8093",
    "identifier": "c1a5ce8d-5843-56e0-a93f-1bc555bf8093",
    "frameworkType": "CourseCodes"
  },
  "CFItems": [
    {
      "fullStatement": "Physical Education 1",
      "abbreviatedStatement": "",
      "uri": "https://casenetwork.imsglobal.org/uri/2faeeb94-7085-56e0-a4fa-9b45b21cf9d7",
      "identifier": "2faeeb94-7085-56e0-a4fa-9b45b21cf9d7",
      "CFItemTypeURI": {
        "title": "CourseCode",
        "identifier": "fe2fda94-d9ea-5f34-8f71-592abc9c0ec5",
        "uri": "https://casenetwork.imsglobal.org/uri/fe2fda94-d9ea-5f34-8f71-592abc9c0ec5"
      },
      "subject": "Physical Health",
      "HumanCodingScheme": "35420000",
      "Description": "Physical Education I focuses on instructional strategies through a planned, sequential, and comprehensive physical education curriculum which provides students..."
    }
  ],
  "CFItemTypes": [
    {
      "uri": "https://casenetwork.imsglobal.org/uri/fe2fda94-d9ea-5f34-8f71-592abc9c0ec5",
      "identifier": "fe2fda94-d9ea-5f34-8f71-592abc9c0ec5",
      "title": "CourseCode",
      "description": "This represents a Course Code as documented: https://www.imsglobal.org/activity/case",
      "typeCode": "CourseCode",
      "hierarchyCode": "CourseCode"
    }
  ]
}

However, CASE 1.1 specifies that, whenever possible, Markdown SHOULD be supported by clients when rendering the CFItem fullStatement, and notes/descriptions on all CASE objects, e.g. by using a Javascript library such as Marked. Markdown is supported because one of the primary goals of the Markdown syntax is that “unrendered” Markdown will still be readable.

There are many “flavors” of Markdown, and CASE 1.1 does not specify exactly which flavors are supported, nor does it specify exactly which parts of the Markdown syntax should be rendered. But a basic list of formatting options that we recommend be supported includes:

Inline Elements:

• Essential to support: *italics* or _italics_ for an italicized string (html <em> tag)
• Essential to support: **bold** or __bold__ for a bold string (html <strong> tag)
• May be supported: surround text with “backticks” ( ` characters) for a span of code (html <code> tag)
• May be supported: [link](https://example.com) for a link
• May be supported: ![Abraham Lincoln](https://tinyurl.com/547dtew2) for an image: (Note however that there is no way to size images in Markdown, so images may be better coded as links to the image file.)

Lists:

May be supported: A bulleted list is created by starting a line with a single *, -, or + character. Multi-level lists can be created by indenting the starting *, -, or + of a line with a tab character or two space characters. So this:

* Item 1
* Item 2
  * Item 2a
* Item 3

Should render like this:

• Item 1
• Item 2
  • Item 2a
• Item 3

May be supported: An ordered list is created by starting each line with a number followed by a period. So this:

1. Bears
2. Beets
3. Battlestar Galactica

Should render like this:

1. Bears
2. Beets
3. Battlestar Galactica

Note that in order to support lists, CASE fields may include newline characters (\n). When unrendered, a newline character is expected to be treated the same as a space character, but when rendered via a library such as Marked, the newlines will be translated according to the Markdown syntax rules.

Competencies for some academic disciplines, particularly STEM fields, often include mathematical and/or scientific notations, and there are situations where understanding of a competency requires the expression of a complex formula or construct that cannot be adequately rendered in plain text. For these situations, CASE 1.1 specifies that, whenever possible, clients SHOULD support the rendering of LaTeX-style math statements, e.g. by using a Javascript library such as KaTeX or MathJax.

LaTeX is an extremely rich document preparation syntax; CASE expects only that LaTeX “math mode” be supported. More specifically, strings surrounded by dollar signs (\$) should be rendered as equations; and to allow for the use of dollar signs in non-math contexts, we recommend that equations should only be rendered if:

• the opening \$ of an equation has [a space character, an opening parenthesis, or an opening square or curly bracket] immediately before it, but is immediately followed by a non-space character,
• while the closing \$ of an equation is immediately preceded by a non-space character, but is immediately followed by [a space character, a closing parenthesis, a closing square or curly bracket, or a comma, period, colon, semicolon, or question mark].

Thus $x^2 + \frac{1}{2z}y = 43$ should be rendered as an equation (), whereas \$5.10 should be rendered as $5.10.

Note that that like Markdown, an unrendered LaTeX equation should still be intelligible to a reader, especially if they have some familiarity with the subject matter. Coding an equation as LaTeX serves to explicitly signal that the string should be interpreted as an equation, so it may be worth coding even single variables (e.g. \$x\$, rendered as ) and simple formulas (\$F = ma\$, rendered as ). See this page for a useful summary of some of what one can do with LaTeX math formatting.

See this appendix for more examples of markdown text and LaTeX and how they would be properly rendered. </code></strong></em>