[
Lists Home |
Date Index |
Thread Index
]
[Happy New Year]
I will presume to give an answer to the question that you ask Tony, and
though it proceeds out of my experience in processing transactions in
financial instruments, I am quite certain that it is not what Tony would
say:
Tony is correct that exchanging data which the recipient is required to
calculate anew has been anathema in the design of financial processing
systems to date. XML, the internetwork topology, and the REST principles
change all that. Or, at least, the promise that the {shudder} new paradigm
offers is that the use of (in this example, financial) data need no longer
be confined solely to the cartel who agree a priori precisely how that data
is to be processed--which is to say, they agree precisely what, and only
what, it is to be used for. In the traditional world of financial
processing, where the parties have already agreed in advance precisely what
processing is to be done, it is a needless exposure to risk in the
vicissitudes of transmission to send unprocessed data and rely on the
recipient to process it correctly when the agreed upon output of processing
could have been sent instead.
But our subject is not the closed cartel of traditional financial
processing, but instead how XML *Components* (to cite the title of this
thread) and the data for interchange might be better designed for a
different environment. When that environment is an internetwork, where the
processing nodes have neither the intimate knowledge of each other's
functions nor the agreed roles which they would have in the traditional
homogenous enterprise network, the REST principles provide our best design
guide. That is, each processing node should publish at a URL the particular
unique output of its processing *without regard for what other nodes might
subsequently use that data, for what purpose, or in what form*. Other nodes
with an interest in that data--whether that interest is one that the
original processor knows or 'approves' of, or not--may GET that output and
then perform their own particular processing upon it.
What then is the proper and the most efficient form of data for interchange?
In the internetwork world, in a system designed on REST principles, and with
XML available as a markup tool, the best form for interchange is the
specific form in which the expertise of each process is most perfectly
captured, which is to say the native form of that process's output, without
regard for what processes will use that data further down the line and in
what form they might wish to receive it.
Respectfully,
Walter Perry
"Roger L. Costello" wrote:
> "Anthony B. Coates" wrote:
> >
> > > 1. You should never interchange data that may be calculated.
> > > Interchange using the "fundamental data", from which calculations
> > > may be done.
> >
> > Sorry to have to say this, but this is one of the prime
> > anti-principles in financial XML specs. It makes the XML compact, but
> > not robust. It assumes that every system will calculate the derived
> > values the same way. This can be very hard to guarantee in practice,
> > and it is a risk not worth taking when you have big sums of money
> > (or in other context, people's lives) involved.
>
> You make an excellent point Tony! I'd like to explore the issue a bit.
>
> If it's okay with you, I'd like to stick with my distance example.
> First, let me make certain that I fully understand your point:
>
> I argued that the aircraft system should not interchange this data:
>
> <distance to="destination airport">590</distance>
>
> Instead, it should interchange position data.
>
> Your concern is that an application will receive the position data, do
> calculations on it to generate the distance, and in so doing may end up
> with a value of something other than 590 (e.g., 585), due to things like
> rounding errors and differing algorithms. I believe that is the crux of
> the problem that you have identified, correct?
>
> It just dawned on me that I have been locked into this mental pattern:
> "distance is the critical value and that value must be maintained
> between the sender and recipients". Let's change that mental pattern.
> (Has anyone read Lateral Thinking by Edward DeBono?)
>
> Let's stop making distance the critical value but rather make position
> the critical value! For example, rather than the recipient application
> behaving in this fashion:
>
> "when the distance is 400 then I will do xyz",
>
> instead the recipient application deals with the position directly and
> thus behaves like this:
>
> "when the position is {lat=39.345, lon=78.410, hae="12000"}
> then I will do xyz".
>
> [hae = height above ellipsoid]
>
> By shifting the applications' focus away from distance to position we
> get multiple benefits:
> - we get all the benefits of interchanging "high value data" (which
> I described in my last message)
> - plus, we get the confidence that the sender and receiver will
> be dealing with the same data
>
> How does that sound Tony? Perhaps you could give an example from the
> financial world and see if we can do a "mental pattern shift" as above?
|
