UNeDocs and UNECE/OASIS/UBL meetings 31st May

["Michael Dill" <dill2@gefeg.com>]

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