Fw: Core Component Analysis - SWIFT's Comments

[Philip Goatly <philip.goatly@bolero.net>]

----- Original Message -----
From: "Philip Goatly" <philip.goatly@bolero.net>
To: "Nigel Wooden" <nigel.wooden@spangraph.freeserve.co.uk>
Cc: "Peter Guldentops" <peter.guldentops@bolero.net>
Sent: Wednesday, January 17, 2001 9:49 AM
Subject: Re: Core Component Analysis - SWIFT's Comments


> Hello folks,
>
>    here's my 2 cents/pennyworth.
>
>   Whilst the SWIFT proposal seems to make for an easier life - and is
indeed
> very useful in the restricted context of a SWIFT message i.e Purely
> financial, where there are a limted number of parties e.g. On a
documentary
> credit an Applicant and a beneficiary plus a couple of banks. In the world
> of international trade there can be, and will be, many Parties on one
> document or message and these may differ depending on industry. This needs
a
> coded value and a code list otherwise the number of classes (hard coded)
> becomes unmanagable. Who would consider making each country a separate
class
> ? or even worse, who would make each UN-Location Code (UN-LOCODE) of which
> there are 30,000 a separate class ?.
>
> In addition SWIFT are modeling in a similar way to system modeling - one
has
> a complete picture of all the transactions - and SWIFT actually controls
> them in coordination with the Banks.
>
>  In the world of international trade there is no complete definition and
all
> of us are modeling in  conditions of uncertainty. It follows that should a
> new party be required in a transaction, for a particular industry then if
> the 'new party' is defined as a class - in XML we have to change the
> schema/DTD or whatever.
>
> This means users of this message must upgrade to maintain compatibility.
>
> If one uses a coding system for the parties then one just adds to the code
> list - for those who need the new party and everyone stays happy.
> *************************************************************
>
> Just one question - how are we gonig to deal with many to many
relationships
> within an XML hieararchy. I am sufficiently old/mature to remember the
> problem  we had with such things in Hierarchical databases and the factors
> which led to Relational Databases where relationships are made at run
time.
> With XML we seem to be back to hierarchies which may lead to similar
> difficulties.
>
> Cheers, Phil Goatly
>
> Bolero.net
> ----- Original Message -----
> From: "Nigel Wooden" <nigel.wooden@spangraph.freeserve.co.uk>
> To: "LITTRE Jacques" <jacques.littre@swift.com>; "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: Tuesday, January 16, 2001 10:14 PM
> Subject: Re: Core Component Analysis - SWIFT's Comments
>
>
> > 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
> > >
> >
> >
>