...
replace ODIN with JSON, YAML, etc, or possibly a choice between such formats
allow free naming of node codes rather than the historical numeric idNNN , codes (atNNN , acNNN codesand acNNN codes would remain numeric). This makes id-codes more like ontology entity names, which is they role they have.
allow more meta-data within terminology definitions and bindings
more powerful annotations to support application form building
more powerful / better defined rules
tuple constraints for non-primitive structures
a constraint type for links / references that would allow stating of the type and possibly archetype of the target
better way to manage translations
probably others.
...
enable human-readable paths to be standardised within archetypes, rather than relying on generator algorithms in disparate tools to generate keys and paths.
Impact Analysis
Area | Description |
---|---|
Specifications | Possible addition to ARCHETYPE_TERM in AOM2, to allow Changes to OPT1.4 and OPT2 - e.g. key-based forms? |
Archie | Change to ARCHETYPE_TERM; add/change path extraction to support key-based paths. |
Authoring tools | Add support for creating |
SDKs / form builders | Add support for extracting key-based paths from OPTs |
CKM | TBD |
CDR | None |
CDR Data | None |
CDR Queries | Possibly allow new key-based form for displaying and authoring queries. |
Advanced Form
In a more advanced environment, the keys could be used as the principle codes instead of the id-codes. This would remove the ability to infer subsumption based on the dotted code system in use since ADL1.4, e.g. id4.0.3 is a specialization of id4 (at top level), introduced 2 specialization levels down. With freely-named codes, the IS-A relationships have to be asserted within the archetype terminology. This is a breaking change, and would only be possible by moving to a new major version of ADL, nominally 'ADL3'.
...
simplify ADL / AOM based software by allowing 3rd party and built-in libraries for data representation (JSON, YAML etc) to be used instead of maintaining the custom ODIN code currently in use
JSON/JSON5/YAML
Impact Analysis
Area | Description |
---|---|
Archie | Replace current ODIN serialise / deserialise with JSON or similar built-in methods |
Authoring tools | Accept ODIN-format archetypes and convert on read and write |
SDKs / form builders | TBD |
CKM | Convert ODIN-format to/from JSON-format as necessary |
CDR | Easier support for JSON-format OPTs; no effect on XML format OPT |
CDR Data | None |
CDR Queries | None |
Link / Reference Constraint
...
Benefits
TBD
Impact Analysis
Area | Description |
---|---|
Archie | Add support for the new constraint type |
Authoring tools | Add support for creating the new constraint type |
SDKs / form builders | TBD |
CKM | TBD |
CDR | Validator needs to implement new constraint type |
CDR Data | None |
CDR Queries | TBD |
Non-Primitive Tuple Constraint
...
Benefits
TBD
Impact Analysis
Area | Description |
---|---|
Archie | Add support for the new constraint type |
Authoring tools | Add support for creating the new constraint type |
SDKs / form builders | TBD |
CKM | TBD |
CDR | Validator needs to implement new constraint type |
CDR Data | None |
CDR Queries | None |
Better Terminology and Binding Meta-data
...
Benefits
TBD
Impact Analysis
Area | Description |
---|---|
Archie | Add support for the new meta-data |
Authoring tools | Add support for new meta-data |
SDKs / form builders | TBD |
CKM | TBD |
CDR | None |
CDR Data | None |
CDR Queries | TBD |
More Powerful Annotations
...
Benefits
TBD
Impact Analysis
Area | Description |
---|---|
Archie | Add support for the new annotations |
Authoring tools | Add support for new annotations |
SDKs / form builders | TBD |
CKM | TBD |
CDR | None |
CDR Data | None |
CDR Queries | TBD |
Separate Translation Files
...
Benefits
TBD
Impact Analysis
Area | Description |
---|---|
Archie | TBD |
Authoring tools | TBD |
SDKs / form builders | TBD |
CKM | TBD |
CDR | Should simplify loading of specific language OPTs |
CDR Data | None |
CDR Queries | TBD |
More Powerful Rules
Description
...