130 likes | 270 Views
A way to proceed…. Martin Forsberg. We have a few problems with huge impact on development and adoption. We have: No control over versioning Names and definitions that confuses us and the end users A harmonization process that takes years.
E N D
A way to proceed… Martin Forsberg
We have a few problems with huge impact on development and adoption We have: • No control over versioning • Names and definitions that confuses us and the end users • A harmonization process that takes years
All TBGs One library One reusable schema One major version number Harmonized Library TBG 17 ICG Working CCL
Approved library ICG ATG2 RAM – ReusableComponent XML Schema CCL08A urn:un:unece:uncefact:data:draft:Re… Version 6
The namespace and version problem CCL06A urn:un:unece:uncefact:data:draft:ReusableAggregateBusinessInformationEntity:2 Version 2 CII = urn:un:unece:uncefact:data:draft:CrossIndustryInvoice:1 Version 1 CCL06B urn:un:unece:uncefact:data:draft:ReusableAggregateBusinessInformationEntity:3 Version 3 CCL07A urn:un:unece:uncefact:data:draft:ReusableAggregateBusinessInformationEntity:4 Version 4 CCL07B urn:un:unece:uncefact:data:draft:ReusableAggregateBusinessInformationEntity:5 Version 5 CCL08A urn:un:unece:uncefact:data:draft:ReusableAggregateBusinessInformationEntity:6 Version 6 CII = urn:un:unece:uncefact:data:draft:CrossIndustryInvoice:2 Version 2 It doesn’t matter what was changed in CII, it must be a Major upgrade
Every update is Major • If the reusable schema is updated in a major way (namespace change) then the document must also be updated with a major version • Affects the documents in a backward incompatible way • Every new version will be backward incompatible • Even if we consider the change to be a minor or revision, it MUST be a major because of the common reusable library
How do we solve this? Split and isolate the library into smaller libraries defined by the TBGs Supply Chain Con-struction Harmonized Library Agri-culture E-Gov
Well, people will say – “But we will not have ABIEs that are reusable cross domain in that case!” • True, but we don’t have it now anyway!!! • The ”Trade_” BIEs can’t be used by other TBGs • Today we need to keep track on the “owner” of each component • Consider this example!
TBG1 has an ABIE called Trade_Contact and needs to add the ASBIE for Skype-name. We can’t use the ”Specified_ Communication”, already defined by TBG1 because it has no channel-code. TBG1 looks in the library and finds ”Universal_ Communication” that seems to be appropriate Sure, it covers more than we need, but reuse can be a good thing…. But, wait a minute!! What’s that? Specified_ Preference?
We now have a new ABIE ”Preference” in the Cross Industy-schema And a ”Specified_ Period” But we already have a Period-ABIE in our schemas!! It is called Trade_ Period and doesn’t look like the Specified one So we create a new ABIE for Skype Communication, that reuses our ABIEs
So by reusing other domains ABIEs you also get their associated ABIEs • If TBG1 reuses “Consignment” from TBG2, we will also have “Cross-Border_ Party” in our schemas (the Cross-Border_ Party looks very differently from the “Trade_ Party” • TBG1 has to make its own Consignment-ABIE more or less identical to TBG2 except from the associated ABIEs.
And this happens all the time • So we are in reality already building isolated libraries • That’s why we need those funny names • Cross-Border_ Address • Tendering_ Address • Cross-Border_ Party • Tendering_ Party • Trade_ Party TBG1 TBG2 TBG6 The ABIE’s name signals which partition of the library it belongs in
Isolated libraries solve more problems • Each isolated library would render its own reusable schema (and namespace) • The TBG can then make a change impact analysis • The user community can actually use the standard over a long period of time • The strange naming wouldn’t be necessary • The Party in SupplyChainLibrary would be called… Party! • The namespace would give the context, not the ABIE-name!