Details
-
Improvement
-
Resolution: Done
-
Major
-
Data Standard v2.0
-
None
-
None
-
Impediment
Description
Quote from linked ticket (DATASTD-526) from Richard Heim:
The reason to leave the current version schemas alone is that they address different needs and purposes. It turns out there are only two distinct uses of version.
For Assessments, the Version element (of type Version) is a required integer value that differentiates one iterative release from another. This element is part of the key that defines uniqueness for an assessment. Due to API requirements for key elements, it cannot be renamed to AssessmentVersion without first creating a new type (also named AssessmentVersion) for this purpose. This would be a breaking change that would affect Assessment vendors already using the v2.0 draft schema.
EducationContent has a Version element of type ContentVersion that is an optional string element not used as a key. EducationContent uses publication date to define uniqueness.
I feel this comment sums up the Version issue best. In addition to EducationContent, ContentStandard also uses the ContentVersion string, which causes a collision on sub table of Assessment. This is handled by a diminisher in MetaEd to rename the column to "AssessmentVersion" in the ODS.
Given we're breaking things, now is the right time to fix the name of Version to be AssessmentVersion for the usage on Assessment. This would allow us to turn off one of the last remaining diminishers in MetaEd. This would be a breaking change on the Xsd.
See DATASTD-864, METAED-113, METAED-61 for reference.
Attachments
Issue Links
- clones
-
DATASTD-526 Naming convention for versions
- Closed
- relates to
-
DATASTD-1091 Determine if descriptors with additional data attached are actually entities
- Closed