An issue is emerging in several blogs and technical lists on the topic of expectations for backward compatibility of document formats on the web. At XML.COM, David Peterson rebuts a Popular Science article about a digital ice age when future archaeologists cannot decipher our current times because of our choices to publish documents in digital formats on digital media.
The long lifecycle argument has been occurring for at least three decades in computer systems circles and was one of the reasons for the success of markup systems. It only has so much mileage because static data is not enough to ensure behavioral fidelity on recovery unless behavioral semantics are stored as well. In the long lifecycle, we know that knowledge does get lost and the medium may not make a difference. Some of it can be recovered if smart people put their minds to it. The recovery of Egyptian hieroglyphics is an example. On the other hand, the library of Alexandria is gone forever.
Shorter lifecycles are immediate problems. The seas for successful products are both smoothed AND made rough by the intersection of competition for improvements and standards for interoperable information. Expectations for backward and upward compatibility vary by product and worse, are violent in the expectations for products that are distinct but familial. Success can be the worst thing that happens to a young band and the worst thing that can happen to a young application. As it was for Egyptian scholars, the history of media and medium can be cruel indeed. It pays to keep a sober head.
A thread is going on the X3D/VRML lists regards VRML 1.0. It was a successful format but not a very capable one. It was 'the simplest thing that could possibly work' and because it was a static model without behaviors, the vendors and the community moved on to VRML97. Then the bubble burst, history has been rewriten since (SecondLife Invents the Metaverse! yeah, whatever...) for the purpose of marketing new applications.
So history, format and application do force some formats out of mainstream use but in the case of the web, NOT OFF THE SERVERS. The dilemma in VRML/X3D is that even with the new X3D format as the third generation of the language, there are a significant number of VRML 1.0 files on the servers. There are no usage statistics but they are still there. The question is, should an author/owner of these files expect the new players to support them?
In the database community, data conversion costs are accepted as a fact of business when a new system replaces an old one. It is priced into the contract. On the other hand, HTML, VRML, SVG, etc are documents. We expect those to keep working in a backwards compatible mode of operation particularly if they were wildly successful in their initial fielding. As a result, HTML design hyteresis is legendary in its impact on the evolution of the language. Design camps have bifurcated into different languages with familial relationships and the (X)HTML browsers have to support them all XML's draconian parse not withstanding. The result: an HTML browser is the exemplar of bloat and script drudgery.
There are no conclusions because the decisions vary by situation. Some observations:
1) Initial fielding of the 'simplest thing that can possibly work' coupled with 'wild success' has consequences. Like an early young marriage, you may outgrow it and face an expensive divorce or an uncomfortable life later.
2) Expectations of databases and document systems are different, but the Internet and WWW system create a hot zone where these requirements overlap. Language by language, we are facing different decisions made by different vendors at different times that will make interoperation in mashups and aggregate documents problematic at best and highly failure prone at worst. What is thinkable and unthinkable varies by situation. Forget the Overton; look at the budgets.
The outcomes for languages and requirements for vendors are left to the reader to work out. Let me put it this way: Microsoft has no reason to fear that it won't have a secure future.
No comments:
Post a Comment