[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Fast text output from SAX?
We will now have a comparative history debate in which two points of view separated by different interests will attempt the usual futile fusions. For those who aren't interested, hit the delete key now. Claude L Bullard wrote: >> There were reasons to go to markup over all of the >> binary solutions that dominated the markets when >> that decision was made. The success of that >> decision is evident by the near ubiquitous use >> of markup systems now and the ease with which >> unprecedented integration and standardization >> is occurring. >I'm sorry but I just don't accept this as anything other than >rewriting history. As far as I know, there was only *one* moment in >this industry when a large number of people sat down to debate the >"text vs binary" decision. That moment came back in the 80's during >the early days of X.400 and X.500. And, the result of that debate was >to choose ASN.1 as the winner. Yes and for a while, ASN had the upper hand which made things moderately difficult for the markup community mostly engaged after that period in DoD work. We found out that reuse of binaries was horrible, that ASN systems were not readily available and were not cost effective as a result. However, the more pressing problem was Adobe's insistence first on Postscript, then on PDF, and the WYSIWYG snake charmers who wanted to trade ease for both speed and reuse. Every time we did the work, it came back to simple tagged data objects as the sweet spot: scalable, easily vetted, cheap, human readable, designable by less than master degreed computer professionals and so on. It was this intersection of human, machine and commercial interests that eventually made STEP/Express and SGML the winners of the CALS initiative. And this was when the cost of an SGML parser was outrageous. As a US Army civil servant said at a large meeting, "It's terrible but the best we have". In short, it wasn't the computer science industry that chose. They never have that choice. It was the customers. Typically, system integrators get to choose formats, not system vendors. Lesson learned. No matter what the propellorHeads tell me, it is the customer that has to be sold on the idea. XML was sold to propellorHeads with a dose of "and this will kill off SGML" and they were naive enough to buy that. Slick! >What happened later was that HTML grew in popularity due to >HTML's use in a single (but compelling application). Gencoding always wins if a naive customer is choosing. There are good reasons for it. That is why it is the original markup application dating from the 1960s. It is the first thing everyone tries. It just has the problem of not being a vertical tag stack. >The HTML folk were then joined by their SGML cousins (the SGML folk wanted to get >"back on top" again) and we eventually got XML. As several people on the list can tell you, SGMLers were there from the time TimBL first started demoing at CERN. Certain ones were incredulous that after as much hypermedia research existed, the wireHead was proposing gencoding. At that time, there was no 'top' to get on. HTML doesn't impress anyone who has a background in the domain. But it was a heckuva a good onramp. The more pecuniary among the SGMLers noted that quickly and worked hard both to make HTML a compliant SGML application, then to get SGML On The Web. Slam dunk because it came in low and fast under the radar. The W3C gets the public credit for XML, but that's another bit of mythInformation. It was SGMLers who made it happen with not an insignificant amount of bad behavior, but that's life online. >This wasn't a decision >-- it was a social process that was driven by primarily non-technical >forces. No significant decisions made for large systems are ever completely technical or non-technical. If they were, we'd all be using LISP on the command line. >However, there are still >applications around that have a need for hard "technical" >characteristics (like compactness and parsing speed) that is greater >than their need for the social benefits of ease of use, debugging, >etc. Here we agree. I've said that from the first email. There are applications for which XML is inappropriate on-the-wire or in memory because verbosity matters very much, datatype support matters very much, and in these cases, human readability matters a lot less. VRML is the case I use. Real-time 3D staggers a processor unless the author is quite proficient, and that sends the cost of the document soaring as well as limits the uptake by the occasional user. So in X3D, there are three encodings including a binary. It comes back to, "will a generalized XML binary work well enough for the applications that need a binary to accept the penalties of generalization? IOW, will they end up creating their own binary anyway, thus nailing to the church door one of the reasons for the WG: preventing single use binaries from proliferating. >The original "decision" to choose ASN.1 was made in a time >when the players were all much more aware of the technical >requirements than they were of social needs. Machines and networks >were terribly slow. Software development was highly concentrated in a >small number of highly skilled groups. The software industry still had >very little experience with non-technical products of any kind. Yes. But ASN went to the parking lot quickly because the cheap processors and memory, GUIs, and the opening of the Internet to commercial use started a grassfire that took out the wheatfield with it. For all of the awards given the web, the first SGML hypermedia systems predate it and yes, they worked on networks. Some of them still do. But as you say, history and markets pick winners and conveniently forget facts that don't fit the mythology. That's fine. >Now, times have changed and we've got XML to solve a whole >class of issues. Today, the percentage of people who *need* something >like binary encodings is much smaller then it was back in the 80's, >but there are still a significant number of applications and >organizations that still have relatively severe technical requirements >for compactness and speed... That's why this perma-thread has never >died. The need is still there. I agree. >What we need is detente between these two camps. They have >been battling for decades now. It is time to stop fighting and learn >to work *together*. We should use XML for text based stuff and ASN.1 >binary encodings for the binary stuff. Anyone who isn't satisfied by >one of these two probably has a requirement so bizarre that there >isn't anything a general standard could do for them. That's what we are here to determine, but when the thread started, it was a polite request to do this on the public list for this task, and so far, I haven't received a single email from that list. It's a demonstration example I want to provide to a certain 'list community maestro' who has told another organization that he can get bigList denizens to accept his forums after years of the community being on a big list. There are cultures that just won't be corraled. There are technologies that just won't die or be replaced. There are niches of alternatives. So we need to work out just how much need there is for another XML system format because unless we can show a ten fold benefit for everyone, it will be better to work this for a smaller application domain. Thanks Bob. Enjoyable as always. len
|
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
|