hcard-issues-resolved - Revision history

Tantek: rm hardcoded IRC server in prose

2024-10-23T19:07:04Z

rm hardcoded IRC server in prose

← Older revision		Revision as of 19:07, 23 October 2024
Line 22:		Line 22:
	'''Note: As the resolutions are enacted and the issues are closed, it may be worth moving this year of issues to its own page.'''		'''Note: As the resolutions are enacted and the issues are closed, it may be worth moving this year of issues to its own page.'''

	* 2006-11-15 raised by [http://lachy.id.au/ Lachy] in ~~[irc://freenode/whatwg~~ #whatwg] (an IRC channel ~~on [http://freenode.net/ freenode] about~~ [http://whatwg.org/ The WHATWG]).		* 2006-11-15 raised by [http://lachy.id.au/ Lachy] in #whatwg (an IRC channel for [http://whatwg.org/ The WHATWG]).
	*# ''I think the whole [[hcard\|hCard]] specification needs to be restructured.''		*# ''I think the whole [[hcard\|hCard]] specification needs to be restructured.''
	# ACCEPTED. I (the editor, Tantek) have been rewriting the spec accordingly since 2007 June.		# ACCEPTED. I (the editor, Tantek) have been rewriting the spec accordingly since 2007 June.

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:26:32Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:26, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~hCard resolved issues~~</entry-title>~~		{{DISPLAYTITLE:hCard resolved issues}}
	== resolved issues ==		== resolved issues ==
	[[hCard]] <span id="Resolved_Issues">issues that are resolved but may have outstanding [[to-do]] items.</span>		[[hCard]] <span id="Resolved_Issues">issues that are resolved but may have outstanding [[to-do]] items.</span>

Tantek: /* resolved 2010 */ follow-up to i18n examples, note authoring guidance of MUST use given-name, family-name on sites in languages where fn-opt doesn't apply, and need new issue for english social nets

2010-07-20T18:35:14Z

resolved 2010: follow-up to i18n examples, note authoring guidance of MUST use given-name, family-name on sites in languages where fn-opt doesn't apply, and need new issue for english social nets

← Older revision		Revision as of 18:35, 20 July 2010
Line 358:		Line 358:
	* <strong class="entry-title">Implied "n" Optimization</strong>. The [[hcard#Implied_.22n.22_Optimization\|hCard spec]] and the derived [http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#conversion-to-vcard microdata vCard spec] has some magic intended to derive N from FN when it is not given explicitly, as N is required by the vCard spec. The guessing employed will fail for at least Vietnamese names (e.g. Phương Thanh => N:Thanh;Phương;;;), Chinese names (e.g. 冯小刚 => N:;冯小刚;; and Feng Xiaogang => N:Xiaogang;Feng;;;) and Japanese/Korean names for the same reasons. The problem is both that family-name and given-name are reversed and that Chinese is written without space, so the whole name is interpreted as family name. If the only issue is that N is mandatory, simply outputting N:;;;; seems the safest. Although it's technically possible to add markup to avoid the guessing, that's not going to be an option when microdata/microformats are used in a template and the user isn't asked for both the full name and all of its components. This issue was previously raised on [http://microformats.org/discuss/mail/microformats-discuss/2010-February/013187.html microformats-discuss].		* <strong class="entry-title">Implied "n" Optimization</strong>. The [[hcard#Implied_.22n.22_Optimization\|hCard spec]] and the derived [http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#conversion-to-vcard microdata vCard spec] has some magic intended to derive N from FN when it is not given explicitly, as N is required by the vCard spec. The guessing employed will fail for at least Vietnamese names (e.g. Phương Thanh => N:Thanh;Phương;;;), Chinese names (e.g. 冯小刚 => N:;冯小刚;; and Feng Xiaogang => N:Xiaogang;Feng;;;) and Japanese/Korean names for the same reasons. The problem is both that family-name and given-name are reversed and that Chinese is written without space, so the whole name is interpreted as family name. If the only issue is that N is mandatory, simply outputting N:;;;; seems the safest. Although it's technically possible to add markup to avoid the guessing, that's not going to be an option when microdata/microformats are used in a template and the user isn't asked for both the full name and all of its components. This issue was previously raised on [http://microformats.org/discuss/mail/microformats-discuss/2010-February/013187.html microformats-discuss].
	** RESOLVED PARTIAL DUPLICATE. This is mostly a duplicate of [[hcard-issues-resolved#fn-opt-i18n\|previous issue raised by James Craig 2007-03-28]], however, the additional information is appreciated. This documentation of the issue contains several points useful to a refined resolution. [[User:Tantek\|Tantek]] 00:22, 16 April 2010 (UTC)		** RESOLVED PARTIAL DUPLICATE. This is mostly a duplicate of [[hcard-issues-resolved#fn-opt-i18n\|previous issue raised by James Craig 2007-03-28]], however, the additional information is appreciated. This documentation of the issue contains several points useful to a refined resolution. [[User:Tantek\|Tantek]] 00:22, 16 April 2010 (UTC)
	*** MUST NOT apply FN to implied N optimization when lang is Vietnamese (need lang code), Chinese (need lang code(s)), Japanese ("ja"), or Korean (need lang code).		*** MUST NOT apply FN to implied N optimization when lang is Vietnamese (need lang code), Chinese ("zh", need lang code(s)), Japanese ("ja"), or Korean (need lang code).
	*** For hCard to vCard converters: If an hCard lacks an 'n' property (either explicit or implied), when producing the equivalent vCard, output an empty N "N:;;;;" property in order to satisfy vCard's requirement that an N property be specified.		*** For hCard to vCard converters: If an hCard lacks an 'n' property (either explicit or implied), when producing the equivalent vCard, output an empty N "N:;;;;" property in order to satisfy vCard's requirement that an N property be specified.
	** '''Further information''' Hey Tantek, this assumes that the page has lang declared. That just isn’t common in Japan, and I guess in the other countries mentioned, given the monolingualism. I did some quick research for you, using the first 10 search results for Nakamura (a common Japanese family name) in kanji:		** '''Further information''' Hey Tantek, this assumes that the page has lang declared. That just isn’t common in Japan, and I guess in the other countries mentioned, given the monolingualism. I did some quick research for you, using the first 10 search results for Nakamura (a common Japanese family name) in kanji:
Line 388:		Line 388:
	**** 6 out of 10		**** 6 out of 10
	*** I’d like to note these are the highest ranked pages for a very popular search term, and include universities, schools and soccer star (well in Japan ;-) Shunsuke Nakamura’s homepage. There’s even a yahoo.co.jp site without lang="ja". I guess you can imagine the long tail :/ If you need Japanese examples or further info, please let me know. Also, check the hCards for http://twitter.com/boblet/following for examples of Philip’s comment about template/social media sites. Ignoring the current invalid stuff, you can see my friend Channy’s vcard is wrong.		*** I’d like to note these are the highest ranked pages for a very popular search term, and include universities, schools and soccer star (well in Japan ;-) Shunsuke Nakamura’s homepage. There’s even a yahoo.co.jp site without lang="ja". I guess you can imagine the long tail :/ If you need Japanese examples or further info, please let me know. Also, check the hCards for http://twitter.com/boblet/following for examples of Philip’s comment about template/social media sites. Ignoring the current invalid stuff, you can see my friend Channy’s vcard is wrong.
			**** Two things: (noted by [[User:Tantek\|Tantek]] 18:35, 20 July 2010 (UTC) )
			**** First, all the search results demonstrate is that we need to provide more precise authoring guidance for hCards in multiple languages. E.g. if/when those sites decide to add hCard, then they {{must}} explicitly markup "given-name" and "family-name", and {{should}} add the correct <code>lang</code> attribute at least to the page at the same time. I'll consider that part of the resolution for this issue (authoring guidance in addition to parsing details).
			**** Second, the example of non-English names on primarily English social media sites is a good one and potentially a bigger challenge. Rather than re-open this entire issue, let's open a new issue for the specific example of multilingual pages or primarily English pages with non-English names in languages where the fn optimization doesn't make sense.
	</div>		</div>
	</div>		</div>

Oli: /* resolved 2010 */ fixing formatting

2010-07-20T03:35:52Z

resolved 2010: fixing formatting

← Older revision		Revision as of 03:35, 20 July 2010
Line 361:		Line 361:
	*** For hCard to vCard converters: If an hCard lacks an 'n' property (either explicit or implied), when producing the equivalent vCard, output an empty N "N:;;;;" property in order to satisfy vCard's requirement that an N property be specified.		*** For hCard to vCard converters: If an hCard lacks an 'n' property (either explicit or implied), when producing the equivalent vCard, output an empty N "N:;;;;" property in order to satisfy vCard's requirement that an N property be specified.
	** '''Further information''' Hey Tantek, this assumes that the page has lang declared. That just isn’t common in Japan, and I guess in the other countries mentioned, given the monolingualism. I did some quick research for you, using the first 10 search results for Nakamura (a common Japanese family name) in kanji:		** '''Further information''' Hey Tantek, this assumes that the page has lang declared. That just isn’t common in Japan, and I guess in the other countries mentioned, given the monolingualism. I did some quick research for you, using the first 10 search results for Nakamura (a common Japanese family name) in kanji:
			*** http://search.yahoo.co.jp/search?p=%中村&ei=UTF-8&fr=top_ga1_sa&x=wrt
	http://search.yahoo.co.jp/search?p=%中村&ei=UTF-8&fr=top_ga1_sa&x=wrt		**** 303,000,000 results
	303,000,000 results		**** http://ja.wikipedia.org/wiki/中村 yes
	http://ja.wikipedia.org/wiki/中村 yes		**** http://www.nakamura.ed.jp/ no
	http://www.nakamura.ed.jp/ no		**** http://shunsuke.com/ yes
	http://shunsuke.com/ yes		**** http://ja.wikipedia.org/wiki/中村紀洋 yes
	http://ja.wikipedia.org/wiki/中村紀洋 yes		**** http://www.mypixel.co.jp/kabuki/nakamura/ no
	http://www.mypixel.co.jp/kabuki/nakamura/ no		**** http://www.nakamuraya.co.jp/index.html no
	http://www.nakamuraya.co.jp/index.html no		**** http://www.nakamura-net21.co.jp/ no
	http://www.nakamura-net21.co.jp/ no		**** http://www.eriko-nakamura.com/index.html no
	http://www.eriko-nakamura.com/index.html no		**** http://ataru-atariya.com/ yes
	http://ataru-atariya.com/ yes		**** http://baseball.yahoo.co.jp/npb/player?id=12101 yes
	http://baseball.yahoo.co.jp/npb/player?id=12101 yes		**** 5 out of 10
	5 out of 10		*** http://www.google.co.jp/search?hl=en&source=hp&q=中村
			**** 28,700,000 results
	http://www.google.co.jp/search?hl=en&source=hp&q=中村		**** http://www.nakamura.ed.jp/ no
	28,700,000 results		**** http://ja.wikipedia.org/wiki/中村 yes
	http://www.nakamura.ed.jp/ no		**** http://ja.wikipedia.org/wiki/中村俊輔 yes
	http://ja.wikipedia.org/wiki/中村 yes		**** http://nakamura-japan.net/ no
	http://ja.wikipedia.org/wiki/中村俊輔 yes		**** http://shunsuke.com/ yes
	http://nakamura-japan.net/ no		**** http://www.nakamura-udon.jp/ no (not even encoding!)
	http://shunsuke.com/ yes		**** http://www.city.nakamura.kochi.jp/topj.html yes
	http://www.nakamura-udon.jp/ no (not even encoding!)		**** http://www.nakamura-u.ac.jp/ yes
	http://www.city.nakamura.kochi.jp/topj.html yes		**** http://dailynews.yahoo.co.jp/fc/sports/shunsuke/ no (!)
	http://www.nakamura-u.ac.jp/ yes		**** http://nakamurajapan.blog17.fc2.com/ yes
	http://dailynews.yahoo.co.jp/fc/sports/shunsuke/ no (!)		**** 6 out of 10
	http://nakamurajapan.blog17.fc2.com/ yes		*** I’d like to note these are the highest ranked pages for a very popular search term, and include universities, schools and soccer star (well in Japan ;-) Shunsuke Nakamura’s homepage. There’s even a yahoo.co.jp site without lang="ja". I guess you can imagine the long tail :/ If you need Japanese examples or further info, please let me know. Also, check the hCards for http://twitter.com/boblet/following for examples of Philip’s comment about template/social media sites. Ignoring the current invalid stuff, you can see my friend Channy’s vcard is wrong.
	6 out of 10

	I’d like to note these are the highest ranked pages for a very popular search term, and include universities, schools and soccer star (well in Japan ;-) Shunsuke Nakamura’s homepage. There’s even a yahoo.co.jp site without lang="ja". I guess you can imagine the long tail :/

	If you need Japanese examples or further info, please let me know.

	Also, check the hCards for http://twitter.com/boblet/following for examples of Philip’s comment about template/social media sites. Ignoring the current invalid stuff, you can see my friend Channy’s vcard is wrong.
	</div>		</div>
	</div>		</div>

Oli: /* resolved 2010 */ adding extra information re: the 18n problem with implied n optimisation (hope this is the right place for it)

2010-07-20T03:32:43Z

resolved 2010: adding extra information re: the 18n problem with implied n optimisation (hope this is the right place for it)

@@ Line 360: / Line 360: @@
 *** MUST NOT apply FN to implied N optimization when lang is Vietnamese (need lang code), Chinese (need lang code(s)), Japanese ("ja"), or Korean (need lang code).
 *** For hCard to vCard converters: If an hCard lacks an 'n' property (either explicit or implied), when producing the equivalent vCard, output an empty N "N:;;;;" property in order to satisfy vCard's requirement that an N property be specified.
 </div>
 </div>

Tantek: /* resolved 2008 */ implemented resolution to issue 2008-12-16 n optimization, moved to hcard-issues-closed

2010-04-16T02:23:16Z

resolved 2008: implemented resolution to issue 2008-12-16 n optimization, moved to hcard-issues-closed

← Older revision		Revision as of 02:23, 16 April 2010
Line 329:		Line 329:
	*** That is true, but it does more tightly associate e-mail addresses with other information. Spammers could use this to tie an e-mail address to other personal/contact details and make their messages less spammy in an attempt to fool filters. For example, some filters will raise the spam score of a message if the "To" field contains just an e-mail address, and not the recipient's name - hCard provides spammers with a fairly reliable way of finding out that name. I don't think this is a ''huge'' concern, but it is a slight concern which shouldn't be entirely dismissed. [[User:TobyInk\|TobyInk]] 16:37, 12 December 2008 (UTC)		*** That is true, but it does more tightly associate e-mail addresses with other information. Spammers could use this to tie an e-mail address to other personal/contact details and make their messages less spammy in an attempt to fool filters. For example, some filters will raise the spam score of a message if the "To" field contains just an e-mail address, and not the recipient's name - hCard provides spammers with a fairly reliable way of finding out that name. I don't think this is a ''huge'' concern, but it is a slight concern which shouldn't be entirely dismissed. [[User:TobyInk\|TobyInk]] 16:37, 12 December 2008 (UTC)
	*** ACCEPTED FAQ. There is already [[faq#Microformats_and_Spam\|a general microformats FAQ on SPAM]] and this should be either added to that or perhaps specifically to [[hcard-faq]].		*** ACCEPTED FAQ. There is already [[faq#Microformats_and_Spam\|a general microformats FAQ on SPAM]] and this should be either added to that or perhaps specifically to [[hcard-faq]].

	* 2008-12-16 raised by [[User:Tantek\|Tantek Çelik]]
	*# The "n" optimization rule for turning an fn of "WORD C." into an n given-name initial of "C" and family-name of "WORD" should be dropped, as it was not based on sufficient usage in practice (based on why I put it in there in the first place), and (a) it actually interferes with some broad usage in historical practice, e.g. on Pownce user's names were abbrevated as "GIVEN F." where GIVEN was their given-name and F was there family-name initial and (b) may have problems with non-Western name abbreviations also.
	# suggested resolution: drop respective "n" optimization rule, and suggest markup for any use of abbreviated name components with abbr tag, e.g. <code><nowiki><span class="fn">Tantek <abbr>Ç.</abbr></span></nowiki></code>
	#* Could retain the rule when a comma or semicolon is found between the two parts though. [[User:TobyInk\|TobyInk]] 22:39, 16 December 2008 (UTC)
	#** At this point, unless sufficient real world sites are documented which use that practice of "a comma or semicolon is between the two parts", it is preferable to drop it, for simplicity. [[User:Tantek\|Tantek]] 23:17, 3 June 2009 (UTC)
	# ACCEPTED. Drop "WORD C." "n" optimization rule, noting the past examples of Pownce and http://dodgeball.com/, and the more recent example of http://playfoursquare.com/.

	* 2008-12-16 raised by [[User:TobyInk\|TobyInk]]		* 2008-12-16 raised by [[User:TobyInk\|TobyInk]]

Tantek: /* resolved 2009 */ add resolved 2010 section with one mostly duplicate bug that provided more information for a better resolution.

2010-04-16T00:22:47Z

resolved 2009: add resolved 2010 section with one mostly duplicate bug that provided more information for a better resolution.

← Older revision		Revision as of 00:22, 16 April 2010
Line 343:		Line 343:
	=== resolved 2009 ===		=== resolved 2009 ===
	<div class="hentry">		<div class="hentry">
	<span class="entry-summary author vcard"><span class="published">2009-218</span> raised by <span class="fn">[[User:Singpolyma\|Singpolyma]]</span></span>		{{ResolvedIssue}} <span class="entry-summary author vcard"><span class="published">2009-218</span> raised by <span class="fn">[[User:Singpolyma\|Singpolyma]]</span></span>
	<div class="entry-content discussion issues">		<div class="entry-content discussion issues">
	* <strong class="entry-title">Format for key</strong>. What format should be used for key? I suggest the following:<pre><nowiki><a class="key" type="application/pgp-keys" href="https://path.to/key">My PGP Key</a></nowiki></pre>With MIME type obviously changed based on type of key.		* <strong class="entry-title">Format for key</strong>. What format should be used for key? I suggest the following:<pre><nowiki><a class="key" type="application/pgp-keys" href="https://path.to/key">My PGP Key</a></nowiki></pre>With MIME type obviously changed based on type of key.
Line 355:		Line 355:
	* <strong class="entry-title">Parsing UTF-8 'special' space characters in telephone fields</strong>. I recently designed a page that used an hCard with a <code>span</code> containing the <samp>tel</samp> value. To space the phone number appropriately, I used the U+8201 (THIN SPACE) character <code>&#8201;</code>. [[operator\|Operator's]] hCard parser coughed up on this and refused to read both the contents of the <samp>tel</samp> <code>span</code> but also an <code>a</code> element containing the <samp>email</samp> property that was contained in the parent <code>p</code> element. I cannot find a clear definition of what is acceptable content for the <samp>tel</samp> property. There seems to be two ways of resolving this: (1) instruct authors of microformat parsing libraries to normalise the Unicode characters U+8194 (EN SPACE), U+8195 (EM SPACE), U+8196 (THREE-PER-EM SPACE), U+8197 (FOUR-PER-EM SPACE), U+8198 (SIX-PER-EM SPACE), U+8199 (FIGURE SPACE), U+8200 (PUNCTUATION SPACE), U+8201 (THIN SPACE), U+8202 (HAIR SPACE), U+8203 (ZERO WIDTH SPACE) and other similar characters (including the HTML entities <code>&ensp;</code>, <code>&emsp;</code>, <code>&thinsp;</code> and <code>&nbsp;</code>) so that, for the purpose of parsing the microformat they are treated as a standard space (U+0020) or (2) instructing microformat authors to not use any other space character than U+0020 (and to use the [http://www.w3.org/TR/CSS21/text.html#spacing-props CSS <code>word-spacing</code> property] for manipulating <samp>tel</samp> properties). Which of these is best? Anyone want to survey the current implementations to see how they currently parse telephone numbers with unexpected characters in them? Part of the problem may be that there doesn't seem to be any clear specification of what a valid telephone number is, so far as I can see—which is just from reading [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] §3.3, which says that it should simply be the telephone format defined in X.500 ([http://www.ietf.org/rfc/rfc1274.txt RFC 1274]), but there is no explicit definition in X.500 except to say it is "telephoneNumberSyntax", which is defined in [http://www.ietf.org/rfc/rfc1778.txt RFC 1778] §2.16 as simply being a printable string. Perhaps I've gone off down a blind alley! (Do we need a page for character encoding/Unicode issues?)		* <strong class="entry-title">Parsing UTF-8 'special' space characters in telephone fields</strong>. I recently designed a page that used an hCard with a <code>span</code> containing the <samp>tel</samp> value. To space the phone number appropriately, I used the U+8201 (THIN SPACE) character <code>&#8201;</code>. [[operator\|Operator's]] hCard parser coughed up on this and refused to read both the contents of the <samp>tel</samp> <code>span</code> but also an <code>a</code> element containing the <samp>email</samp> property that was contained in the parent <code>p</code> element. I cannot find a clear definition of what is acceptable content for the <samp>tel</samp> property. There seems to be two ways of resolving this: (1) instruct authors of microformat parsing libraries to normalise the Unicode characters U+8194 (EN SPACE), U+8195 (EM SPACE), U+8196 (THREE-PER-EM SPACE), U+8197 (FOUR-PER-EM SPACE), U+8198 (SIX-PER-EM SPACE), U+8199 (FIGURE SPACE), U+8200 (PUNCTUATION SPACE), U+8201 (THIN SPACE), U+8202 (HAIR SPACE), U+8203 (ZERO WIDTH SPACE) and other similar characters (including the HTML entities <code>&ensp;</code>, <code>&emsp;</code>, <code>&thinsp;</code> and <code>&nbsp;</code>) so that, for the purpose of parsing the microformat they are treated as a standard space (U+0020) or (2) instructing microformat authors to not use any other space character than U+0020 (and to use the [http://www.w3.org/TR/CSS21/text.html#spacing-props CSS <code>word-spacing</code> property] for manipulating <samp>tel</samp> properties). Which of these is best? Anyone want to survey the current implementations to see how they currently parse telephone numbers with unexpected characters in them? Part of the problem may be that there doesn't seem to be any clear specification of what a valid telephone number is, so far as I can see—which is just from reading [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] §3.3, which says that it should simply be the telephone format defined in X.500 ([http://www.ietf.org/rfc/rfc1274.txt RFC 1274]), but there is no explicit definition in X.500 except to say it is "telephoneNumberSyntax", which is defined in [http://www.ietf.org/rfc/rfc1778.txt RFC 1778] §2.16 as simply being a printable string. Perhaps I've gone off down a blind alley! (Do we need a page for character encoding/Unicode issues?)
	** ACCEPTED FAQ, parsing. [[microformats]] depend on the character parsing of the language they are in. In this case, let's for example see what HTML4 and HTML5 say, and advise accordingly in [[hcard-faq]] and [[hcard-parsing]]. [[User:Tantek\|Tantek]] 08:56, 9 October 2009 (UTC)		** ACCEPTED FAQ, parsing. [[microformats]] depend on the character parsing of the language they are in. In this case, let's for example see what HTML4 and HTML5 say, and advise accordingly in [[hcard-faq]] and [[hcard-parsing]]. [[User:Tantek\|Tantek]] 08:56, 9 October 2009 (UTC)
			</div>
			</div>

			=== resolved 2010 ===

			<div class="hentry">
			{{ResolvedIssue}} <span class="entry-summary author vcard"><span class="published">2010-02-03</span> raised by <span class="fn">[http://foolip.org/ Philip Jägenstedt]</span></span>
			<div class="entry-content discussion issues">
			* <strong class="entry-title">Implied "n" Optimization</strong>. The [[hcard#Implied_.22n.22_Optimization\|hCard spec]] and the derived [http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#conversion-to-vcard microdata vCard spec] has some magic intended to derive N from FN when it is not given explicitly, as N is required by the vCard spec. The guessing employed will fail for at least Vietnamese names (e.g. Phương Thanh => N:Thanh;Phương;;;), Chinese names (e.g. 冯小刚 => N:;冯小刚;; and Feng Xiaogang => N:Xiaogang;Feng;;;) and Japanese/Korean names for the same reasons. The problem is both that family-name and given-name are reversed and that Chinese is written without space, so the whole name is interpreted as family name. If the only issue is that N is mandatory, simply outputting N:;;;; seems the safest. Although it's technically possible to add markup to avoid the guessing, that's not going to be an option when microdata/microformats are used in a template and the user isn't asked for both the full name and all of its components. This issue was previously raised on [http://microformats.org/discuss/mail/microformats-discuss/2010-February/013187.html microformats-discuss].
			** RESOLVED PARTIAL DUPLICATE. This is mostly a duplicate of [[hcard-issues-resolved#fn-opt-i18n\|previous issue raised by James Craig 2007-03-28]], however, the additional information is appreciated. This documentation of the issue contains several points useful to a refined resolution. [[User:Tantek\|Tantek]] 00:22, 16 April 2010 (UTC)
			*** MUST NOT apply FN to implied N optimization when lang is Vietnamese (need lang code), Chinese (need lang code(s)), Japanese ("ja"), or Korean (need lang code).
			*** For hCard to vCard converters: If an hCard lacks an 'n' property (either explicit or implied), when producing the equivalent vCard, output an empty N "N:;;;;" property in order to satisfy vCard's requirement that an N property be specified.
	</div>		</div>
	</div>		</div>

Tantek: /* resolved 2007 */ clarify n property left empty when not doing implied optimization

2010-03-11T11:25:28Z

resolved 2007: clarify n property left empty when not doing implied optimization

← Older revision		Revision as of 11:25, 11 March 2010
Line 167:		Line 167:
	* 2007-03-28 raised by [[User:JamesCraig\|James Craig]]		* 2007-03-28 raised by [[User:JamesCraig\|James Craig]]
	*#[[internationalization\|Internationalization]] <span id="fn-opt-i18n">(i18n) issue for implied optimization of FN</span>. Many languages (for example, Japanese) often list FN as "family-name given-name" instead of the assumed "given-name family-name" in English and other Western languages. There should be a affordance to indicate the order ''or'' a note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time.		*#[[internationalization\|Internationalization]] <span id="fn-opt-i18n">(i18n) issue for implied optimization of FN</span>. Many languages (for example, Japanese) often list FN as "family-name given-name" instead of the assumed "given-name family-name" in English and other Western languages. There should be a affordance to indicate the order ''or'' a note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time.
	# ACCEPTED. Tantek [[to-do]]: add internationalization section in [[hcard\|hCard]] spec, and note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time. In particular, the fn implied n optimization should be limited to fn properties which themselves are on elements that are on a whitelist of Western languages that typically publish with "given-name family-name" order, such as "en" (add others as confirmed by i18n experts). fn elements of other languages should not imply this optimization.		# ACCEPTED. Tantek [[to-do]]: add internationalization section in [[hcard\|hCard]] spec, and note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time. In particular, the fn implied n optimization should be limited to fn properties which themselves are on elements that are on a whitelist of Western languages that typically publish with "given-name family-name" order, such as "en" (add others as confirmed by i18n experts). fn elements of other languages should not imply this optimization. When the optimization is not implied, then the n property is left as is - if it were otherwise empty, it is left empty.
	* 2007-03-31 raised by [[User:AndyMabbett\|Andy Mabbett]]		* 2007-03-31 raised by [[User:AndyMabbett\|Andy Mabbett]]
	*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman\|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett\|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)		*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman\|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett\|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)

Tantek: /* resolved 2007 */ add fn-opt-i18n id, clarify whitelist for Western languages where given-name family-name order is provided for fn

2010-03-11T03:35:14Z

resolved 2007: add fn-opt-i18n id, clarify whitelist for Western languages where given-name family-name order is provided for fn

← Older revision		Revision as of 03:35, 11 March 2010
Line 166:		Line 166:

	* 2007-03-28 raised by [[User:JamesCraig\|James Craig]]		* 2007-03-28 raised by [[User:JamesCraig\|James Craig]]
	*#[[internationalization\|Internationalization]] (i18n) issue for implied optimization of FN. Many languages (for example, Japanese) often list FN as "family-name given-name" instead of the assumed "given-name family-name" in English and other Western languages. There should be a affordance to indicate the order ''or'' a note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time.		*#[[internationalization\|Internationalization]] <span id="fn-opt-i18n">(i18n) issue for implied optimization of FN</span>. Many languages (for example, Japanese) often list FN as "family-name given-name" instead of the assumed "given-name family-name" in English and other Western languages. There should be a affordance to indicate the order ''or'' a note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time.
	# ACCEPTED. Tantek [[to-do]]: add internationalization section in [[hcard\|hCard]] spec, and note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time.		# ACCEPTED. Tantek [[to-do]]: add internationalization section in [[hcard\|hCard]] spec, and note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time. In particular, the fn implied n optimization should be limited to fn properties which themselves are on elements that are on a whitelist of Western languages that typically publish with "given-name family-name" order, such as "en" (add others as confirmed by i18n experts). fn elements of other languages should not imply this optimization.

	* 2007-03-31 raised by [[User:AndyMabbett\|Andy Mabbett]]		* 2007-03-31 raised by [[User:AndyMabbett\|Andy Mabbett]]
	*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman\|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett\|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)		*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman\|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett\|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)

Tantek: /* resolved 2006 */ resolve a 2006-12-15 issue re: invisible data - all follow-up actions were completed.

2009-11-24T07:03:47Z

resolved 2006: resolve a 2006-12-15 issue re: invisible data - all follow-up actions were completed.

@@ Line 76: / Line 76: @@
 *# originally [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007337.html raised  on uf-discuss] by David Janes.
 *#* ACCEPTED. This is a good suggested clarification. Tantek [[to-do]]: update [[hcard|hCard]] accordingly.
 * 2006-12-15 raised ([http://microformats.org/discuss/mail/microformats-discuss/2006-December/007730.html on 2006-12-14, on the mailing list]) by Joe Andrieu.

← Older revision		Revision as of 02:23, 16 April 2010
Line 329:		Line 329:
	*** That is true, but it does more tightly associate e-mail addresses with other information. Spammers could use this to tie an e-mail address to other personal/contact details and make their messages less spammy in an attempt to fool filters. For example, some filters will raise the spam score of a message if the "To" field contains just an e-mail address, and not the recipient's name - hCard provides spammers with a fairly reliable way of finding out that name. I don't think this is a ''huge'' concern, but it is a slight concern which shouldn't be entirely dismissed. [[User:TobyInk\|TobyInk]] 16:37, 12 December 2008 (UTC)		*** That is true, but it does more tightly associate e-mail addresses with other information. Spammers could use this to tie an e-mail address to other personal/contact details and make their messages less spammy in an attempt to fool filters. For example, some filters will raise the spam score of a message if the "To" field contains just an e-mail address, and not the recipient's name - hCard provides spammers with a fairly reliable way of finding out that name. I don't think this is a ''huge'' concern, but it is a slight concern which shouldn't be entirely dismissed. [[User:TobyInk\|TobyInk]] 16:37, 12 December 2008 (UTC)
	*** ACCEPTED FAQ. There is already [[faq#Microformats_and_Spam\|a general microformats FAQ on SPAM]] and this should be either added to that or perhaps specifically to [[hcard-faq]].		*** ACCEPTED FAQ. There is already [[faq#Microformats_and_Spam\|a general microformats FAQ on SPAM]] and this should be either added to that or perhaps specifically to [[hcard-faq]].

	* 2008-12-16 raised by [[User:Tantek\|Tantek Çelik]]
	*# The "n" optimization rule for turning an fn of "WORD C." into an n given-name initial of "C" and family-name of "WORD" should be dropped, as it was not based on sufficient usage in practice (based on why I put it in there in the first place), and (a) it actually interferes with some broad usage in historical practice, e.g. on Pownce user's names were abbrevated as "GIVEN F." where GIVEN was their given-name and F was there family-name initial and (b) may have problems with non-Western name abbreviations also.
	# suggested resolution: drop respective "n" optimization rule, and suggest markup for any use of abbreviated name components with abbr tag, e.g. <code><nowiki><span class="fn">Tantek <abbr>Ç.</abbr></span></nowiki></code>
	#* Could retain the rule when a comma or semicolon is found between the two parts though. [[User:TobyInk\|TobyInk]] 22:39, 16 December 2008 (UTC)
	#** At this point, unless sufficient real world sites are documented which use that practice of "a comma or semicolon is between the two parts", it is preferable to drop it, for simplicity. [[User:Tantek\|Tantek]] 23:17, 3 June 2009 (UTC)
	# ACCEPTED. Drop "WORD C." "n" optimization rule, noting the past examples of Pownce and http://dodgeball.com/, and the more recent example of http://playfoursquare.com/.

	* 2008-12-16 raised by [[User:TobyInk\|TobyInk]]		* 2008-12-16 raised by [[User:TobyInk\|TobyInk]]

← Older revision		Revision as of 11:25, 11 March 2010
Line 167:		Line 167:
	* 2007-03-28 raised by [[User:JamesCraig\|James Craig]]		* 2007-03-28 raised by [[User:JamesCraig\|James Craig]]
	*#[[internationalization\|Internationalization]] <span id="fn-opt-i18n">(i18n) issue for implied optimization of FN</span>. Many languages (for example, Japanese) often list FN as "family-name given-name" instead of the assumed "given-name family-name" in English and other Western languages. There should be a affordance to indicate the order ''or'' a note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time.		*#[[internationalization\|Internationalization]] <span id="fn-opt-i18n">(i18n) issue for implied optimization of FN</span>. Many languages (for example, Japanese) often list FN as "family-name given-name" instead of the assumed "given-name family-name" in English and other Western languages. There should be a affordance to indicate the order ''or'' a note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time.
	# ACCEPTED. Tantek [[to-do]]: add internationalization section in [[hcard\|hCard]] spec, and note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time. In particular, the fn implied n optimization should be limited to fn properties which themselves are on elements that are on a whitelist of Western languages that typically publish with "given-name family-name" order, such as "en" (add others as confirmed by i18n experts). fn elements of other languages should not imply this optimization.		# ACCEPTED. Tantek [[to-do]]: add internationalization section in [[hcard\|hCard]] spec, and note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time. In particular, the fn implied n optimization should be limited to fn properties which themselves are on elements that are on a whitelist of Western languages that typically publish with "given-name family-name" order, such as "en" (add others as confirmed by i18n experts). fn elements of other languages should not imply this optimization. When the optimization is not implied, then the n property is left as is - if it were otherwise empty, it is left empty.
	* 2007-03-31 raised by [[User:AndyMabbett\|Andy Mabbett]]		* 2007-03-31 raised by [[User:AndyMabbett\|Andy Mabbett]]
	*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman\|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett\|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)		*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman\|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett\|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)

← Older revision		Revision as of 03:35, 11 March 2010
Line 166:		Line 166:

	* 2007-03-28 raised by [[User:JamesCraig\|James Craig]]		* 2007-03-28 raised by [[User:JamesCraig\|James Craig]]
	*#[[internationalization\|Internationalization]] (i18n) issue for implied optimization of FN. Many languages (for example, Japanese) often list FN as "family-name given-name" instead of the assumed "given-name family-name" in English and other Western languages. There should be a affordance to indicate the order ''or'' a note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time.		*#[[internationalization\|Internationalization]] <span id="fn-opt-i18n">(i18n) issue for implied optimization of FN</span>. Many languages (for example, Japanese) often list FN as "family-name given-name" instead of the assumed "given-name family-name" in English and other Western languages. There should be a affordance to indicate the order ''or'' a note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time.
	# ACCEPTED. Tantek [[to-do]]: add internationalization section in [[hcard\|hCard]] spec, and note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time.		# ACCEPTED. Tantek [[to-do]]: add internationalization section in [[hcard\|hCard]] spec, and note in the spec indicating that the two-word FN is a shorthand for Western languages and any languages not fitting this format should explicitly define "family-name" and "given-name" every time. In particular, the fn implied n optimization should be limited to fn properties which themselves are on elements that are on a whitelist of Western languages that typically publish with "given-name family-name" order, such as "en" (add others as confirmed by i18n experts). fn elements of other languages should not imply this optimization.

	* 2007-03-31 raised by [[User:AndyMabbett\|Andy Mabbett]]		* 2007-03-31 raised by [[User:AndyMabbett\|Andy Mabbett]]
	*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman\|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett\|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)		*# The [http://en.wikipedia.org/wiki/World_Geodetic_System WGS84 scehma] used as a default by <code>geo</code> will not remain valid forever. Fortunately, the proposed [[geo-extension-strawman\|geo extension]], originally intended for lunar/ Martian coordinates, also provides a facility for the specification of other, Earth-bound schema, which will alleviate this problem. [[User:AndyMabbett\|Andy Mabbett]] 13:00, 31 Mar 2007 (PDT)