Markdown a un principe fort.
C'est un document, ou plutôt une manière d'écrire du contenu enrichi (comme des documents Word, webs, PDF, epub). Mais lui contrairement aux précités, ne contient que son contenu. Comparable a un HTML qui ne contiendrais que l'information humaine : textes, images, formules mathématiques, selon l'utilisation. Pas de données parasites si bien que son fonctionnement est compréhensible par tous. Il y a bien sûr des indications, des signes pour permettre à "l'interpréteur" de savoir quoi faire avec quoi, où mettre les titres, les listes, etc... Mais ces symboles sont choisis pour correspondre à ce qu'on aurait pu choisir pour symboliser ces éléments graphiquement, avec un stylo.
Par exemple :
># Ceci est un titre
>`## Ceci est un sous-titre
>[ceci est un lien](quimeneversça)
>Et tout ceci est inséré dans un blocquote grace aux ">"
##L'intérêt
Il y a des languages de programmation qui s'éloignent des concepts humains à mesure qu'ils sont éfficaces et qu'ils gagnent en possibilités, plus proches du language machine. Markdown est le plus humain, écrire un titre se fait comme sur une feuille de classeur et un lien hypertexte comme une référence bibliographique. Markdown utilise de très petits indices, des caractères spéciaux généralement, pour permettre à un interpréteurs de différencier les éléments, lui permettre de choisir quelle action appliquer à quelle parcelle de texte.
Son principe de fonctionnement permet de faire des choses compliquées de façon très simple. Potentiellement on pourrait inclure le code civil dans la page juste en inscrivant les lettres "#[lecodecivil]" du moment que les interpréteurs de Markdown possèderaient la même fonction rechercherait cette expression précise pour la remplacer par le code civil. Mais biensur cela n'aurait pas beaucoup d'intérêt car peu de personne auront l'occasion d'utiliser cette fonction et on ne peut pas créer cette fonction très lourde pour chaque livre qui existe. Mais le potentiel est là : Interpreter des instructions humaines intélligibles par des fonctions potentiellement très compliquées.
En s'améliorant il pourrait gagner la bataille culturelle des ebooks, du HTML, du pdf du .rtf et du .doc tout en cohabitant avec eux. Car il pourrait être interprété par tous, et convertible dans tous ces formats, éditable en WYSIWYG ou simplement avec un blocnote.
Car pour l'instant le Markdown est pauvre, il ne surpasse en rien un document texte enrichi classique si ce n'est qu'on a pas nécessairement besoin d'un logiciel spécifique pour créer ce fichier, et qu'il est très facilement convertible en plusieurs formats puisque simple à interpréter. Mais de toute façon avec des solutions comme google document, les logiciels de traitement de texte lourds finirons par être spécifiques à certaines applications professionnelles. Il ne surpasse par non plus un document web basique (HTML), puisqu'il se limite à créer des titres, sous-titres, images et liens, sont avantage est de rendre son écriture plus efficace.
On se frotte alors à une problématique : ajouter des fonctions sans rendre le language plus compliqué. Car si il y a trop de fonctions, on ne pourra plus se contenter d'indices simples comme des _backspace_ ou des *étoiles*. Et il ne doit pas non-plus être en constante évolution car alors en changeant il y aurait des "interpréteurs" de markdown qui ne serait pas "à jour" et n'interprêteraient plus les fonctions de nouveaux documents.
Pour ainsi dire, il faudrait qu'il soit différent, mais surtout ne pas le changer, pour qu'il reste un fichier d'information "pure" qui ne devrait se soucier ni de versions, ni du media.
Il faut donc un changement, majeur et unique, qui lui donnerait un potentiel complet.
Puisque Markdown doit être capable de faire autant que n'importe quel type de fichier (tout) sans pour autant se compliquer il y a une solution très simple. Lui ajouter la capacité de lire n'importe quel type de fichier en les incluant dans le document. Lui ajouter la capacité de "déléguer" des taches.
>[fonction](ficher.extention "commentaire")
Disons alors que j'ai un dossier avec mon fichier markdown (.md) dans ce dossier, ou un dossier proche. Dans ce dossier : image.jpg, video.avi, youtubevideo.url (fichier raccourci), application.exe, fichier.inconnu.
La fonction >[action](fichier.extension) " Indique à l'interpreteur qu'il doit inclure avec telle "action" un certain "fichier". Ces fonctions peuvent être personnalisable suivant l'interpréteur. Ainsi chez un blogueur un fichier vidéo pourrait être visible directement alors que chez un producteur il ferait d'abord appel à un système de micro-paiement pour donner l'accès à la vidéo, sur un eReader il génèrerait un flashcode menant vers la vidéo (ne sachant pas lire les vidéos lui même).
J'utilise donc
>[image](image.jpg "titre")
>[youtube](youtubevideo.url)
>[vimeo](youtubevideo.url)
La fonction "youtube" lirait le fichier .url, récupèrerait l'adresse et intègrerait le lecteur youtube pointant vers la vidéo dans la page interprétée. Si j'utilise la mauvaise fonction sur le mauvais fichier (La fonction viméo sur raccourci vers youtube) ça ne marchera pas, bien sûr. C'est pourquoi il devrait y avoir une fonction "automatique".
>[auto](file.extention)
La fonction \>[auto] informera l'interpréteur qu'il doit déterminer lui même quelle fonction appliquer à quel fichier. Pour les interpréteurs les plus simple qui ne chercherons pas à rentrer dans la complexité, il suffirait d'attribuer l'équivalent HTML <a href="adresse du fichier">Nom du fichier</a> à "auto" ainsi peut importe le fichier inclu, il serait "compris" par l'interpréteur.
Pour les interpréteurs plus complets, on chercherait selon l'extension du fichier à attribuer automatiquement la fonction correspondante. Il serait alors ainsi intéressant que chaque lecteur de markdown ai son répertoire de fonctions spécifiques à certains fichier.
Grâce à cette amélioration on possède un fichier markdown(.md) qui peut faire appel à des fonctions spécifiques, des lecteurs externes et n'importe quel fichier avec une simple fonction. Le rôle de l'interpréteur change, même si il peut rester un simple "traducteur" et se contenter de fonctions simples, il doit faire appel à des algorithmes un peu plus complexes pour obtenir plus de compétences. Si l'on respecte ces règles, le fichier markdown pourra connaître une capacité potentiellement infinie tout en attribuant aux fichier markdown ainsi qu'aux interpréteurs une péreinité. Aucun problème d'incompatibilités.
Règles incontournables:
- Il doit au moins comprendre la fonction
>[auto]()même si c'est pour lui attribuer un équivalent HTML simple comme un lien hypertexte pointant vers le fichier spécifié entre les parenthèses. - Il doit également attribuer aux fonctions qu'il ne connait pas, la fonction
>[auto](). Par exemple si j'écris un fichier markdown pour un site qui sais lire les modèles 3D :>[3DSmax](nameoffile.3ds)alors si je le met sur un autre interpréteur qui ne connaît pas la fonction>3DSmax()-ou qui en utilise une autre pour cette extension- alors il rebasculera vers la fonction[auto]()qui à défault de trouver quoi faire avec le fichier, executera la fonction basique destinée aux fichiers non pris en charge -disont un lien hypertexte.
Conseillées:
- Prendre en charges dès le départ quelques format basiques (Txt, url, videos, images)
- Ne pas hésiter à faire appel à des lecteurs externes exemple pour une tentraine de fichiers différents on peut faire appel à google document "http://docs.google.com/viewer?url=**adressedufichier.extension**" en tant que lien ou directement dans une iframe.
- Pour les interpréteurs qui cherchent à inclure la fonction auto complète penser à créer un fichier qui repertorie les fonctions et les attributions de ces fonctions en selon l'extension. (Personnalisable par l'utilisateur, éventuellement)
###Les conflits :
Par exemple le cas des fichier "raccourcis" .url et des adresses externes.
Un peu de recherche est encore nécessaire de ce côté là sur comment doit réfléchir l'interpréteur (et donc comment doit s'écrire la fonction) pour inclure et ou différencier des contenus externes. L'idée étant qu'en lisant un fichier .url menant vers une vidéo youtube par exemple, l'interpréteur puisse reconnaître celle-ci et appliquer une fonction spécifique aux vidéos youtubes. Mais puisque les fichier .url ne contiennent quasiment que l'adresse, il serait légitime qu'on puisse simplement utiliser >[auto](http://youtube.com/watch?v=xxxxxx) mais si la fonction qui cherche à reconnaitre les url pour appliquer certaines actions est spécifique aux fichiers .url alors la fonction auto ne pourrat pas reconnaitre l'adresse youtube comme une adresse youtube. La solution à laquelle je pense pour l'instant serait simplement de forcer l'utilisation d'une fonction lorsqu'on inclut l'url en toute lettre plutôt que part un fichier .url :
>[url](http://youtube.com/watch?v=xxxxxx)
ou même la fonction spécifique à youtube :
>[youtube](http://youtube.com/watch?v=xxxxxx)
###La syntaxe
La syntaxe de cette commande provisoire et doit être clairement défini avant que cette fonction ne soit développée pour éviter des conflits avec d'autres commandes qui utilisent le signe ">", mais également pour permettre de fournir suffisement d'information à l'interpréteur sur certains fichier. Par exemple pour une intégrer une image pour l'instant on utilise la fonction
Or si on intègre une image avec la fonction >[auto](url/images.jpg "metadonnée") on perd directement un champ de métadonnée qui était entre crochets. Alors on pourrait imaginer une suite de métadonnée entre guillemets définies par un ordre précis : le titre en premier, puis le texte alternatif, ou l'inverse.
>[auto](url/image.jpg "metadonnée1" "metadonnée2")
Mais alors il y aurait un conflit illogique entre la fonction basique pour inclure les images  et inclure une image avec la fonction pour créée ici >[x](b "a" "c" "d" "...") et on ne peut pas vraiment envisager une fusion des deux fonction maintenant car il faudrait réécrire tout les interpréteurs markdown actuels sous peine d'avoir des images avec comme texte alternatif "auto". A l'inverse, si les nouveaux interpréteurs respectent la règle qui consiste à ignorer une fonction qu'il ne connait pas, les images créées dans les anciens fichiers markdown pourrons se voir attribuer la bonne fonction, mais se véront certainement privées de texte alternatif et/ou de titre.
###Les pièces jointes
Le language markdown gère actuellement des fichiers externes et pointe vers eux grace à une url. Idéalement, il serait pratique qu'a ce fichier on puisse joindre une "bibliothèque" locale. Si l'on a une image qui est lié à une page écrite en markdown, qui ne sers que cette page. Pour la syntaxe il serait plus facile d'écire "le nom du fichier" plutôt que sont adresse complète. De plus si on déplace ces fichiers alors l'adresse de référence n'est plus la bonne et il est nécessaire de réecrire le fichier. Pour éviter ce soucis je pense à un dossier qui accompagnerait si il y a lieu, le fichier markdown. Pour un fichier titre.md un dossier .titre.md serait créé contenant les pièces jointes. Et la référence aux fichiers contenus dans ce dossier serait facilitée dans la syntaxe d'une manière qui doit être définie.
>[](.fichier.extension)
>[]($attached/fichier.extension
pourrait être des idées, bien qu'on pourrait simplement écrire le nom du dossier en toute lettre :
>[](.nomdudossier/fichier.extension)
Les éditeurs markdown pourrait se doter d'un gestionnaire de fichier et intégrer, déplacer automatiquement des fichier dans et hors de la bibliothèque aussi simplement qu'on attache ou supprime des pièces jointes à un email.
Une idée pourrait être également qu'a l'image des .epub .pages .cbz .cbr (fichiers pour les livres ou les bandes déssinées) le tout pourrait être encapsulé dans une archive et créer ainsi un fichier "portable" qui se tient tout seul. Mais il me semble que cela offrirait plus de contraintes que d'avantages. On pourrait très bien imaginer aussi cette alternative : des fichiers "markdownarchive(.mda)" que l'ont pourrait stoquer, déplacer sans craindre de compromettre leur fonctionnement.