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:
- CodeSystemVersionCatalogEntryDirectory and other top level list containing elements have lists of entries which are designated entryList in CTS 1.0 but are simply called entry (which is still a collection of values) in CTS2 1.1.
- Entities returned in JSON are returned under an “entityDirectory” in CTS2 1.0 and as an “EntityDirectory” in CTS2 1.1.
- Any URIAndEntityName references should all be changed to EntitySynopsis
CTS2 1.0 | CTS2 1.1 |
entityDirectory | EntityDirectory |
entryList | Entry |
knownEntityDescriptionList | knownEntityDescription |
iteratableResolvedValueSet | ResolvedValueSetDirectory |