Re: [ebxml-dev] ebXML specifications interdendancies

[Mike Rawlins <mike@rawlinsecconsulting.com>]

Duane,

Thanks.  A few comments below:

Duane Nickull wrote <snipped>:

> 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.

Agreed.  Core components are defined as being context independent.  Any real business data
has context associated with it.  In ebXML terms, a Business Information Entity is a CC with
context applied (at least according to my understanding of the latest CC draft).

>
>
> 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.

I agree that you can't do anything useful in terms of processing the data without knowing the
context.  Where we get hazy is on what is meant by "context mechanism".

> 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.

Here is where I disagree with you.  In the most straight forward usage, context is known at
the time of analysis and design, when you develop the schema from BIEs.  A context mechanism
or message may be an aid in analysis and design, but it this case context could just as
easily be derived from a database rather than a message.  Also, given the current state of
software engineering, I don't believe that we can be completely deterministic in schema
analysis and design using context applied to CCs, so it will only be an aid.

But, for sake of argument let's assume that deterministic schema assembly in this fashion
isn't science fiction.  I then ask the question why should we rely on a context
message/mechanism at runtime?  The schema can be created at the time the business
collaboration is set up based on database contents.  It is static so long as the
collaboration is unchanged.  Why should each party need to assemble the schema every time at
run time?  This poses yet another onerous processing requirement on application software
which puts ebXML even further out of reach for SMEs.

In addition, transformation can be done very well using UIDs assigned to BIEs.  These are
also static.  I see only unnecessary processing overhead in always having to derive the BIEs
dynamically by applying context to CCs.

There are other complexities as well.  If one takes the strictly CC approach and doesn't use
BIEs when setting up a collaboration, then in an instance document we would need to have
something like <party role="buyer"> and <party role="seller">, applying at the instance level
the context "role".  The XSD schema could only say that we must have a party element with
between minOccurs and maxOccurs occurrences.  I don't see a way in this approach to specify
that we must have a buyer and seller.  (Someone know an XSD trick to do this?).   The only
reasonable way to write the schema to express this constraint is to have something like
<buyerParty> and <sellerParty> with minOccurs and maxOccurs on both of "1".  At this point we
then have applied at least one type of context to a CC to create BIEs, and are not in a
"pure" CC environment.  Why not just then just use only BIEs and make for a reasonable schema
at design time instead of trying to get real fancy and do everything dynamically at run time?

There *may* be other uses for a context message that I don't see right off, but I don't see
justification for using them at run time to understand message semantics.

Cheers,

--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com