1.1 Status of this document

This document is in IMS Final release status, meaning the technical specification is also in Final release status. IMS members are currently working towards successful completion of conformance certification.

IMS strongly encourages its members and the community to provide feedback to continue the evolution and improvement of the OneRoster standard. To join the IMS developer and conformance certification community focused on OneRoster and the other related IMS standards please visit the IMS EduERP alliance online here: https://www.imsglobal.org/lis/alliance.html

1.2 Where Can I Get Help?

If you have questions or need help with implementing OneRoster or achieving conformance certification, here are some available resources:

• Public Forum - for all parties interested in OneRoster.
• OneRoster Support - for EduERP Alliance, Affiliate, and Contributing Members.
• OneRoster Developer FAQs - series of articles published by the IMS staff answering frequently asked implementation questions.
• IMS Contributing Members have access to private GitHub repositories and a Slack channel for OneRoster Project Group discussions and collaborations. Contact an IMS staff member to gain access.

1.3 Conformance Certification

IMS offers a process for testing the conformance of products using the IMS certification test suite. Certification designates passing a set of tests that verify the standard has been implemented correctly and guarantees a product’s interoperability across hundreds of other certified products. The OneRoster 1.2 Conformance Certification Guide [OR-CERT-12] provides details about the testing process, requirements, and how to get started.

Conformance certification is much better than claims of “compliance," since the only way IMS can guarantee interoperability is by obtaining certification for the latest version of the standard. Only products listed in the official IMS Certified Product Directory can claim conformance certification. IMS certification provides the assurance that a solution will integrate securely and seamlessly into an institution's digital learning ecosystem.

In order to become certified a paid IMS membership is necessary. Here's why: while conformance certification provides a "seal" for passing prescribed tests it is much more than that. It is a commitment by a supplier to the IMS community for continuous support for achieving "plug and play" integration. Certification implies ongoing community commitment to resolve problems, revise implementations and retest as need. For that reason, only IMS Contributing Members, Affiliate Members and Alliance members are eligible to apply for conformance certification. Details and benefits of membership are listed at https://www.imsglobal.org/imsmembership.html.

1.4 Product Directory Listing

The IMS Certified Product Directory is the official listing of products that have passed IMS Global conformance certification testing. Products that are listed in this directory are guaranteed to meet the IMS standards for which they have passed testing. If you experience an integration issue with a product listed here, IMS will work with the supplier to resolve the problem. If a product is NOT listed here it has either not passed IMS testing or its certification has expired.

1.5 Acronyms

The following acronyms are used in this document

2.1 REST Documents

• Rostering Service Documents
• OneRoster 1.2 Rostering Service Information Model
• OneRoster 1.2 Rostering Service REST Binding
• Gradebook Service Documents
• OneRoster 1.2 Gradebook Service Information Model
• OneRoster 1.2 Gradebook Service REST Binding
• IMS Assessment Results Profile for Gradebook Service
• Resource Service Documents
• OneRoster 1.2 Resource Service Information Model
• OneRoster 1.2 Resource Service REST Binding

2.2 CSV Documents

• OneRoster 1.2 CSV Binding

2.3 Supporting Documents

• OneRoster 1.2 Implementation Guide
• OneRoster 1.2 Conformance and Certification Guide

3.1 OneRoster Process Flow

OneRoster defines two roles, a Provider and a Consumer. Technical administrators or other users of the CSV will export from the Provider system such as a student information system and import to a consumer system, such as an LMS or a digital text. REST API-based products adopt the same concepts but users are not handling files directly since the exchange is system-to-system.

3.2 Additional Product Considerations

When selecting products it is very important to understand what OneRoster product type you are considering purchasing. Will the product be a OneRoster Provider or a OneRoster Consumer? Or is the product performing an Aggregator service, which is a Consumer of data from one system and Provider of that data to another system? An Aggregator service usually performs additional value-added services to help make the onboarding and enrollment of students in multiple platforms easier and more efficient. Because of their intermediary role, to be compliant, Aggregator product types must be certified as both Consumers and Providers.

5.1 Specification-wide Changes

5.2 Rostering Service Changes

Changes have been made to the rostering service to support the following use cases.

5.3 Gradebook Service Changes

5.4 Resource Service Changes

6.1 Identifiers and Their Use

6.2 User Status and User Record Status

The enabledUser field originates from the status field in OR 1.0. In discussing the status field values in OR 1.0 as they are used in 'users.csv', a problem was identified in that the delta mode submissions carried more information than could be expressed in bulk mode. In delta mode, using the status field, one could distinguish a user as needing to be deleted, as being current and active, and as being current but not active. In bulk mode, there are two states, "the row is present in the csv", which most closely corresponds to the delta status of active and "the row was in a previous submission but is now missing from the CSV", which most closely corresponds to the delta status of tobedeleted. So there is an entire value, inactive, which cannot be modeled in a bulk transmission in OR 1.0.

Further discussion revealed that the distinction between active and tobedeleted was a concern of the data exchange protocol, whereas the distinction between active and inactive was useful entity data. Further investigation found that the distinction was only ever intended for users.

Given those observations, it was decided to eliminate inactive as a status for all files, and for the Users class, add a new field, enabledUser. EnabledUser is used to expresses the distinction between the OR 1.0 active and inactive statuses. OR 1.1 fixed this flaw that bulk files cannot express all three states. Now they can, with "row present" and "row missing" being an indication of active vs tobedeleted, and, for 'users.csv', the enabledUser field indicating the distinction between OR 1.0's active and inactive. This support continues in v1.2.

Since the status field was mandatory in OR 1.0 delta submissions, the enabledUser field was made mandatory in later versions of OR. The ability to accept and understand the inactive status was mandatory in OR 1.0 as well, so it does not add further constraint to later versions of OR to require that a processor accept the enabledUser field.

6.3 Consideration of Learning Objective Support

OneRoster 1.2 added support for Learning Ojbectives via the ability to attach a set of learning objectives and their scores to line items. This is accomplished by attaching the guid for the appropriate learning objective to via the use of the new 'learningObjectiveIds' class.

Additionally, a result object has both a score and a textScore attribute. The result field is used to store numeric scores; the textScore is used to store non-numeric scores.

The resultValueMin and resultValueMax attributes are provided to give context for the score attribute and must not be used to interpret the textScore attribute.

The service provider should return an error code of 422, unprocessable entity, if they do not support standards-based grades. The service provider must be able to retain the right to require numeric values for their specific implementation.

6.4 Access to Specific Information

In some cases it may be desirable for an API provider to allow for the restricting of data to individual consumers without relying on the consumer’s proper use of query filters. This concept is different than what you normally see with OAuth scopes because while OAuth scopes define access to individual endpoints, data scoping may allow for limited access to data within each endpoint. Common examples of data scoping include:

6.5 Resource License Allocation & Tracking

OneRoster 1.2 enhances systems ability to exchange resource allocation information. It may additionally be necessary for content providers to communicate not only the allocation of resources to a user or class but also the associated licensing information for customers / partners in order to facilitate resource binding and accurate licensing.

To accomplish this, a system can extend OneRoster (either REST or CSV) with an extension of the 'OrgResources' data set provided by the content provider extended to includes the following additional metadata fields:

• License_StartDate
• License_EndDate
• metadata_LicenseType
• metadata_LicenseValue

In this model, metadata_LicencyeType is defined as an enumerated list consisting of the following suggested values: Concurrent Users, Seat Count, Class Count, Concurrent User Type

The content consumer would then use the data in these metadata fields to populate their ‘CourseResources’ or ‘ClassResources’ data according to the aggregate metadata_ LicenseValue limits for a given resource that are active as of the metadata_StartDate and metadata_EndDate values

It should be understood that there may be multiple instances of a license for a resource as it may have been provisioned at different times. It would be useful for the content consumer to provide a warning when over enrollment happens or when licenses are nearing exhaustion.

6.6 Filtering fields in an array

The existing specification query syntax can be used to filter on fields in an array (e.g. a collection of userIDs on a User object). To achieve this, one should use the 'Contains' operator to inspect the contents of the array and find an object with multiple matched attributes. For example, to find a user with a sisId of 500, the syntax would be:

user.userIds~(type='sisId'ANDidentifier='500')

6.7 Supporting need for multiple phone numbers

It can sometimes be necessary to provide multiple phone numbers for some users. This makes contact possible when one of the phone numbers is unavailable or untenable for any reason. While OneRoster 1.2 supplies only one phone number field in the user class. There are 2 recommended paths to follow if you need multiple phone numbers.

• Put the second number in the sms field of the user record. If you do this, you need to agree that this number can be used for voice calls.
• Add a field via extension mechanisms. The suggested field name is metadata.secondaryPhone

7.1 File Encoding and File Ordering

The file format for each of the data files is a comma separated values format (CSV) as specified in RFC 4180 with the extra restriction that carriage-returns are not permitted within a field. Fields containing commas and double-quotes must be enclosed in double-quotes. If double-quotes are used to enclose a field, then a double-quote appearing inside the field must be escaped by preceding it with another double-quote.

The CSV files must be UTF-8 encoded RFC3629. Importing processors must tolerate BOM (Byte Order Mark) prefixes and ignore them. In a UTF-8 encoded file with a BOM, the BOM will appear as the 3-byte sequence ‘EF BB BF’ at the beginning of the file. If present, the CSV header will begin at the 4th byte of the file; if not present, the CSV header will begin at the 1st byte of the file.

When the data is exchanged as CSV files, there will be 1-14 CSV files. An exchange MUST include the ‘manifest.csv’ file. The case of when only the ‘manifest.csv’ is supplied is used to denote that no updates occurred. At most, 14 CSV files exchanged i.e. there MUST NOT be more than one of each of the data CSV files. When the set of files are for bulk processing then they must be semantically consistent i.e. every object referenced in a file must also be defined in either the same, or one of the other files in the zip package.

The CSV files will be exchanged as a zip file. The encompassed files must be at the root level i.e. they MUST NOT be contained within an enclosing directory. There is NO constraint on the name of the zip file but it must have a file extension of ‘zip’. The compression must conform to RFC1951. Within the zip file there is NO preferred ordering of the CSV files.

7.2 Exchanging the CSV Files

The CSV files should be exchanged as a zipped file. These files must NOT be encrypted otherwise they will not pass validation: the transport mechanism is responsible for encrypting the data and so protecting the integrity of the CSV files.

The transport mechanism is out the scope of the CSV Binding.

7.3 Round-tripping Between OneRoster Versions

It is good best practice to support round-tripping between OneRoster versions without losing data. For example, consider when an organization submits a OR 1.2 CSV file to a OneRoster gateway that needs to support downstream consumers who support 1.2 as well as systems that only support 1.1. In this scenario sends it in v1.1 form, but rather than throwing away fields which are not part of the v1.1 specification, these are encoded as metadata fields of the same name.

For example if the v1.2 'users.csv' includes data in the 'primaryOrg' field convert that to a 'metadata.orv1p2.primaryOrg' field in the equivalent ORv1.1 CSV. While the 1.1 conformant system may not understand the semantics of 'primaryOrg', it may support the display of the metadata fields, including primary org to end users who need this information, and it may also have use where a system allows search filters include meta-data fields make use of the 'primaryOrg' information by filtering on 'metadata.orv1p1.primaryOrg'.

When converting between versions ALL the columns with 'metadata.**' should be placed as the final set of columns (the order is NOT significant).

7.4 Ensuring Semantic Consistency

For bulk exchange the set of CSV files MUST be semantically complete i.e. if a sourcedId reference for an object is used in one of the CSV files then that object MUST be defined somewhere in the set of CSV files (it may be the CSV file in which the reference occurs). The data models for the CSV files means that the following groups of files may be exchanged with the accompanying constraints of:

• 'academicSessions.csv' - this file may contain references to other academicSessions and so ALL such definitions must be contained within the same file. This CSV file may be exchanged independently of other files;
• 'categories.csv' - this file contains no references to other files and so it may be exchanged independently of other files;
• 'classes.csv' - this file MUST contain references to the relevant academisSession, course and organization objects. Therefore it must be accompanied with the 'academicSessions.csv', 'courses.csv' and 'orgs.csv' files;
• 'classResources.csv' - this file MUST contain references to the relevant academisSession, class, organization and resource objects. Therefore it must be accompanied with the 'academicSessions.csv', 'classes.csv', 'orgs.csv' and 'resources.csv' files;
• 'courseResources.csv' - this file MUST contain references to the relevant academisSession, course, organization and resource objects. Therefore it must be accompanied with the 'academicSessions.csv', 'courses.csv', 'orgs.csv' and 'resources.csv' files;
• 'demographics.csv' - this file MUST contain references to the relevant organization and user objects. Therefore it must be accompanied with the 'orgs.csv' and 'users.csv' files;
• 'enrollments.csv' - this file MUST contain references to academicSession, class, course, organization and user objects. Therefore it must be accompanied with the 'academicSessions.csv', 'classes.csv', 'courses.csv', 'orgs.csv' and 'users.csv' files;
• 'lineItems.csv' - this file MUST contain references to academicSession, categories, class, course, organization and user objects. Therefore it must be accompanied with the 'academicSessions.csv', 'categories.csv', 'classes.csv', 'courses.csv', 'orgs.csv' and 'users.csv' files;
• 'courses.csv' - this file MUST contain references to the associated organization and may contain references to academicSession objects. Therefore it must be exchanged with an 'orgs.csv' file and may require an 'academicSessions.csv' file;
• 'orgs.csv' - this file may contain references to other organizations and so ALL such definitions must be contained within the same file. This CSV file may be exchanged independently of other files;
• 'resources.csv' - this file contains no references to other files and so it may be exchanged independently of other files;
• 'results.csv' - this file MUST contain references to academicSession, categories, class, course, lineItem, organization and user objects. Therefore it must be accompanied with the 'academicSessions.csv', 'categories.csv', 'classes.csv', 'courses.csv', 'lineItem.csv', 'orgs.csv' and 'users.csv' files;
• 'users.csv' - this file MUST contain references to the associated organization and may contain references to other user objects (whose definition must be contained within the same file). Therefore it must be exchanged with an 'orgs.csv' file.

The full details of this grouping of files is available in the OneRoster CSV definition OneRoster 1.2 CSV Binding. However, it should be noted that an implementation may require/supply more than the minimum set of semantically consistent files. For example is not uncommon to encounter implementations to require/provide the following sets of files:

• For Rostering exchange - 'academicSessions.csv', 'classes.csv', 'courses.csv', 'enrollments.csv', 'orgs.csv' and 'users.csv' files;
• For Resource exchange - 'academicSessions.csv', 'classes.csv', 'classResources.csv', 'courseResources.csv', 'courses.csv', 'enrollments.csv', 'orgs.csv' and 'resources.csv', 'users.csv' files;
• For Gradebook exchange - 'academicSessions.csv', 'categories.csv', 'classes.csv', 'courses.csv', 'enrollments.csv', 'lineItems.csv', 'orgs.csv', 'results.csv' and 'users.csv' files;

7.5 Extending the Data Model for the CSV Files

Open vocabularies MAY be extended. These extensions should take the form of a URI so that the creator of the term is also supplied.

For CSV exchange, the data model can only be extended by adding new columns to the end of the defined set of columns. A suitable naming convention should be used for the new header names. An example is: metadata.[orglabel].[namepart] Where:

• 'metadata' is the initial set of characters for all extensions;
• [orglabel] is the label used to identify the organization that has created the extension. In the case of an extension from IMS Global this field will be empty and one of the delimiters removed;
• [namepart] the unique header name part allocated by the organization for the data model.

Examples are: 'metadata.hmh.homeemail', 'metadata.pearson.namesuffix', etc.

7.6 Suggested Extension Fields

Below are a set of suggested metadata fields that can be added to some of the OneRoster 1.2 CSV files as well as the rationale behind using them.

8.1 Compatibility of the REST API between Versions

A system that is certified as OneRoster 1.0 or 1.1 must be separately certified for OneRoster 1.2 compliance. Updating an OR 1.0 or 1.1 system for OR 1.2 conformance testing requires the following changes:

• The base URL must be changed from '/ims/oneroster/v1p1' to /ims/oneroster/{rostering|gradebook|resources}/v1p2.
• The redefinition of the required endpoints (classified in the three groups of rostering, resources and gradebook) should be inspected (in OR 1.0 there was no subgrouping and support for only a subset of the endpoints is required). A set of new endpoints have been added.
• The detailed data models must be investigated. A number of optional additional attributes have been made to the data models, some attributes in the data models have been renamed and some have had their types refined. These have created significant differences in some of the JSON payloads.

8.2 Authentication

OneRoster 1.2 requires OAuth 2.0 Bearer Tokens (Client Credentials Grant) as the authentication mechanism. Use of OAuth 1.0a message signing has been removed. For more information please review the IMS Security framework document.

8.3 Read, Write, Delete Choreography Implications

In OR 1.2, Read, Write and Delete choreography is only an issue for the Gradebook services endpoints. The set of Read endpoints provide the data 'pull' capability whereas the Write/Delete provide the 'push' capability. The specification does not prescribe any specific choreography. A choreography is defined to realize a specific workflow but the OR specification is designed to enable a wide range of workflow. Typically, a workflow will require a mix of the 'pull' and 'push' endpoints. Some issues to be considered when realizing a workflow are:

• The Write and Delete endpoints can only operate on a single object at a time. Therefore, the REST API should not be used for large-scale deletions and data creation;
• When an object has been 'deleted' the 'sourcedId' MUST not be reallocated and a Read request on that 'sourcedId' MUST result in a read failure (with a HTTP 404 code);
• Care should be taken to avoid overlapping Read/Write requests at a Provider i.e. a Provider should not issue a Write request to a Consumer that has an incomplete Read request being processed by the Provider;
• Care should be taken to avoid overlapping Read/Write requests at a Consumer i.e. a Consumer should ensure that a received Write/Delete request does not conflict with a concurrent and incomplete Read request. The manner in which the conflict is avoided is implementation dependent.

8.4 Gradebook Exchanges

8.5 Matching End-to-End Service Capabilities

The available certifications for a OR 1.2 REST implementation is summarized in Table 5.1.

Therefore, when matching whether or not two certified OR 1.2 REST systems can exchange data the following rules should be applied:

• A Provider/Consumer pair WILL have core endpoint interoperability if they support the same mode(s) pairings of operation i.e. rostering/rostering, resources/resources, gradebook(pull)/gradebook(pull) and gradebook(push)/gradebook(push) pairings;
• For a common pairing there will also be interoperability for ANY of the optional endpoints that are supported by both the provider/consumer;
• Only the mandatory data attributes are guaranteed to be exchanged. Different systems will support different combinations of the optional data attributes and so a mapping between the capabilities of the provider/consumer must be undertaken (this information is not available from the IMS certification report or the IMS product database);
• ALL REST implementations MUST support the OAuth 2.0 Bearer Tokens (Client Credentials Grant).

8.6 Escaping Characters in Filter Criteria

Section 6.1 describes the file encoding requirements for OneRoster CSV. Additionally It is necessary in some scenarios to escape a character that exists within the text of a field in the filter criteria of a REST call. The way to add filter criteria is to surround the text with single quotes. However if you require a single quote character as a value in the filter string then use a double single quote to escape that character.

For example, to do a filter for users with the last name O'Connor you would send a GET to.

.../oneroster/ims/oneroster/v1p2/users?filter=lastName='o''connor'

8.7 Enhance filter syntax to support filtering fields in an array

The existing specification query syntax may be used to filter on fields in an existing array (e.g. a collection of userIDs on a User object). To achieve this, one should use the ‘Contains’ operator to inspect the contents of the array and find an object with multiple matched attributes. For example, to find a user with a sisId of 500, the syntax would be:

user.userIds~(type='sisId'ANDidentifier='500')

8.8 Extending the REST API

By definition the creation and use of extensions creates features that are not interoperable. Extensions must NOT be used to replace the supported functionality. Extensions should be created as a last resort. There are two ways in which the REST API can be extended:

• Adding endpoints - new endpoints can be defined and added to the API. Such endpoints should follow the pattern of the established endpoints and the associated JSON payloads should be well defined and, if required, use the same data model extension method as used for the other endpoints;
• Adding to the data model - the data model includes a 'metadata' class that MUST be used when new attributes are to be added to a JSON payload (the use of this class is explained in the OneRoster 1.2 specification [OneRoster, 17a]. The addition of attributes into a JSON payload using any other technique is PROHIBITED;
• Adding Scopes - new scopes can be defined and agreed to between partners. Such scopes should be defined and agreed to between partners. The considerations are detailed below.

It is recommended that organizations that wish to create extensions contact IMS Global (Lisa Mattson, IMS COO).

8.9 Extending the Scopes

The OneRoster 1.2 REST Binding documents for each service define the set of specified scopes. However it can be valuable at some times to create specific and refined access to specific information as needed to support a given integration. The url naming pattern for the scope should be "http://purl.imsglobal.org/spec/or/v1p2/scope/[scopename].operation" and should be recognizable for the access that it provides.

The scope should provide access to a specific set of the OneRoster 1.2 operation endpoints as defined by the specification that are not already covered by the OneRoster 1.2 service bindings.

When defining the definition of the scope between the integration partners the operation, HTTP Verb and Endpoint's included should be defined.

For Example if you have an integration with an application looking to provide notifications to users with the guardian role, you may wish to limit their access to only the get users and get individual user endpoints. That scope might be defined as:

• Scope URL: "http://purl.imsglobal.org/spec/or/v1p2/scope/rostering-guardian.readonly"

9.1 Making Roster Information Available

Rostering data can be made available through the REST API or as a set of exported CSV files. Exported CSV files should be used when real-time availability is not required and/or when the size of the data-set is excessive i.e. gigabytes. Once the zip file containing the CSV files has been created the method of exchanging the file is implementation dependent. The REST API makes collections of data sets available depending on the endpoint i.e. all of the 'user' objects are available from one endpoint, a separate endpoint is used for obtaining all of the 'course' objects, etc. Therefore, obtaining a mixed set of objects requires the use of more than one endpoint (the corresponding choreography is implementation dependent). The REST API permits reading of the roster data ONLY i.e. the consumer MUST issue a read request to the provider.

9.2 Establishing and Maintaining a District Repository for K-12 Information

Large-scale data aggregation should be realized using CSV Import. The manner in which the zip file data is made available for import is implementation dependent i.e. it is NOT defined as part of the OR specification. The supplier of the CSV files is responsible for assigning/identifying each record with a 'sourcedId'. Therefore, there may be 'sourcedId' clashes when zip files are supplied from more than one supplier/source. Import of a set of CSV files using the bulk mode is used to establish/redefine the data set whereas the delta mode is used to update the data set. The aggregation of data from multiple sources should be carefully managed to ensure that data separation/integrity is managed appropriately.

9.3 Identification of Resource Allocation

OR 1.2 continues to support the ability to identify the set of resources that are required for a class and/or course. This identification uses a GUID for the resource i.e. it does not include the actual resource (one way of obtaining the resource is to use an IMS Common Cartridge/Thin Common Cartridge which provides the access to the resource via an identifier). The resource identification can be supplied using either CSV-based or REST API-based exchange.

9.4 SIS/LMS Exchange of Gradebook Information

OR 1.2 expands on the support for the exchange of gradebook information added in v1.1. Both CSV-based and REST API-based approaches are available. In the case of the REST API both 'push' and 'pull' endpoints are available. In many implementations there is a choreography using both push and pull approaches (see Section [7.4.1](#Assignment Grade Transfer)for a detailed explanation of how this can be achieved).

9.5 Standards Based Gradebook Exchange

OR 1.2 adds the ability to align learning objectives to gradebook lineitems and their results via the use of their framework guids. This is done using the 'learningObjectiveSet' class that has been added as part of OR 1.2.

9.6 Real-time Bulk Exchange of OneRoster Information

This is achieved using the REST API with the consumer system reading the data sets from the provider. The consumer must issue a set of read requests on each of the collections that are required for the batch exchange. The REST API defines a pagination mechanism to ensure that the consumer can control the amount of data that it will receive in each response payload. The consumer will issue a sequence of requests until all of the collection has been received. The next collection can then be requested. The order of the reading of the collections is determined by the consumer.

9.7 Batch Bulk Exchange of OneRoster Information

This is achieved using CSV export/import. The source system creates the set of CSV files using OR 1.2 CSV export to create the new zip file. This file is now transported to the receiving system (the method of transport is implementation dependent e.g. using secure FTP, etc.). The receiving system must now import the CSV file set using OR 1.2 CSV import capability. If errors are detected during the import then a manual recovery mechanism must be used.

9.8 Handling Users with Start and/or End Dates

Sometimes it may be necessary to indicate that a user has left an organization mid-year. Common examples are dropouts or a student changing schools.. It may be desired to maintain the now defunct org association until the end of the year. This is handled by the use of the beginDate and endDate fields on the 'Role' object in the 'User' Model. Below are examples payloads detailing how this might be accomplished for the 2 scenarios mentioned.

9.9 Score Status Usage

The scoreStatus field in the 'Result' class is used to determine whether or not a score should be considered as final. For example, a scoreStatus of "fully graded" may be a clue for the SIS that they should expect no more score updates and can use that result in term grade calculations. scoreStatus is, however, not a representation of the status of a student's submission.

To enable OneRoster to be able to describe metadata about the student's submission, OneRoster 1.2 has added a series of true/false fields to allow for the submission status to be richly described without muddying the original intent of the scoreStatus field. These new fields are:

10.1 CASE - Competencies and Academic Standards Exchange

The IMS Global CASE standard is designed to align learning content, activities, assessments, and assertions of mastery with academic standards. Work has been done in OneRoster 1.2 to allow for the alignment of learning objectives with results. Using the new learningObjectiveSet attribute on the 'lineItem' or 'assessmentLineItem' class, systems can now exchange information about which learning standards are aligned with the gradebook entries as well as exchange the related results information by including the corresponding CASE guid.

10.2 User roles and how they compare to other specifications