Re: Core Component Analysis - SWIFT's Comments

[Nigel Wooden <nigel.wooden@spangraph.freeserve.co.uk>]

Dear all,

I would just like to add support to the comments submitted by SWIFT.

We have to realize that we are analyzing core components at different levels
of abstraction.
We have actual business data elements as well as business data 'types' e.g.
party, date,
amount, measure, code etc.
Each piece of business data should have a business data type to underpin it
(just as SWIFT demonstrated with their examples of buyer, seller, birth date
etc). These business data types are core components that we should agree and
define 'urgently' - there is a small number - they probably relate exactly
to our representation terms (almost!). I  know we are 'syntax neutral' but I
believe we should provide an XML schema for each 'type' so that us poor
users can pick up standard representations for our data when developing
business documents for use in an ebXML environment - which we are already
doing. Our core component dictionary can them concentrate on defining and
agreeing semantic meaning for common business data e.g. Transaction
Effective Date - it is important that we have an agreed understanding of the
meaning for this data. The TAG we use for it is not so important as long as
we can link it to the core component dictionary - for this reason each entry
should contain a unique id and we should add this to the spreadsheet.

I would expect an example like Transaction Effective Date to be an entry in
our dictionary as it should be common to several industry sectors and it's
entry should contain a clear unambiguous description of the meaning as well
as details of the 'type' that underpins it.

When I want to include Transaction Effective Date in a business message:-

if my message uses the EDIFACT syntax I would map data from the 'type' date
to the DTM segment. Because all occurrences of the DTM segment have the same
TAG! I would include a 'type code' (qualifier) to identify the content as
Transaction Effective Date.

if I use XML I would create a tag <TransactionEffectiveDate> and use the
ebXML schema for Date to map data from 'type' date. I do not need a
qualifier. To make my core component require a type code or qualifier
because it is a feature of EDIFACT is not the correct way to develop core
components and not the most efficient way to implement XML!!

Similarly, Attribute is a segment in EDIFACT that is very useful for
carrying codes (an example we use it for is Construction material code)
which do not fit other segments. We have hundreds of such code lists in
Insurance. I would expect ebXML to have a core component 'type' of 'Code'
which would underpin all such business items and contain info about code
list id and owner etc. Therefore Attribute should be removed from our list.

One last thing - Insurance is not an aggregate please remove that, unless
you are going to make all the industry sectors aggregates!!!!

Nigel.

----- Original Message -----
From: LITTRE Jacques <jacques.littre@swift.com>
To: Heilig, Paula <paula.heilig@worldspan.com>
Cc: <ebxml-core@lists.ebxml.org>; Frank Vandamme <frank.vandamme@swift.com>;
Carlo Palmers <carlo.palmers@swift.com>; Kris Ketels <kris.ketels@swift.com>
Sent: Friday, January 12, 2001 4:34 PM
Subject: Core Component Analysis - SWIFT's Comments


> Dear Paula,
>
> Please find attached SWIFT' s comments on the CoreComponents Analysis
document.
>
> I will remain at your disposal if your need further clarifications on
them.
>
> Best regards and see you in Vancouver.
> Jacques
>