Case against proprietary software on government systems

This has been sitting as a draft for more than two years now so I figured I should publish it.

The modern government is an information processing entity where public servants and software collaborate to serve the people. If you take away any of those two components, governments cease to operates. So it is crucial that government maintains control over its processes to shield itself from interference by outside interests; it is at the basis of sovereignty and part of what makes its area of jurisdiction a country.

You wouldn’t hire foreigners as public servants, so why would you trust your software to outside interests?

Software was introduced into governments by individuals who had no idea of what software was in the first place. It was and is still purchased, managed and used like off the shelf physical goods, but it was already too late when people figured out that replacing a vehicle fleet is a lot less work than migrating from on operating system to another.

Nowadays, companies like Microsoft could make every developed country’s government grind to a halt very easily or severely compromise it. Take the US patriot act for instance, which lets the government request any data from companies based in the US if they deem it necessary even if that data does not belong to an american entity. Another yet even more disturbing example uncovered by Edward Snowden is Microsoft handing out the keys to its encryption systems to the NSA thus actively collaborating in their espionage projects.

The European Union is starting to come to grips with this reality and is moving towards drafting rules and regulations that will make the interaction between software corporations and governments more open and directed towards giving their citizens security and value; unless this initiative gets killed by a lobby. This has obviously positioned open-source software as a preferred choice, prompting changes such as a migration to Ubuntu by the French Gendarmerie Nationale and the creation of Trustedbird by the french department of defense and British Telecom, a more secure fork of Mozilla Thunderbird (an e-mail client) whose code they intend to contribute back to the main Thunderbird tree for everyone to benefit from.

The procurement process in its current form cannot consider open-source technologies as it depends on active bids by companies. Software developed by volunteers is systematically left out for a lack of an imperative to market itself using conventional challenges. A few consulting firms on open-source technologies are trying to turn the tide but they only advertise the tip of the iceberg when it comes to all the available open-source solutions. There has been litigation lately in Quebec following decisions from the government to award a contract to Microsoft without a call for tenders based on criteria purposely crafted to exclude other vendors. A similar conflict occurred more recently when another governmental organization decided to procure MS Office licenses using the same scheme. This begs the question of whether the procurement process is really providing the government with the best value for its dollars.

I could go on detailing how companies are consciously locking governments in their own system by not following industry standards (Internet explorer has systematically been failing the ACID test) and violating anti-trust laws but I believe the previous paragraphs have been sufficient at getting my point across. I have nothing against Microsoft, IBM, or any other software corporation, they make quality products that are most often superior to the open-source equivalent (things would be the other way around if governments took part in helping developer communities improve their software). In fact, they themselves are  increasingly embracing the open development model because they have figured out that it provides them with the best value. Individuals and private businesses are free to spend their money in whatever manner they want, but government are not. They are not profit making machines or fashion following teens; they exist to bring security and prosperity to their citizens and basing information processes on closed-source software is an hindrance towards the achievement of those goals.

The lobby is strong so it is unlikely that change will come from atop. And even down at the individual level, most are incapable of dissociating Windows from a computer as Microsoft has made it certain in concert with the rest of the industry that every new computer around will be provided with a license of that operating system for very cheap (again sparking anti-trust lawsuits), thus never giving the user a real choice. Apple is starting to grind away at Microsoft’s market share thanks to the visibility it gets from its massively popular IPods and IPhones, but at the root, this company is not a whole lot different than its main competitor and in some cases practices even worse methods of locking customers in such as with their closed platform policies.

Nuts for coconuts, the amazing ways of consuming this exotic fruit

The coconut at the stage we are most familiar with

We know coconuts as the principal ingredient of a piña colada, we know coconuts as the tasty filling of a bounty chocolate bar, we know coconuts as the crucial part of a good curry, we know coconuts for their awesome taste but otherwise, we remain pretty ignorant about its many uses and life cycle.

Allow me to enlighten you with my recent experience with this incredible fruit and the knowledge I gathered from the locals in the Carribean. While not scientifical, I sincerely hope you will remember this little piece should you ever become stranded on a lonely tropical island. Otherwise, just take it as a little how-to guide for the next time you find yourself around a lot of coconuts.

An opened coconut

Coconuts as their name implies, are the nuts (or fruit (technically a drupe)) of the coconut palm tree. They grow everywhere around the carribean coast of Costa Rica and as far as I know, their extend is very large and in some cases, their productivity can turn them into a nuisance. There is no season for these trees, they just constantly produce all throughout the year, with every batch taking a couple months to mature. Coconuts are large fruits and do not biodegrade very easily. So much so that locals have to get rid of them (and their leaves) using bonfires.

A yellow coconut palm

Coco palms come into a few varieties which are mainly differentiated by the colours of their nuts: yellow, green, or something in between. If you are after pipa, you will prefer the green variety for its sweetness but when they age, the differences in flavor dissapear and the nuts all turn the same brown.

The pipa

A green coconut palm, preferred for pipa

There is a couple of vendors yelling “pipa fria” around you but cannot quite figure out what they are selling? Its coconut water, or “pipa”. A young coconut before it becomes ripe has a lot of water in it, easily 150 ml I would say. This water is sweet, very rich in minerals and feels very healthy to drink, if you can get past the weird taste (it’s somewhat of an acquired thing). Mike, another volunteer at the association has aptly called pipa “the gatorade of the jungle”: some local guides will not bring any water bottles on patrols, they will just reach up for a pipa or two.

A yellow “coco tierno” alongside a green pipa

The pipa is probably the stage of the coconut that is easiest to consume. Vendors in the street will slice the top off, put in a straw an refrigerate pipas but in nature, you just grab, smash and drink. Grab a pipa from the palm, smash it one or two times against the trunk until the nut cracks and drink the dripping water. It’s a bit messy but even though it is sweet, pipa will not get your hands all sticky.

The older pipa (or half-coconut)

Size comparison of a more mature coconut to a young pipa (which I am holding)

As they age and ripe, pipas grow bigger, thicker, and get harder to crack open. Should you succeed tough, you get rewarded with sweeter coconut water and a gelatinous substance called “coco tierno” (tender coco) that covers the inside surface. Coco water serves as a suspension for the endosperm of the nut and as it matures, will form this deposit. This substance is what is later going to become the white hard flesh of a ripe coconut and while the taste is somewhat different, it definitely hints towards that flavor.

The white gelatinous flesh can be scooped using a slice from the skin, notice the presence of shell

This tasty flesh can be scooped using a broken piece from the shell or a slice from the skin of the husk but in order to access it the nut has to be split in half. Without the proper tools (a machete), this is quite a challenge and requires a lot of smashing around and prying. At this stage, the very hard shell which we are used to crack with a hammer has started forming.

The nut (as we know it)

The tool of choice when working with coconuts: the machete

Now we come back into known territory, the ripe and mature nut is what we are used to finding in northern hemisphere supermarkets. What we are not familiar with however is how incredibly hard it is to get to the nut itself. Covered by a dry husk made of a thick skin and very fibrous material, this one it truly a “tough nut to crack”. Once open, little coconut water remains, most of it has coalesced into the very flavorful flesh we are all so fond of.

A ripe coconut with the husk removed

When on the ground and in the presence of humidity, the nut will obviously start to germinate. From one end of the nut, leaves will burgeon and from that same end a root system will emerge, all feeding on what is inside the nut and turning the flesh and water into a coconut sponge. Very rich, this sponge when be pressed will ooze oil (good for cooking) or can simply be eaten. Be careful, common wisdom has that eating too much of this will give you diarrhea.

A germinating coconut

These nuts are nature’s own small ships, known to have traveled by sea for thousand kilometers to land on a small remote island and populate it with this awesome tree. I did not get into the great many uses of the husk (textile), shell (jewelry, combustible) and the tree (lumber) itself, I did not cover the great many culinary, medicinal and industrial applications of this plant as well. I admit to be

Coconut sponge

wholly ignorant in this matter: the list of use cases for the coconut palm and its fruits seems virtually endless, I just know how to eat them raw.

Now we need to figure out how to grow these in Canada.

The fatality of modern work

This is translation of a text originally written in french and published around April 2009 on amoriscreatio.com, a friend`s blog. The original version can be found here. It turns out that translating is not as easy as it seems, even if I am both the original author and the translator. Incidently, my apologies are given in advance for everything that still has a french syntax to it.

At the time I am starting to write this piece, I have only spent two months and half in this field of cubicles but I feel like a man in his forties, jaded and purposeless from all those years wasted away in floors of false-walls, desks and computers. How can they do it, those colleagues of mine to whom I have never spoken a word, but on which I spy relentlessly in the hope that I will someday understand; understand how they came to accept this fatality of modern work.

What I mean by fatality.

On many occasions, I have shared my desire with my relatives to do what I love most full-time while possibly making enough money to live a frugal but comfortable existence. Almost systematically, I have been replied that work is a necessity before a leisure, that it’s one of those things in life you cannot avoid and that whatever your occupation, you should see it from a positive eye, especially if it pays well. In brief, work is a fatality every member of a society at least a bit conscientious of his quality of life must submit to.

The individuals I work with, should I present them the same question, would most likely give me the same answer. Not that I have asked around, but the fact that I have great difficulty in conceiving them being empty enough to fall under the charms of this paradigm, brings me to the same conclusion.

Times have changed; the western man no longer works solely for subsistence. It seems the American dream has taken over the latter as the first motive of work even tough it is no synonym of accomplishment. Yet, we still justify this quest for manufactured and artificial comfort as a necessity not unlike that of serfdom a few centuries ago. Only now, we seem to be in servitude of economical growth.

A disconcerting superficiality.

It took about ten seconds for discomfort to settle inside me. The moment I first sat in my cubicle, number 441 on the 4th floor of some government building, I kept immobile, stopped my breathing and opened my ears to the ambient sounds. On a background noise of typing, computer hums and various other humanly sonorities, I could hear two women converse; one explaining the traumatizing experience of driving her pet in emergency to the veterinary hospital and the other mechanically acquiescing. The rhythmic flow of typical linguistic constructions evoked a profound disinterestedness from the latter, but the axioms of office life dictated that she could not politely bring this conversation to an early but still overdue end. Trough extrapolation or empathy, I saw myself in a few years time in the very same situation and this is when I really sensed the discomfort. I could not see past my walled cubicle, but it felt like the field was closing in on my person, engulfing me in an insipid lifestyle.

Every day now I encounter this sort of situation where my colleagues chat about the weather (even though they will spend the entirety of the day inside), ask one another how they are doing (even though they do not care) or how their week-end went (even though they still do not care). I agree, those are sometimes legitimate questions, but I am also fully aware that they most often are asked out to promote a polite and concerned image. An image that I am currently forced to project myself, but which I find profoundly dishonest and artificial so incidentally I do my best to avoid those discussions like the plague for I do not want to foster any false friendships in this context. And I could be in the wrong, it could be that all of this is authentic; regardless, I do not want to hang around individuals who cannot converse about anything else.

They do not do it because they believe in it, but because they play the game; or is it that trough inevitable conditioning, they no longer question themselves? How can you show any interest about the low-level bureaucratic hardships of project in a sub-organization or some massive department? I don’t understand. Is it egoism? A desire for promotion? A tacit acceptation of this fatality? A pure lack of consciousness? The sheer variety of human minds that populate this planet leads me to believe to some entertain a genuine interest for this occupation, but that a thousand of them ended up in the same building appears to me as improbable. So, what type of person must you be to accept to spend a sizeable chunk of your conscious life as a cog of this administrative machine?

Profile of a victim.

Who are they and who should I be in order to become comfortable in such an environment? How can they tolerate an existence passing before their eyes in a monotonic cycle of work days, short evenings of numbing TV watching and a week-end instantly ruined by the perspective of yet another Monday? To this question I have found only one plausible answer: the absence of ambitions that cannot be realized by the simple accumulation of capital or social status. The fatality of work matches perfectly the very human goals of family, material comfort and peer recognition. However, it is grossly insufficient at fulfilling any desire for creation or intellectual development, which can only be fully realized when one is in full control of their existence and even more so their intellect.

Buried alive

My ambitions, I believe, are part of the second category and cannot consequently be fulfilled in this present context. I am then forced to choose between the pursuit of those ambitions of the plain acceptance of this fatality. Both options are risky, but one is necessarily nobler while the other confers greater security. If I select the path of reason and continue my progression in this present situation, certainly a physically comfortable one, I will be constrained to bury part of myself with the risk of it coming back to haunt me later on in life. On the other hand, if I follow my ambitions, I risk failure and could see myself having to accept the fatality of modern work and live with the sour taste of defeat for the rest of my days. I prefer the second options, burying a part of oneself is seldom advisable; plus, there is merit in the simple act of trying. But when I expose my vision to others, all I get for feedback is that I am an idealist, that my projects are nothing but utopia and that I am heading for a major disappointment. Although my interlocutors most often fit within the aforementioned descriptions, it remains that there is wisdom in their sayings as for lack of examples, they can only judge my success as unlikely. It seems that their solutions always consist of a change in attitude and an increase in openness towards variety of experiences my situation could bring me.

A question of attitude.

There exists a multitude of trades on this planet which could be classified as interesting. If I suppose for one second I had an infinite lifespan, I would have no problem with trying each and every one of them. However, the transient nature of our existence constrains us to make choices, and I have decided to spend my energies on things I genuinely like rather than trying to convince myself of the good of my present position. We have to be honest with ourselves.

The prevention of the creative process or the constraints of intellectual work.

Intellectual work, in an organizational context, is more than often issued and controlled in a hierarchical manner as the responsibility for success lies generally on higher echelons. Incidentally, those higher echelons expect that work be done in accord with their vision and with tools they are familiar with. While this state of affairs is totally justifiable, it has the major drawback of impeding the creative process, which can only strive in a horizontal manner when cooperation between individuals is involved. Mechanical work that requires no imagination and thus no creativity is generally attributed to workers. The difference here is that we are not transforming metal but information; since information is manipulated with the intellect, bureaucrats are then intellectual workers.

A place of decay.

The location this text questions is a place of decay, where every employee’s brain is slaved and drain of its energy in long hours spent facing a screen repeating more or less the same administrative processes. Upon coming home, this employee is overwhelmed with a feeling of mental fatigue and can not do anything but mundane leisure. The origin of this phenomenon is evident: the body tires. Sadly, after repeating this routine every single day, the individual looses his intellectual vivacity, killed by years of cycling between office work and television. A schism is created, where work and leisure can no longer cohabit. Work being intellectual, leisure time can no longer be of this type. He becomes uniform, inanimate, but more so less interesting and less interested; what used to make him question and think has been replaced with a never satisfied need to evade to a world where everything is simple and unchanging. Some do evade this fatality; those who have and authentic love for what they do; a passion exempt from the prospect of social promotion or peer recognition. But those are too rare of a species.

Manipulating oneself.
An ambition is a dream in effort of realization. Consequently, what transforms a dream in an ambition, what constitutes the effort is action. The amplitude of this action then depends on the magnitude of the ambition and its nature. Can it be realized in the near future? What sacrifices need to be made? How much effort needs to be expanded before coming to an end?

Some ambitions will materialize themselves without any work while others will require constant action, which is regrettably not the easiest for humans who have a strong tendency towards stability and facility once they are within reach. On top all the effort required to accomplish an ambition, we must also combat ourselves, fight this desire to let go and let the flow against which we were advancing overtake us; “what’s the point…” Against ourselves, two weapons are of particular efficiency, conviction and manipulation. Conviction pushes us towards realizing our ambitions trough faith while manipulation entices us to act on ourselves and our environment for the purpose of creating conviction. One must precede the other; conviction only is very often not sufficient, especially for more rational types. We can dream all we want, but sometimes, we must artificially create the conditions necessary to break ourselves out of comfort and push towards battling an imaginary nemesis whose sole function is to motivate us. To barricade ourselves in fortresses of biased beliefs and see evil everywhere except where our ambition lies. Sometimes, this can be the only way of escaping the sea of facility we live in.

A personal opinion in a relative world.

Does salvation resides in the liberation from organizational thought? Not for everyone. Most appear to be perfectly content where they are at, because of personality, because of unconsciousness, because of ambition, because of necessity, because of a need for servitude, etc. In a sense, what seems to be a fatality pleases the majority; negative for some can be positive for others, or it could be the simple acceptance of the order of things. So how do they live within it, what drives them? Most likely the instinctive ambitions upon which western society is built and the need to preserve them once they have been acquired; the rest is only consequent. The only thing that is certain is that I cannot accept this fatality.

Why all this? Moralizing others is a very audacious activity that very often turns sour, so I content myself with asking questions and sharing the results of my thinking with whoever will bother reading them; with the hope that they will in turn questions themselves.

A RESTful 3D web

Lately, I have come across many articles talking about opening the realm of accelerated 3D graphics to the web. While there has been many other initiatives to do such a thing in the past, it has gotten more serious lately since the big players have started to show interest in it. For example, the Khronos group (the consortium responsible for OpenGL, OpenAL, OpenGL | ES) has just recently launched a proposal to build a standardised JavaScript API for that purpose while Google just released O3D, its own JavaScript API for creating 3D applications on browsers. This is rather exciting as this seems like a definitive step towards moving away from proprietary applications to display rich graphics on the web, flash being the most ubiquitous.

However, judging by those press releases, I have a great concern over the direction a potential standard will be evolving towards. As it stands, it aims at implementing this new feature using JavaScript. While there is nothing wrong with using this language in general, using it to add a dimension to the Web does not go along with the philosophy the web is built on (REST) for reasons that will be detailed below. On top of that, there is already a standard that brings 3D to the Web in a RESTful way: X3D. For some reason, it is still in the dark as these lines are written and has not seen wide acceptance yet, but it is in my opinion the right way of doing things. Using JavaScript would relinquish X3D (or any perspective of a declarative way of describing 3D) to speciality applications because it is for now hard to work with. The fact is, people like to take the easy route, but in this case it will mean a lot more trouble down the line. To develop a bit more on this problem, this article will try to outline a few arguments for a RESTful implementation of the 3D web through a description language over an API based one and explain why a XML based solution is a good contender for an implementation.

Representations: guaranteed to work.

Mark-up languages currently in use on the web all share a simple fundamental goal: to describe the visual and semantic organization of information. HTML, for instance, describes the document tree or what relationship blocks of information (text) have with one another and what their respective purpose is with regards to the visual and semantic aspect of the data. The HTML specification also permits the description of visual features trough inline styling (b, font, h1, h2, etc.), but this usage will slowly disappear in order to give way to CSS. CSS, on the other hand, concerns itself mostly with visuals through describing both the styling and spatial representation of a document: nodes from the document tree can be moved around and styled as the designer sees fit. CSS and HTML are both different languages used for almost different purposes but they tackle two intersecting areas of the same problem space: pleasing and adapting to the human visual system.

The usage pattern of the two aforementioned languages in the context of the web fits perfectly with the REST mentality. Call an HTTP GET on a resource and it returns an HTML representation with embedded links to the CSS style sheets and scripts it uses. Then, upon reception of the documents, the browser from which the request originated will render this HTML + CSS representation and respond to user events according to the script. This request and render activity is at the core of the REST architecture and actually constitutes the bulk of the traffic on the web: get a representation and render it; representational state transfer. Trough transacting representations this way, the server cannot enforce any technical constraints with regards to what is done with the document once it is has been transferred to the requestor; the only exception being the version and type of the language. Hence, rendering representation is the client’s responsibility. The navigating can happen from a cell phone or by calling a wget on a Linux terminal; the concerned software will take care of transforming what it receives to the best of its ability. A representation is only a declaration issued by the resource on how it suggests it is best presented; if for some reason, the request originator cannot correctly render or understand the description language it just fetched, it remains possible to get a partial view and if all fails, the software can display the document itself, which happens to be human-readable. For example, with Windows computers whose ActiveX controls are disabled , web pages very often fail to display correctly and sometime are just plain unreadable. In this case, the user can just check the HTML source, from which he can infer the document layout but more importantly still get access to the information. Had the browser received a pile of vectors with several hundred lines of JavaScript code to render them instead, it is very likely that the individual could not have guessed it was actually rendered text or a teapot. This guaranteed level of service is not a feature of the Web itself but a consequence of the declarative nature of REST. Representations that are generated using scripting like JavaScript violate this principle because there is no way to know what it is without executing the script nor is there a way to tailor (to a certain extent) it for specific constraints like hardware, accessibility or internationalization; if the script fails, the user is left with nothing or very little to work with. The correct execution of scripts is their creators’ responsibility and there use as representation generators is therefore problematic because they cannot be validated and interpreted, not to mention the inherent security risks associated with their usage.

The declarative advantage.

Declarative architectures such as REST not only provide a consistent quality of service, but they also enable other entities to perform other operations than rendering the resources that compose them. A whole lot more information that has nothing to do with visuals can be inferred from the documents that describe the representation of those resources The semantic web, linking, microforms, search engines or mashups are very compelling examples of the declarative advantage. This type of interaction between resources is probably possible with scripted 3D, but not without a serious overhead in analysis and a very strict naming standard. Even there, the use of the aforementioned technologies would not integrate naturally with scripted 3D because they would have to remain within the declarative structure of the document.

The API tar pit.

JavaScript is quite different from HTML and CSS, because the way it acts on a representation has nothing to do with spatial representation: it adds interactivity. In a sense, JavaScript can be seen as the description of the interactive aspect of representation although it is not a declarative language. The programmatic nature of scripting makes JavaScript very versatile for certain tasks but it also makes matters a lot more complicated. The web would be a lot simpler without JavaScript, but it would also be completely static, just like in 1994. Scripting is a necessary evil, but it is nonetheless evil because it cannot be easily analysed and interpreted (not in the programming sense), either you do exactly what the script command says either you don’t. If the script wants to display a pop-up there is little you can do to stop it without interfering with the pages that make an honest use of this feature. Thankfully the language itself is textual and interpreted (in the programming sense), which makes it a very portable and powerful tool, but insofar as it remains true to its function: adding interactivity to representations. If it is used for any other purposes, we then run into the risk of negating the many advantages of the REST architectural style. It might not appear to be such a big deal, but if one looks at the way things are messed up and complicated in the application software world, they come to realize that using JavaScript as a full-fledged programming language is somewhat risky in the Web context, even if it remains on the last layer of a software stack (if it is not interacted with). If the 3D web is implemented using an API, then it will not be long until other APIs based on it start proliferating and what was originally a great idea will turn into an immense collection of multiply-versioned and incompatible APIs doing more or less the same thing. The browser is not supposed to be a runtime environment; it is a window on the Web whose only purpose is to act as an interpreter for humans navigating it. If we build JavaScript APIs to add 3D content to the web, we face the risk of turning it into a tar pit, even with standardization. Microsoft is notorious for not following standards; now imagine we include Nvidia and ATI in this business. 3D solutions vendors operate with different marketing techniques than in other fields; they and their customers are all about visuals, and vendors will not hesitate to break standards and to promote a new feature on their product. Naturally, that feature will only be available on hardware that supports it. The pace of the 3D market is just too quick for standardized APIs; vendors need a lot more flexibility, they need an extensible language.

XML.

A 3D environment is not that different from a webpage and can easily be described using XML. It involves many objects that all share relationships of dependence with one another; just like the document tree (the equivalent in 3D jargon is called the scene graph). Reality in fact, which 3D usually aims at approximating is no different and can be represented using a tree structure. Take for example a table with a teapot on it. If the table is moved around, the teapot will follow because its absolute position is dependant on the table’s position. The teapot’s location with regards to the table, its relative position did not change. This makes the teapot a child of the table. This example failed to account for physics for the sake of simplicity, but it shows XML based languages are perfectly fit for describing 3D spaces. As a matter of fact, the idea is not new and many languages exist for this purpose, like VRML, X3D and COLLADA just to name a few. Consequently, using such a document to convey the 3D representation of a resource stays true to the declarative nature of the Web. If a browser is not compatible with an API, it cannot just skip the unknown script lines; otherwise, the whole script will most likely fail. On the other hand, if a browser cannot interpret a tag on a 3D description document it can skips that node of the document tree without worrying whether or not it will compromise the rest of the rendering. The user will be presented with an approximate view of the representation that might very well be sufficient for what he wants to accomplish. There will be no need to specify many render paths for different hardware or rely on the JavaScript engine to do it, if a tag cannot be rendered, it is just skipped. Programmable shader pipelines are a nice technology, but they do not add very much to the functionality of a 3D environment; if a teapot is to be displayed, it does not need to be refractive for the user to figure out it is a transparent teapot. Put differently, no one should need a cutting edge GPU to see some polygons. With XML based languages, descriptions are naturally extensible so vendors are free to add their own tags without waiting for standard approval and without sacrificing the user-base that does not support this new feature; they still break the standard, but the consequences are not as grave. In the absence of 3D rendering capacities, XML always remain fairly readable and can be consulted directly, a 3D scene generated with JavaScript is, on the other hand, very difficult if not impossible to infer without execution of the script.
The advantages of using a XML language to describe spaces do not end there. If a developer wants to add physical properties to a set of objects, all he has to do is to insert the pertinent tags in the document tree describing the scene. With an API things are much more complicated. The same can apply for movement, which can also be considered an integral part of a representation. Displaying 3D this way is completely RESTful and it leaves JavaScript doing the job it does best: add user interactivity through modifying the DOM.
XML also provide a fair amount of interoperability out of the box; by mixing a spatial description language with other compatible languages, like XHTML, it becomes possible to blend many types of content together. As an example, a website could be developed to provide a small service where users can consult multiple web pages simultaneously using a cube like Linux’s Compiz or tiling like Mac OS X’s exposé. The different faces involved would contain XHTML IFrames, or for a more static display, the XHTML could be part of the document tree describing the scene as a child of the face displaying it.

Complexity.

A 3D description language is without a doubt much more complex than any other one that deals with a lesser number of dimensions. The X3D specification, for instance, is many pages long and makes a fair amount of assumptions over the reader’s proficiency with computer graphics concept, but it is nonetheless much easier to deal with than program; the syntax is self-explanatory and there is not need to deal with the complex resource management required to program efficient 3D. Many already know OpenGL and Direct3D and they surely use their present skills over learning a new description language. However, they are far from representative of the majority; for a newcomer, it is much easier learning a description language than an API. Plus, WYSIWYG tools can be developed to automate the generation of 3D, so anyone can with little effort create a 3D web page. Thanks to the ease of use of its core languages and the many authoring tools available, programmers are now far from being the main creators of content on the Web. Doing it with a JavaScript 3D API would be way too intimidating and would drive away the vast majority of users, making the 3D web inaccessible to most.

The bottom line.

Could the 3D web be implemented with an API? Certainly, computers provide us with infinite ways to do an infinite amount of things, but some ways are better than others. Since the inception of the Web, there has only been a handful of versions of its core components, and thanks to this consistency, 10 years old web browsers can probably still navigate it; the same cannot be said for a five year old GPU and current games. Programs are strict successions of operations and are not subject to interpretation; visualisation, on the other hand is everything but that. After all, we already use XML to describe 2D so why should it be different for 3D? The ease of use of the core languages of the Web has made the creation of content accessible to anyone; I would like to see the use and authoring of 3D become an integral part of it as well, not some obscure feature only gamers and the technical crowd can make use of.