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


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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

Subject: RE: [ebxml-bp] ebBP 10/10/2005: Specification and Logical Bus Documents

Title: Message
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.
-----Original Message-----
From: Tim McGrath [mailto:tmcgrath@portcomm.com.au]
Sent: Tuesday, October 11, 2005 8:27 AM
To: Monica J Martin
Cc: Stephen Green; ebxml-bp@lists.oasis-open.org; ubl@lists.oasis-open.org
Subject: Re: [ebxml-bp] ebBP 10/10/2005: Specification and Logical Bus Documents

just want to be clear here, i think a logical document is a document NOT a model.  I think the the ebBP description sounds like they mean "document model" not "document".

also, i dont want to get into "term warfare" but stephen's definition is the interpretation taken from software engineering, ie "logical" disk storage versus "physical" disk allocation.  mine is taken from information modeling where a logical model is a data model that describes in an abstract way how data is represented. it has more detail than a conceptual model but does not include the design considerations and implementation parameters found in a physical model.Both are valid but we need to know which one ebB means.

Monica J Martin wrote:
Stephen Green wrote:


Tim McGrath raised an interesting question on the ubl list:
what exactly is meant by logical business document? Tim's
understanding was that it was a document's model. Mine
was that a logical document is one that may include other
documents but is regarded as just one document 'logically'.

I reckon this needs some exact agreement and definition
since it clearly has different possible interpretations which
could make a big difference to this matter.

mm1: Agreed. We will discuss in today's call. Thanks.

tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services

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