[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: UNeDocs and UNECE/OASIS/UBL meetings 31st May
Dear all, Please let me give some thoughts re. the upcoming UBL/CEFACT transition call with respect to UNeDocs: New kinds of documents Besides XSD schema issues, there are conceptional, purely business semantic driven things. One is that the UNeDocs concept of reuse reflects the changes of international trade behaviours - Single Windows Approaches of Customs and other governmental agencies will lead to the elemination of redundancy across different documents in order to decrease process costs etc. The 'data on demand' concepts and the web services also lead to new kinds of documents. Example: traditional Customs documents request partial invoice data from exporters whilst at the same time very many of these same corporates send, often in EDIFACT, their complete customs export invoices (these are different from their commercial invoices, too) to Customs instead. This saves work for the exporter but makes extra work for Customs. The UNeDocs aproach eliminates the data redundancy simply by reusing the Invoice structure in a customs document. Regional or national customization can further restrict or extend the required content. This is a technique which only CCTS allows and which meets the trend to build NEW kinds documents, which reflect the origin of the data, the time that they are really used ('data on demand') and the requirements of Single Windows approaches. On the other hand traditional documents, as defined both by UNeDocs and UBL will still be playing the major role in many areas. Therefore, a combined approach should cover both, I think. Contribution of UNeDocs to UBL In order to harmonize what is harmonizable, several month ago the UNeDocs project leader sent ALL UNeDocs data models to UBL. These models are CCTS-compliant UNTDED aligned and are reusing the still evolving TBG CC Library. IMO Tim McGrath appreciated this very much. The hope is that both the UNeDocs concepts and the UNeDocs data, which are globally focussed and also include the specific requirements of the UK, will be a key foundation for an upcoming UBL version. Especially the customs and transport business knowledge, which is incorporated in the UNeDocs data is a very wide one hving been developed in conjunction with the TBG3 transport working group. Therefore I feel that UBL has already had the advantage of taking the work, which has been done within and outside of CEFACT. By contributing the UneDocs data models to UBL, TBG2 has demonstrated its intention to encourage convergence with UBL and at least to co-operate. I think, that a future release of UBL should consider giving a credit to UNeDocs. Further requirements and considerations from a UNeDocs perspective 1. UNeDocs bases on the ISO/UNTDED. The use of UNTDED, wherever possible, is important for UN/CEFACT, the international trade user community as well as for UNeDOCS implementation. 2. UNeDocs bases on the UN Layout Key. The ISO parts of it need to be extended by an electronic version, which should not only be expressed with stylesheets. 3. UNeDocs does not know stand alone BIEs in the document root. IMO they would not be really maintainable. 4. The XML deliverables of UNeDocs should not only be one schema language. It should try to cover all UN/CEFACT approved XML languages, if there are several. And if there are more future requirements, like RNG, OAGI, EAN.UCC ebMethodology, or even xBRL then the content of UNeDocs should be transformed into these languages too, if technically possible. 5. UNeDocs has to care about EDI implementations and the mapping between its data models and EDI 6. UNeDocs uses Core Components and BIE, whereas UBL just uses BIE. No clue yet whether these different approaches are combinable. This will need to be investigated. 7. UNeDocs has as a basic concept that national, regional or industry specific implementations can be customized from a global data model level; at least they should;-). [note: This concept needs to be refined, for sure.] It seems that UBL does not have a customization concept, which links the central data model deliverables with user extensions/restrictions and which allows a user to replace one released version by a newer one. 8. UNeDocs would like to convince major vendors to use its deliverables. I'll send this email as a separate one to the UBL list. Best regards, Michael Dill for TBG2
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]