...
binding strength
namespaces
groups (not yet supported in Archie)
annotations (some possible in OPT!)
value terminology bindings?
?
Specialisations can be done converted without problems! . ADL 2 handles the validation, and valid specialisation can be converted.
The impact is mainly for tooling development. The specification may need to address how graceful degradation in conversion from ADL 2 to ADL 1.4 works.
Thing to check: do we actually need to ADL 2 to ADL 1.4 converter, or just the OPT converter?
...
id/ac/at instead of atxxxx-codes
at0001 will become id2 (node id), or ac2 (value set), or at2 (value code)
templates are specialisations, so .1 syntax of codes in ADL 2
namespace makes inheritance tricky in CDR
Template ids are now archetype ids, before they were a different syntax
more blockers present?
Possible solutions
...
for ID/AT-codes problem
Convert the ADL2 to OPT 2 with at000x-syntax
Migrate to new numbers for new archetypes, keep using the at000x-style numbers for old archetypes
Change ADL 2 to use at000x style codes
Change ADL 2 to use id/ac/at-codes, but use id0 as first code instead of id1
Define a way so that both old and new queries work at both data formats
...
Convert the ADL 2 to OPT 2 with at000x syntax
define OPT 2 with at codes
autogenerated from archetypes
Convert Idx codes to at000x-style codes
for specializations introduced in templates, remove the .1. This likely should be configurable
need check: possible to always remove the specialisation from template codes? Sibling nodes with same at-codes possible in OPT 1.4?big drawback:
Benefits
No change needed to ADL 1.4 CDRs in the short term
no change needed to ADL 2 CDRs ever
Drawbacks
some systems will have different codes than others. Interoperability will become more complicated
conversion could solve this
Migration remains hard for ADL 1.4 CDRs
Change ADL 2 to use different coding (adl 1.4 style, or id0 as root node)id/ac/at-codes, but use id0 as first code instead of id1
Define a new ADL version, and a way to indicate in ADL which system is used (machine recognizable!). ADL 3?
Write converters for the current ADL 2 archetypes
Adapt existing modeling tools to work with the new codes
Nedap will need to do some kind of migration to be standards compliant again (same migration as the others would need to do)
benefits
interoperability is easier without conversion
less work to migrate ADL 1.4 CDRs
drawbacks
work to migrate ADL 2 CDRs
Blocking issues:
id0.1 is both the root node for a specialised archetype, AND a newly added non-root node in a specialised archetype
tricky to solve - specific root node syntax? keep it at at0000 or id0000?
Change ADL 2 to use at000x style codes
Create a new ADL version that is ADL 2, but with at000x style codes
This keeps the full code syntax of ADL 1.4. The specialisation syntax that is currently underspecified in ADL 1.4 will need to be specified much better.
Benefits:
ADL 1.4 CDRs require no change
interoperability/data requires no change
Drawbacks:
ADL 2 CDRs require a full migration
All modeling tools and libraries supporting ADL 2 will need change
slightly incoherent code system
Migrate to new numbers for new archetypes, keep using the at000x-style numbers for old archetypes
benefits:
no migration of data for ADL 1.4 CDRs
drawbacks
ADL 2 CDRs will require a migration, or suffer reduced interoperability
conversion can solve this
ADL 1.4 CDRs will require a change
Define a way so that both old and new queries work at both data formats
impact: to be checked
Interoperability:
convert RM data, basics done in Archie proof of concept
accept .1 data (templates!) For ADL 1.4 templates? Or just convert those as well? Slightly more complicated, but possible: you need the path to inheritance root of archetypes for that
...
define profiles for in between steps?
define the wanted long term situation - what to migrate towards
-
...
AQL, inheritance and specialized codes (templates!):
...