Re: Syntax Free Models

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

Bob

> The reason for posing the Type, Commitment and Event levels is
> that it was not always clear which level you were talking about,
> and it seemed to me to be a good way to clarify concepts -
> as it helps to distinguish class from instance in object modeling.

Very much a needed thing: fortunately we have the DTD classe definitions and
the XML message instances well split for ebXML.

... [Have cut irrelevant info from in front of all the remaining parts of
this message!]

> Commitments are records of agreement on events that are supposed
> to happen in the future.

Interesting you should stress the future. A message normally implies a
future event, but the timescale is undefined. You seem to be talking about
something (a commitment) that is within, for example, a 1 day to 1year time
frame, whereas the general case is within a 1sec to 1 century time frame.

> I concur that your information units are about the messages
> involved in commitments.  Your process chains are are something
> else again - a mixture of material and info flows.

I am in the process of splitting these two out. Later today I'll post a
revised version at http://www.sgml.u-net.com/neutral.htm. What is important
though is that material flows (processes) are triggered by info flows
(messages)

> Types are (as the name implies) metadata, or the types of objects
> that live in the Commitment or Event levels.  For example,
> CommitmentType might be Purchase or Sale or ProductionSchedule -
> or more concretely, the type of Purchasing agreement used by
> Ford when it buys oxygen sensors from Bosch.  An instance
> of that type would govern such purchases.

OK, so we split the Type as defined in the
DTD/Schema/InformationMessageDefinition from the
Committment/MessageInstance.

> Your process chains to be working at the Type level, if I understood
> correctly.  They were normative descriptions, not instances of
> commitments or events.

Yes

> >> Likewise at the commitment level, when operational plans are made,
> >> for example replenishing retail stocks based on point of sale events:
> >> the demand flow travels backward along the process chain for the
> >> product-to-be-replenished until it (possibly) hits some
inventory-on-hand
> >> sufficient to satisfy the demand - possibly at a distribution center.
> >> In this case, the replenishment process chain starts at the
> >> distribution center.
>
> >> You may have these levels of variation in  mind as well.
> >> I'd be interested to know.
>
> Did you answer this question and I missed it?

I did not. The question of direction of message travel is to me irrelevant.
The point is that there is an event that generates a message that triggers
another event that .... Whether the first event starts in company A and ends
in company B, or vice versa, is irrelevant. What is important is that
eventually the event chain needs to return to the source, because the last
action is invariably taken by the organization that undertook the first
action (or its representative, the bank if the last action is payment).

>The collaborating process
> agents need to agree on the state names that they will use
> to collaborate.  That is much simpler than agreeing on internal
> processes.  When one processing agent gets something with
> an agreed state name from another, the processing agent
> can determine from the state name what to do next.  But
> the state name does not directly tell that, it just gets
> mapped to something in the internal systems of the
> processing agent.

My message name and your state name seem to coincide. The question is should
the name be that of the state that generated the message or that the message
is designed to trigger. As the state to be triggered can vary from scenario
to scenario my preference is to record the name of the state that generated
the message, and then for "listening event processors" to identify that that
type of message is one that they can use to trigger an event. (I know a
number of examples where messages are sent around a ring which has a number
of processes attached to it: each process checks to see if the message is of
a type that has contents that it needs to process, and if so it processes
the relevant part of the message, leaving the message to continue on the
ring to be seen by other processors. One advantage of this is that you can
get parallel processing using this technique, rather than the more
tradiitional serial processing of messages passed between processes.)

Martin Bryan