Effectivement, les auteurs de ces langages n'ont en général pas lu la RFC de Berners-Lee et Fielding sur la définition des URI (RFC 3986) qui a explicitement autorisé les espaces comme délimiteur d'URL, ce qui est en général pratique et tout à fait adapté à des langages « humains » sans balisage. L'autre manière standard sont les signes inférieurs/supérieurs (utilisés historiquement dans les textes comme les e-mail depuis le début de son existence), qui ont été ré-inventés avec les crochets et/ou parenthèses et qui foutent le bazar car ce sont normalement des caractères autorisés dans une URL. Bref, de la réinvention de la roue.
Pour moi, le seul qui respecte à peu près bien cet esprit est reStructuredText, dont il n'existe qu'une version car le modèle de gouvernance de Python fait qu'on essaye de faire des trucs cohérents et pas chacun dans son coin.
[^] # Re: Wiki, Markdown
Posté par benoar . En réponse au journal Saletés de codes différents et tutoriel wiki. Évalué à 3.
Effectivement, les auteurs de ces langages n'ont en général pas lu la RFC de Berners-Lee et Fielding sur la définition des URI (RFC 3986) qui a explicitement autorisé les espaces comme délimiteur d'URL, ce qui est en général pratique et tout à fait adapté à des langages « humains » sans balisage. L'autre manière standard sont les signes inférieurs/supérieurs (utilisés historiquement dans les textes comme les e-mail depuis le début de son existence), qui ont été ré-inventés avec les crochets et/ou parenthèses et qui foutent le bazar car ce sont normalement des caractères autorisés dans une URL. Bref, de la réinvention de la roue.
Pour moi, le seul qui respecte à peu près bien cet esprit est reStructuredText, dont il n'existe qu'une version car le modèle de gouvernance de Python fait qu'on essaye de faire des trucs cohérents et pas chacun dans son coin.