Subject: RE: [ebxml-bp] ebBP 10/10/2005: Specification and Logical Bus Documents
At the process layer we need to allow mulitple "format expressions" for a document to map state into the business process.
ebBP uses semantic document use/content as the basis for our logical document. .
Another way to express this is to say "a logical document in ebBP describes the semantic content of a physical document" - this includes not only the semantic business objective of the document, but also maps the semantic content of the document (e.g. a physical PO response document may be mapped to two or more logical documents in ebBP, "acceptPOResponse" / "rejectPOResponse" or "ShipImmediatePOResponse" / "HoldForReleasePOResponse") This is important because even though the physical layout may be the same, the semantic content may map differently based on the semantic purpose of the document.
The variables allow us to access into the physical content to condition process execution, but by-and-large the ebBP tries to stay away from knowledge of the physical content of the documents.
(sorry for so many uses of the word "semantic", I got carried away).
The point is that this allows effective mapping of both format and use case, which is so important given the reuse of document schemas we are seeing. It also allows the process to describe the logical business execution and leave latitude for mapping that the specific implementations.
I guess I would agree that ebBP points at the document model, rather than the document itself (with the exception of the variables and document schema references). This is valuable in keeping the ebBP squarely focussed at semantic business execution. I would argue that there are elements of both information modeling and data organization in this approach, leaving your last question still ambiguously answered.