1. A way to proceed… Martin Forsberg

2. 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

3. All TBGs  One library  One reusable schema  One major version number Supply Chain Components TBG1 UNEdocs components TBG2 Construction eTendering TBG6 Agriculture TBG18 …. TBGx TBG 17 Harmonized Library ICG Working CCL

4. Approved library ATG2ICG RAM – Reusable Component XML Schema NDR CCMA CCL08A urn:un:unece:uncefact:data:draft:Re… Version 6

5. 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

6. 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

7. How do we solve this? Split and isolate the library into smaller libraries defined by the TBGs Harmonized Library Supply Chain Con- struction Agri- culture E-Gov

8. 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!

9. 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?

10. 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

11. 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.

12. 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

13. 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!