Fw: The role of context in the re-usability of CoreComponentsandBusiness Processes - OR Say What???

[Lisa Shreve <lshreve@mediaone.net>]

> Andrzej,
>
> Based on your experience and as a representative of a SME, your insight is
> very valuable.  I'd like to encourage you to make specific comments.
> However, I'd like to clear up a couple of issues, so that your comments
will
> be most effective.
>
> The core components project team had long discussions over the topics
raised
> here.
>
> > I was lurking on this list for some time now. Let me share with you my
> > impressions about the CC (I also participated in that CEN/ISSS meeting
as
> > a representative of an SME).
> >
> > First of all, I had an impression (gotten from the "Methodology for the
> > Disc. and Analysis of CC") that this group is convinced and dedicated to
> > the use of UML to present models. However, from reading the final
> > documents I can see it's not the case, and I can't understand why. That
> > Excel spreadsheet is mighty unclear, and it looks like just a heap of
> > everything and anything thrown together from various existing standards.
> > The UML model recreated from this (that someone sent a week or two ago),
> > seems to support this impression...
>
> There are a couple of points that I see as important here.
>
> *  use of UML
> *  the excel spreadsheet
>
> First, ebXML as a whole, and the core components project team, debated the
> use of UML.  The arguments, in short, revolve around complexity and
> applicability.  Replaying this argument is not what I want to do here.  In
> general, the outcome was to develop a specification for what the final
> results must conform to, and not require use of any specific technique.
CC
> supports the use of modeling.
>
> The excel spreadsheet is merely a tool, a poor one admittedly, to present
a
> logical organization.  The process that was followed has been iterative,
and
> continues to evolve.  With input from over 10 industries, many logical
> decompositions of the information are possible.  Finding the proper
balance
> to facilitate interoperability is our goal.  How the information is
> ultimately stored is a different issue.
>
> This is why we have requested that comments be on the logical
organization,
> not the presentation.  It sounds like you might have comments on the
logical
> organization, which we would like to hear.
>
> >
> > Next, I thought that I perhaps missed some unofficial documents that
> > present MORE of the core components than just the Party related ones. I
> > was very surprised to find out that this is the only catalog of CC
> > available. Where is the rest of the core components then, for those who
> > want to exchange something more than the Party related information?
> >
>
> The output from ebXML is specifications for how to develop core
components,
> not actual core components.  The example is published to demonstrate a
> logical approach.  The bulk of the work for development will occur within
> the joint EWG/X12 union.  If you will be attending the EWG meeting next
> week, you will be given updated and more inclusive work in progress.
>
> > Now, please bear with me one more moment. The SMEs, and not only, are
> > waiting with great eagerness for the ebXML project to produce something
> > that can be implemented, and which would ensure interoperability and
lower
> > costs for them to enter the e-commerce arena. Many ebXML spec drafts
have
> > already been used as a basis for early adopters, as well as strategic
> > guidelines, but not the CC, which (as the name suggests) form the core
> > needed for exchanging the business information. So, IMHO, many of these
> > SMEs will be very disappointed if the CC specification will be accepted
in
> > its vague and incomplete form, as it basically is today.
> >
> We welcome specific comments about the specifications.
>
> > What are my expectations then? Maybe I'm just an isolated case, but I
> > think that in order for this specification to be accepted and deployed,
> > and if you really have the SME market in mind, these specs must be much
> > more concrete. Giving too much freedom is not always good, especially
for
> > interoperability.
>
> Agreed.
>
>
>  And, they should present a
> > COMPLETE model of the core components needed to perform the most common
> > business exchanges, with the guidelines for extending it. Otherwise,
what
> > is the practical meaning of this spec if it doesn't guarantee a decent
> > level of interoperability? Why should I accept this vague model (that in
> > fact places on me the burden of creating my own components) instead of
any
> > other one (RosettaNet or xCBL comes to mind)?
>
> This is a long discussion, but the CC work has always focused on semantics
> and interoperability is in the forefront of our thinking.  There are a
> number of levels of core components, and given a set of core components,
> specific business specification can be produced.  The core components
> themselves are designed to facilitate generation of these interoperable
> business specifications-- but the cc's themselves are context independent.
> This is an important point.
>
>
> As a project team consisting of over 60 experienced people, we well
> recognize the complexity associated with interoperability.  It is simple
to
> create a specification for a single industry, and a whole different issue
to
> create for interoperability amongst various industries.  If this were a
> simple problem, it would have been solved long ago.
>
> It sounds like, based on your experience and association with a SME, you
> have some very valuable insight.  I encourage you to make specific
comments
> to assist the project team in completing the specifications.
>
> Lisa M. Shreve
>
> >
> > As a system architect for an SME, I'm certainly not going to embark on
the
> > ebXML adventure without much more clear and precise definitions for such
> > central concepts. Which is sad, cosidering how many excellent specs this
> > project already produced...
> >
> > Andrzej Bialecki
> >
> > //  <abial@webgiro.com> WebGiro AB, Sweden (http://www.webgiro.com)
> > // -------------------------------------------------------------------
> > // ------ FreeBSD: The Power to Serve. http://www.freebsd.org --------
> > // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ ----
> >
> >
> >
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
>