Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Adam Bosworth Article - what does "direct access" mean?
 James Governor wrote: > Are you for real? Trying to work out how much irony is in your posts. > > James Governor > RedMonk > (+44) 207 254 7371 None. What would be the point? I do have a full schedule and better things to do with my time than score points for smirking off those who drop in to XML-DEV a time or two and then disappear. I have said the same things here consistently for five years. I think that it is necessary that they be said (and heeded) for the long-term good of the craft. I have organized the monthly meetings of the XML SIG in New York since 1998 for the same reason. In both forums I have seen a steady parade of those who would improve XML by subsetting it for efficiency in doing this or that. Their prescriptions always involve cutting away at either the lexical or the internetwork roots of XML, usually both. My work depends on using XML to process documents, or data, together though they come from disparate sources, usually unknown to each other, and were never intended to mix. The 'intended' is crucial. The applications of XML which appear truly magical, which provide the true "aha!" moment for someone seeing them for the first time are, in my experience, always the result of doing something which was never intended to be. But that's just the point. What XML offers that nothing else I have worked with does is freedom from intent. My process doesn't, and shouldn't, care what the creator of some bit of data which it uses might have wanted, even to the extent of whether what I have received is 'valid' according to some content model. The bare lexical instance is there; either it provides something of use to me on this particular occasion or it doesn't, without regard to whether that something is labelled as it was in previous examples, or whether it parses out to the same level in a hierarchical tree. The richness or value of XML as data is observably in inverse proportion to its intent. If you set out to publish a document full of information then your primary concern is for the quality of the data which you will include in that document, not for the nature of its eventual user. If I gain access to that document there will be much in it which I can use, regardless whether my use is one that you ever imagined. At the other extreme, if all that your document contains is keys to a database which is available to the document's intended recipient then that document is likely useless to me as a third party bystander to its transmission between closely coupled sender and receiver. The sender has perfect knowledge of the receiver's internals and can therefore select, and force the receiver's attention to, particular items of the receiver's own local data. Such intent is the underlying premise of traditional enterprise network systems, where closely coupled nodes have intimate knowledge of each other behind the firewall. In transaction processing it is the fundamental premise of two-phase commit. XML, by contrast, can leverage its lexical and internetwork roots to offer an entirely different model of operation. The fundamental internetwork assumption is that every node is directly addressable, but beyond that may be entirely unknown. Communication between such nodes is necessarily loosely coupled and depends in large part on one offering enough data that another might do something useful with, even where the creator or publisher of information does not know which particular data a particular user of that information requires, nor how that user might process it. Such assumptions coupled with the markup tools of XML result, in the best cases, in the publication of well-labelled documents, filled with information that their creator has to offer and cannot assume that any particular recipient might otherwise have access to, and published at an internetwork URL where a variety of interested parties might gain access. As I see it, the real problem is imagining that a schema for a document is like an interface to an object. Direct access--addressing parts of a document based on what a schema indicates should be there--has been too readily confused with invoking the methods of an object by presenting the expected arguments to an interface. We have seen that, in practice, it is too short a step from accepting that analogy to chopping away at the lexical or the internetwork roots of XML, or both. Why can't an object serialization, encoded as XML perhaps or maybe not, be passed between processes, and save the inefficiencies of parsing and generally dealing with awkward, prolix text? The answer is that in that question too many unwarranted assumptions have been made, among them that any particular user of an XML document will use it in any particular way, that the object serialized by one user is useful, or even understandable, as an object to another user, and that the data structure built on the output of a parse by one process will, or should, be the same as that built by another process on the output of a different parse of the same document. The problem is thinking of documents in imperative terms: it seems to be too short a step from imagining a document as a message to imagining that message can convey a command or anything resembling RPC. That assumption depends not only on mistaking that one process will use a message or document in much the same way as another, but also wrongly assuming that different processes will instantiate anything like the same data from their separate parsing of the same message. Those are assumptions which are workable and useful in some narrow scenarios, but when they become the general assumptions of XML processing the scope of XML's possibilities is dramatically narrowed. It is important to me to keep all of the possibilities inherent in XML open, no matter for how small a minority of users, and to keep them open forever, because one of the chief needs for XML's possibilities of interoperability is interoperability over time. If most users, relying on tool vendors and a perspective of purely programming efficiency, begin to create XML documents which are, as instances in their own right, information poor because they are intended for very specific narrow uses by particular programs, all of us lose. I lose more than others because I depend so greatly on making unexpected use of information-rich documents. But in general what is best about XML is lost when documents aren't really documents at all, but codes and keys used for interprocess communication between senders and receivers locked in a brittle, closely coupled embrace. 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
|
|||||||||
