[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Diversity (was RE: The lists I monitor)
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|