[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Abstract Equivalence (was Microsoft FUD on binary XML...)
W. E. Perry wrote: > draw a distinction between XML and any platonic > abstract syntax such as ASN.1 and the like. Yes, I'm a "platonist" as far as this discussion goes and I suspect that many of the ASN.1 supporters are as well. I assume we're talking about the "cave" here... In the cave, the schema is the form and the shadows on the wall are the XML, BER, PER, etc. I may block the light with my fingers and cause what appears to be the shadow of a rabbit to appear on the wall. You may choose to see it as a rabbit and that might be my intent, but then again it might not. You may see a rabbit when what I wanted you to see was something different -- perhaps just a demonstration that even after 50 years, my fingers are still flexible enough to bend as shown in the shadow. But whatever my intent, and whatever you believe you see, I will always know that it is merely the shadow of my fingers. But, I'm also Aristotelian in that I think that "The Rhetoric" is relevant reading whenever one is dealing with communications systems. As Aristotle teaches, it is important for the speaker to understand the warrants of his audience. Both speaker and audience must share a common understanding of the speech and the context in which it is made -- otherwise, what is heard may not be what was said. If I wish to show flexible fingers, yet you see rabbits, we have not communicated... Schemas help us communicate and share warrants -- they are the ground, implicit or explicit, upon which all communications are built. Of course, by communications, I mean "utterances" that are made with "intent." I do not believe it useful to consider all processes which cause modifications in the entropy of remote systems to be "communications". > the 50 years or longer struggle in the 20th century > that was required for classical philology to > understand the nature of oral poetry demonstrates > why the physical, rather than any abstract nature of > a text is worth insisting upon. You declare here the end of a battle that still rages. Perhaps *you* have accepted this view, but many others -- including myself, have not. But, the subject here is interprocess communication -- not poetry. Thus, I will resist the temptation to flame about what passes as teaching in the literature departments of today's universities... > ASN.1 and abstract syntax generally are incapable > of a precise and unambiguous encoding of inherent > fundamental textual properties without resorting > to a priori agreements between the creator and the > consumer of a document, and from the very nature of > document processing such agreements are unreliable > and negligible. This is simply not true. Technical inaccuracies do little to advance your cause... There is no question that an ASN.1 schema can be defined that encodes, without loss, all of the emanent qualities of any particular piece of text. And, it need not do it with any more ambiguity than exists in a textual encoding where questions of spelling, lexicography, the formation of letters, etc. all introduce ambiguity into most texts. The difference here may be between the "explicit" schemas which are presented with languages like ASN.1 and the "textual" encodings which typically rely on "implicit" schemas that are the sum of massive amounts of schema-like material in the form of shared experiences, agreement on language, the semantics of words, context, etc. > the fundamental distinction of document and > data to which all permathreads return XML, ASN.1, BER, etc. are all used, in one application or another, to deal with both documents and data. You seem to argue for rules that are mostly applicable to these things you call documents -- to the exclusion of solutions that make data interchange as easy and accurate as it might be. It seems that to maintain this position, you would have to insist that XML is an inappropriate tool for "data applications." Yet, you appear to be taking the alternate rule of insisting that all XML based data systems be forced to accept the "fundamentally" different constraints of a document-oriented system. How can you justify this? Why do you care what the "data people" do if your concern is so clearly focused on non-data things? If data and document are as fundamentally different as you say they are, then we, and you, should allow and encourage distinct sets of rules and tools for dealing with each. (But, no more distinct than necessary! Reuse is good...) Perhaps with "documents" one would not use schemas -- but with data it is often an exceptionally good idea to use schemas. Given that XML is used for both "documents" and for data, I suggest that the folk concerned with documents would be well advised to define schemas for their work -- if only to prevent the "data" people from making the mistake of thinking that they understand some "implied" schema in the documents. For instance, if you are one of those that insists that an element whose value is "00123" should be passed *with* the leading zeros intact, then define a schema that explicitly defines the element as a character string or use a schema language that lets you say "don't trim leading zeros." At the same time, if I am working with data which a schema says is an INTEGER -- whether or not it has leading zeros, then I should be free to ignore these pesky wasted of bits. i.e "The Schema shall set us free!" by allowing us to make the document/data distinction when necessary. (Note: I do agree that by default, in the absence of an explicit statement in a schema, the values in an arbitrary chunk of XML should be treated as character strings.) Perhaps in this conflict between "document" and "data" we are like the English and the Americans peoples were in the eyes of Winston Churchill -- Churchill said we are: "two peoples separated by a common language." If so, let us come together. bob wyman
|
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
|