DOMAIN GROUPS WORK IN PROGRESS
These web pages represent the joint work of the core components group and the business process group as formed at the August 2000 San Jose meeting.
Please use the links below to navigate the site and follow the work effort.
Home Page
Team Members
Work Plan
Working Documents

go to Manufacturing/Material Management Domain

go to Finance Domain

go to Insurance Domain

go to Retail Domain

go to Customs Domain

Manufacturing/Material Management

Finance


Examples of completed forms for capturing core component definitions -as described within Hisanao's methodology and captured on Martin's forms

Pattern   Entity     Representation - amount

    Representation - code

Data format - monetary amount

Code set - balance type code

To view completed forms follow the above links (PLEASE NOTE IF YOU ARE USING NETSCAPE, OR A NON XML ENABLED BROWER DOWNLOAD FILE(S) TO YOUR LOCAL DIRECTORY WHICH CONTAIN MARTIN'S DTD AND XSL FILES), to view issues see text below

From meeting of the core component financial group on the 21/22 June 2000

Issues regarding Hisano's methodology

Issues regarding Hisanao's methodology

We decided that rather than describe a list of components that may or may not be core to the financial sector that we should start with the financial statement message. This would enable us to capture the core information from a particular perspective. While doing this we came across a number of issues which are captured below.

Issues

  1. There are differing levels of core component, i.e. atomic or groupings like party. From this perspective it is possible to have core components which may contain lower level examples of core components, for example the occurrence of address within party.

  2. At certain points the terminology within the forms in confusing. However it was felt that once a number of examples were available it would become clearer what information is expected, in what fields and how it relates.

  3. While working through the forms it became evident that the registry/repository needs to have functionality such that the information on the forms can be fully captured and presented in a meaningful way. This issue is an important one to clarify with the registry/repository group as soon as possible.

  4. What rules are there concerning generic naming rules for all aspects of the forms. This again relates to storage of this information within the context of a repository, where the problem of unique naming must be considered.

  5. What decisions have been made to cater for non-standard code lists within an ebXML framework? If these code lists are allowed then will maintain them?

  6. Code lists patterns should record context. This would therefore allow particular codes to be stipulated with relevance to particular contexts. This would allow high level contextual factors to intelligently present the correct (used) codes. It was also discussed that context should be applicable at all levels within the forms to provide for reproducibility of the data when accessing information through a repository.

  7. Specify generic components which contain a type. Depending upon context the type and cardinality may vary. For example a generic component "charges" may have a type "freight charges" as a permitted value.

  8. Levels of context are likely to be extensive. Far more extensive than the factors listed from the Brussels meeting.

Insurance

Retail

Customs

Issues regarding Hisano's methodology
Completed forms to be added

1) Links between different levels of information (e.g from a Pattern definition to Entity definition) are not stored. So you have to takecare of it by naming the objects.

2) Code Set form has some problems (in the description area appears a part of the XML code).

3) Changing names of objects is too difficult because of the missing links between different levels (see number 1).