Review of core components

[Chris Nelson <chris@cnelson.demon.co.uk>]

I attach below the comments made by a team of 4 people that reviewed the core component and business process list, in the context of trying to map these to a UML model of a specific statistical declaration.  Thus review was carried by Eurostat (Statistical Office of the European Communities), assisted by consultants.

 

I assisted in the role of having been involved in the ebXML process and therefore could understand a lot of the background.

 

We hope this will be useful for the meeting in London this week.

 

Regards,

Chris Nelson

Dimension EDI

 

 

 

Comment on Core Component Documents

 

Documents Reviewed
1) Initial Core Components Version 1.02 (Appendix A)
2) Core Components Catalogue for Review (3-01).xls
3) ebXML Catalog of Common Business Processes version 0.9

 

Background

 

The documents were reviewed in the context of a UML model that supports the EU INTRASTAT declaration.  INTRASTAT is a statistical declaration for inter community trade. The current declaration is made in a varuery of electronic formats, as well as paper. An implementation of the EDIFACT CUSDEC message is one such format.  The UML model is based on the artifacts of the declaration, it is not a model of the CUSDEC message as used for INTRASTAT.

 

General comments

 

1) It is virtually impossible for an "outsider" to review and evaluate the core components as currently presented in the spreadsheet, or to try to map these to a UML model. What is required is a representation of the core components in UML.

 

2) However, we are confident that the UML model could be mapped to the core components in the list contained in the documents reviewed, except, of course, components that we would regard as domain specific.

 

Specific comments

 

Document: Initial Core Components Version 1.02 (Appendix A)

 

1) line 418 UID 000093 - code list agency, identifier

 

It is not clear how this works. Is this intended to be the same process as in EDIFACT, whereby every organisation that wishes to maintain a code list must itself be identified on a code list that is maintained by a single agency? If so, which organisation and which code list is intended for ebXML?  Is the URL intended for this purpose?

 

2) line 411 UID 000088 - Identification Details

 

This component seems to be the basic building block of all identifiers and codes. Codes are different from identifiers and there should be a different underlying core component for identifiers. Many organisations maintain lists of identifiers.  These are usually internal to the organisation and its partners (e.g. a list of concept names, even a list of organisation identifiers).  A code, on the other hand, always has one or more labels (perhaps multi-lingual labels) which gives it semantic meaning to a human, and can have a correspondence with codes in other code lists. Is the UID a code or an identifier?  It is an identifier used to uniquely identify an object, it is not a code which has some decoded meaning and can be converted to a code in another list maintained by another mantenance agency.  Note that Identifiers also have maintenance agencies.

 

3) line 75 UID 000057 -Telephone country identifier

 

Why is this a basic entity?  Should it not also use the identifier aggregate - it seems to be a code.

 

4) line 13 UID 000013 - Organisation tax identifier

 

Is this not just another type of party identifier?  For the INTRASTAT declaration this is the identifier used (i.e. the VAT number).  Is it really a core component - surely it is an application specific use of a party identifier?  There will be many such identifiers in the various domains.

 

5) line 177 UID 000014 - Organisation tax identifier

 

The same comments as line 13.  Also, why is this a basic entity, surely it is an agrregate based on identification details?

 

6) line 179 and 180  UID 000067 and 000068 - date, time

 

Why are these both mandatory? It must be possible to give only a time or only a date (e.g. opening days, opening times).

 

Document:ebXML Catalog of Common Business Processes version 0.9

 

REA paragraph 8.3

 

A common business process that seems to be missing from this analysis is that of Business Reporting.  There are some specific reporting requirements identified (e.g. customs) but the common process should be Business Reporting, broken down into regulatory and other governmental reporting, and non governmental reporting. The reporting of statistical information is usually in the first category.