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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

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

Subject: RE: Business Process team Preliminary Document

Hi Martin,

As a member of the Business Process team and also
Core Components, I can respond to your issues to some
extent.  I'm copying the BP list on this message, too -
hope you don't mind.  They need the issues.

I put your last issue first because I agree with you
(although I am not speaking for the BP group in any
official capacity here, just expressing my own opinion):

Martin Bryan wrote:
>I note with dismay that the scenario proposed by the Business Process group 
>"assumes for simplicity that none of the parts of the business model are yet 
>in the repository and that the organization(s) designing it are willing to retrofit 
>their applications to fit the new model." What I thought we were trying to do was 
>to stop people starting from scatch or from their own proprietary solutions, 
>encouraging them wherever possible to start from an existing sets of core 
>components rather than their existing set of information entities!

 I think you are correct that core components should either be part of the 
"New Business Model" scenario or a separate scenario should be written 
explicitly using core components.

There are several scenarios in the document - the one you quoted is only 
one possibility.  There is another one called "Conversion" that assumes
a business model that pre-dated ebXML.  

I have no immediate response to your other issues, which
seem to me to require more discussion between BP and CC groups,
especially the relationships between Business Signals and 
Business Documents. Maybe this can happen in Brussels.

So I just quoted your statements below in order to present them
to tbe BP list.

Bob Haugen

More issues for the BP group from Martin Bryan of Core Components:
>I am worried about the way the Business Process team see the role of Information 
>Entities within Business Documents. It would seem that what they refer to as 
>Fundamental Information Entities are what we refer to as Core Components, which 
>are the things they have stored in Dictionaries The definitions of how these would 
>be used in Business Documents seem wrong to me. Their current definitions are:

>Business Document.
>A business document is the description of a particular entity within a business, 
>or the description of an agreement between organizations, or the description of 
>an business event. So the document is never the 'real' thing, just a description of it. 
>A business document is the central component of any information exchange 
>among partner roles.

>Information Entity.
>An information entity is a primitive or complex data structure. We haven't defined 
>this yet, but it may be that the difference between a data structure and an 
>information entity is that the information entity also contains business rules about 
>the data.

>Fundamental Information Entity.
>A Fundamental Information Entity is in essence a data type. In business contexts 
>we might need many more 'data types' with business semantics beyond the 
>standard data types of 'int', float' etc.

>(Consider how core components organize terms in the dictionary for optimal re-use.)
>The dictionary should contain data types, re-usable components, and the templates 
>(DTD's) of the business documents, but not the documents themselves.

>I would prefer to have definitions more along the following lines:

>The Dictionary contains re-usable components, including fundamental information 
>entities, enumerated code lists, data type representation specifications and templates 
>for business documents (e.g. DTDs and Schemas).

>Fundamental Information Entity.
>A Fundamental Information Entity is a reusable unit of exchangeable information, 
>together with a set of rules defining constraints on its content (e.g. it conforms to 
>a named data type representation or has a value from a named enumerated code list).

>Information Entity.
>An Information Entity defines a processable unit of information within a business 
>document. It can have either a simple (single component) or a complex (multiple 
>component) data structure. Where possible it should consist  of one or more 
>Fundamental Information Entities. Information Entities can be constrained in terms 
>of both their contents (e.g. the set of permitted components in a complex data 
>structure) and in the relationships between information entities (e.g. if this entity 
>contains component X with contents y then that entity must contain component A 
>with contents B within the same document entity).

>Business Document.
>A Business Document is a set of Information Entities that is exchanged between 
>Partners as a Business Signal relating to a particular Business Process Interface. 
>A Business Document is the central component of any information exchange 
>among Partners.

>(Other forms of "business document" might include the description of a particular 
>entity within a business, or the description of an agreement between organizations, 
>etc, but such documents are not used directly as business signals. The above 
>definition applies only to documents that contain information of relevance to a 
>business event.)

[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