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 as a REST service against a fully vetted and approved specification, but against a non-canonical JSON representation.
CTS2 JSON
From the REST service user's perspective the most significant changes in CTS2 from the 6.1 implementation to the 6.2 implementation 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.
JSON associated with the CTS2 1.0 implementation in LexEVS 6.1
(Not an official specification)
CTS2 1.1 JSON
Implemented in LexEVS 6.2
CTS2 Model Changes
While there is an extensive list of model changes, few will affect end users. We've listed one change that some REST interface users will see and followed up with a link to the complete change reference.
- Any URIAndEntityName references should all be changed to EntitySynopsis
- Link to complete model change reference
Summary
A mapping of changes a REST interface user is likely to come across.
CTS2 1.0 | CTS2 1.1 |
entityDirectory | EntityDirectory |
entryList | entry |
knownEntityDescriptionList | knownEntityDescription |
iteratableResolvedValueSet | IteratableResolvedValueSet |
| URIAndEntityName | EntitySynopsis |
A Summary of Objects Mapped To LexEVS
This gives some context for the LexEVS user who wants to take advantage of the REST api over LexEVS and gives a sense of what the current object set is that might be returned by a rest call. (And parsed from XML or JSON into Java objects)
