Cart
[Home] [By Thread] [By Date] [Recent Entries]
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
|
