hcard-brainstorming-fr - Revision history

AmeerDawood: /* Problèmes clé/points de discussion */

2009-06-24T14:15:17Z

Problèmes clé/points de discussion

← Older revision		Revision as of 14:15, 24 June 2009
Line 599:		Line 599:
	- e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported		- e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported
	* Forms may contain more than one hCard so using <FORM class="vcard"> should not be required		* Forms may contain more than one hCard so using <FORM class="vcard"> should not be required
	- ''Positive'' : this ~~minimises~~ the changes to current parsing rules		- ''Positive'' : this minimizes the changes to current parsing rules
	* Empty values should be ignored when extracting hCards		* Empty values should be ignored when extracting hCards
	* hCards with all empty values should be ignored when listing/extracting hCards		* hCards with all empty values should be ignored when listing/extracting hCards

Brian: reverting spam

2008-12-20T21:02:51Z

reverting spam

Show changes

LicocOracv: lipasbasc

2008-12-20T03:45:58Z

lipasbasc

Show changes

RovidOmchi: tavarzela

2008-12-19T10:16:40Z

tavarzela

Show changes

Tantek: Reverted edits by AmeerDawood (Talk) to last version by ChristopheDucamp

2008-11-18T19:38:16Z

Reverted edits by AmeerDawood (Talk) to last version by ChristopheDucamp

← Older revision		Revision as of 19:38, 18 November 2008
Line 50:		Line 50:
	==== Exemples potentiels dans la jungle ====		==== Exemples potentiels dans la jungle ====

	* Le lieu "Phone Boxes by the Sealife ~~Center~~" [http://upcoming.yahoo.com/venue/5668/ sur Upcoming] est actuellement marqué sous "fn org":		* Le lieu "Phone Boxes by the Sealife Centre" [http://upcoming.yahoo.com/venue/5668/ sur Upcoming] est actuellement marqué sous "fn org":
	<pre><nowiki>		<pre><nowiki>
	<div class="vcard">		<div class="vcard">
	<div class="fn org">Phone Boxes by the Sealife ~~Center~~</div>		<div class="fn org">Phone Boxes by the Sealife Centre</div>
	<div class="adr">		<div class="adr">
	<span class="street-address">Marine Parade</span><br />		<span class="street-address">Marine Parade</span><br />
Line 69:		Line 69:
	<div class="vcard">		<div class="vcard">
	<div class="adr">		<div class="adr">
	<div class="fn extended-address">Phone Boxes by the Sealife ~~Center~~</div>		<div class="fn extended-address">Phone Boxes by the Sealife Centre</div>
	<span class="street-address">Marine Parade</span><br />		<span class="street-address">Marine Parade</span><br />
	<span class="locality">Brighton & Hove</span>,		<span class="locality">Brighton & Hove</span>,

AmeerDawood: /* Exemples potentiels dans la jungle */

2008-11-17T23:58:23Z

Exemples potentiels dans la jungle

← Older revision		Revision as of 23:58, 17 November 2008
Line 50:		Line 50:
	==== Exemples potentiels dans la jungle ====		==== Exemples potentiels dans la jungle ====

	* Le lieu "Phone Boxes by the Sealife ~~Centre~~" [http://upcoming.yahoo.com/venue/5668/ sur Upcoming] est actuellement marqué sous "fn org":		* Le lieu "Phone Boxes by the Sealife Center" [http://upcoming.yahoo.com/venue/5668/ sur Upcoming] est actuellement marqué sous "fn org":
	<pre><nowiki>		<pre><nowiki>
	<div class="vcard">		<div class="vcard">
	<div class="fn org">Phone Boxes by the Sealife ~~Centre~~</div>		<div class="fn org">Phone Boxes by the Sealife Center</div>
	<div class="adr">		<div class="adr">
	<span class="street-address">Marine Parade</span><br />		<span class="street-address">Marine Parade</span><br />
Line 69:		Line 69:
	<div class="vcard">		<div class="vcard">
	<div class="adr">		<div class="adr">
	<div class="fn extended-address">Phone Boxes by the Sealife ~~Centre~~</div>		<div class="fn extended-address">Phone Boxes by the Sealife Center</div>
	<span class="street-address">Marine Parade</span><br />		<span class="street-address">Marine Parade</span><br />
	<span class="locality">Brighton & Hove</span>,		<span class="locality">Brighton & Hove</span>,

ChristopheDucamp: /* home page vers page contact */

2008-01-16T07:48:26Z

home page vers page contact

← Older revision		Revision as of 07:48, 16 January 2008
Line 254:		Line 254:
	* Ryan King, http://theryanking.com/ , http://theryanking.com/contact/		* Ryan King, http://theryanking.com/ , http://theryanking.com/contact/
	* Tantek Çelik, http://tantek.com/ , http://tantek.pbwiki.com/ContactCard/		* Tantek Çelik, http://tantek.com/ , http://tantek.pbwiki.com/ContactCard/
	* Google, http://www.google.com/ , http://www.google.com/intl/en/contact/index.html		* Google, http://www.google.com/ , http://www.google.com/intl/fr/contact/index.html

	Ces exemples pourraient être traités par le brainstorming suivant mini hCard vers hCard étendue.		Ces exemples pourraient être traités par le brainstorming suivant mini hCard vers hCard étendue.

ChristopheDucamp: /* Auto-Découverte */ [fr:sync'd with english version]

2008-01-16T07:47:32Z

Auto-Découverte: [fr:sync'd with english version]

← Older revision		Revision as of 07:47, 16 January 2008
Line 240:		Line 240:

	== Auto-Découverte ==		== Auto-Découverte ==
			=== découverte hCard représentative ===
			Compte tenu d'une page comportant une ou plusieurs hCards, quelle hCard est la hCard représentative pour la page ?

	Voir [[representative-hcard-fr\|hCard-représentative]]		Voir [[representative-hcard-fr\|hCard-représentative]]

	=== ~~lien rel vCard d'auto-découverte~~ ===		=== relations hCard vers hCard ===
	~~Une possibilité similaire est un lien d'auto-découverte dans l'en-tête du document~~ qui ~~pourrait pointer vers~~ une ~~URL (peut-être avac transformation)~~ vers une ~~version vCard de la~~ hCard ~~représentative.~~		Il existe plusieurs types de relations hCard vers hCard, ce qui veut dire, une hCard faisant un hyperlien vers une autre hCard qui pourrait bénéficier des valeurs rel explicites qui ont décrit la relation spécifique.

	~~Sur la page avec l'encodage hCard, le meilleur lien serait comme suit :~~

	~~<code><nowiki> <link~~ rel~~="alternate" type="text/directory" href="..." /> </nowiki></code>~~
	~~cette page HTML est une vue alternative de~~ la ~~vCard.~~

	Le [http://www.iana.org/assignments/media-types/text/ type approprié et enregistré] pour les entités vCard est “text/directory”, comme défini dans la RFC 2425 Internet “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, spécifie le profil vCard pour les entités “text/directory” entities, que le profil champ header MIME/HTTP “Content-Type” indiquerait avec un paramètre “profile” quelle valeur est “VCARD”.

	~~Il n~~'~~est pas clair si l~~'~~attribut HTML/XHTML “type” permet des valeurs avec les paramètres. Le 2004~~-~~05-23~~, ~~[http://bjoern.hoehrmann.~~de~~/ Björn Höhrmann] a envoyé au [http://www~~.~~w3.org/2002/05/html/charter HTML Working Group]~~ une ~~[http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de demande de clarification] sur la problématique~~.		==== home page vers page contact ====
			Bon nombre d'individus et d'organisations s'identifient eux-mêmes à travers leurs URLs, et puis incluent une page séparée pour leur information de contact. Ceci est une pratique existante qui pourrait être représentée avec des microformats.

	~~Quand on est sur une page différente~~, ~~référencer cette page encodée dans le href ne serait ''pas'' une vue alternative de la page en cours~~. ~~Par conséquent rel="alternate" peut ne pas être approprié~~. ~~Le problème de la valeur rel à utiliser est plus grand que les liens vers les vCards~~.		Exemples :
			* Ryan King, http://theryanking.com/ , http://theryanking.com/contact/
			* Tantek Çelik, http://tantek.com/ , http://tantek.pbwiki.com/ContactCard/
			* Google, http://www.google.com/ , http://www.google.com/intl/en/contact/index.html

	~~===~~ hCard vers ~~les relations~~ hCard ~~===~~		Ces exemples pourraient être traités par le brainstorming suivant mini hCard vers hCard étendue.
	Il existe plusieurs type de relations hCard vers hCard, ce qui veut dire, une hCard hyperliant vers une autre hCard qui bénéficierait des valeurs rel explicites décrites dans la relation spécifique.

	==== mini hCard vers hCard étendue ====		==== mini hCard vers hCard étendue ====
Line 302:		Line 301:

	Ceci fût suggéré par Jens Alfke le 20050606 durant le dîner des blogueurs WWDC.		Ceci fût suggéré par Jens Alfke le 20050606 durant le dîner des blogueurs WWDC.

			=== auto-découverte lien vCard rel ===
			Une possibilité similaire est un lien d'auto-découverte dans l'en-tête du document qui pourrait pointer vers une URL (peut-être avac transformation) vers une version vCard de la hCard représentative.

			Sur la page avec l'encodage hCard, le meilleur lien serait comme suit :

			<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
			cette page HTML est une vue alternative de la vCard.

			Le [http://www.iana.org/assignments/media-types/text/ type approprié et enregistré] pour les entités vCard est “text/directory”, comme défini dans la RFC 2425 Internet “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, spécifie le profil vCard pour les entités “text/directory” entities, que le profil champ header MIME/HTTP “Content-Type” indiquerait avec un paramètre “profile” quelle valeur est “VCARD”.

			Il n'est pas clair si l'attribut HTML/XHTML “type” permet des valeurs avec les paramètres. Le 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] a envoyé au [http://www.w3.org/2002/05/html/charter HTML Working Group] une [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de demande de clarification] sur la problématique.

			Quand on est sur une page différente, référencer cette page encodée dans le href ne serait ''pas'' une vue alternative de la page en cours. Par conséquent rel="alternate" peut ne pas être approprié. Le problème de la valeur rel à utiliser est plus grand que les liens vers les vCards.

	== Améliorations geo ==		== Améliorations geo ==

ChristopheDucamp: /* Optimisation Implicite "FN et N" Optimization */

2008-01-09T22:02:59Z

Optimisation Implicite "FN et N" Optimization

← Older revision		Revision as of 22:02, 9 January 2008
Line 781:		Line 781:
	See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.		See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

	=== Optimisation Implicite "FN et N" ~~Optimization~~ ===		=== Optimisation Implicite "FN et N" ===

	A cette heure, un parseur cherche d'abord un élément "n".		A cette heure, un parseur cherche d'abord un élément "n".
Line 787:		Line 787:
	Et ensuite si "n" n'est pas présent, il chercher un élement "fn" à utiliser pour tirer implicitement un élément "n" selon les règles de la "propriété n implicite" dans la spéc.		Et ensuite si "n" n'est pas présent, il chercher un élement "fn" à utiliser pour tirer implicitement un élément "n" selon les règles de la "propriété n implicite" dans la spéc.

	~~BACKGROUND~~:		HISTORIQUE :

	~~Due to the prevalence of the use of~~ "nicknames" or "~~handles~~" ~~on the~~ Web, ~~in actual content published on the~~ Web (e.~~g. authors of reviews~~), ~~there has been~~ a discussion ~~about adding a~~ "fn" ~~shortcut to the~~ "n" ~~shortcut that used the~~ "nickname" ~~as a fallback~~.		Du fait de la prévalence de l'usage de "nicknames" ou "pseudos" sur le Web, dans le véritable contenu publié sur le Web (par ex. les auteurs de critiques), il y a eu une discussion à propos de l'ajout d'un raccourci "fn" au raccourci "n" qui utilisait le "nickname" comme solution de repli.

	~~PROPOSAL~~:		PROPOSITION :

	~~We should consider adding one more implied optimization after the steps documented above and that is~~:		Nous devrions imaginer ajouter une ou plusieurs optimisations implicites après les étapes documentés au-dessus et c'est :

	~~If no~~ "fn" ~~is present either~~, ~~then look for a~~ "nickname" ~~element to use to imply both the~~ "fn"~~, and the~~ "n/given-name", ~~leaving the~~ "n/family-name" ~~as empty~~.		Si aucun "fn" n'est présent, alors chercher un élément "nickname" à utiliser pour sous-tendre à la fois le "fn" et le "n/given-name", en laissant vide le "n/family-name".

	~~This would enable~~ "nickname" ~~only hCards for denoting and individual on a website~~, ~~which is quite common on~~ blogs ~~and reviews published on the Web~~.		Ceci permettrait des hCards uniquement avec "nickname" pour indiquer l'individu sur un site web, ce qui est tout à fait commun sur les blogs et critiques publiés sur le web.
	* +1 [[User:Atamido\|Atamido]]		* +1 [[User:Atamido\|Atamido]]
	* +1 [[User:ChrisMessina\|ChrisMessina]] - note: ~~multiple alternate~~ nicknames ~~should also be allowed~~		* +1 [[User:ChrisMessina\|ChrisMessina]] - note : plusieurs nicknames alternatifs devraient être aussi permis
	* +1 [[User:DimitriGlazkov\|DimitriGlazkov]]		* +1 [[User:DimitriGlazkov\|DimitriGlazkov]]

ChristopheDucamp: /* multiple type parsing */

2008-01-09T21:56:15Z

multiple type parsing

← Older revision		Revision as of 21:56, 9 January 2008
Line 603:		Line 603:

	=== multiple type parsing ===		=== multiple type parsing ===
	* Multiple Type parsing / Type Optimization: ~~The~~ spec ~~allows for~~, ~~and the~~ [[hcard-authoring#~~Phone_Numbers~~\|~~hcard-authoring~~]] ~~demonstrate the use of multiple type designations for a single value of~~ tel. ~~The syntax used in the authoring examples where each seems like it could become cumbersome~~. ~~As these~~ type ~~designations are all single~~ '~~word~~' ~~strings it may be~~ possible ~~to implement additional parsing rules to allow for multiple~~ types ~~inside the same~~ HTML ~~element~~. ~~Handling delimiters may be an issue~~ [~~space~~, ~~comma~~, etc?], ~~and some in~~-~~the~~-~~wild usage of multiple~~ types ~~would need to be located and examined before considering additional parsing rules along these lines~~ [ [[User:ChrisCasciano\|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]		* Multiple Type parsing / Type Optimization : La spec le permet, et la [[hcard-authoring-fr#Num.C3.A9ros_de_T.C3.A9l.C3.A9phone\|publication de hCard]] démontre l'usage de plusieurs désignations de types pour une valeur unique de tel. La syntaxe utilisée dans les exemples de publication où chacun semble comme s'il pouvait devenir encombrant. Du fait qeu ces désignations de type soient toutes des chaînes uniques de 'mot' il peut être possible d'implémenter des règles supplémentaires de parsage pour plusieurs types dans le même élément HTML. Gérer les délimiteurs peut être un problème [espace, virgule, etc?], et quelques-un des usages dans-la-jungle de plusieurs types auraient besoin d'être repérés et examinés avant de considérer quelques règles supplémentaires de parsage le long de ces lignes [ [[User:ChrisCasciano\|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]

	=== parsage hyperlien fax et modem ===		=== parsage hyperlien fax et modem ===