OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Core Components work plan


Dear Bob,

The work that we were doing at X12X/TG4 Core Components was an exercise designed
to
'prove' a methodology.  Your comments tell me that we may not have hit the mark
completely,
but I feel we made a pretty good start.  The team you were involved in had a
difficult task, since
no one from the particular industry (Gasflow) was present.

Having said that, we did learn a lot and will be much better able to complete
our work because
of the X12 activities.  I'm very excited by the fact that the work done
internationally at ebXML,
then nationally at X12, and then at various trade/industry associations is
beginning to involve
many people with many different areas of expertise.  The work of Core Components
is
extremely challenging, and it's wonderful that so many people are interested and
willing to
support our efforts.

One question, though...can you provide examples of static information that a
company would
keep on its own web site rather than on an external site?  Or would each
company's web site
be addressable via some generic registry?  What comes to mind for me is names
and phone
numbers and Email addresses of employees, or trade names of products offered,
or annual report information.  Is that the kind of data you meant?

Mary Kay





"Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com> on 06/23/2000 11:29:47 AM

To:   ebxml-core@lists.oasis-open.org
cc:    (bcc: Mary K Blantz/CLGO/LTV)
Subject:  RE: Core Components work plan



Hi All,

I sat in on some of the X12 CC discussions.  Much of the effort seemed to
focus on commonalities of information transmitted in a given message across
a set of industries.  That's interesting, but it does not yield the whole
story.  Let me explain.

To conduct business with its trading partners, a business needs a large
wealth of information.  Only part of that information need shows up in a
single transaction set - the part of the information which is dynamic in
nature.  The relatively static information is just as important to the
business process, but it has typically already been acquired and saved for
continuing use.

Now it happens that information that is relatively static in one industry is
relatively dynamic in another industry.  So measuring commonality of
information actually exchanged in a given business document somewhat
understates the actual commonality of information needs. I suspect that a
'core component' should address the commonality of information needs (not
dynamic exchange needs), such that individual usage objects built upon the
object lilely act both to subset and superset the core component.

I feel it is of prime importance to understand and map the relationships of
of the 'global' information sets (e.g., the 'party' set.  Given the global
information set, is is then appropriate to discern which portions of the
global set are not used at all in a given business, which are relatively
dynamic in nature, and what aspects of the business environment make this
so.

A second concern is that the X12 Transaction Sets were designed to provide
all the information needed to conduct a given transaction in that single
transaction set, without consideration of the nature or source of the
information.  So even information which is relatively static,
such as a business warehouse address, is accomodated in the tranaaction set,
even though in practice it is not often used, as that information may
already be stored in the recipient's database and linked to a warehouse
identifier.

In an internet environment, it makes more sense for a business to store its
own relatively static information in a well known location at its own
internet site, so that a trading partner who needs the information can
retrieve it as needed.  This leads to a different information model than the
model used to design an X12 Transaction Set.

Cheers,
         Bob Miller

=======================================================================
= This is ebxml-core, the general mailing list for the ebXML          =
= Core Components project team. The owner of this list is             =
= owner-ebxml-core@oasis-open.org                                     =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-core                                         =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-core myname@company.com                      =
=======================================================================





=======================================================================
= This is ebxml-core, the general mailing list for the ebXML          =
= Core Components project team. The owner of this list is             =
= owner-ebxml-core@oasis-open.org                                     =
=                                                                     =
= To unsubscribe, send mail to majordomo@lists.oasis-open.org with    =
= the following in the body of the message:                           =
=      unsubscribe ebxml-core                                         =
= If you are subscribed using a different email address, put the      =
= address you subscribed with at the end of the line; e.g.            =
=      unsubscribe ebxml-core myname@company.com                      =
=======================================================================


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC