Re: Business Process team Preliminary Document

["Martin Bryan" <mtbryan@sgml.u-net.com>]

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.

Dictionary.
(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:

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

----------

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!

Martin Bryan
CEN/ISSS DAMSAD project group