[
Lists Home |
Date Index |
Thread Index
]
It would seem that would be of use in a design
for a virtual data warehouse. In essence, it
is the contract for the backend systems to join.
len
-----Original Message-----
From: Steven R. Newcomb [mailto:srn@coolheads.com]
> How useful is that in the real world? That is, if
> company A defines one format for invoices and company
> B defines another format, what are the chances that
> these are (hierarchically) similar enough that I can
> define AFs to process them as a single format? My gut
> reaction is that this is unlikely.
Right, Ron. The AF paradigm is not for everyone, and
it's not useful for every purpose.
AFs provide a way for Companies A and B to *cooperate*
with each other to maintain one or more common base
syntaxes that will permit them to interchange
information reliably, and point the finger of blame
when information interchange fails to occur, but
without giving up any sovereignty that they wish to
retain over their separate-but-derived syntaxes.
If A and B haven't chosen to cooperate (or, more
accurately, if they don't both happen to use (any of)
the same base architecture(s), for whatever reason),
AFs have nothing to offer.
The act of cooperating can have many benefits in
addition to the benefit of reliable information
interchange, while retaining local control of the
details. AFs just provide a tangible, workable goal
for cooperative efforts that use syntax as the basis of
cooperation. That's not an insignificant thing.
|
