OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: XML Gave A War, But Nobody Came

Just a small addition to what Lisa said, which I agree with by the way.
Specifically, Lisa said:

>>> Strictly from a structure perspective, a message is probably made up of
three components:  Header, Detail and Summary.<<<

We mustn't forget the envelope.

Before you send someone a letter you put it in an envelope and then post it.
What Transport Routing and Packaging group is doing is to design an
electronic envelope in which to put the "message" (we call it a document
rather than a message so we need to sort out our terminology!). We also
specify how an electronic postal system should work so that you know that
your message will get to its destination securely and safely, and if there's
a problem, you're told about it.

IMHO, I really think what ebXML is doing hangs together.


-----Original Message-----
From: Lisa M. Shreve [mailto:lms@wwnet.com]
Sent: Friday, June 02, 2000 10:03 AM
To: Robert Dakin
Cc: ebXML@lists.oasis-open.org; mel@wwnet.com
Subject: Re: XML Gave A War, But Nobody Came


I'd like to agree with much of what you have said, with some additions.

> >[snipped]
> >
> >Therefore, why not spend our collective efforts on developing a common
> >framework/infrastructure that will support interoperability of any and
> >variants? That's much more achievable than developing a single common
> >document format and then getting the world to adopt it.
> Having lurked for some time, I am venturing from my bunker to say
> a few words.
> I would have thought that he natural OO approach would be  to
> think of a PO (or whatever) as a class and develop a tree of PO's.
> The root of the tree would comprise a common subset of data
> and functionality, and descendent classes would elaborate parent
> classes to satisfy real application contexts.
> Root classes would most naturally belong in Core Components.
> I had assumed that an OO approach to EC would include this idea,
> extending to multi-transaction scenarios - but I have
> not seen much evidence of this way of thinking in recent ebXML
> material.  Please correct me if I have missed something.
> By exploiting polymorphism and inheritance it should be
> relatively easy to construct software components that handle
> any of a subtree of PO's or whatever and achieve interoperability
> between them.

>From the perspective of one person from Core Components PT,

As the Project Team Leader for CC, I'd like to repeat again what we have
saying from the start  ... we recognize that the last thing the world needs
yet another PO!

That said, what can we do?  Well, we sure know quite a bit about what
work!  Independent industry development leads to a proliferation of
incompatible messages, and makes interoperabililty unnecessarily complex &
expensive!  One size fits all business usages [process] and all industries
messages, leads to very large, complex, semanticall vague and very costly

OK, what do we do?  Well, we can build a framework, capitalizing on levels
stability where we can achieve core object "standardization" and provide an
extention methodology for all the "customization" necessary for real world
implementation.  And, very simply put, what we are doing in Core Components.

How might that look ******* my own personal theory ******

First, our levels of stability, starting on the data side with the core
Message.  That message has two characteristics:  Structure and content.
Strictly from a structure perspective, this message is probably made up of
three components:  Header, Detail and Summary.  Header contains information
that is relevent to the entire message:  Document References and the Role
Players [simple case = requester/responder pair, complex cases involve
and brokers for requester/responder].  The Detail section could have a
of structures:  flat, flat loop, hierarchical loops, etc.  From a content
standpoint, there are a limited number of  conceptual or abstract classes
repeat through out messages:  Requester, Responder, goods, packaging,
etc.  Then, at the lowest level, there are other *stable* core elements,
as name, address, quantity, amount, etc.

Now on the process side of the house, clearly there is a core business
for PROCUREMENT ... and in that procurement process there are a series of
NOTICE, etc.  These Core messages, within this business process, probably
an abstract description, based on Content abstract classes:  Role Players,
Document References, Goods, Pricing, etc.  What we will find is that there
significant content overlap amongst these messages, which is exactly what we

start with the CORE Procurement business process, and then begin to subclass
the process [using the meta model as a guide], and those messages such as
Core ORDER message, and for each high level abstract class, given the set of
stable low level core elements, each industry can build the industry
components such as Joe Industry Goods descriptions.  Some abstract elements
the message should not be industry specific, such as payment details, which
occur in multiple formats, but not as many as one for each industry.

Next, context.  Based on some handful [small number] of contextual clues
[business process, industry, etc.] combined with an organization scheme, one
can predict [deterministic] which Goods descriptions, Requester/Responder
descriptions, etc., apply to any specific message object.

What do we have now, 1) an architecture which supports industry specific
2) an infrastructure which encourages reuse, 3) concise messages which do
depend on additional "implementation guides", 4) reusable components, at a
variety of levels, which are semantically consistent [one way to say one
thing], and 5) extensibility which facilitates the reuse process with a
mechanism to add to or reduce existing sub-components.  Obviously, having a
registry/repository which facilitates sharing, reuse, and organization will
of tremendous value!

On the subject of how this aids the SME, I hope the answer is obvious ...
way to say one semantic thing, concise messages, and an infrastructure for
organization, etc., aid application developers to incorporate ecommerce into
applications ... shrink wapped solutions become feasable.

I doubt that anything that is done in ebXML can impact the ability to "duct
tape" ebXML to legacy systems, however, the very same qualities that make
shrinkwrapped applications feasible, result in the availablility of
semantically stable middleware that can be "duct taped" to legacy

Regardless of the level of technological sophistication, in the end we all
depend on implementors/industries/standards developers to assume a mentality
compliance, and recognize the cost of non-conformance to the community at
large.  Standards built need to be considered a "neutral" representation,
an image in existing internal systems.  As long as we can concatenate,
cross reference, bridge, etc., to and from the standard without violating
semantic integrity, there should never be a reason to modify the core.

All this said, this is one persons vision.  Until the project teams are
to complete their work, we won't be able to determine if this theory of
"stability points" is any better than other guesses.  So, I'd like to
that we call an end to this theoretical discussion, until technical research
tells us how we put the pieces together to solve this problem.

I have tried to put this in business terms, and have tried to stay away from
jargon, but if this message needs to be made clearer, I propose that this
discussion be taken over by marketing, and moved to the marketing and
project team.

Thank you,


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC