There are days on which you whip out your text editor, take a deep and fulfilling breath, set your jaw to its squarest, type line after line of code as clouds drift by in fast motion, run your code, and it just works. Right there. Right now. Smooth. And then there are days like today when it seems the Universe is bending itself not just backwards but into exotic topologies to tell you you shouldn't be writing code. Days, for instance, very much like today.

Le toujours très à propos Stéphane Sire me faisait part il y a peu de la citation qui suit. Essayez de deviner de qui elle est, où elle est publiée, et la date de sa rédaction avant d'avoir fini de la lire.

Il y a quelques mois, le site de l'Assemblée Nationale s'est vu ajouter une page listant les projets de loi dont les études d'impact sont actuellement ouvertes aux contributions. Les internautes peuvent y consulter un dossier et y déposer une contribution. C'est très limité, on ne sait pas très bien à qui l'on s'adresse, il n'y a pas vraiment de voie de retour ni de place pour le débat mais ne boudons pas: c'est déjà un (tout petit) pas en avant.

La semaine dernière je suis allé à la conférence débat Les actifs immatériels publics, leviers de création de richesse et de modernisation de l'Etat de l'APIE (Agence du Patrimoine Immatériel de l'État). J'avoue que j'étais assez excité à l'idée d'aller voir de plus près ce qui se trame en matière d'Open Data en France. Je n'en ai été que plus déçu à la fois par la totale absence du débat annoncé, et par le peu de vision claire ou prometteuse fournie.

Après avoir pratiqué une politique pour le moins agressive, et justement décriée, à l'encontre d'Internet, une partie, au moins, des députés de la majorité semble avoir réalisé que ses actions étaient à rebours de l'évolution de la société et qu'elle paraissait ne manifester pour ces changements que mépris et incompréhension. En réaction à ce dommageable état de fait, un groupe de travail “Éthique du Numérique” réunissant deux douzaines de députés UMP s'est penché sur une politique alternative, se voulant plus en phase avec son temps. Ce dernier a récemment publié un rapport intitulé “Vive internet! Liberté et règles dans le monde numérique”. Si son contenu est de qualité inégale, il fait néanmoins preuve d'un mouvement salutaire dans le sens d'une meilleure compréhension d'Internet par les politiques, et quelles que soient mes appréciations variées de ses diverses parties je lui reconnaît sincèrement de contenir suffisamment de matériau pour justifier le bazar de retour que je présente ici.

WebIDL is a schema language for APIs that is being used (primarily) as part of W3C specifications in order to define various interfaces. If you've read any recent API specification, you've read WebIDL. It is abstract enough that using it one could generate interfaces for a great number of programming languages, but given its origin it is only normal that the vast majority of the time it is used to produce Javascript bindings.

Un adage commun parmi les normalisateurs est qu'il y a deux entités dont nul ne peut vouloir connaître le réel fonctionnement interne: une usine de saucisses, et un groupe de normalisation. Mais avant que tu ne fuies, cher lecteur, saches que dans cet article je ne m'attacherai qu'aux cotés positifs de ce monde méconnu avec pour principaux objectifs d'expliquer d'une part l'utilité de la normalisation, et de faire ressortir d'autre part ceux de ses aspects qui pourraient être utilement appliqués dans d'autres domaines.

Back in the late XXth century I used to be a big fan of the Persistence of Vision Raytracer (aka POV-Ray). My general lack of design taste, at best very fuzzy understanding of what I was doing, and a sluggish P166 combined to keep me from ever doing anything really good with it, but still I toiled the nights away making shiny metal balls that would reflect checkerboards in misty mornings.

Le Web politique français bout aujourd'hui de toutes ses bullesD'aucuns se réjouiront du fait qu'au moins il ne bulle pas de tous ses bouts.. De nombreux politiques se jettent gaiment dans les eaux mouvementées des réseaux sociaux et de Twitter comme autant de brigades de sauvetage aux bronzages galbés un jour de grande alerte près de Malibu. Ces dernières semaines ont vu l'arrivée de nouveaux sites pour le PS comme pour l'UMP, ainsi que de leurs plateformes collaboratives la “CooPol” et les “Créateurs de Possibles”. Cet engouement soudain porte en lui nombre d'innovations dans la façon de faire de la politique en France. La question que je me pose ici est de définir ce qu'elles devraient être.

SVG has grown a lot over the past decade. It is now available in the vast majority of phones, and in all browsers save Internet Explorer. Even there, the SVG Web project has made it possible to use it universally, and as Microsoft has recently joined the SVG Working Group, hope is blooming that the next version of their browser will support it natively. As with any technology that has grown over time, hindsight allows one to evaluate past decisions more clearly. As SVG becomes as ubiquitous a part of the Web stack as HTML or CSS, I believe that it is time to revisit these decisions in order to make it easier to use and evolve going forward. My wishlist for the next version is therefore far more concerned with changing or removing existing parts than with adding new features. This is just an early shopping list, more thinking and discussion is required before actually jumping in with most of these items.

Microparsing has been the topic of much debate, often framed in Yes or No positions. I don't believe it possible to have such a clear-cut position on it, though there is little doubt that it can be used excessively. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

This problem is simple and requires very little explanation. Yet it occurs altogether too often. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

Schemata (also known as schemas for the less pedantic) seem for some people to belong to an almost mythical dimension. Not only do many appear to believe that you need a schema to "define a namespace" (whatever that means), but even those bereft of that error altogether too often expect a schema to be step in — cape and superpowers flapping in the wind — to fix parts of language design that they wish not to think about. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

At times it feels like the XML family of technologies is just that: one big family. Likewise web technologies. And you wouldn't want to forget anyone when your baby language is born. Or would you? This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

Excessive complexity is a scourge that hurts universally, from the paperwork involved in running the simplest of businesses in France to XML Schema's terminology but it is specifically dangerous in XML language design because it is too easily hidden. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

The penultimate chapter in this series works through a motley list of what I had originally dubbed "Wishful Thinking and Doe-Eyed Beliefs". The idea is that while the heart of a language designer is often in the right place; the problem has more to do with what their hands are doing. One of the most common such wishful contraption is to use a naïve versioning strategy. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

In my experience, language design is nothing if not an enthusiastic moment. The sky is full of pie, and no problem seems nigh — in 1.0 that is. Given a choice between the mother of all hangovers and having to work on version 1.1 of a (naïve) language, I'll take that hangover thank-you-very-much and not just because of all the drinking. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

More complex and harder to specify (or for that matter, decide) properly than lacunae values and syntax-level error handling is the processing of errors at the language level, in the context of a well-formed parse tree that has semantic discrepancies. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

Contrary to common belief, apart from a set of specific cases, XML does not save you from having to pay attention to error processing at the syntax level. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

A marked design problem, that leads to violations of the DRY (Don't Repeat Yourself) principle as well as to error handling issues, is the lack of lacunae (or default) values. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

We continue our exploration of XML Bad Practices with issues pertaining to language design in general. Language design sits above the previous considerations yet is hard to set entirely apart from them. Some of the examples here mesh into other previous ones, and some apply outside of XML. This first article looks at inconsistency. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

They are amongst us. I've seen them. Or rather their traces. Some XML languages have very obviously been designed for use by cyborgs. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

Attributes feel "cheaper" than elements, and it is therefore tempting to use an attribute for quick labelling of content, even if that label is intended for human consumption. That's what HTML's img does, after all. Well just because it was done many years ago doesn't mean it's really right. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

One of the advantages that XML brings is that elements appear in the context of (at the very least) their parents. When one ignores this aspect, the result is useless extraneous information. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

Even when people don't author by hand, they still often have to debug by hand. If a name is hard to memorise, not only will it be hard to write, but it will be hard to spot it misspelt. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

After a number of articles on namespaces bad practices, follow a few that talk of the human in the loop. XML was intended to be human-readable. While that idea may make some people chortle, it is still a worthy goal to design with human readability — and writability — in mind. After all, if all one needs is a way to dump data that is only to be readable by machines in a format available anywhere other options will be faster and simpler, e.g. JSON or YAML. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference. Many of the mistakes in this section are by no means limited to XML, and tend to apply to other contexts — notably programming — as well, but they are nevertheless worth recalling.

The "X" in XML stands for "eXtensible". Yet it is altogether too common to see vocabulary authors try to prevent this extensibility, sometimes on purpose, sometimes unknowingly through XML Schema. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

After looking at various ways in which namespaces can be misused at the vocabulary level, here we have a case of redefining how they work, and how it goes wrong. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

Namespaces are defined to be URIs (IRI references for the pedants out there), and while many use HTTP URIs, some use anything else ranging from URNs to URIs with made-up schemes. In this article we look at why the latter's a bad idea. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.

After having looked at the issues involved in not using a namespace, we look at those that stem from overdoing them. This article is part of a series based the paper on "Designing XML/Web Languages: A Review of Common Mistakes" which I presented at the XML Prague 2009 conference.