Re: [ebxml-dev] ebXML specifications interdendancies

[Todd Boyle <tboyle@rosehill.net>]

Duane said,
 >>Okay - here it is in non technical language:
 >>
 >>Core Components are too abstract to be readily usable.  For Core
 >>Components to be used on a global basis,  we need the context
 >>mechanism.

That's fine but then, defining the allowable Contexts becomes
a hugely important economic and political question.  Just as are
the core components themselves.  But there's no sufficient process
for dialog on either one!  Viewed from the outside, the six contexts
appear to be handed down from philosopher kings, fully baked.

For example, I posted my viewpoint more than once here, that
internal application integration is a context, of which accounting
integration is a sub class.  Nobody reacted at all.  No dialog.
Maybe my idea is wrong; maybe it fits under the "Legacy Systems"
context... but I couldn't quite get it.

Please don't mistake my comments as negative, I think ebXML
is the greatest thing to come along in ages, and grateful for
everything that has been produced so far!

I think the sorts of people actually building ebXML should let the
other shoe fall, and articulate their own core components and
contexts. Maybe that's what's already happening thru the BP*
and BOT efforts.

This dimly reminds me of the OMG who have their MOF and CWM,
etc.  They are really in the registry/repository business.  Even
the ebXML BP and CC groups are dependent on the UML and XMI.

What a different world if would be if the OMG had produced just
a bit better effort at round-tripping data definitions thru a 11179
registry, and populated it with the obvious type sets for various
string, numeric and date/times.

The XML Schema inventors found they could not proceed without
the data types, and the Core Components group also found, they
could not proceed either.   Well, we can't either.  I think we need
more CCT's such as the Identifier Type I suggested, based on
URIs instead of "Agency".

Todd

At 06:34 AM 12/12/01, Duane Nickull wrote:


>Mike Rawlins wrote:
> > Thanks, but I still don't think I have an answer.  I know perfectly 
> well what "context"
> > is.  From your previous messages in this thread, I thought you were 
> referring to the
> > "context message".  Specifically, about it I was asking:
> >
> > 1)  How do you expect the context message to be used?
> >
> > 2)  Why is the context message "depended on by several other systems in 
> ebXML"?  (or at
> > least that's what I thought that you were asserting.  Forgive me if I 
> misread you.)
> >>>>>>>>>>>
>Okay - here it is in non technical language:
>
>Core Components are too abstract to be readily usable.  For Core
>Components to be used on a global basis,  we need the context
>mechanism.  Otherwise,  ebXML users will likely convert their existing
>business messages into their own core components.  This will lead to a
>proliferation of core components, hence interoperability will suffer.
>
>Therefore,  I assert that every scenario within ebXML that is concerned
>with Business Information is dependant on the COntext Mechanism.  If you
>look at a Runtime Stack or a Design sequence, the dependencies are
>obvious.
>
>IF you start to build software, and use proper object oriented
>techniques,  you will quickly discover that all the core components
>engines, the transformation components, assembly document engines and
>design tools are ALL dependent on the context rules message either
>directly or indirectly.
>
>
>Duane
>
>----------------------------------------------------------------
>The ebxml-dev list is sponsored by OASIS.
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.ebxml.org/ob/adm.pl>