[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: It's the syntax. . .
Thank you very much for a thoughtful and detailed reply: "Eve L. Maler" wrote: > I'm sorry, but speaking as someone who was there, I disagree entirely with > your perspective on the history of XML. It is solely about syntax > precisely *because* we knew it was impossible to anticipate the semantic > needs of the world in a single standard; we fully expected all these > various semantic efforts to get going. I do not think we are very far apart here, given the difference of our viewpoints. I am obviously inferring motivation from an historian's perspective, whereas you are recalling your intentions and expectations as a first-party participant. Nonetheless, you assert my two principal points: 1) it (that is, XML 1.0 as promulgated) *is* solely about syntax; and 2) it was (is) impossible to anticipate the semantic needs of the world in a single standard. Naturally, I would go further than you may be persuaded, in contending that the various follow-on semantic efforts have, each in its own purview, behaved as if the semantic needs of the world could be anticipated, and prescribed for, in a single standard. > Also, we didn't invent well-formedness in order to eliminate the need for > shared semantics; the original reason was to reduce bandwidth where the DTD > (but really, the semantics, since DTDs have very little meaning all by > themselves) was agreed on beforehand. Again, we are not that far apart, given your contemporary versus my historical perspective on intent. I would argue that, whatever the intent, the primary effect of WF was to open at least the possibility of eliminating (explicitly) shared semantics, as a legitimate and equal alternative to the pre-agreed semantics of the DTD. That is (by far!) the single most significant innovation of XML. To me, the inescapable principal consequence of that innovation is to force us to pay attention to the markup on its own terms. > Being in possession of a single well-formed XML document, with no other > information at hand to say how to interpret it, is extremely uninteresting. Extremely challenging, yes, yet not only not uninteresting (sorry!) but, to me the central problem and greatest fascination of XML processing. And, in fact, there is a great deal of information to hand for interpreting the document. Appropriate questions for determining how to interpret--that is, to process--it include: what processing am I, as a node, capable of? what information to work upon does that processing require? is there in this document any such information, or indications of where and how to find or derive it? > Even "autonomous, largely anonymous nodes" need a shared context in which > to exchange information. Yes, but the *shared* portion of that context may consist principally of the information itself. Each node also has its internal, private context, within which the interpretation, and therefore the appropriate processing of the data, may appear very different than within the context of the other node. > If the point is to share information, then I don't see how standardized > semantics can be considered a bottleneck. They are, in fact, the principal bottleneck in such operations, and often fatal to a useful outcome. The point of putting this information onto a network was to expose it to a vastly larger audience than was otherwise possible. Most of those many additional nodes do not share a broad basis for common syntax, precisely because they were not previously part of the club (or vertical market, or common business practices) which agreed on those semantics at a time when the new majority of nodes were still inaccessible. There is no choice in many cases--and the general case should be--that the only workable common denominator of semantics is no shared semantics at all, only markup syntax. > I just called a fabric-cleaning person on the phone today, someone I've > never > met before. I wouldn't have gotten anywhere if I'd simply said > "subject-verb-object" to him, but because I could safely assume he spoke > English, and knew something about fabric cleaning, You make the assumption, but *he* has to implement it--in processing. He may well be hiding from you that he does not understand English, or even that he cannot understand from your message that it has anything to do with fabric cleaning. What if this was, in fact, a worst case miscommunication and he defaulted to a crude brute-force solution: he replied to your message with a statement of every service he was able to offer (there probably aren't that many), and you ignored what appeared to be gibberish until you received, and replied to (perhaps with modifications) the one thing--an offer of fabric cleaning--which made sense to you in the context of the conversation you thought you were conducting. At that point, you and he have the basis for ongoing conversation--in fact, for stepwise refinement and agreement to a transaction. > Different parties may want to perform different processing (e.g., > translation of text vs. formatting it), but share a common understanding of > what the content means in order to perform their different tasks > successfully. Or they may want to use different subsets of the shared > information. Or use different augmented *supersets* of the shared > information. Or it may be more efficient for the recipient to do the > processing than the sender. XML's standardized syntax facilitates all of > these situations where nothing else could before. I couldn't agree with this more. It is XML's standardized *syntax* on which all of these possibilities depend. Simple well-formedness enables any of this processing, within the context of how the node doing the processing understands the data and is capable of handling it. Yet as soon as one node tries to force its semantics along with the data onto another node whose internal structures and methods it does not know, it may preclude if those semantics are heeded the very structure into which the other node might have instantiated the data and thereby understood how to process it in some useful fashion. > I don't mean to trivialize your points by eliding them, but I have no idea > what it means to have a processor of XML (higher-level than a true "XML > processor") that *doesn't* depend on semantics. You can't glean any hidden > instructions for what to do with XML stuff by merely parsing it; you need > something in addition that tells you either (a) what things "mean" (perhaps > in prose or perhaps by reference to shared semantical nuggets) or (b) what > to do with them (something executable). Yes, you do, but the greatest part of that is context and capability internal to the node doing the processing. Respectfully, Walter Perry *************************************************************************** This is xml-dev, the mailing list for XML developers. To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ ***************************************************************************
|
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
|