Re: Software abstraction layer to ebXML core component objects

["Hayes, Brian" <Brian.Hayes@Commerceone.com>]

Todd wrote:
- Couldn't the software developer implement some kind of abstraction 
- layer, that could point to *any* core component?  This would 
- let their 
- software survive the changes in Core components. 
[Brian] There is a great deal to be learned from EDI and back-office
integrations on how to handle this.  Big hint: documents are yet just
another presentation of information just as a UI is a presentation of
information.  Those who tie themselves to native implementation of standard
representation models of the information may find it difficult to adjust to
changes in the models as they version over time.

Todd wrote:
- That is as far as I go, with the business requirements.  I'm 
- waiting for ebXML to cough up some more core components and willing to 
- lay odds that 
- the SMEs will just pick them up and start using them natively.
[Brian]
1.  I always thought the Core Component's charter to be that of providing a
methodology for discovering core components NOT delivering core compenents.
This is a huge distinction.
2.  I'm not sure what you mean by "just pick them up and start using the
natively."  As I mentioned above, "there is a great deal to be learned from
EDI and back-office integrations."

Todd wrote:
- Meanwhile--small developers I suppose, should write an 
- abstraction layer 
- to interoperate with these diverse, new, ever-changing core component 
- objects, to play in this fascinating new game. 
It's good to state this and restate this (and is in line with my "big hint"
above).  Of course, what we will see in many cases is just the opposite of
this as time-to-delivery schedules and poor design result in implementations
with a high meintenace cost.

/Brian

application/ms-tnef