Re: Diversity (was RE: The lists I monitor)

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

Richard Lanyon wrote:

> On Tue, 8 May 2001, Simon St.Laurent wrote:
> > At 01:40 PM 5/8/01 +0200, Anderson, John wrote:
>
> > >Wasn't the whole point of XML to remove diversity so we could all join
> > >hands and dance together as one big happy web enabled platform independent
> > >family?
>
> > My usual answer is that XML 1.0 removed syntactic diversity
>
> And I thought that XML enabled self-describing diversity. Anyone else?

I believe that to take this any further we will have to distinguish data
structure from process, or in more homely terms, nouns from verbs. Where data
structures are not self-describing, interoperability requires significant a
priori agreement on process. It is self-describing data markup which offers at
least the possibility of one node instantiating received data, or some part of
it, directly in a form specific to the perhaps unique processing which that node
performs. That is, the syntax of data as received might be submitted directly to
processing which yields semantics unique to that node. Your node, for example,
might be a cash register sending me a bill of sale as you execute each
transaction. The unique function of my node, however, might be to tabulate sales
by various taxable categories in New Jersey. The structure of your bill of sale
and the datatyping of its fields would be largely irrelevant to me. Yet without
self-describing markup I would have to instantiate that data in the form and of
the types which you intended, only then largely to disregard it. My ability to
perform that instantiation would depend entirely on my a priori agreement with
you on the form and 'meaning' of the data, even though that agreed 'meaning' was
nothing like my particular understanding or use of the data. Among other
consequences of this required agreement is that neither of us can execute
transactions over this data against other parties before such agreements are in
place, even though the details of those agreements might be largely, or entirely,
irrelevant to the specific transactions which are to be consummated.

Self-describing markup offers the possibility of process-centric rather than
data-centric transactions. It is axiomatic for me that each functional node
expresses an expertise in a particular, and potentially unique, process. It
should be the business of that process to determine, at that node and in each
instance, whether received data can be usefully manipulated. Rather than
'validating' that the data structure received was the data structure
expected--and therefore should be locally processable without error--the local
process, through its own unique operation, either makes something useful of the
data received or it does not. The data-centric approach stifles diversity:  not
only are the data structures exchanged only those which all parties have agreed
on beforehand, but the processes which manipulate them at each node are largely
dictated by the agreed form of the data. As I see it, the alternative is to build
locally unique processes, perfectly expressing local expertise, whose
expectations of data are based on the manner in which they process it rather than
on the form in which they have agreed that it should arrive. In such a design,
self-describing markup allows that data to be instantiated directly in the form
it is locally consumed, rather than in the sender's understanding of its meaning.
This allows the sender to transmit data structures which make sense to him,
without regard to the expectations of the recipient. The result is a diversity of
both data and process, and a proliferation of unique combinations of the two.

Respectfully,

Walter Perry