CTS2 Changes from 6.1 to 6.2:
Overview of Previous Implementations
CTS2 had a presence in LexEVS 6.0, but as a Java API implemented against a draft specification. CTS2 1.0 was implemented in LexEVS 6.1 against a fully vetted and approved specification, but against a non-canonical JSON representation.
CTS2 JSON
The most significant changes in CTS2 exist in the JSON representation. Fortunately these changes are naming convention based and should not mean significant changes to client code. Users migrating from CTS2 1.0 to CTS2 1.1 services will find that object-naming conventions have changed in the JSON representation. Virtually all top-level objects now start with an upper case character. Object collections previously represented with a “list” suffix will have that suffix removed in 6.2.
CTS2 Model Related Changes
The CTS2 service for 6.2 features an additional module, Value Sets, which brings it into line with a number of other CTS2 specification implementations. A number of updates under CTS2 1.1 are carried over into the framework supporting this implementation but these will rarely change the users implementations.
Examples:
JSON List Naming Convention
- Top level list containing elements such as CodeSystemVersionCatalogEntryDirectory have
- entryList in CTS 1.0
- simply called entry (which is still a collection of values) in CTS2 1.1.
JSON Top Level Element Naming Convention
- Entities returned in JSON moving from lower to upper case top level element
- returned under an “entityDirectory” in CTS2 1.0
- as an “EntityDirectory” in CTS2 1.1.
CTS2 Model Changes
- Any URIAndEntityName references should all be changed to EntitySynopsis
CTS2 1.0 | CTS2 1.1 |
entityDirectory | EntityDirectory |
entryList | Entry |
knownEntityDescriptionList | knownEntityDescription |
iteratableResolvedValueSet | ResolvedValueSetDirectory |
