[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Core Components work plan
Gentle People,
It was not my intent to suggest the work done at X12 was in the wrong
direction or
was not worthwhile. I did mean to caution that a simple comparision of the
fields
used by different industries likely understates the commonality found
through a
comparison approach.
Placing (XML-based) name/address info on a web site is probably the most
obvious
'ststic' information. Many companies have a good deal of static information
in
transportation and other areas of logistics that could be stored on the web
site.
In the gas supplier pipeline example, my gas well may be connected to a
single
pipeline, so that's static information, and I'm sure going to know in great
detail
who owns the pipeline, and the pipeline owner is going to know a great deal
about me.
Whether 'static' information is retrieved from a pointer in a 'dynamic'
message, or
is retrieved by initiating a separate retieval message, it may still
represent core
information to be defined in Core Components. And the 'why' behind the
absence of
information in a given message usage may well be its static 'property'
For a given 'Core Component', I'd like as much structure defined as we know
how to
define. In my opinion, such structure would consist of an organzed
collection of
Core Subcomponents (one of which might always be present) comprising the
full Core
Component. I sometimes here words that suggest to me that a 'Core Component'
defines
just a piece of what I think should a Core Component should define.
To take the familiar example of 'Party', I would not expect to find 'City'
in the
'Party' component. I might find 'City' in a 'postal address' sub-component
that is
referenced somewhere in the global definition of 'Party' Some
sub-components might
only appear in one hierarchy, others might appear in more than one.
-----Original Message-----
From: mblantz@LTVSteel.com [mailto:mblantz@LTVSteel.com]
Sent: Friday, June 23, 2000 2:03 PM
To: ebxml-core@lists.oasis-open.org
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 =
=======================================================================
=======================================================================
= 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]
Powered by eList eXpress LLC