Développement et Technologies
WTML : vous reprendrez bien un peu de pastèque ?
8 mars 2008
Le concept de WTML
L'accessibilité ou l'interopérabilité d'un contenu web, c'est un peu comme la photographie autrefois : ce n'est pas au moment où elle "apparaît" dans le bain révélateur qu'une image est bonne ou pas, c'est au moment de sa prise de vue... Cadrage, composition, exposition, piqué, richesse de ses hautes et basses lumières, tout ceci le laboratoire ne fait que le révéler : il y a à un moment mise en forme de quelque chose qui était virtuellement présent dans l'intégralité de ses qualités depuis l'acte de déclencher. De même, quoique ce ne soit qu'à l'affichage d'un document web qu'on peut dire s'il est in fine accessible ou pas (ou à quel degré il l'est ou ne l'est pas), ce qui se joue au moment de la restitution est largement tributaire du contenu tel qu'il a été produit dès sa conception. C'est là que se met en place tout ce qui fera ultérieurement un contenu conforme. C'est la raison pour laquelle un site ne pourra jamais être rendu accessible et que l'accessibilité ne sera jamais un patch à rajouter après.
Concernant donc la façon dont un contenu est produit, la quasi-totalité des outils CMS (systèmes de gestion de contenu) disponibles - on peut faire aujourd'hui l'impasse sur les sites codés "en dur" - opèrent de la même manière : l'utilisateur injecte du contenu (disons du texte copié-collé) que de nombreux fonctionnalités permettront ensuite de mettre en forme : titrage, séquençage, enrichissement, etc. On appelle ça un(e) rich text interface .
En fait, c'est un peu plus compliqué. Il y a simultanément écriture d'un contenu avec son balisage et écriture du modèle de page qui va le recevoir pour restitution. Il y a donc une imbrication étroite entre le contenu proprement dit (le texte et ce qui l'accompagne, photos, sons, etc) et le cadre dans lequel il apparaîtra. Le balisage entourant les objets, même si et quoiqu'il puisse être "sémantiquement cohérent", est toujours produit en rapport avec sa structuration finale une fois mis en page. Le CMS produira des titres en h1 et des sous-titres en h2 (je fais ici l'impasse sur les solutions CMS produisant des titres en font-size) parfaitement normalisés tant que ce contenu restera dans le cadre prévu : la mise en page associée au système.
Alors quid des contenus migrants ? Quid des objets importés online ? En gros la situation qui prévaut aujourd'hui est simple à décrire : je garantis des contenus accessibles tant qu'ils relèvent d'une production sous mon contrôle (solution CMS) et pour le reste (liens copiés-collés d'appel à contenu externe) je déplore qu'il(s) invalide(nt) mon document.
Dans l'optique où les contenus vont être amenés à migrer (passer d'un site à l'autre...), à muter (passer d'un UA à un autre...), à converger (se mixer les uns avec les autres...), comment les produire indépendamment de leur usage immédiat ? Un simple exemple : mon outil CMS me produit des textes séquencés en h1 > h4, soit 4 niveaux hiérarchiques de titres/soustitres ; je souhaite partager ces ressources avec un site partenaire qui lui utilise déjà h1 et h2 pour structurer ses propres pages ; ce qui va se passer, c'est que mes structurations vont entrer en conflit avec les siennes. On va avoir au final un double jeu de titres h1 ne décrivant pas du tout le même type d'objets, sans parler des attributs de class ou d'id ! ... Du coup l'utilisateur équipé d'une synthèse vocale naviguant de titres en titres ne comprendra pas la logique de structure (normal, y'en a plus...) et l'affichage sur écran d'ordi présentera deux titres hiérarchiquement et aspectuellement identiques pour deux types d'informations distinctes : question accessibilité on peut mieux faire...
Reste la solution - lourde parce que manuelle - de réinterpréter (via PHP par exemple) les contenus importés pour les rendre compatibles avec la structure-hôte et ainsi maintenir l'accessibilité générale du document.
Les rôles de WTML
L'autre possibilité est de considérer tout contenu comme une "marque blanche", un contenu "neutre" capable d'être absorbé par une structure de document en cohérence avec ses règles propres. Et puisqu'il s'agit de balises, la "marque blanche" devient un "balisage blanc" : un white tag. Et puisqu'il s'agit d'un langage, un white tag markup langage : WTML. Et puisque "weu-teu-meu-leu" veut à peu près dire "watermelon" , il s'agit donc bien pour finir d'une histoire de pastèque ;-)
WTML n'a pas pour objectif de se substituer aux langages du web actuels (HTML, XHTML,...) mais de structurer les contenus en amont de leur traitement par ces langages. A la manière d'XML il se compose de balises faisant sens ; là où il se distingue d'XML c'est que son balisage n'est pas porteur d'une sémantique liée au contenu lui-même (genre <auteur></auteur>) mais à la structuration même du contenu : <article>, <titre>, <soustitre>, <texte>, <citation>, etc. Mais si XML est un langage orienté données, WTML un langage orienté documents.
Si XML est parsé par XSL (pour tous ces termes techniques, voir wikipedia ou les documentations W3C), WTML est incorporé tel quel comme contenu dans les documents web. Mais... mais incorporé comme tel il sera aussi restitué comme tel... il est donc nécessaire de passer WTML par un jeu de filtres pour le parser. Ces filtres peuvent être de plusieurs types, je n'exposerai ici que leur version PHP.
PHP est capable d'inclure (fonction include) du contenu dans le document au moment de la requête sur le serveur et de lui appliquer des traitements particuliers avant distribution aux UA clients. Un de ces traitements possibles est un filtrage WTML : par regex ou str_replace, PHP est capable de transformer une balise <titre> en n'importe quelle balise <h[n]>, ou encore n'importe quelle balise <commentaire> en une balise <blockquote>... C'est là que tout l'intérêt de WTML apparaît : le contenu étant structuré selon un jeu de balises normées (voir plus loin : "internationalisation"), sa restitution, via tout un jeu de filtres, est optimisable pour s'adapter aux contraintes du document-hôte, un peu à la manière d'une syndication RSS par exemple.
Les usages de WTML
1. Soit deux documents appartenant à deux sites distincts. Disons que le premier structure chacune de ses pages par une entête en h1... dans ce cas le filtre (f-WTML) mutera <titre> en <h2>, <soustitre> en <h3>, etc. Le second document en revanche incorporera le contenu WTML dans un groupe de contenus déjà encadré par un jeu de <h[n]>... dans ce cas f-WTML remplacera les balises par des jeux d'équivalences de type <p class="nom-de-classe">.
2. Soit un document unique inclus dans un site mais dont la structure de contenu mutera en fonction de l'UA (voir l'article "Mutabilité des contenus mobiles"). Dans ce cas le filtre f-WTML mutera les <h3> en <ul><li>.
3. Soit un site donné qui change de charte graphique au cours d'une refonte d'identité et/ou de communication globale. Un filtre f-WTML adaptera instantanément l'ensemble des contenus...
Ces trois exemples - on pourrait en inventer des dizaines d'autres - montrent la souplesse et la robustesse de WTML : non seulement les contenus sont indépendants de leurs couches graphiques, événementielles, etc (couplage HTML/XHTML à CSS et JS) mais en plus ils sont indépendants du langage qui les restituera. L'arrivée prochaine d'HTML5, une éventuelle version d'XHTML2 ou l'usage de tout autre langage pour tout autre usage à venir (web 3D ?) ne sont plus synonymes de reprise en main de l'ensemble des documents dont l'auteur de contenus est responsable. De nouvelles balises de type <section> ou <datalist>, annoncée pour HTML5, ne nécessiteront pas la refonte complète des sites existants mais la simple écriture d'une ligne de code dans le filtre f-WTML concerné.
Les structures de WTML
Comme XML dont il s'inspire, WTML est constitué de balises fermantes ou auto-fermantes
; il est d'autre part inclus dans une balise globale <article> :
<article>
<titre>Mon titre d'article</titre>
<intro>Mon texte d'intro</intro>
<soustitre>Sous-titre 1</soustitre>
<texte>Mon texte 1</texte>
<soustitre>Sous-titre 2</soustitre>
<texte>Mon texte 2</texte>
</article>
Selon les besoins, cette balise globale <article> sera ignorée ou filtrée en <div> par exemple et destinée à subir un traitement graphique CSS...
Nommage et internationalisation
WTML étant d'une part conçu comme un outil de sémantisation structurelle et de l'autre devant être de toute façon parsé par un filtre, rien n'interdit son internationalisation : un simple filtre f-WTML complémentaire assurera la traduction <content> | <contenu> | <inhalt>... De la sorte, toute communauté de développeurs de filtres peut oeuvrer conjointement chacun dans sa langue puisqu'au final <contenu> deviendra <div lang="fr"> et <content> <div lang="en"> si l'on veut... WTML deviendra ce que ses utilisateurs en feront. Il conviendra de s'entendre sur un ensemble de balises basiques (à équivalence HTML "naturelle") et sur des conventions de nommage pour que WTML devienne immédiatement opérationnel.
Produire du WTML
WTML est constitué de 3 ensembles imbriqués :
1. le balisage,
2. un jeu de filtres,
3. les outils de production.
Un outil de production de contenus WTML de type CMS - produire du code en dehors d'un outil de gestion de contenu n'a pas de sens puisque pour être partageable ce dernier doit être autonome - doit être capable d'écrire la sémantique structurelle (le balisage normé) en même temps que le contenu lui-même.
Un fichier WTML est donc constitué en bloc cohérent individualisé, et devient utilisable en tant que tel. Tout l'intérêt de la fonction "white tags/pastèque" réside dans cette indépendance structurelle ; ne pas la respecter, c'est développer du contenu pour rien ; autant alors s'en tenir aux langages courants.
Toute solution de production de contenus peut à moindre coût se transformer en outil de production WTML : il suffit d'affecter dans la rich text interface des contenus de balises WTML aux tags HTML standards.
Stratégie(s) de développement
100% open source (et pour cause...) WTML permettrait à toute communauté de se constituer en productrice de filtres f-WTML ; pour ce faire, si le projet rencontre son public, il conviendra de développer des interfaces d'échanges, et des supports de normes techniques devront être tenus à jour par la communauté ainsi qu'un centre de ressources à télécharger.
Les pistes à explorer sont nombreuses :
- relations entre WTML et XML,
- nommage HTML (correspondances exactes) et non-HTML (contenus sans balisage HTML
à "displayer" d'une façon ou d'une autre...),
- versions internationales cohérentes pour filtrage cohérent (l'idée du système
de filtrage est de constituer des briques f-WTML opérant les unes à la suite
des autres... comment optimiser tout cela en temps-serveur, en gestion de risque
de conflits d'instructions, en utilisabilité pratique sans les "usine à gazer",
en mises à jour et adaptabilité aux besoins présents et à venir ?),
- interaction avec des solutions "markdown",
- etc.
Quoique tout développeur puisse créer une version de WTML qui lui convienne, le sens de ce projet "innovation" est de constituer un outil commun utile à tous. On peut rêver que demain blogs et sites relaieront des contenus mutualisés construits sur un langage indépendant des langages de restitutions et développé spécifiquement pour cet usage, et qu'après-demain ce langage pourrait, de par sa souplesse et sa robustesse, s'imposer comme norme pour assurer toutes sortes d'interopérabilités.
