Re: Syntax Free Models

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

Keith

> I have some difficulty with the process definition (InformationSeq)
transfer.  By this I mean - which process are we referring to: the last
process activated, the next intended, the set of all possible candidates....
We also get into the problem of process granularity and variations of
practice between trading partners and market participants.
> The Information Sequence concept has not been defined and seems the most
debatable concept in the paper.

An Information Sequence is simply the definition of the order in which a
particular group of Information Sets have been used within a specific
Information Message type. Different Information Message types could use the
same Information Sets in a different Information Sequence. Alternatively the
same Inforrmation Message can provide alternative Informaion Sequences that
can serve the same purpose. What is important about the Information Message
type is that it contains answers to a known group of Information Sets, in
some known order.

The name of an Information Message should normally refer to the process that
created the last set of answers to be completed. A Process Chain always
moves Information Messages from an Orgininating Process to a Receiving
Process. What needs to be identified to understand the context of answers
received is the Originating Process that generated that answer. The
Receiving Process needs to be known to the workflow engine, but need not be
recorded as part of the exchanged message. (This does not mean to say it
cannot be recorded in the message, just that this wil make the message less
flexible in terms of reusability.)

> I suggest that process id/label(InofrmationSeq)  transfer should not be
done, but that the more stable State signal be transferred.

Information Sequences are not labelled: they inherit the label of the
Information Message.
(In XML terms you can think of Information Sequences as parameter entities
used to define the model of the Information Message. The names of the
parameter entities never appear in the message: they are there for modelling
purposes only.)

> This does not mean that we dont analyse processes and describe value
chains, dependencies ..., but that these do not form part of the information
transfer.

Recording the relationships between answers needs to be part of the business
model.

> I have attached a modified internal paper for your review.  I have
attempted a change of language to some of those you have suggested - but
have not yet been completely consistent.

This seems to mainly concern how Process Chains should evolve in response to
answers. I agree that processes can/should lead to splits in Process Chains
dependent on answers given. However, I did not try to fully cover this in
the first draft of my paper.

> There is also another piece of work where one of my collegues (Andrew
Blair) has detailed a Workflow Specification (using a range of UML compliant
techniques) for particular transactions within the Australian Pensions
Industry - I will provide the URL in another email.

This will be very welcome. To my mind Workflow is the key to much of this.
Have you been following the work of the Workflow Management Consrotium and
the IETF SWAP group in this area? They also use the concept of events.
Incidentally, I don't see a fundamental difference between an event and a
process, except that most people seem to see events as a sub-component of a
process.

Martin Bryan