Arofan,
> You make a point about
industry-specific vocabularies that is exactly one of the issues that the core
component mechanism was designed to address. This is the idea of
> "context" as used in these specifications.
To make things simpler, you actually have also to consider
diverse national regulations handling the same industry worldwide.[Gregory,
Arofan] The Context mechanism does capture the combination of
global, governmental, and industry distinctions: there are a set of
categories in the context spec which are combinatorial. These are: (1)
Business Process; (2) Industry; (3) Product; (4) Legislative; (5) Business
Process Role; (6) Supporting Role (third parties to the transaction); (7)
Systems Capabilities. You can describe almost any business situation fairly
completely here. My next questions to all of
you:
> The context mechanism provides a way for each industry
or other interest group to specify deviation from core components and standard
message types, and to tie that
> specific deviation to their industry, business process,
product, geographical setting, legislative influences, etc.
Can you give me a hint/link towards specs/definitions for
the context mechanism? A dummy-guide, maybe? Or just a simple explanation how
it is supposed to work in practice?
[Gregory, Arofan] The best place to go in the
immediate future will be the specification at www.ebtwg.org. This should be released in a
week or so. This will be followed by the release of a complete end-to-end
example, and of the actual library of core components thus far identified and
catalogued, hopefully within a metter of a few weeks (I'm not sure of the
timeframes). Note that the books currently available on the subject are *not*
(in my opinion) worthwhile, because they are outdated, and that the same holds
true in the case of core components for what was published as technical
reports at the end of the ebXML effort last May. Too much work has gone
into the core components and context specification that has refined and
clarified the contents of those technical reports for them to be considered
up-to-date.
> A business person goes to look in the repository for
what document structure to use. By filling in information about
what business process, what industry, what
> geographical region, and what products, he will
discover exactly what changes to the
generic components and documents other people using the repository saw
as
> necessary to do business in the same
situation. Because it is easier and cheaper to re-use others work than to do a
redesign, the busines person will take what he finds,
and
> use it. Only if something is missing will the
businessperson have to go back and create something new, and only
where the gap specifically is. This new work would then
> become available for that specific
business situation in the repository, for others to
discover and re-use.
Specifically, to rise the policy discussion once again - who
is the likeliest operator for such repository - service providing businesses,
state, third parties such as trade facilitation units/bodies, or all of them
jointly? Does such practice exist, to your knowledge? Where (give URL)? Are
there already existent ebXML compliant industrial repositories known to you,
and in which countries?
[Gregory, Arofan] This has not yet been
determined. I personally see the existing set of standards bodies as the
likely operators of these repositories, but to my knowledge there are
none currently in operation (not surprising since the spec hasn't been
finalized yet). Duane Nickull's company XML Global has done some work with the
ebXML specs and their own repository software which will show that the
basic concept is implementable, but I am not aware of any live repositories
even using their implementation. They might know more. People reading this
list may know of similar cases where some work has been
done.
And, more to the point, how is the business person in
your example supposed to notify the repository operators that there is a gap
and (s)he has a proposal to fill it wit such and such component?
[Gregory,
Arofan] My impression is that this functionality would need to be part of
the repository functionality. While it is standards bodies that maintain the
official list of core components, the use of those components will be up
to the business users. If I find a gap and take the trouble to build a new
component for my business context (termed a "business information entity" in
the core components specification), then the interface repository will allow
me to check my new component into the repository. This would be a process
of indicating which core component I was building on, what changes I needed to
make, and what my business situation ("business context")
is.
The ongoing Technical Architecture work now occurring
in UN/CEFACT will be addressing this point, as will - presumably - the OASIS
follow-on work around the ebXML Registry (although I don't know this for a
fact).
Cheers,
Kremena
[Gregory, Arofan]
I hope this is helpful.
Cheers,
Arofan
Gregory