Re: [ebxml-dev] ebXML specifications interdendancies

[Duane Nickull <duane@xmlglobal.com>]

Comments inline:

Mike Rawlins wrote:
<SNIP>
> > 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. 
>>>>>>>>
How do you expect to get the Geopolitical context from a database when
the information is only available when the two CPP's are bound
together?  

Mike, context is used in design,  becuase the Runtime Phase is dependent
on the design phase,  it therefore affects everything in the Runtime
pahse that interacts with the business information.

> 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.
>>>>>>>>>>
Matt MacKenzie and I have implemented a rudimentry Proof of concept
which I have demonstrated for over three months now.  It can be done. 
Its' in the Wrox book called "Professional ebXML Foundations" with code
samples and a full explanation.
 
> 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?
>>>>>>>>
This is not directly relied upon.  It is an indirect relationship
becuase the business payloads are built on Core COmponents that "Could"
be context constrained or modified.

>  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.
>>>>>>>>>>>>>>>>>>>>
What you are talking about is a "bottom up" approach.  Instead of using
the UN/CEFACT Core COmponents and applying context, a business can use
the XML Core Components schema to re purpose their existing business
information into their own messages.

FTR: I think in reality, many will use this approach and gradually,
perhaps over several years,  they will harmonize this with the UN/CEFACT
Core Components.  My original statement was that the ebXML mechanisms
pertaining to UN/CEFACT COre COmponents are dependent on the context
mechanism.  I stand by that.

For the record,  I have also written a chapter in the wrox book
documenting the ground up approach, even if it is not the advocated
method described within ebXML.  It was however, an example and case
study of what could be done today.
 
> 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.
>>>>>>>>>>>>
I suggest you are mising up the Design time with the Runtime.  The
processing overhead of configuring a business collaboration would  be
done during Design time and only ponce.  THat could lead to a series of
Runtime Transformations which are not required to do a context process
at each phase. 

The context is applied to the metadata, not the business message
instances.  There is still an implied dependency becuase the metadata is
derived using UN/CEFACT COre Components.
 
> 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?
>>>>>>>>>>>>
This is similar to the UBL approach and I see lots of merit to it.
> 
> 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.
>>>>>>>>>>>>

<Sigh> - I agree 100% with you.  The only way to find all of this is
probably by implementation.  The other complexities become unnerving for
most which worries me becuase of the requirement to keep ebXML simple
for SME's.

I guess interoperability comes wiht a price.  The one who wins will be
th eone who designs the system with a two click GUI and hides all of
this complexity in the back end.

I see that offering several key components of ebXML as web based
services can keep the costs low.  I will work on making the context
engine into a web service and poist a white paper showing how to use it.

Thanks for the many insightful comments.  Vigilane pays off.  I think
this thread has pushed the context implementation envelope out the
furthest its' ever been.

Cheers

Duane Nickull
-- 
CTO, XML Global Technologies
****************************
Transformation - http://www.xmlglobal.com/prod/foundation/
ebXML Central - http://www.xmlglobal.com/prod/central/