Liens

Le fait que l'URL vient en premier et que le séparateur soit l'espace rends cette forme plus intuitive amha -- François Granger
Cette solution est adoptée par Moin Moin et Wiki Ni (même s'ils ne partagent pas les mêmes marqueurs). Je trouve également cette notation plus intuitive que celle qui consiste à mettre d'abord le titre, puis le lien... (PhPWiki). Mais je ne saurais pas expliquer concrètement pourquoi elle est plus intuitive -- Charles Nepote
J'ai un début d'explication en généralisant mon usage : une fois que l'url est écrite on peut se concentrer sur la formulation du titre. --Eve La Fee
Sur la lisiblité du texte, je pense qu'un exemple vaut un grand discours :

* Syntaxe Moin Moin :
== Planification ==
 * [http://xhl/cvs/projets/planification/MgPlanete/ MoeteurGraphique]
  * Documentations technique [[!http://localhost/docs/MgPlanete/html/ en HTML]
  Voir également [wiki:SamErreur liste de codes d'erreur]
* Ma version à moi :
== Planification ==
 * MoeteurGraphique[http://xhl/cvs/projets/planification/MgPlanete/]
  * Documentations technique "en HTML"[http://localhost/docs/MgPlanete/html/]
  Voir également "liste de codes d'erreur"[wiki:SamErreur]
Je propose également, pour les images non évidentes :
[image:http://url/]
-- Un Becile?

Une autre solution est un système par référence. Par exemple, Le W3C[1] est un consortium et ailleurs dans le texte, surement à la fin.

[1] http://www.w3.org/

--Karl Dubost

Pour ma part je trouve les deux solutions élégantes. La solution de Karl Dubost, que je trouve la plus élégante, est peut-être la moins facile à mettre en oeuvre pour l'utilisateur : nécessité d'aller en fin de document pour les liens. Elle convient très bien pour des chercheurs, étudiants littéraires ou scientifiques, rompus aux techniques d'écriture ; elle dénote plus l'appareil critique que l'hyperlien. -- Charles Nepote

Est-ce qu'une solution gérant les deux systèmes serait envisageable ? C'est quand même moins pénible de ne pas avoir à se poser de questions. -- Un Lunar

Un système à deux zone de texte est envisageable peut-être. Une pour le texte, une pour les liens, le défaut, c'est que cela sépare les deux contenus. A moins de les reconstruire à chaque fois. -- Karl Dubost

Ben moi j'aime beaucoup la syntaxe Wiki Ni ici. La seconde solution est jolie aussi, mais c'est un système de gestion de note de bas de page. Ca existe sous SPIP et c'est assez sympathique. Je ne crois pas qu'on puisse envisage de créer des notes de bas de page "lien" sans créer des notes de bas de page texte. --Eve La Fee

Faut-il parler des

classiques Mot Wiki (?)
des liens forcés ?

OUI ! -- François Hodierne

Caractère séparateur

Un petit problème également avec les espaces. Il arrive d'avoir des URLs avec des espaces, c'est pourquoi certains systèmes utilisent un "|" (pipe) comme séparateur, car peu de gens savent traiter ou écrire un %20 pour écrire un espace. --Karl Dubost

Merci Karl pour cette judicieuse remarque. Je pense qu'on a pas a discuter sur le bien-fondé ou non des URL avec des espaces mais qu'on a en effet intérêt à choisir un séparateur le plus judicieux possible. Il se trouve que le chapitre "2.2. URL Character Encoding Issues" de la RFC:1738 liste les caractères possibles et "impossibles" ("unsafe") dans une URL. Je suggère donc qu'on choisisse un des caractères "impossibles" de manière à laisser tous les caractères possibles disponibles. -- Charles Nepote

L'espace ne peut exister dans une URL que sous la forme réencodé. Quelqu'un qui fait un copier/coller d'une telle URL aura donc l'espace réencodé. Essayez de taper un espace dans une URL dans votre navigateur. Il sera réencodé avant d'être envoyé au serveur. Il peut donc être utilisé comme séparateur sans risque. -- François Granger

Unsafe:

   Characters can be unsafe for a number of reasons.  The space
   character is unsafe because significant spaces may disappear and
   insignificant spaces may be introduced when URLs are transcribed or
   typeset or subjected to the treatment of word-processing programs.
   The characters "<" and ">" are unsafe because they are used as the
   delimiters around URLs in free text; the quote mark (""") is used to
   delimit URLs in some systems.  The character "#" is unsafe and should
   always be encoded because it is used in World Wide Web and in other
   systems to delimit a URL from a fragment/anchor identifier that might
   follow it.  The character "%" is unsafe because it is used for
   encodings of other characters.  Other characters are unsafe because
   gateways and other transport agents are known to sometimes modify
   such characters. These characters are "{", "}", "|", "\", "^", "",
   "", "?", and "`".

   All unsafe characters must always be encoded within a URL. For
   example, the character "#" must be encoded within URLs even in
   systems that do not normally deal with fragment or anchor
   identifiers, so that if the URL is copied into another system that
   does use them, it will not be necessary to change the URL encoding.

Le caractère "|" en fait partie aussi je pense qu'on peut le considérer comme un bon candidat.

Limite consensus même ! --François Hodierne

Avantages :

déjà employé par certains moteurs de wiki
séparateur employé dans les commandes Unix et DOS
représente graphiquement une séparation

Inconvénients :

Est-il facilement accessible sur tous les claviers ? <troll>Et l'arobase, elle est accessible ?</troll> To Delete?

À titre indicatif: plusieurs applications autorisent déjà la citation d'URL espacés selon la forme <http://example.org/copy of example.html>. En suivant cette logique, le caractère d'espacement pourrait demeurer blanc et les becs seraient requis pour éliminer la confusion lorsqu'elle se présente.

Quelques remarques:

L'autodétection est pour moi indispensable: on copie/colle un URL et hop, on a un lien. Très pratique et intuitif.
Si on veut faire un texte un peu plus travaillé, on peut donner un titre au lien. Je trouve la forme [url titre] très pratique.
L'espace est tout autant interdit dans un URL que le tube ("|"). Les URLs contenant un espace sont invalides et ne devraient pas être acceptés, à mon avis.
Je trouve la forme séparée par un tube moins lisible car le titre est moins isolé de l'URL. En regardant vite, on peut croire que le titre fait partie de l'URL. C'est moins lisible et pas très intuitif.
La forme "note en bas de page" est intéressante mais si elle est acceptée, elle ne devrait pas être imposée. Je crois que cette forme est surtout utilisé quand, justement, on ne peut pas faire de vrai lien, pour eviter de surcharger le texte brut. On est en HTML, autant en profiter et faire un lien sur le mot.
Pour les images, il faudrait une liste d'extensions considérées comme des images. Le W3C a-t-il emis une recommendation sur les formats d'image à utiliser sur le web? Si oui, ca serait bien de l'utiliser.

Attention. L'inconvénient de cette méthode c'est qu'une image sans extention (par exemple les icônes RDF proposées par le W3C) n'est pas affichée. -- Charles Nepote

La forme [image_url texte] pourrait servir pour mettre un texte alternatif (paramètre "alt").
On pourrait aussi afficher les animations Flash directement, comme pour les images. Idem pour le SVG.
La forme [Mot Wiki texte] pourrait servir, comme pour les liens, à pointer sur un Mot Wiki avec un autre mot (ou plusieurs mots).

-- Michael Witrant

Comment fait-on un lien vers une image sans l'afficher ? -- Charles Nepote

Effectivement le problème des images sans extension et des liens vers des images incitent à utiliser une syntaxe différente. Existe-t-il des wiki qui ont une solution à ces problèmes? Il serait aussi utile de pouvoir mettre un lien sur une image, mais ca devient peut être un peu trop complexe pour un wiki. Sauf bien sur si on trouve une bonne syntaxe.

Pour le mail, Use Mod utilise la syntaxe mailto:adresse_email. On peut imaginer une forme similaire: image:url ou image:[url alt]. Pour faire un lien dessus, on pourrait faire: [link_url image:image_url] voir même [link_url image:[image_url alt]].

-- Michael Witrant

Pensez-vous incorporer une syntaxe Inter Wiki à votre syntaxe universelle?

Depuis peu, j'ai découvert un autre système par référence. Il s'agit du lecteur syntaxique Markdown. Il est assez complexe, n'est pas à proprement parler un moteur de wiki, mais je pense que en ce qui concerne les liens, ça pourrait devenir une référence (désolé du jeu de mots pourri ^__^ ). Ca fonctionne comme ceci : j'insère [un lien][lien]. Et on crée un nouveau paragraphe juste en dessous, ou même tout en bas du document, relatif [aux liens][liens]. Il y a même moyen de ne pas avoir à utiliser d'[identifiant][], le texte du lien devient alors identifiant.

[lien]: http://www.lien.com/ "lien.com" "fr"
[liens]: http://www.links.com/ "links.com" "en"
[identifiant]: http://www.id.com/ "id.com" "en"

Le texte reste présent, mais est mis sous forme de lien, avec comme URL celle donnée dans le paragraphe des URLs et avec les attributs adéquats. Le paragraphe des liens n'est pas affiché lors de la lecture de la page, mise en page.

Cette syntaxe permet de garder une excellente lisibilité, et quand l'oeil voit le paragraphe de liens, il le saute. La gêne reste donc très minime. De plus, elle permet de garder très facilement une sorte de gestionnaire des attributs. Les URL écrites telles quelles dans le texte sont transformées.

-- Olivier Grégoire?

Il est très étrange que personne n'ait songé à employer plusieurs caractères au lieu d'un seul. D'autant qu'on peut facilement créer des agrégats parlants, comme <===> par exemple.
Songez par ailleurs que la plupart du temps ce qui est l'URL et ce qui est le titre sont difficiles à confondre du point de vue d'un humain : il est très rare que quelqu'un s'ingénie à créer un titre commençant par http, tout comme l'URL...
Dans ces conditions, on pourrait très bien écrire http://www.toto.org <===> toto, aussi bien que toto <===> http://www.toto.org... Le parseur y retrouverait ses petits.
J'ajoute que si le titre fait plusieurs mots, hé bien les humains ont déjà un symbole typographique connu de tous pour indiquer qu'on groupe ensemble : les parenthèses !
Donc http://www.toto.org <===> (mon lien vers toto) ou bien Lisez (mon lien vers toto) <===> http://www.toto.org pour en savoir plus.
Enfin, en autorisant un nombre quelconque de = dans la double flèche, on libère l'utilisateur d'une dernière contrainte idiote à retenir.
Mettez-vous à la place du péquin lambda. Et surtout, du péquin qui n'en a rien à battre des syntaxes informaticiennes. -- esc

Ce que tu proposes là est une règle syntaxique assouplie, plus tolérante envers l'erreur humaine, mais ça reste une règle syntaxique, donc également pénible à retenir. Pour ce qui est du péquin qui n'en à rien à battre des syntaxes ... que penses tu par exemple de la différence entre 1+1 et 1-1 ? --ylg

Certes, certes, mon bon. Mais si on va par là, tout est syntaxe, dans l'univers. L'intérêt de poser une dichotomie entre "syntaxe informaticienne" et "syntaxes non-informaticiennes", est précisément d'éviter de différencier dans le vide. J'avoue ne pas voir ce que signifie l'affaire du 1+1 et du 1-1.

sauf erreur de ma part, le + et le - sont des éléments de la syntaxe algébrique ? ce que j'entends par là, c'est que tout élément de syntaxe se doit d'avoir été conçu, appris, compris (associé à autre chose, une opération, un contexte sémantique, informatique ...) et retenu, mémorisé, à un moment ou un autre. Tout cela constitue un ensemble de travaux mentaux extrêmement pénibles, mais qui semblent constitutifs de notre nature humaine.

Ce qui me paraît clair, en revanche, c'est que, d'une part,

les agrégats sont d'autant plus clairs qu'ils sont historiés (c'est-à-dire que X ---> Y parlera mieux que X:Y, si la sémantique sous-jacente est celle d'une relation directionnelle de X vers Y), et que, d'autre part,

voici ce que je comprends à première lecture:
X ---> Y = X implique Y
X:Y = X divisé par Y
sans doute qu'il me manque le contexte de cette syntaxe.

les symboles à rallonge (i.e. mobilisant plusieurs caractères) se désambiguïsent d'eux-mêmes du fait de la rareté des contextes où ils pourraient paraître à contresens.

L'important dans cette histoire, c'est la capacité de désambiguätion collective, qui est le point aveugle de l'informatique moderne.

désambiguätion collective: je crois que tu as soulevé là un concept à développer

Considère le nombre de cas, très réduit, où le <===> voudra vraiment dire <===> et pas "lien http". Sans compter que pour qu'il y ait problème, il faudra de surcroît qu'un http://toto.org qui ne veut pas dire http://toto.org traîne d'un des deux côtés du <===>. Très rare, comme événement. Hé bien, l'événement est si rare qu'on peut pour la peine apprendre à l'utilisateur à le contourner dans ce cas-là, et dans ce cas précis seulement.

On voit par là poindre, non pas non une nouvelle logique programmatoire (car au fond, les parseurs restent des parseurs), mais une nouvelle éthique...ette, puisque ce sont les facilités informatiques qui se mettent au service de l'entendement humain -- et non l'inverse. -- esc

Ce n'est pas à proprement parler une nouvelle éthique, je crois que le développement des langages informatiques va dans le sens de cet entendement humain, depuis le bas niveau jusqu'au haut niveau (le C est déjà fait pour les humains). Je crois que c'est un nouveau et poétique pas dans ce sens. --ylg

Poétique vs. Logique : tu as vu exactement où se situait la nouveauté. Dans la vision des symboles qui est sous-jacente à ton intervention, c'est le paradigme de l'algèbre mathématique qui gouverne ("implication", "division", "plus", "moins", etc.) Chaque symbole est pris pour une entité unique et autonome. Le + est un + et si on écrit a+b, il y a trois entités, dont une infixe et binaire au centre qui gouverne les deux sur les bords. Et si quelqu'un écrit += en C, c'est juste un raccourci pour une incrémentation qu'on pourrait écrire avec un plus et un égal. Le +=, le <<, le != dans cette circonstance se comportent comme s'ils n'étaient qu'un seul caractère unique (ce qu'ils sont, en un sens).
Maintenant, considère une philosophie opposée à celle-ci, ou -plus exactement- non pas opposée, mais englobant celle-ci, dans laquelle ce qui détermine la valeur du signe n'est jamais au grand jamais le signe lui-même. Mais le signe plus son entourage, les deux étant d'ailleurs inséparables, et les termes signe et entourage n'étant, par conséquent, qu'une façon de parler.
Je vais tâcher de donner un exemple. Dans "le chat mange la souris", on peut déterminer la sémantique de la phrase en considérant à part la sémantique de le chat, celle de mange et celle de la souris. En notant C, M et S ces trois sémantiques, la sémantique de la phrase sera donc M(C,S). C'est un cas de sémantique logiciste (= la logique, les mathématiques).
Imaginons à présent le cas opposé où aucune formule de ce type ne pourrait être posée. Par exemple, dans "pomme de terre", la sémantique de l'ensemble ne se déduit pas (pas vraiment) de celle de pomme_ plus celle de de plus celle de terre. Ou alors il faut introduire des éléments de connaissance pragmatique humaine, une véritable encyclopédie de la nature, de la botanique, la raison pour laquelle on a appelé ce légume ainsi, etc.
En fait, ce serait, selon tes termes, un cas de Poésie. Mon affaire de désambiguätion collective, où chaque unité, socialement, reçoit l'aide de toutes les autres pour recevoir sa valeur et même tout simplement exister, est un tel cas. J'ai proposé ici un exemple qui permettrait de passer progressivement, et comme qui dirait en douce, de l'approche logique pure à l'approche poétique.
Mais concevoir des parseurs qui épousent ce nouveau régime, cela exige de nouvelles manières d'envisager la programmation... -- esc

Dernière modification le vendredi 15 juillet 2005 0:16:13