Re: Picking the Tools -- Marrying processing models to data model s

["W. E. Perry" <wperry@fiduciary.com>]

Al Snell wrote:

> On Mon, 21 May 2001, Uche Ogbuji wrote:
>
> > OO was about making the operations actually intrinsic to the bundles of
> > data.
> >
> > The post-OO evolution at which I think you hinted is about flipping it
> > all the way around so we're drafting neat functions to operate against
> > the properly considered data models.
>
> That's a backwards step - databases started with that kind of architecture,
> and are trying to move to an OO model (limited somewhat by the lack of a
> decent standard)

I believe that Al is quite correct that moving toward a data-centric
architecture is retrograde. We have seen a fundamental shift from a network to
an internetwork topology. In the network topology characterized by enterprises
facing one another through their respective gateways, we can design both data
and process within each enterprise around consistent and
mutually-corroborating assumptions. For their gateways, the various
enterprises can either adopt an 'industry standard' vocabulary (specifying
more than 2000 of which seems to me to have been the chief employment of XML
as a modelling tool to date), or each enterprise can establish custom
transforms for dealing with each of its data interchange counterparties. In
either case, the transactional possibilities for each enterprise are limited
both by the transaction definitions--including both data and process
models--within the enterprise firewall and by the specific data model
transforms available at the enterprise gateway.

An internetwork, however, does not bring its constituent networks into
conformity as an homogenous whole, but instead overlays upon them a universal
addressing scheme. In that topology, every node is addressable from every
other node, and both the enterprise gateway and the homogeneity of the network
within it become relics of a design which is incapable of exploiting the full
range of transactional possibilities offered by that any-to-any addressing
scheme. The question of whether data model dictates process model or vice
versa falls moot before the autonomy of each addressable node. Nodes have
processes which are specific to their--often unique--roles in the hands of
their immediate users. Whether local process at a node is designed around
local data structure, or the reverse, is immaterial to another autonomous
node. Data models at one node have no standing, in the internetwork topology,
to influence the local process models of another node, nor may those process
models expect that they will be provided in a data interchange with the
precise structures or content models which their local operations anticipate.

Bridging the simultaneous autonomy of process as locally performed and data as
interchanged node to node is the role par excellence of XML markup. Instance
markup expresses the data model of the document creator while not constraining
the process of the document consumer to the creator's intent. Given the mutual
autonomy of the nodes, and the simultaneous autonomy of foreign data and local
process, there could hardly be any other workable solution.

Respectfully,

Walter Perry