Microformats Wiki - User contributions [en]

implementations

2007-11-06T01:13:40Z

RalfEngels: /* Applications / Plugins / Services / Tools */

<h1>Microformats Implementations and Implementers</h1>
{{TOC-right}}
This page lists the applications, plugins, sample code, services, tools that produce or consume microformats as well as companies, developers, and organizations who implement the aforementioned. This is only a partial list. If you know other companies implementing tools for microformats, please add them and list their services/tools and what specific microformats they support.

== Implementations vs. Examples in the Wild ==
This page is ''only'' for implementations of tools that publish or consume microformats. Companies simply ''using'' microformats on their pages/sites belong in the "Examples in the wild" sections of those respective microformats, e.g.:
* [[hcard-examples-in-wild|hCard Examples in the wild]]
* [[hcalendar-examples-in-wild|hCalendar Examples in the wild]]
* etc.

== Editing This Page ==
When you find an implementation, first make sure that it is ''actually'' an implementation as opposed to ''just'' an [[hcard-examples-in-wild|example in the wild]] of publishing microformats (see above).

Second, note the name of the ''tool or service'' separately from the name of the ''developer(s)'' who wrote the tool/service.

Add a third level heading with the name of the tool/service ( <code>=== Name of Tool ===</code> ) to the Applications / Plugins / Services / Tools section, sorted alphabetically by name of tool/service. Add a top level list item (*) just below the heading with an external link to the tool/service, along with a link to evidence of their support for microformats, and mention (and locally link) each microformat that is supported.

Add a nested list item <code>* by Name of Developer</code> and local to wiki hyperlink the Name of Developer to a fragment identifier in the [[implementors]] page, e.g. Apple Computer would be linked like this: <code><nowiki>[[implementors#Apple_Computer|Apple Computer]]</nowiki></code>

Check to see if there is an entry for the developer in the [[implementors|list of implementors]], if not add them there. Add a link to the developer's home page followed by "has implemented microformats in:".

In the entry for the developer, add a list item <code>* Name of Tool</code> and local to wiki hyperlink the Name of Tool to a fragment identifier in this page, e.g. X2V would be linked like this: <code><nowiki>[[implementations#X2V|X2V]]</nowiki></code>

Save the page and make sure that each fragment ID local hyperlink when clicked scrolls you to the right spot (for the developer, and for the tool). Make any fix-up edits as necessary. That's it!

== Reporting Bugs ==
In short, [[put-it-on-the-wiki]]. In particular, add bug reports, with URL(s) to a valid demonstrative test case(s) of course, to the listing of an implementation on this page, OR on the specific implementations wiki page (e.g. [[hcard-implementations]]). Please describe why you think it is a bug (user interface, cosmetic, violates a spec page, e.g. for problems parsing hCards, reference which part of [[hcard-parsing]] the implementation appears to not be following).

If you have a sense of urgency for getting that particular bug fixed in that implementation, you may email [http://microformats.org/discuss/ microformats-dev] with the URL of that implementation on the wiki page, and *summarize* the bug (the full description being on the wiki page instead).

== Formats ==
Most microformat specifications have an "implementations" section, e.g.:
*[[rel-tag#Implementations|rel-tag implementations]]
*[[vote-links#Implementations|vote-link implementations]]
*[[xoxo#Implementations|XOXO implementations]]

In addition, some microformat specifications have separate implementation pages:
*[[hcalendar-implementations|hCalendar implementations]]
*[[hcard-implementations|hCard Implementations]]
*[[xfn-implementations|XFN implementations]]

== Applications / Plugins / Services / Tools ==
This is an alphabetical listing of all applications, plugins (grouped with their app/tool), services and tools that implement microformats, along with the list of microformats that are supported, and the company and/or developers responsible for it.

As a user, the implementations listed below will automatically help you use microformats and help your data portability and interoperability with other apps and services.

Please help complete this list! If you know of additional apps/plugins/services/tools that support microformats, please add them!

Note: this section is only for listing specific ''implementations''. The list of ''implementors'' is in the [[implementors#Companies / Developers / Organizations|Companies / Developers / Organizations]] section on the [[implementors]] page.

=== Tomota ===
* The [http://www.tomota.de Tomota] allows import, export and conversion from and to hcards.
** by [[implementors#RalfEngels|Ralf Engels]]

=== .Mac Webmail ===
* The [http://www.mac.com/webmail .Mac Webmail] ''service'' now [http://factoryjoe.com/blog/2006/10/28/apple-embraces-microformats-in-new-mac-webmail/ supports hcard].
** by [[implementors#Apple_Computer|Apple Computer]]

=== AlchemyPoint ===
* [http://www.orch8.net/ AlchemyPoint] is a structured web / mashup platform that supports parsing hCard, rel-tag and other microformats.
** by [[implementors#Orchestr8|Orchestr8]]

=== Blinksale ===
* [http://blinksale.com Blinksale] uses [[hcard|hCard]] standard throughout for people and companies.

=== BlogMatrix ===
* [http://www.blogmatrix.com BlogMatrix] - user information marked as [[hcard|hCard]], tag directories in [[xfolk]]/[[rel-tag]], enclosures are marked as [[rel-enclosure]].
** by [[implementors#David_Janes|David Janes]]

=== Blogmarks.net ===
* [http://www.blogmarks.net Blogmarks.net] publish user bookmarks in [[xfolk]]/[[rel-tag]].

=== cmSiteNavigation ===
* [http://www.christophm.de/software/firefox/cmSiteNavigation/ cmSiteNavigation] extension for Firefox make use of links marked with a [[existing-rel-values|"rel" value]], and parses additional link types also.

=== Community Server ===
* [http://communityserver.org Community Server] supports tagging posts with [[rel-tag]], implements [[rel-nofollow]] on links in comments, and allows users to create link lists using [http://gmpg.org/xfn/ XFN].

=== Conferenceer ===
* Built for SXSW 2007, [http://sxsw07.conferenceer.com/ Conferenceer] supports hcalendar and hcard.

=== Citycita===
* [http://www.citycita.org Citycita] supports [[hCal|hCal]] in all event pages for local social groups.
** by [[implementors#Rubio_Jamin|Rubio Jamin]]

=== Cork'd ===
* [http://corkd.com Cork'd] supports [[hcard|hCard]] for user profiles, [[hreview|hReview]] for wine reviews, along with [[rel-tag]] for tagging wines as announced in [http://www.simplebits.com/notebook/2006/06/10/wineformats.html Pairing Wine and Microformats]
** by [[implementors#Dan_Cederhold|Dan Cederholm]]

=== Delicious Generation ===
* [http://deliciousgeneration.com/ Delicious Generation] supports [[hCal|hCal]] for the event and [[hcard|hCard]] for sponsors and people.
** by [[implementors#Chris_Messina|Chris Messina]]

=== Dreamweaver ===
==== Microformats Extensions ====
* [http://www.webstandards.org/action/dwtf/microformats Dreamweaver Microformats Extensions] ([http://allinthehead.com/beta/microformats.mxp.zip download]) support authoring [[hcard|hCard]], [[hcalendar|hCalendar]], [http://gmpg.org/xfn XFN], [[rel-tag]], [[rel-license]] as [http://allinthehead.com/retro/282/microformats-in-dreamweaver announced by Drew]
** by [[implementors#Drew_Mclellan|Drew McLellan]]

=== Drupal ===
==== Upcoming module for Drupal ====
* [http://hybernaut.com/upcoming-module Drupal Upcoming.org syndication module] emits [[hcalendar|hCalendar]]
** by [[implementors#Brian_Del_Vecchio|Brian Del Vecchio]]

=== Etnies ===
* [http://etnies.com/extra/calendar/ Etnies Calendar] supports hcalendar. Maybe the [http://thecolab.com/blog/2007/01/22/etniescom-relaunch/ first skate-shop to support microformats].

=== Eventful ===
* [http://eventful.com Eventful] supports [[hcalendar|hCalendar]] for over 1,000,000 event listings and [[hcard|hCard]] for venues.

=== Ficlets ===
* [http://ficlets.com Ficlets] supports [[hcard]] for author data and [[hatom]] for stories and lists of stories.
** [http://sixtwothree.org Jason Garber] and [http://lawver.net Kevin Lawver] for [http://aol.com AOL]

=== Finetoothcog ===
* [http://finetoothcog.com/site/stolen_bikes Stolen Bikes] now supports [[hcalendar|hCalendar]] for reported stolen bikes. Also provides iCal subscription.

=== Firefox ===
* See [[firefox-extensions]]

=== FunAdvice ===
* [http://funadvice.com FunAdvice] supports using the rel-nofollow tag to prevent users posting content simply for the search engine benefit, to improve teh quality of the advice giving community.

=== Gravatar Commenters as hCards ===
* [http://thedredge.org Andy Hume] added code to his blogging software to automatically mark-up the names and URLs of commenters on his blog with [[hcard|hCard]].
** by [[implementors#Andy_Hume|Andy Hume]]
** Andy - any chance of open sourcing your code to turn Gravatars into hCards?

=== Flickr People ===
* [http://flickr.com/ Flickr]'s profiles on its people pages supports both [[hcard|hCard]] and [http://gmpg.org/xfn XFN].
** by [[implementors#Cal_Henderson|Cal Henderson]]
**[http://flickr.com/people/tantek example]

=== Flickr Photos ===
* [http://flickr.com/map/ Flickr's geo tagged photos] are marked up with the [[geo]] microformat.

=== Flock Web Browser ===
* The [http://flock.com Flock web browser] supports the [[rel-tag]] microformat.
** by [[implementors#Flock|Flock]]

=== Google Search ===
* [http://google.com/ Google Search] - supports [[rel-nofollow]]
** by [[implementors#Google|Google]]

=== Google Blogger ===
* [http://blogger.com/ Blogger] supports [[hatom|hAtom]] (citation to blog post needed - 2007)
** by [[implementors#Google|Google]]

=== Google Creative Commons Search ===
* [http://www.google.com/webhp?as_rights=(cc_publicdomain%7Ccc_attribute%7Ccc_sharealike%7Ccc_noncommercial%7Ccc_nonderived) Google Creative Commons Search] - supports [[rel-license]]
** by [[implementors#Google|Google]]

=== Google Maps ===
* [http://maps.google.com/ Google Maps] supports [[hcard|hCard]] (see [http://googlemapsapi.blogspot.com/2007/06/microformats-in-google-maps.html 2007-06-31 announcement by Google])
* Google maps also allows reviewers and map creators to [http://maps.google.com/maps/me attach a public profile], which includes hCard and rel="me' XFN markup. See [http://google-latlong.blogspot.com/2007/10/put-yourself-on-map.html 2007-10-17 announcement]. Sample profile: [http://maps.google.com/maps/user?uid=109581870574956225297 Kevin Marks].
** by [[implementors#Google|Google]]
**Unfortunately, [http://microformats.org/discuss/mail/microformats-discuss/2007-July/010311.html Google Map's implementation is broken]. [http://microformats.org/discuss/mail/microformats-discuss/2007-August/010457.html Google are aware; a fix is awaited].
** Also, there is no hCard nor any XFN rel values on the [http://maps.google.com/maps/user?uid=109581870574956225297 sample profile] itself, it appears to include a [http://maps.google.com/maps/c/widgets/ProfileViewer?js=RAW&maximize=true&hide=false&width=40&noTitle=true&theme=theme_2&service=local&uid=109581870574956225297&height=0&background=transparent&serverbased=true&border=NONE&eventCallback=ParentStub1192999211538&zx=dc574o15j0wrv frame] which then has an hCard and rel="me" to the user's blog.

=== Greasemonkey ===
* [http://greasemonkey.makedatamakesense.com/google_hcalendar/ Google hCalendar] - Adds hCalendar data to Google Calendar.
* [http://www.nickpeters.net/?p=35 Social xFolk] - Adds xFolk links to social bookmarking sites del.icio.us and ma.gnolia.

=== hCalendar creator ===
* [http://microformats.org/code/hcalendar/creator hCalendar creator] (originally [http://theryanking.com/microformats/hcalendar-creator.html published by Ryan King]) is a javascript form for creating [[hcalendar|hCalendar]] events.
** by [[implementors#Ryan_King|Ryan King]]

=== hCard creator ===
* The open source [http://microformats.org/code/hcard/creator hCard creator] (originally [http://tantek.com/microformats/hcard-creator.html published by Tantek]) is a very simple, yet illustrative, open source user interface / form / script which creates an [[hcard|hCard]] in real-time as you type in a set of contact information.
** by [[implementors#Tantek_Çelik|Tantek Çelik]]

=== hKit Microformats Toolkit for PHP5 ===
* [http://allinthehead.com/hkit hKit Microformats Toolkit for PHP5] as [http://allinthehead.com/retro/291/hkit-microformats-toolkit-for-php announced by Drew McLellan]. See also [[hkit|hKit on this wiki]].

=== hReview creator ===
* [http://microformats.org/code/hcalendar/creator hReview creator] (originally [http://theryanking.com/microformats/hreview-creator.html published by Ryan King]) is a javascript form for creating [[hreview|hReviews]].
** by [[implementors#Ryan_King|Ryan King]]

=== Ice Rocket ===
* [http://icerocket.com] - [http://blogs.icerocket.com/tag/ supports] [[rel-tag]]

=== iChat buddy list to hCards ===
* [http://tantek.com/microformats/buddylist2hcards.html iChat buddy list to hCards] - open source AppleScript to automatically convert one's buddy list in the MacOSX iChat AIM client into a valid XHTML 1.0 Strict list of hCards.
** by [[implementors#Tantek_Çelik|Tantek Çelik]]

=== Internet Explorer ===
* See [[internet-explorer-extensions]]

=== JobiJoba ===
* [http://www.jobijoba.com JobiJoba : moteur de recherche emploi] parses and supports [[hCard|hCard]] and [[rel-tag|rel-tag]] for over 40,000 job listings.

=== JSCalendar ===
* [http://web.mit.edu/glasser/www/JSCalendar/ JSCalendar] parses [[hcalendar|hCalendar]] and produces a displayable HTML table/CSS-based calendar.

=== Konqueror ===
* [http://www.konqueror.org/ Konqueror] - [http://flickr.com/photos/factoryjoe/68755089/ supports] [[hcard|hCard]]

=== Last.fm ===
* [http://last.fm Last.fm] - [http://factoryjoe.com/blog/2006/10/31/lastfm-adds-support-for-hcalendar/ Last.fm supports] [[hcalendar|hCalendar]]

=== LouderVoice ===
* [http://www.loudervoice.com Publishes and aggregates hreview content] - The LouderVoice site provides a variety of tools to publish hreview to blogs and it also aggregates hreview content from any registered RSS Feed so that users can search/rate/collect distributed reviews.

=== Laughing Squid Calendar ===
* The [http://laughingsquid.com/squidlist/calendar/ Laughing Squid Calendar] events listings support [[hcalendar|hCalendar]].
** by [http://laughingsquid.com/ Laughing Squid]

=== LinkedIn ===
* [http://www.linkedin.com LinkedIn] - LinkedIn includes [[hcard|hCard]] and [[xfn|XFN]] on contacts, [[hresume|hResume]] for public profiles and [[hreview|hReview]] on service provider recommendations

=== Live Clipboard ===
* [http://spaces.live.com/editorial/rayozzie/demo/liveclip/liveclipsample/techPreview.html Live Clipboard Technical Introduction]
* [http://spaces.live.com/editorial/rayozzie/demo/liveclip/liveclipsample/clipboardexample.html Live Clipboard Example]

=== LiveJournal ===
* [http://www.livejournal.com LiveJournal]
** supports tagging posts with [[rel-tag]]
** supports [[hcard-supporting-user-profiles|hCard user profiles]] and [[XFN]] ([http://community.livejournal.com/lj_releases/24768.html 2007-09-27 release #15]).

=== LJFind ===
* [http://www.ljfind.com LJ-Find] - LJFind supports tagging posts with [[rel-tag]].

=== Ma.gnolia ===

* [http://ma.gnolia.com Ma.gnolia] has wide [http://wiki.ma.gnolia.com/Ma.gnolia_Feeds_Guide#Microformats support for a variety of microformats] including [[rel-tag]], [[xfolk]], [[hreview]], [[xfn]] and [[hcard]].

=== Maxthon ===
[http://maxthon.com Maxthon] is a browser for Microsoft Windows that uses the Trident rendering engine and provides additional user interface. Maxthon has built and published a plugin for their browser that recognizes microformats in web pages and allows users to take action with them, similar to Operator for [[Firefox]].
* [http://forum.maxthon.com/index.php?showtopic=65408 Microformats Button Version 1.0.0 Release Candidate 1]
** Description: "Microformats Button extracts Microformats from websites and allows you to export the data to vCard, vCalendar, Google Maps, Yahoo Maps and other sites."

=== Microformat Base ===
* [http://randomchaos.com/microformats/base/ Microformat Base]
** by [[implementors#Scott Reynen|Scott Reynen]]

=== Microformat Bookmarklet Overlay ===
* [http://leftlogic.com/info/articles/microformats_bookmarklet Microformats Bookmarklet] for Safari, Firefox and Camino, supports [[hcard|hCard]] and [[hcalendar|hCalendar]] and allows the user to import individual microformats on the fly.
** by [[implementors#Remy_Sharp|Remy Sharp]]

=== Microformat Parser for Ruby ===
* [http://blog.labnotes.org/2005/11/20/microformat-parser-for-ruby/ Microformat Parser for Ruby]
** by [[implementors#Assaf Arkin|Assaf Arkin]]

=== MyMap.yam.com ===
* support [[geo]] microformat in the POI page. example: [http://mymap.yam.com/place/point/charleschuang/6695/ a book store in Tamsui].

=== National eXtension Initiative ===
* [http://www.extension.org/ eXtension Home] - content marked-up with [[hatom|hAtom]] and events marked-up as [[hcalendar|hCalendar]] entries.
** by [[implementors#James E. Robinson, III|James E. Robinson, III]]

=== Nature Network Boston ===
* [http://network.nature.com/boston/ Nature Network Boston], a social networking community for scientists, supports [[reltag|rel-tag]], [[hcard|hCard]] for user profiles and [[hcalendar|hCalendar]] for marking up events across the site.
** by [[implementors#Nature Publishing Group|Nature Publishing Group]]

=== Nature Protocols ===
* [http://www.nature.com/nprot/ Nature Protocols], a forum for scientists to upload and comment on protocols, supports [[hcard|hCard]] and [[XOXO]].
** by [[implementors#Nature Publishing Group|Nature Publishing Group]]

=== NetNewsWire ===
*[http://www.newsgator.com/Individuals/NetNewsWire/ NetNewsWire] is an easy-to-use RSS and Atom reader for your Mac. NetNewsWire 3.0 detects, extracts and converts hcard and hcalendar data from feed entries.
** by [[implementors#NewsGator|NewsGator]]

=== Nutch ===
* [http://www.mail-archive.com/nutch-dev@lucene.apache.org/msg01295.html rel-nofollow support added]
* [http://www.mail-archive.com/nutch-commits@lucene.apache.org/msg01014.html rel-tag support checked in]

=== ODEO ===
* [http://odeo.com/ ODEO] [http://odeo.com/blog/2005/07/adding-microformats-to-odeo.html noted] that they support microformats: [[rel-tag]], [[rel-enclosure]], [http://gmpg.org/xfn XFN].

=== Optimus ===
*[http://microformatique.com/optimus/ Optimus]. Output formats: XML, JSON, JSON-P.

=== phpMicroformats ===
* [http://enarion.net/phpmicroformats/ phpMicroformats] is a PHP class library that generates microformat entries for [[hcalendar|hCalendar]] and [[hcard|hCard]]. It is released under GPL.

=== PostNuke ===
''[http://www.postnuke.com PostNuke] is an Application Framework/Content Management Systeme''
* [http://www.pagesetter.net/index.php?module=pagesetter&func=viewpub&tid=4&pid=96 hCards4Pagesetter] - hCards Publication Type for the PostNuke module "Pagesetter"
* [http://www.pagesetter.net/index.php?module=pagesetter&func=viewpub&tid=4&pid=97 hCalendar4Pagesetter] - hCalendar Publication Type for the PostNuke module "Pagesetter"
* [http://www.pagesetter.net/index.php?module=pagesetter&func=viewpub&tid=4&pid=98 hReview4Pagesetter] - hReview Publication Type for the PostNuke module "Pagesetter"
* [http://noc.postnuke.com/frs/?group_id=256&release_id=477 Blogroll] - XFN Block/Modul
* [http://noc.postnuke.com/frs/?group_id=256&release_id=628 nofollow] - nofollow Hook

=== Profiler ===
* [http://microformat.makedatamakesense.com/profiler/ Profiler] works as a proxy service adding microformat profiles to documents that appear to contain microformats.

=== RFC2629.xslt ===
* [http://greenbytes.de/tech/webdav/rfc2629.xslt rfc2629.xslt] now attempts to generate [[hcard|hCard]] information ([http://ietf.org/rfc/rfc2629 RFC2629] in an XML format for authoring RFCs and Internet Drafts, see [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html example document])

=== Salesforce ===
* [http://salesforce.com Salesforce] [http://flickr.com/photos/kingsleyj/175689109/ supports] [[hcard|hCard]]
** by [http://flickr.com/people/kingsleyj/ Kingsley Joseph]
==== Spanning Salesforce ====
* [http://spanningsalesforce.com/ Spanning Salesforce] supports [[hcalendar|hCalendar]].

=== Sivitools ===
<blockquote>
Sivitols is a Java library for microformats. Currently only the xFolk RC1 standard is implemented, but additional microformat support is planned. This library is being written and maintained for a tag sharing project undertaken by Video Vertigo.
</blockquote>
[http://blog.blip.tv/blog/microformats/ Annoucement], [http://pokkari.com/microformat/javadoc/ Docs]

=== SPRACI ===
* [http://www.spraci.com SPRACI] - nightlife/events - [[hcalendar|hCalendar]] published in events listings, aggregator can read hCalendar

=== stuckUnstuck ===
* [http://stuckunstuck.com stuckUnstuck] supports [[hcard|hCard]] and [[hatom|hatom]].

=== Sunnyvale House Concerts ===
* [http://concerts.shrub.ca/shows Sunnyvale House Concerts] supports [[hcard|hCard]] and [[hcalendar|hCalendar]].

=== Technorati Contacts Feed Service ===
* [http://feeds.technorati.com/contacts/ Technorati Contacts Feed Service] is a deployment of [[implementations#X2V|X2V]] to convert [[hcard|hCards]] to vCard (.vcf) format.
** by [[implementors#Technorati|Technorati]]

=== Technorati Events Feed Service ===
* [http://feeds.technorati.com/events/ Technorati Events Feed Service] is a deployment of [[implementations#X2V|X2V]] to convert [[hcalendar|hCalendar]] events to iCalendar (.ics) format.
** by [[implementors#Technorati|Technorati]]

=== Technorati Microformats Search ===
* Technorati [http://kitchen.technorati.com/search/ Microformats Search]. Search for contacts ([[hcard|hCard]]), events ([[hcalendar|hCalendar]]), or reviews ([[hreview|hReview]]) published on blogs and other web sites.
** by [[implementors#Ryan_King|Ryan King]]
** first version (2006 May) by [[implementors#Tantek_Çelik|Tantek Çelik]], [[implementors#Ryan_King|Ryan King]], [[implementors#Kevin_Marks|Kevin Marks]], [[implementors#Josh_Smith|Josh Smith]]

=== Technorati Search ===
* [http://technorati.com/ Technorati] [http://technorati.com/search Search] supports and handles both [[vote-links]] and [[rel-nofollow]] for indicating whether a link should have any/positive/negative weighting towards the destination.
** by [http://technorati.com/about/staff.html Technorati Staff]
=== Technorati Tags ===
* [http://technorati.com/tags/ Technorati Tags] pages aggregate blog posts tagged with the [[rel-tag]] open tagging standard, in addition to recent tagged photos and links.

=== Textpattern ===
==== Microformats Plugin ====
* [http://placenamehere.com/TXP/pnh_mf/ Textpattern Microformats Plugin] supports authoring [[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [http://gmpg.org/xfn XFN], [[rel-tag]], [[rel-license]] in the [http://www.textpattern.com/ Textpattern] CMS/blogging tool
** by [http://placenamehere.com/ Chris Casciano]

=== TYPO3 ===
* [http://www.typo3.com TYPO3], [http://typo3.org TYPO3 Developer Ressource]
==== tt_address extension====
* [http://typo3.org/extensions/repository/view/tt_address/2.0.1/ tt_address] - hCard support with the tt_address extension version 2.0.0
** by [[implementors#Ingo_Renner|Ingo Renner]]
==== TIMTAB extension====
* [http://typo3.org/extensions/repository/view/timtab/0.5.11/ TIMTAB] - XFN support for blogrolls with the TIMTAB weblog extension for TYPO3
** by [[implementors#Ingo_Renner|Ingo Renner]]

=== Twitter ===

* [http://twitter.com Twitter] [http://twitter.com/al3x/statuses/53982402 supports] [[hatom|hAtom]], [[hcard|hCard]], and [http://gmpg.org/xfn XFN].

=== Upcoming.org ===
* [http://upcoming.org Upcoming.org] - hCalendar support in events listings and individual events.
** by [[implementors#Andy_Baio|Andy Baio]], [[implementors#Leonard_Lin|Leonard Lin]], [[implementors#Gordon_Luk|Gordon Luk]]

=== vCardExplorer ===
* [http://vcardexplorer.corefault.de/ vCardExplorer for MacOSX] - browses local vcards and converts hcards from URLs.

=== WindowsLiveWriter ===
* [[implementors#Microsoft|Microsoft's]] WindowsLiveWriter (WLW) [http://gallery.live.com/liveItemDetail.aspx?li=9751e563-1408-4fc3-8028-bd4351edb1fb&l=8 event plugin] supports [[hcalendar|hCalendar]].

=== WordPress ===
* [http://wordpress.org WordPress] supports [http://gmpg.org/xfn/ XFN] blogrolls through a very nice built-in user interface. (cf. [[xfn-implementations]])
** by [[implementors#Matt_Mullenweg|Matt Mullenweg]] and friends

==== WP Microformatted Blogroll ====
* The [http://factorycity.net/projects/wp-microformatted-blogroll/ WP Microformatted Blogroll 0.2] Wordpress plugin by [[implementors#Chris_Messina|Chris Messina]] supports [[hcard|hCard]] and [http://gmpg.org/xfn/ XFN].

==== VoteBack Plugin ====
* [http://redmonk.net/archives/2006/12/21/voteback/ VoteBack plugin for Wordpress] - checks incoming pingbacks and trackbacks for [[votelinks]].

==== Save Microformats Plugin ====
* [http://notizblog.org/projects/save-microformats/ Save Microformats plugin for Wordpress] - a plugin to save posted Microformats using technorati feeds.

==== WP Themes ====
* [http://www.plaintxt.org/themes/sandbox/ Sandbox] is a theme for Wordpress that uses [[hatom|hAtom]].
** The theme is also available to accounts on the <username>.wordpress.com hosting service.
* [http://www.jesuscarrera.info/proyectos/startpoint/ StartPoint] A theme for theme developers. A good start point to make your own templates. It supports multiple languages, widgets, contains semantic hAtom microformats, and more.
* [http://www.whump.com/dropbox/Strangelove.zip Strangelove] is a modification of the default Wordpress theme (Kubrick) with [[hatom|hAtom]] support.
** It points to the hAtom2Atom proxy service as the link for syndication feeds.

=== X2V ===
* Brian Suda has created several XSLT files to extract microformats from HTML. From that the [http://suda.co.uk/projects/X2V/ X2V] webservice/favelet emerged. The XSLT and favelet extracts [[hcard|hCard]] and to produces .vcf (vCard) files and [[hcalendar|hCalendar]] to produce .ics (iCal) files. Also in the labs is a universal XMDP validator and a site-wide search spider that recognizes 'no-follow', 'license' and other microformats so they can be used in a more semantic way when displaying search results.
** by [[implementors#Brian_Suda|Brian Suda]]

=== XWiki ===
* [http://xwiki.org XWiki] (as of [http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXWiki10Beta5 version 10Beta5]) publishes the user profiles using [[hcard | hCard]], the events in the calendar application using [[hCalendar | hCalendar]], the blog entries using [[hAtom | hAtom]] and homepage links using [[rel-home | rel-home]].

=== Yahoo Creative Commons Search ===
* [http://search.yahoo.com/cc/ Yahoo Creative Commons Search] - supports [[rel-license]] specifically to search for Creative Commons licensed content.

=== Yahoo Local ===
* [http://local.yahoo.com Yahoo local] supports [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]].

=== Yahoo Tech ===
* [http://tech.yahoo.com Yahoo! Tech] supports [[hreview|hReview]].

=== Yahoo UK Movies ===
* [http://movies.yahoo.co.uk Yahoo! UK Movies] supports [[hreview|hReview]].
** by Mark Norman Francis

=== Yedda ===
* [http://yedda.com Yedda] supports [[hcard|hCard]] for exposing users information, [[hatom|hAtom]] for exposing data that is already exposed via feeds (like list of questions and answers) and [[rel-tag|rel-tag]] for every tag used to tag questions and users.

== Validators ==
This is an alphabetical listing of tools that have been created to validate implementations, and which formats they support.

Please add to this section if you have a validator/checker, no matter which or how many microformats you test for.

=== rel-lint ===
* [http://tools.microformatic.com/help/xhtml/rel-lint/ rel-lint] supports validation of [[rel-tag|rel-tag]] and [[xfn|XFN]]
* by [[implementors#Drew_McLellan|Drew McLellan]]

== Companies / Developers / Organizations ==

See [[implementors]]

The following have been moved from the sections above due to problems, stated below:

=== Web Essentials ===
* [http://we05.com/ Web Essentials] - supports [[hcard|hCard]] and [[hcalendar|hCalendar]], e.g. in their [http://we05.com/presenters.cfm list of presenters] and [http://we05.com/program.cfm program schedule].
** John McKerrell tried to look at the site on 24th October 2006 but could not access the site, server didn't seem to be up.

== Other ==
Some notes on initial thoughts around [[implementation-guidelines|Guidelines and Strategies for Implementing Microformats]]

hcard-implementations

2007-11-06T01:07:58Z

RalfEngels: /* Web Services */

<h1>hCard Implementations</h1>
{{TOC-right}}

This page is an '''informative''' section of the [[hcard|hCard specification]].

The following implementations have been developed which either generate or parse [[hcard|hCards]]. If you have such an hCard implementation, feel free to add it to '''the top''' of the New Implementations section. If you have a page or site which just ''publishes'' hCards, please use [[hcard-examples-in-wild]] instead.

== New Implementations ==
Add new implementations here for evaluation and classification into the below taxonomy of implementations.
* [[org.microformats.hCard]] - java hCard parser and creator.
* [http://mobileonlinebusiness.com.au/uf/vCard_to_hCard_converter.html Mobile Online Business' vCard to hCard converter]
*[http://www.jamplanet.com Jam] is an active address book extension for Firefox/Flock. Jam imports Vcard and various CSV formats, and can output contacts in Vcard and hCard format.
*The "[http://typo3.org/extensions/repository/view/tt_address/2.0.1/ tt_address]" extension for [http://www.typo3.com TYPO3] supports hCard since the latest release, v2.0.0
*[https://addons.mozilla.org/firefox/4106/ Operator] lets you combine pieces of information on Web sites with applications in ways that are useful. (Firefox-plugin)
*[http://rafaeloliveira.net/labs/hcard_creator.zip Wordpress hCard Creator] - I've made this simple plugin for wordpress. It adds the hCard Options submenu at Options menu, where you can create a simple hCard and put it on your blog using < ?php hcard_creator() ?> to show it. Also, it is possible to show an "export to vCard" link, which uses Brian Suda X2V. (Got send an e-mail to him regarding this)
*[http://www.alexa.com/site/devcorner/hcard Alexa hcard search]
*[http://leftlogic.com/lounge/articles/microformats_bookmarklet/ Microformats Bookmarklet] is a bookmarklet designed for IE6 and IE7, Firefox, Safari, Opera and Camino, that overlays on the current page to allow users to import individual hCards or hCalendars. Written by Remy Sharp.
*[http://domanske.de/2006/09/vcardexplorer-04/ vCardExplorer] is a Mac OS X Application, that displays VCF-Files and extracts hCards from Websites written by [http://vcardexplorer.corefault.de Daniel Kagemann].
* [http://placenamehere.com/mf/nnwextract/ Extract Microformats] is a script for NetNewsWire that supports extracting hCard and hCalendar data in blog posts (via technorati service). Written by [[User:ChrisCasciano|Chris Casciano]]
* [http://allinthehead.com/hkit/ hKit] is an open source PHP 5 parsing library with support for hCard.
* [http://kitchen.technorati.com/search Technorati Microformats Search] indexes [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]] as [http://tantek.com/log/2006/05.html#d31t1802 announced by Tantek].
** list of pages with indexing Issues so they can be looked into as to why data is not being extracted
** suda.co.uk/contact
** multipack.co.uk
* [http://www.webstandards.org/action/dwtf/microformats/ Dreamweaver Extension suite] from the [http://webstandards.org/ Web Standards Project] enables the authoring of hCards from within Dreamweaver 8.
* [http://scooch.gr0w.com/ Scooch] is a slide show and presentation creator that generates a [[hCard]] for individual slide show authors and comment authors with a CSS button to parse and download via [http://suda.co.uk/projects/X2V/ X2V]. Also uses [[hReview]] for slide ratings and [[rel-tag]] for categories.
* [http://blog.codeeg.com/2006/03/20/flock-tails-flocktails/ Flocktails] - port of Tails extension for Flock 0.5.12 that looks for hCards, hCalendar, xFolk and hReview and tosses them into a handy topbar
*[http://opensource.reevoo.com/2006/03/08/release-uformats-12/ uformats] is a ruby library that can parse [[hCalendar]], [[hCard]], [[hReview]] and [[rel-tag]]
* [http://blog.codeeg.com/tails-firefox-extension-03/ Tails] is a Firefox Extension that will display the presence and details of microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [[xfolk|xFolk]]) on a webpage. [https://addons.mozilla.org/firefox/2240/ Tails Export] is an extended version.
* [http://www.stripytshirt.co.uk/features/firefox/smartzilla Smartzilla is a Firefox Extension] that finds hCards on web pages and lets you add them to your addressbook.
* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] is a plugin for [http://textpattern.com/ Textpattern] that supports embedding hCard and other microformats in templates and blog posts. Written by [http://placenamehere.com/ Chris Casciano].
* There is [http://flickr.com/photos/factoryjoe/68755089/ evidence of built-in hCard support in the Konqueror browser]. Specifically, Konqueror 3.5, in KDE 3.5 (kubuntu Breezy w/ update).
* There is [http://tagcamp.org/index.cgi?ContactList evidence of a kwiki plugin for hCards]. Update: the [http://svn.kwiki.org/cwest/Kwiki-hCard/ hCard kwiki plugin svn repository]. See the [http://microwiki.caseywest.com/index.cgi?hCard documentation of the hCard kwiki plugin].
* [http://suda.co.uk/projects/X2V/ X2V] is a bookmarklet that parses hCard and produces a .vcf (vCard) stream. Note: needs to be updated as the spec is refined.
* [http://www.stripytshirt.co.uk Duncan Walker] has built [http://www.stripytshirt.co.uk/features/firefox/smartzilla a Firefox extension] that gets hCard data from a webpage, uses Brian Suda's XSL (locally) to transform it to vcard format and opens the resulting .vcf file.
* [http://george.hotelling.net/90percent/ George] has written a [http://george.hotelling.net/90percent/geekery/greasemonkey_and_microformats.php Greasemonkey user script] that detects hCards and allows users to easily add them to their address book application. Relies on the X2V web service to do the conversion.
* [http://inside.glnetworks.de/ Martin Rehfeld] has updated the work of [http://blogmatrix.blogmatrix.com/ David Janes] and produced a [[Greasemonkey]] [http://inside.glnetworks.de/2006/06/05/microformats-have-arrived-in-firefox-15-greasemonkey-06/ script] that finds many microformat elements, including hCards, and [http://blog.davidjanes.com/mtarchives/2005_08.html#003379 provides a popup menu of actions]. The hCard to vCard conversion is done internally within the script. ''This will work with FireFox 1.5+/GreaseMonkey 0.6.4+ now.''
* [http://diveintomark.org/ Mark Pilgrim] has also written an [http://diveintomark.org/projects/greasemonkey/hcard/ hCard parser Greasemonkey user script]. It is self-contained and does not rely on the X2V web service.
* [http://www.oliverbrown.me.uk/2005/09/03/a-working-microformats-extension-to-simplexml/ Oliver Brown] has written an "extension" to [http://www.php.net/simplexml SimpleXML] that gives simple access to hCard information in PHP 5.
* [http://thedredge.org/ Andrew D. Hume] has built a system (Wordpress plugin?) for [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hCards in your blog] to represent people leaving comments on blog posts.
* [http://greenbytes.de/tech/webdav/rfc2629.xslt rfc2629.xslt] now attempts to generate hCard information ([http://ietf.org/rfc/rfc2629 RFC2629] is an XML format for authoring RFCs and Internet Drafts, see [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html example document])
* [http://tantek.com/microformats/buddylist2hcards.html iChat buddy list to hCards] - Open source AppleScript to automatically convert one's buddy list in the MacOSX iChat AIM client into a valid XHTML 1.0 Strict list of hCards.
* [http://dev.w3.org/cvsweb/2001/palmagent/ palmagent] is a collection of palmpilot and sidekick tools. It includes X2V derivatives xhtml2hcard.xsl and toICal.xsl plus some [http://dev.w3.org/cvsweb/2001/palmagent/hcardTest.html hcardTest] materials
* [http://www.openpsa.org/ OpenPsa 2.x] CRM application uses hCard for all person listings. The widget is [http://www.midgard-project.org/midcom-permalink-922834501b71daad856f35ec593c7a6d reusable across Midgard CMS]
* [http://www.metonymie.com Emiliano Martínez Luque] has written an experimental [http://www.metonymie.com/hCard_extract/app.html hCard finder and structured search application] that finds hCards within a given set of URLs and returns the ones that match the specified search criteria.


==Authoring==
Implementations you can use to author, create, and publish hCards.

===Web-based Creators===
;hCard Creator : [http://microformats.org/code/hcard/creator hCard creator] ([[hcard-creator-feedback|hCard creator feedback]]) - create your own hCards.
; ... :

===Blogging and CMS tools===
;Textpattern plug-in :
[http://euphemize.net/blog/plugins/textpattern/jmc_event_manager/ jmc_event_manager] is a plugin for [http://textpattern.com/ Textpattern] that outputs locations and events in hCard (and hCalendar) formats. Written by [http://euphemize.net/ Joel Courtney].
; ... :

===Browser scripts and plug-ins===
Browser plugins that work with existing authoring tools:
; Any browser with javascript and a little bit of CSS : [http://microformats.org/code/hcard/creator microformats.org hCard creator] (see also [http://tantek.com/ Tantek]'s original [http://tantek.com/microformats/hcard-creator.html hCard creator on tantek.com].

===Desktop Authoring Tools===
* ...

==Search and Discovery==
* [http://kitchen.technorati.com/search Technorati Microformats Search] indexes [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]] as [http://tantek.com/log/2006/05.html#d31t1802 announced by Tantek].
* [http://leftlogic.com/info/articles/microformats_bookmarklet Microformats Bookmarklet] is a bookmarklet designed for Safari (works in Firefox and Camino) that overlays on the current page to allow users to import individual [[hcard|hCards]] or [[hcalendar|hCalendars]]. Written by [http://leftlogic.com Remy Sharp].



==Conversion and Import==
Implementations you can use to importing into an address book application, typically by converting hCard to vCard.

===Web Services===
These return vCard (.vcf) and other contact formats for easy importing into typical address book programs or other processing.
* [http://www.tomota.de www.tomota.de] Online address book that allows to import, export and convert hCard into vCard, ldif, csv and plain text.

* ...

===Firefox Greasemonkey Plugins===
* ...

===Aggregators===
* ...

==Browsing==
Implementations that detect, display and otherwise highlight hCards in pages.
* ...

===Firefox extension===
* ...

====Pending====
* ...

===Flock extension===
* ...

==Open Source==
Open source libraries of hCard parsers and other related code for building hCard implementations. Note: it is very likely that above implementations may be duplicated in this section. That's ok.
* ...
;Javascript
: The [http://microformats.org/code/hcard/creator hCard creator] ([[hcard-creator-feedback|hCard creator feedback]]) is a very simple, yet illustrative, open source user interface / form / script which creates an hCard in real-time as you type in a set of contact information.

; PHP :
* [[hKit]]
; Java :
* [[org.microformats.hCard]]
; Ruby :
: ...
; XSLT :
* ...

== Additional Applications ==
This section should probably be incorporated into [[hcard-brainstorming]].

There are numerous potential additional uses and applications for hCards on the Web. The following are merely a few thoughts and possibilities that folks have come up with:

* As an open standard/format for [http://www.gravatar.com/ Gravatars].
** Like [http://alper.nl/cgi-bin/OpenAvatar.py?url=http://tantek.com this].
** Wordpress plugin with hCard based replacement for gravatar is in the make. [[User:Alper|Alper]] 12:59, 8 Aug 2007 (PDT)
* Marking up individual authors of blog posts on a group blog
* Marking up people's names and URLs in a blogroll
* Any reference to people in blog posts (e.g. when citing them, or referencing them, or describing them, by name).
* ...

== Related Pages ==
{{hcard-related-pages}}

hcard-issues

2007-11-05T21:04:12Z

RalfEngels: /* 2007 */

<h1> hCard issues </h1>

These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See also related [[hcalendar-issues]].

__TOC__

== Closed Issues ==
Resolved issues that have no further actions to take. These will likely be moved to a separate page like [[hcard-issues-closed]].

* ...

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items. As issues are resolved, they will be moved from the top of the [[hcard-issues#Issues|Issues list]] to the bottom of this section.

* 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.
*#* 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.

== Issues ==
Please add new issues to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2005 ===
* 2005-06-21 raised by Hixie
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCards must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
*#*A: ACCEPTED RESOLVED. See [[hcard-parsing]] for how hCards must be parsed. For errors/unexpected content/missing content, please provide specific examples.

* 2005-06-30 raised by Jack L. Wolfgang II. Please feel free to move these to the FAQs if they are better suited there.
*# ''Handling middle names and suffixes: How does one handle middle initials/names in the hCard format and suffixes that are not honorific suffixes (e.g. Jr., Sr., II, III, etc. as opposed to Ph.D., Esq., M.D., etc.)?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]; 2006-11-16 updated by [[User:AndyMabbett|Andy Mabbett]]) hCard is based of the RFC2426 spec. I you want to use a middle initial it can be expanded using the abbr element. <code><abbr title="[MiddleName]" class="additional-name">M</abbr></code>. Honorific Suffixes in the RFC include Jr., Esq. and other inherited suffixes, so I would just use <code><abbr class="honorific-suffix" title="Junior">Jr.</abbr></code> etc.
*# ''Handling different types of addresses: How does one handle the TYPE (e.g. postal, work, etc.) specification for addresses as specified in RFC 2426 Section 3.2.1?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]) If you want to add a type to certain elements, including address and telephone it may be done in the following manner:
<pre><nowiki>

work:
...

</nowiki></pre>
<pre><nowiki>

work:
123.456.7890

</nowiki></pre>
the TYPE needs to be a sub-element of the property (adr, tel, etc) NOTE: EMAIL does NOT have many TYPE attributes, only INTERNET and X400

* 2005-07-22 raised by DanConnolly
*# ''...in my cellphone/sidekick address book, I have a number of entries for companies. I wrote [http://dev.w3.org/cvsweb/2001/palmagent/asHCard.xsl asHCard.xsl] to convert the data from RDF to hCard, but I don't know what to do with entries for companies, since FN is mandatory in hCard.''
*#*A: ACCEPTED FAQ. This should be an FAQ. "How do I write an hCard for a company?" The vCard specification is silent on this point (entries for companies). Thus there are two options as far as the hCard standard is concerned:
*#*# Set "fn" and "org" to the same value. E.g. <code>W3C</code> (recommended)
*#*# Set "org" as usual, and set "fn" explicitly to empty. E.g. <code>W3C</code> or
*#*#* Simply have no "fn", and on the parsing side, if there is no "fn" present, but there is an "org" property, then duplicate the "org" value as "fn"
*#*The last two options are effectively the same and are both not explicit and easily confusable with a "missing data" condition. Thus option 1 is preferred. For converting applications (hCard to vCard), they ''may'' consider using proprietary extensions to make the distinction explicit in generated vCards, based on either case 1 or 2 above. E.g. Apple's Address Book application supports the property: <code>X-ABShowAs:COMPANY</code>
*#*We are looking for descriptions of how other vCard supporting applications treat "company" vCards differently from "person" vCards. Please provide descriptions here:
*#** Address Book / MacOSX.3:
*#*** Export (e.g. drag & drop to desktop, view in text editor)
*#**** Sets "FN" and "ORG" to the name of the company
*#**** Sets proprietary <code>X-ABShowAs:COMPANY</code>
*#*** Import (e.g. edit in text editor, drag & drop from desktop)
*#**** By setting "FN" and "ORG' to the same name (e.g. Banana Computers Inc.)
*#**** And removing any proprietary properties (e.g. X-ABShowAs)
*#**** Address Book user interface showed new vCard as a "company" contact rather an a person
*#** Address Book MacOSX.4:
*#*** same results as above -RyanKing
*#** The Danger Hiptop (aka T-Mobile Sidekick) address book:
*#*** Export (e.g. [http://lists.w3.org/Archives/Public/www-archive/2005Sep/0007.html email to a mailing list])
*#**** Sets "FN" to the empty string and puts the company name in "ORG".
*#*** Import - could not find a way to import a .vcf, by email, IM, or other means into the Sidekick.
*#** Contacts / Outlook 2003 Windows
*#*** Export (e.g. Highlight contact, File, Save As, vcard)
*#**** Sets "N" and "ORG to the name of the company
*#**** Sets "FN" to value in "File as:"
*#** Add another vCard app here.

* 2005-07-23 raised by DanConnolly
*# ''Are class names case sensitive or not? [[hcard]] says "If names in the source schema are case-insensitive, then use an all lowercase equivalent."''
*#* A: ACCEPTED FAQ. Class names are case sensitive per the HTML4 specification. Hence hCard explicitly specifies the case of class name to use for source schema names that are case-insensitive.
*# ''...but I find example data with class="Given-Name"''
*#* A: ACCEPTED RESOLVED. That is from an older preliminary version of the hCard spec which used mixed case class names. Such class names are no longer valid hCard. Please note which examples (URLs) are using the older class names and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the lower-case style, this is a hold-over from the original design, X2V has been updated.
*# ''..and code that supports it [data with class="Given-Name"].''
*#* A: ACCEPTED RESOLVED. Any code supporting the older class name(s) is for backward compatibility only, and should be phased out. Any new hCard code SHOULD NOT support such mixed case class names.
*#** [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html rfc2629xslt.html] uses Street-Address, Family-Name, etc.
*#*** A: By [http://greenbytes.de/tech/webdav/ Julian Reschke] Fixed rfc2629.xslt (2005-10-29)
*#** [http://suda.co.uk/projects/X2V/ X2V] Version 0.5.1 2005-07-08 supports Family-Name etc.
*#*** A: By [http://suda.co.uk Brian Suda] I agree that the upper-case class names can be removed from the code, this was a hold-over and will be trimmed.
*# ''The ul/ol stuff for multiple values of a property seems to be in the X2V code and in [[hcard-brainstorming]] but not in the [[hcard]] spec.''
*#* A. ACCEPTED RESOLVED. This needs to be added to the spec. 2005-11-08 Update: the way multiple values has been updated to work much better and not require ul/ol.
*# ''the [[hcard-profile]] says country-name but X2V and lots of the data I've seen says country''
*#* A. ACCEPTED RESOLVED. RFC 2426 clearly says "country name" in both the prose and the grammar, thus "country-name" is the correct class name to use. If X2V uses just "country", it needs to be fixed to use "country-name", and any such examples as well. Please note which examples (URLs) are using the class name "country" and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the proper country-name, X2V will support this in the next iteration when i fix several bugs at once.

* 2005-08-12 raised by [http://home.alltel.net/jackwolfgang/contact/ Jack L. Wolfgang II]. Use of mailto transport functionality for the E-Mail address field.
*# ''As stated in the [[hcard-brainstorming]] document, mailto is abused by spammers. As a result, many organizations have moved to form-based contacts as opposed to mailtos. According to [http://www.ietf.org/rfc/rfc2426.txt RFC 2426], Section 3.3.2, "A non-standard value can also be specified." Does this refer to a non-standard e-mail address value or type value?''
*#* A: ACCEPTED FAQ. Type value.

* 2005-10-30 raised by [http://greenbytes.de/tech/webdav/ Julian Reschke].
*# ''Several implementations'' '''(Which ones? Please provide links.)''' ''seem to assume that any class attribute that contains the substring "vcard" indeed signals the presence of vcard information. Not so: there are examples'' '''(What examples? Please provide links.)''' ''of where a token in the class attribute indeed only ''starts with'' "vcard", in which it should be ignored. Implementations using XPath (such as XSLT or Greasemonkey scripts) should be advised to do a <code>contains(concat(@class,' '),'vcard ')</code>.
*#* REJECTED VAGUE. Which implementations? And which examples?
*#*''(Note: the code <code>contains(concat(@class,' '),'vcard ')</code> is broken see [[parsing-microformats#Parsing_class_values]] for a correct example --[[User:RobertBachmann|Robert Bachmann]])''

* 2005-12-08 raised by [http://www.heatonarts.com Kenny Heaton].
*# ''The specification gives no way to to declare a telephone extension, as in (800) 234-5678 ext. 101''
*#* ACCEPTED FAQ. What is the best way to declare a telephone extension in a "tel" property? (also seems like it would be a vCard FAQ).

=== 2006 ===

* 2006-01-21 raised by [http://inspire.server101.com/ben/resume/ Ben Boyle].
*# ''Have run into issues trying to use definition lists with hCard, specifically around nesting requirements for tel where the DT element takes a class "type" (e.g. Telephone, Facsimile) and the DD element marks the value. It is invalid to place any other elements within a DL that wrap around the DT/DD pairs so there is no available element to assign the class "tel" to. XHTML2 proposes a DI element that will resolve this issue. I am hoping for an interim solution for those that wish to use definition lists, perhaps that "any class that would be placed on the DI parent (in XHTML2) must instead be placed on the first DT element". I realise this will cause headaches for those implementing hCard parsers. I'd also like to note this may affect other (current or future) microformats and relates to the general hassle of definition lists in current (X)HTML recommendations. For your consideration - thanks!''
*#* REJECTED WORKAROUND AVAILABLE. Either don't use definition lists in this manner (because the description of a definition should go completely in the DD element, and thus you should be able to put the class on that), or use separate DLs in the cases where you would otherwise have needed a DI element.

* {{OpenIssue}} 2006-01-23 raised by David Janes (?).
* ''Issue 1: Specifying Authoritative or Canonical or Official Hcard''
** Use of rel="me" only specifies an alternate version, not necessarily the canonical version
** Suggestion: use rel="me self". Adopt "self" semantics from Atom which means "the", or controversially "alternate, equivalent" version
*** The combined use of rel="me" and rel="self" may conflict with their definitions in the [http://www.gmpg.org/xfn/11#me XFN Profile] and RFC 4287 respectively. See [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008443.html the mailing list discussion on rel="me self"] for more information. From [[User:RCanine|Ryan Cannon]].
** Suggestion: use rel="via". Per RFC 4287, via "signifies that the IRI in the value of the href attribute identifies a resource that is the source of the information provided in the containing element." from [[User:RCanine|Ryan Cannon]].
** Other suggestions? "authoritative", "canonical"?
** Problems with this suggestion?
** How does this relate to authentication/trust issues? Is this a different problem with a different scope?
*** (microformats-discuss list) Joe Andrieu: The concept behind an "authoritative" hCard rather than "definitive" or "canonical" one was that "authoritative" would explicitly be a ''claim'' by the author of the hCard regarding its authority in describing the subject of the hCard, i.e., use ''this'' hCard as the one true source of this individual's contact information.
*** To summarize: authentication/trust is a separate topic.
** What exactly is the scope of the problem to solve here?
*** (IRC) (10:47:44) sreynen: for example, all of the examples I've seen involve a single person publishing multiple hCards of himself
*** (IRC) (10:48:13) sreynen: yet many people are talking about 3rd parties publishing hCards and pointing back to the subject's own hCard
** rel="me" must be symmetrical, per the XFN spec. What exactly does this mean for this use?
** "me" (and, depending on usage, "self") are not appropriate for content referring to third- parties. [[User:AndyMabbett|Andy Mabbett]]
''TODO:'' please add appropriate context and history of this issue from the mailing list. Sign your name to your comments.

* {{OpenIssue}} 2006-01-28 raised by [http://rbach.priv.at/Microformats-IRC/2006-01-28#T075222 Tantek on #microformats]
*# ''Is hCard is really appropriate for a named phone bridge, or do we need something else for a named phone numbers that are neither people nor organizations (the current two precise semantics that can be defined by hCard). For example see the "Zakim" hCard on http://www.w3.org/2005/12/allgroupoverview.html''

*2006-02-03 raised by Brian
*# We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

* 2006-02-13 raised by [http://microformats.org/wiki/User:Eron_Wright Eron Wright]
*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''
*#* REJECTED POSTPONED. Not in vCard. There is no "altitude" component in vCard (RFC 2426), and thus (certainly for now) there won't be any in hCard. If a new version of vCard were to come out with altitude, then we would add it to hCard. At some point we may also consider adding explicit extensions beyond vCard, but if we were to do so, we would capture them first on the [[hcard-brainstorming]] page. See also [[geo-extension-elevation]].

* 2006-02-19 raised by Miika Mäkinen.
*# ''Couldn't the types for tel numbers be specified in a class? Now, for a phone number one needs to add the type as "visible" text, which is not always preferred. For example, type "Work", many times more suitable label could be "Office" or similar and sometimes you might not want to display any type information at all.''
*#* REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was attempted], and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the ''visible'' markup. Note that you can use abbreviations, e.g. <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> in order to present the type in a way that may better fit in with the rest of your presentation.

* 2006-02-23 raised by [http://www.thefutureoftheweb.com/ Jesse Skinner] and [http://www.thefutureoftheweb.com/blog/2006/1/hcard#comment1 Ben Buchanan].
*# ''Are multiple URLs allowed? The [http://microformats.org/wiki/hcard#Property_List Property List] suggests not, whereas email and tel have multiple type/value pairs. However, the [http://microformats.org/wiki/hcard-parsing#finding_hCard_properties parsing page] suggests multiple URLs are OK. Either way, it seems clear that a type cannot be associated with a URL. So how exactly does hCard deal with multiple URLs?''
*#* RESOLVED FAQ: Multiple URLs are allowed. Some consuming agents (Apple's AddressBook.app among them) don't have an interface for producing multiple URLs, but they are still valid in vCard and therefore hCard. --[[User:RyanKing|RyanKing]] 17:58, 12 Jun 2006 (PDT)

* {{OpenIssue}} 2006-03-07 raised by [http://tantek.com Tantek].
*# ''Issue 1: In 99% of the cases I am finding the need to explicitly do "n" markup, the person has a three word fn which is in the form "given-name additional-name(or initial) family-name". Should we make three word fn's into another shorthand notation to make this easier for authors?''

* 2006-04-06 raised by [[User:Evan|Evan]].
*# ''What is the relationship between the CATEGORY property and [[rel-tag]]? Can you add a tag to an hCard? How can you add a tag to a particular hcard on a page without tagging the other cards on a page?''
*#* ACCEPTED. Categories can optionally be represented as tags. The classname 'category' should always be used, but rel="tag" can optionally be used (in addition to the category classname). In the case that a rel-tag tag is used, the tag (as defined by [[rel-tag]]) is used for the category. Examples: (1) <code><nowiki>food</nowiki></code> and (2) <code><nowiki><a class="category" rel="tag" href="http://example.com/food">Food!</a></nowiki></code>. --[[User:RyanKing|RyanKing]] 15:16, 13 Jun 2006 (PDT)

* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].
*# ''When someone looks at the [[hcard|hCard]] pages, one sees no collection of real-world publishing of contact data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the [[process]] nor the hcard pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

* 2006-11-16 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''The "type" for "tel" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)].''
*#*A: REJECTED. This is a vCard issue, as the "type" taxonomy for "tel" is determined by vCard. We are not presently extending hCard beyond the properties and values in vCard.
*#** ''I'm not clear how you can "reject" a provably factual statement. What's the process of suggesting an update to vCard? [[User:AndyMabbett|Andy Mabbett]]''
*#***A: ACCEPTED PARTIAL RESOLVED. Unfortunately it is not clear what the process is for updating vCard. However, we can at least capture suggestions for improvement to vCard from this community which may be helpful once the process for updating vCard is understood. I've created [[vcard-suggestions]] for this purpose and added this suggestion. - Tantek
*#**** The vCard spec is updated by RFC, for example [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770]. [[User:AndyMabbett|Andy Mabbett]] 06:22, 12 Jan 2007 (PST)

* 2006-11-23 raised by [[User:AndyMabbett|Andy Mabbett]]
*# The specification should be "stand alone", and not normally require reference to the vCard specification.
*#*A: ACCEPTED PARTIAL. Agreed that [[hcard|hCard]] should be usable by typical web authors without having to dig through the vCard specification. Precise implementation of parsing etc. hCard properties however will likely require programmers to reference the specifics/grammars in the vCard specification which we will NOT replicate in the hCard specification in order to avoid inevitable introduction of errors due to duplication. And that being said, ''informative'' explanations may be a good idea, while the vCard property/value definitions are kept as ''normative''.
*#** Yes; my meaning was with reference to hCard publishing, not parsing-into-vCards. [[User:AndyMabbett|Andy Mabbett]]
*# ''The specification should state that "telephone numbers SHOULD adhere to [http://en.wikipedia.org/wiki/E.123 ITU-T Recommendation E.123]" (or perhaps "MUST").''
*#* ACCEPTED PARTIAL. This makes sense as an informative reference and a MAY, but since vCard makes no such SHOULD statement for TEL values, neither should/will hCard. In addition, as a Wikipedia URL that is subject to drastic change, we cannot make that a normative reference.
*#** I take your point about Wikipedia - here's [http://www.itu.int/rec/T-REC-E.123-200102-I/en a more definitive ITU-E.123 URL]; but it's for a chargeable document. Using "SHOULD" or "MUST" in hCard will not affect compatibility with or conversion to vCard. [[User:AndyMabbett|Andy Mabbett]]

* {{OpenIssue}} 2006-11-24 raised by [[User:AndyMabbett|Andy Mabbett]]
*# A suggested work-around for the lack of a gender property is to represent gender implicitly in the honorific-prefix field, e.g. Mr. for male, and Ms. for female. This approach does has the limitation that "Mr." and "Ms." (or "Miss"/ "Mrs.") conflicts with a higher-ranking, gender-neutral honorific, such as "Dr." or "Rev." for the person, as it is unusual (and sometimes, outside the USA, invalid) to refer to someone as "Mr. Dr." or "Mrs. Rev." for example. Note also that some cultures or religions regard such titles as offensive, or at least disdain them.

* {{OpenIssue}} 2006-12-07 raised by RyanKing.
*# ''hCard org-fn matching should use organization-name, if given.''
*# originally [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007337.html raised on uf-discuss] by David Janes.

* {{OpenIssue}} 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.
*# (Paraphrased) By including organisations and places, as well as people, hCards have lost semantic specificity (see cited mailing list post for details).
*#* [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009102.html Apparently intentional], but possibly requiring further extension. [[User:AndyMabbett|Andy Mabbett]]

* 2006-12-15 raised by [[User:WizardIsHungry|WizardIsHungry]]
*# ''[Moved from a user talk page] Hey, why is hiding semi-useful information using CSS bad? The Geo and Address stuff wouldn't be enough to contact me, but I would like there so bookmarklets, crawlers, greasemonkey etc can manipulate it. Is there a policy on using CSS hiding of fields? Thanks :)''
*#* I guess we can't rely that anything that consumes hCards is normalizing it to a particular format instead of just taking all the xml inside the hcard classed block and sticking it somewhere. If it does just store it as a string, then generating html from it will yield the same hidden fields. Perhaps hiding fields by applying a stylesheet to the relevant hcard styles is ok, but not hiding them using in-line CSS styling. Feedback? --[[User:WizardIsHungry|Jon Williams]] 10:28, 22 Dec 2006 (PST)
*#* Furthermore, [[hcard-example1-steps]] shows using inline CSS to hide fields. What gives? I still think this is an open issue; particularly the distinction between external stylesheet hiding and inline rules though. --[[User:WizardIsHungry|Jon Williams]] 13:33, 5 Jan 2007 (PST)
*#* Should this be on [[microformats-issues]]? --[[User:WizardIsHungry|Jon Williams]] 13:37, 5 Jan 2007 (PST)
*#** The example you cite is the first of several steps, which refine and improve the first step's suboptimal hCard.
*#*** The question is: ''why is this considered suboptimal if it is ok to hide the entire card?'''
*#**** REJECTED CLOSED TOO THEORETICAL. It is not OK to hide the entire card. Without further concrete examples with real world URLs on the web, this issue is closed.
*#***** Here are a number of examples of hiding the entire card, taken from [[hcard-examples-in-wild]]: [http://www.meryl.net/] [http://www.fberriman.com/] [http://www.fberriman.com/] [http://www.last.fm/user/Crok/?scrobbling=t1] -- Could someone link to where this was discussed and decided in the past, as it seems like this is being governed by fiat. Even if you don't care to have consensus, but could you at least justify this? This stonewalling is rather rude. --[[User:WizardIsHungry|Jon Williams]] 13:24, 9 Jan 2007 (PST)
*#* [[hcard-brainstorming#CSS_Styles]] explicitly permits this. I'm going with what they say.

=== 2007 ===

* 2007-01-22 raised by [[User:Christina Hope|Christina Hope]].
*# ''What is the easiest way to display an hCard all on one line with spacing. Currently I am using this - but I know that there has to be an easier/ simpler way to do it. Examples: (1) <pre><nowiki>

Christina Hope& nbsp;& nbsp;& nbsp;
Information Technology& nbsp;& nbsp;& nbsp;
Website Coordinator& nbsp;& nbsp;& nbsp;

 x3408 & nbsp;& nbsp;& nbsp;
<a href="mailto:chope@example.com">chope@example.com</a>
</nowiki></pre>''

:: Try <pre><nowiki>
Christina Hope
Information Technology
Website Coordinator
<abbr class="tel" title="+44123 456 7890 x 3408"> x3408</abbr>
<a class="email" href="mailto:chope@example.com">chope@example.com</a>
</nowiki></pre>

::Note: apply classes to existing elements; use abbr to give the phone number in full, in international format. Also, use CSS, not non- breaking spaces, for spacing.

::[[User:AndyMabbett|Andy Mabbett]] 08:34, 22 Jan 2007 (PST)

* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. abbr-design-pattern would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>

<abbr class="type" title="home">Casa</abbr> (preferido):
+1.415.555.1212

</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]

* 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# ''Proposal to use the class attribute for qname prefixed type values (and others such as dtstart values), AKA meta classes.'' <pre><nowiki>
Home (preferred): +1.415.555.1212
Casa (preferido): +1.415.555.1212
</nowiki></pre>
*#* REJECTED DUPLICATE ETC. Class attributes for type values [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was tried and rejected] and in addition, [[qnames-considered-harmful]].
*#* Clarified proposal, leaving REJECTED.

* {{OpenIssue}} 2007-01-30 raised by [[User:AndyMabbett|Andy Mabbett]]
*# Many sites, not least Wikipedia, publish co-ordinates as degrees-minutes-seconds (e.g. [http://en.wikipedia.org/wiki/Birmingham]). Should [[geo]] be extended to allow for this, with parsers making the conversion to digital values?

* {{OpenIssue}} 2007-02-02 raised by [[User::DerrickPallas|Derrick Pallas]]
*# [[adr]] says that all of it's properties are singular; however, "street-address" is listed as zero-or-more.

* {{OpenIssue}} 2007-02-25 [http://microformats.org/wiki?title=adr&diff=next&oldid=13732 raised elsewhere] by [[User:JamesCraig]]
*#internationalisation Note: <code>country-code</code> may be missing. Usually a postal-code prefix such as "FIN-00630 Helsinki" or "L-4750 Petange" (Luxembourg).

* {{OpenIssue}} 2007-03-19 raised by [[User::ChristinaHope|Christina Hope]]
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL?

* {{OpenIssue}} 2007-03-26 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Parsers (Operator, Tails) currently expect <code>adr</code> to have one or more children. It is not clear from the spec that that's mandatory; nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity. See [[hcard-brainstorming#ADR with no children]] for discussion.

* {{OpenIssue}} 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)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)

* {{OpenIssue}} 2007-04-09 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Why is [[geo]] still a draft, when it's included in the already-published [[hcard|hCard]] spec?

*{{OpenIssue}} 2007-04-19 raised by [[User:AndyMabbett|Andy Mabbett]]
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style , using the <code>abbr-design-pattern</code> if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?

*{{OpenIssue}} 2007-04-24 raised by [[User:Singpolyma|singpolyma]]
*# ''What is the 'Label' property for''

*{{OpenIssue}} 2007-05-08 raised by Tantek as a result of a message from [[User:AndyMabbett|Andy Mabbett]] on microformats-new
*#''How do you distinguish a '''place''' vs. an '''organization''' hCard, both from the perspective of a publisher (author) wishing to express the particular semantic, and from the perspective of a parser (developer) wishing to discern the difference? This is different from the 2006-12-15 issue on semantic specificity because this issue is *specifically* about place vs. org, rather than conflating that with person.''
*#Note: mailing list post cited in 2006-12-15 issue is quite clear; it says "''when a spider finds an hCard, it can't tell if it is a person, company, organization, or place.''".

* {{OpenIssue}} 2007-08-03 raised by [http://www.kaply.com/weblog/ MikeKaply].
*# ''Issue 1: When using the value design pattern, should the data be extracted completely (including HTML tags) or just text content? In general, the value pattern seems to imply taking the data exactly.''

* {{OpenIssue}} 2007-11-04 raised by [http://www.tomota.de/ RalfEngels].
*# ''Issue 1: The section Organization Contact Info is exeedingly vague. It says "I must not set the N property" and later on it says that I could set it to an empty value. Which of both is true? Must not or empty?''
*# ''Issue 2: Same section. It does not cover e.g. Mr Fischer (N=Fischer) from the Fischer AG (ORG=Fischer). Could you re-formulate it stating that if the N attribute is missing the hcard is regarded as the card of a company.''
*# ''Issue 3: Grouping as specified by rfc2425 and supported by vcard cannote be expressed. Grouping allows you to express the relation between different values.''
*# ''Issue 4: Implied n optimization: the typical case list specifies a (space) in the first and last line. In the middle lines it specifies a (comma). I guess this should mean (comma)(space) instead. In addition it contradicts with the previous text where you state that the separating character is a (whitespace)''
*# ''Issue 5: Contatination of texts is not consistent in the examples. Example file 21 contatinates telephone fields with spaces. Example 16 concatinates multiple name sub-properties by a comma. Example 34 even concatinates multiple note fields.''

== Template ==

Please use this format (copy and paste this to the end of the list to add your issues):
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

== Related Pages ==
{{hcard-related-pages}}

hcard-issues

2007-11-04T21:09:58Z

RalfEngels: /* 2007 */

<h1> hCard issues </h1>

These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See also related [[hcalendar-issues]].

__TOC__

== Closed Issues ==
Resolved issues that have no further actions to take. These will likely be moved to a separate page like [[hcard-issues-closed]].

* ...

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items. As issues are resolved, they will be moved from the top of the [[hcard-issues#Issues|Issues list]] to the bottom of this section.

* 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.
*#* 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.

== Issues ==
Please add new issues to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2005 ===
* 2005-06-21 raised by Hixie
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCards must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
*#*A: ACCEPTED RESOLVED. See [[hcard-parsing]] for how hCards must be parsed. For errors/unexpected content/missing content, please provide specific examples.

* 2005-06-30 raised by Jack L. Wolfgang II. Please feel free to move these to the FAQs if they are better suited there.
*# ''Handling middle names and suffixes: How does one handle middle initials/names in the hCard format and suffixes that are not honorific suffixes (e.g. Jr., Sr., II, III, etc. as opposed to Ph.D., Esq., M.D., etc.)?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]; 2006-11-16 updated by [[User:AndyMabbett|Andy Mabbett]]) hCard is based of the RFC2426 spec. I you want to use a middle initial it can be expanded using the abbr element. <code><abbr title="[MiddleName]" class="additional-name">M</abbr></code>. Honorific Suffixes in the RFC include Jr., Esq. and other inherited suffixes, so I would just use <code><abbr class="honorific-suffix" title="Junior">Jr.</abbr></code> etc.
*# ''Handling different types of addresses: How does one handle the TYPE (e.g. postal, work, etc.) specification for addresses as specified in RFC 2426 Section 3.2.1?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]) If you want to add a type to certain elements, including address and telephone it may be done in the following manner:
<pre><nowiki>

work:
...

</nowiki></pre>
<pre><nowiki>

work:
123.456.7890

</nowiki></pre>
the TYPE needs to be a sub-element of the property (adr, tel, etc) NOTE: EMAIL does NOT have many TYPE attributes, only INTERNET and X400

* 2005-07-22 raised by DanConnolly
*# ''...in my cellphone/sidekick address book, I have a number of entries for companies. I wrote [http://dev.w3.org/cvsweb/2001/palmagent/asHCard.xsl asHCard.xsl] to convert the data from RDF to hCard, but I don't know what to do with entries for companies, since FN is mandatory in hCard.''
*#*A: ACCEPTED FAQ. This should be an FAQ. "How do I write an hCard for a company?" The vCard specification is silent on this point (entries for companies). Thus there are two options as far as the hCard standard is concerned:
*#*# Set "fn" and "org" to the same value. E.g. <code>W3C</code> (recommended)
*#*# Set "org" as usual, and set "fn" explicitly to empty. E.g. <code>W3C</code> or
*#*#* Simply have no "fn", and on the parsing side, if there is no "fn" present, but there is an "org" property, then duplicate the "org" value as "fn"
*#*The last two options are effectively the same and are both not explicit and easily confusable with a "missing data" condition. Thus option 1 is preferred. For converting applications (hCard to vCard), they ''may'' consider using proprietary extensions to make the distinction explicit in generated vCards, based on either case 1 or 2 above. E.g. Apple's Address Book application supports the property: <code>X-ABShowAs:COMPANY</code>
*#*We are looking for descriptions of how other vCard supporting applications treat "company" vCards differently from "person" vCards. Please provide descriptions here:
*#** Address Book / MacOSX.3:
*#*** Export (e.g. drag & drop to desktop, view in text editor)
*#**** Sets "FN" and "ORG" to the name of the company
*#**** Sets proprietary <code>X-ABShowAs:COMPANY</code>
*#*** Import (e.g. edit in text editor, drag & drop from desktop)
*#**** By setting "FN" and "ORG' to the same name (e.g. Banana Computers Inc.)
*#**** And removing any proprietary properties (e.g. X-ABShowAs)
*#**** Address Book user interface showed new vCard as a "company" contact rather an a person
*#** Address Book MacOSX.4:
*#*** same results as above -RyanKing
*#** The Danger Hiptop (aka T-Mobile Sidekick) address book:
*#*** Export (e.g. [http://lists.w3.org/Archives/Public/www-archive/2005Sep/0007.html email to a mailing list])
*#**** Sets "FN" to the empty string and puts the company name in "ORG".
*#*** Import - could not find a way to import a .vcf, by email, IM, or other means into the Sidekick.
*#** Contacts / Outlook 2003 Windows
*#*** Export (e.g. Highlight contact, File, Save As, vcard)
*#**** Sets "N" and "ORG to the name of the company
*#**** Sets "FN" to value in "File as:"
*#** Add another vCard app here.

* 2005-07-23 raised by DanConnolly
*# ''Are class names case sensitive or not? [[hcard]] says "If names in the source schema are case-insensitive, then use an all lowercase equivalent."''
*#* A: ACCEPTED FAQ. Class names are case sensitive per the HTML4 specification. Hence hCard explicitly specifies the case of class name to use for source schema names that are case-insensitive.
*# ''...but I find example data with class="Given-Name"''
*#* A: ACCEPTED RESOLVED. That is from an older preliminary version of the hCard spec which used mixed case class names. Such class names are no longer valid hCard. Please note which examples (URLs) are using the older class names and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the lower-case style, this is a hold-over from the original design, X2V has been updated.
*# ''..and code that supports it [data with class="Given-Name"].''
*#* A: ACCEPTED RESOLVED. Any code supporting the older class name(s) is for backward compatibility only, and should be phased out. Any new hCard code SHOULD NOT support such mixed case class names.
*#** [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html rfc2629xslt.html] uses Street-Address, Family-Name, etc.
*#*** A: By [http://greenbytes.de/tech/webdav/ Julian Reschke] Fixed rfc2629.xslt (2005-10-29)
*#** [http://suda.co.uk/projects/X2V/ X2V] Version 0.5.1 2005-07-08 supports Family-Name etc.
*#*** A: By [http://suda.co.uk Brian Suda] I agree that the upper-case class names can be removed from the code, this was a hold-over and will be trimmed.
*# ''The ul/ol stuff for multiple values of a property seems to be in the X2V code and in [[hcard-brainstorming]] but not in the [[hcard]] spec.''
*#* A. ACCEPTED RESOLVED. This needs to be added to the spec. 2005-11-08 Update: the way multiple values has been updated to work much better and not require ul/ol.
*# ''the [[hcard-profile]] says country-name but X2V and lots of the data I've seen says country''
*#* A. ACCEPTED RESOLVED. RFC 2426 clearly says "country name" in both the prose and the grammar, thus "country-name" is the correct class name to use. If X2V uses just "country", it needs to be fixed to use "country-name", and any such examples as well. Please note which examples (URLs) are using the class name "country" and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the proper country-name, X2V will support this in the next iteration when i fix several bugs at once.

* 2005-08-12 raised by [http://home.alltel.net/jackwolfgang/contact/ Jack L. Wolfgang II]. Use of mailto transport functionality for the E-Mail address field.
*# ''As stated in the [[hcard-brainstorming]] document, mailto is abused by spammers. As a result, many organizations have moved to form-based contacts as opposed to mailtos. According to [http://www.ietf.org/rfc/rfc2426.txt RFC 2426], Section 3.3.2, "A non-standard value can also be specified." Does this refer to a non-standard e-mail address value or type value?''
*#* A: ACCEPTED FAQ. Type value.

* 2005-10-30 raised by [http://greenbytes.de/tech/webdav/ Julian Reschke].
*# ''Several implementations'' '''(Which ones? Please provide links.)''' ''seem to assume that any class attribute that contains the substring "vcard" indeed signals the presence of vcard information. Not so: there are examples'' '''(What examples? Please provide links.)''' ''of where a token in the class attribute indeed only ''starts with'' "vcard", in which it should be ignored. Implementations using XPath (such as XSLT or Greasemonkey scripts) should be advised to do a <code>contains(concat(@class,' '),'vcard ')</code>.
*#* REJECTED VAGUE. Which implementations? And which examples?
*#*''(Note: the code <code>contains(concat(@class,' '),'vcard ')</code> is broken see [[parsing-microformats#Parsing_class_values]] for a correct example --[[User:RobertBachmann|Robert Bachmann]])''

* 2005-12-08 raised by [http://www.heatonarts.com Kenny Heaton].
*# ''The specification gives no way to to declare a telephone extension, as in (800) 234-5678 ext. 101''
*#* ACCEPTED FAQ. What is the best way to declare a telephone extension in a "tel" property? (also seems like it would be a vCard FAQ).

=== 2006 ===

* 2006-01-21 raised by [http://inspire.server101.com/ben/resume/ Ben Boyle].
*# ''Have run into issues trying to use definition lists with hCard, specifically around nesting requirements for tel where the DT element takes a class "type" (e.g. Telephone, Facsimile) and the DD element marks the value. It is invalid to place any other elements within a DL that wrap around the DT/DD pairs so there is no available element to assign the class "tel" to. XHTML2 proposes a DI element that will resolve this issue. I am hoping for an interim solution for those that wish to use definition lists, perhaps that "any class that would be placed on the DI parent (in XHTML2) must instead be placed on the first DT element". I realise this will cause headaches for those implementing hCard parsers. I'd also like to note this may affect other (current or future) microformats and relates to the general hassle of definition lists in current (X)HTML recommendations. For your consideration - thanks!''
*#* REJECTED WORKAROUND AVAILABLE. Either don't use definition lists in this manner (because the description of a definition should go completely in the DD element, and thus you should be able to put the class on that), or use separate DLs in the cases where you would otherwise have needed a DI element.

* {{OpenIssue}} 2006-01-23 raised by David Janes (?).
* ''Issue 1: Specifying Authoritative or Canonical or Official Hcard''
** Use of rel="me" only specifies an alternate version, not necessarily the canonical version
** Suggestion: use rel="me self". Adopt "self" semantics from Atom which means "the", or controversially "alternate, equivalent" version
*** The combined use of rel="me" and rel="self" may conflict with their definitions in the [http://www.gmpg.org/xfn/11#me XFN Profile] and RFC 4287 respectively. See [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008443.html the mailing list discussion on rel="me self"] for more information. From [[User:RCanine|Ryan Cannon]].
** Suggestion: use rel="via". Per RFC 4287, via "signifies that the IRI in the value of the href attribute identifies a resource that is the source of the information provided in the containing element." from [[User:RCanine|Ryan Cannon]].
** Other suggestions? "authoritative", "canonical"?
** Problems with this suggestion?
** How does this relate to authentication/trust issues? Is this a different problem with a different scope?
*** (microformats-discuss list) Joe Andrieu: The concept behind an "authoritative" hCard rather than "definitive" or "canonical" one was that "authoritative" would explicitly be a ''claim'' by the author of the hCard regarding its authority in describing the subject of the hCard, i.e., use ''this'' hCard as the one true source of this individual's contact information.
*** To summarize: authentication/trust is a separate topic.
** What exactly is the scope of the problem to solve here?
*** (IRC) (10:47:44) sreynen: for example, all of the examples I've seen involve a single person publishing multiple hCards of himself
*** (IRC) (10:48:13) sreynen: yet many people are talking about 3rd parties publishing hCards and pointing back to the subject's own hCard
** rel="me" must be symmetrical, per the XFN spec. What exactly does this mean for this use?
** "me" (and, depending on usage, "self") are not appropriate for content referring to third- parties. [[User:AndyMabbett|Andy Mabbett]]
''TODO:'' please add appropriate context and history of this issue from the mailing list. Sign your name to your comments.

* {{OpenIssue}} 2006-01-28 raised by [http://rbach.priv.at/Microformats-IRC/2006-01-28#T075222 Tantek on #microformats]
*# ''Is hCard is really appropriate for a named phone bridge, or do we need something else for a named phone numbers that are neither people nor organizations (the current two precise semantics that can be defined by hCard). For example see the "Zakim" hCard on http://www.w3.org/2005/12/allgroupoverview.html''

*2006-02-03 raised by Brian
*# We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

* 2006-02-13 raised by [http://microformats.org/wiki/User:Eron_Wright Eron Wright]
*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''
*#* REJECTED POSTPONED. Not in vCard. There is no "altitude" component in vCard (RFC 2426), and thus (certainly for now) there won't be any in hCard. If a new version of vCard were to come out with altitude, then we would add it to hCard. At some point we may also consider adding explicit extensions beyond vCard, but if we were to do so, we would capture them first on the [[hcard-brainstorming]] page. See also [[geo-extension-elevation]].

* 2006-02-19 raised by Miika Mäkinen.
*# ''Couldn't the types for tel numbers be specified in a class? Now, for a phone number one needs to add the type as "visible" text, which is not always preferred. For example, type "Work", many times more suitable label could be "Office" or similar and sometimes you might not want to display any type information at all.''
*#* REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was attempted], and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the ''visible'' markup. Note that you can use abbreviations, e.g. <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> in order to present the type in a way that may better fit in with the rest of your presentation.

* 2006-02-23 raised by [http://www.thefutureoftheweb.com/ Jesse Skinner] and [http://www.thefutureoftheweb.com/blog/2006/1/hcard#comment1 Ben Buchanan].
*# ''Are multiple URLs allowed? The [http://microformats.org/wiki/hcard#Property_List Property List] suggests not, whereas email and tel have multiple type/value pairs. However, the [http://microformats.org/wiki/hcard-parsing#finding_hCard_properties parsing page] suggests multiple URLs are OK. Either way, it seems clear that a type cannot be associated with a URL. So how exactly does hCard deal with multiple URLs?''
*#* RESOLVED FAQ: Multiple URLs are allowed. Some consuming agents (Apple's AddressBook.app among them) don't have an interface for producing multiple URLs, but they are still valid in vCard and therefore hCard. --[[User:RyanKing|RyanKing]] 17:58, 12 Jun 2006 (PDT)

* {{OpenIssue}} 2006-03-07 raised by [http://tantek.com Tantek].
*# ''Issue 1: In 99% of the cases I am finding the need to explicitly do "n" markup, the person has a three word fn which is in the form "given-name additional-name(or initial) family-name". Should we make three word fn's into another shorthand notation to make this easier for authors?''

* 2006-04-06 raised by [[User:Evan|Evan]].
*# ''What is the relationship between the CATEGORY property and [[rel-tag]]? Can you add a tag to an hCard? How can you add a tag to a particular hcard on a page without tagging the other cards on a page?''
*#* ACCEPTED. Categories can optionally be represented as tags. The classname 'category' should always be used, but rel="tag" can optionally be used (in addition to the category classname). In the case that a rel-tag tag is used, the tag (as defined by [[rel-tag]]) is used for the category. Examples: (1) <code><nowiki>food</nowiki></code> and (2) <code><nowiki><a class="category" rel="tag" href="http://example.com/food">Food!</a></nowiki></code>. --[[User:RyanKing|RyanKing]] 15:16, 13 Jun 2006 (PDT)

* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].
*# ''When someone looks at the [[hcard|hCard]] pages, one sees no collection of real-world publishing of contact data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the [[process]] nor the hcard pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

* 2006-11-16 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''The "type" for "tel" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)].''
*#*A: REJECTED. This is a vCard issue, as the "type" taxonomy for "tel" is determined by vCard. We are not presently extending hCard beyond the properties and values in vCard.
*#** ''I'm not clear how you can "reject" a provably factual statement. What's the process of suggesting an update to vCard? [[User:AndyMabbett|Andy Mabbett]]''
*#***A: ACCEPTED PARTIAL RESOLVED. Unfortunately it is not clear what the process is for updating vCard. However, we can at least capture suggestions for improvement to vCard from this community which may be helpful once the process for updating vCard is understood. I've created [[vcard-suggestions]] for this purpose and added this suggestion. - Tantek
*#**** The vCard spec is updated by RFC, for example [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770]. [[User:AndyMabbett|Andy Mabbett]] 06:22, 12 Jan 2007 (PST)

* 2006-11-23 raised by [[User:AndyMabbett|Andy Mabbett]]
*# The specification should be "stand alone", and not normally require reference to the vCard specification.
*#*A: ACCEPTED PARTIAL. Agreed that [[hcard|hCard]] should be usable by typical web authors without having to dig through the vCard specification. Precise implementation of parsing etc. hCard properties however will likely require programmers to reference the specifics/grammars in the vCard specification which we will NOT replicate in the hCard specification in order to avoid inevitable introduction of errors due to duplication. And that being said, ''informative'' explanations may be a good idea, while the vCard property/value definitions are kept as ''normative''.
*#** Yes; my meaning was with reference to hCard publishing, not parsing-into-vCards. [[User:AndyMabbett|Andy Mabbett]]
*# ''The specification should state that "telephone numbers SHOULD adhere to [http://en.wikipedia.org/wiki/E.123 ITU-T Recommendation E.123]" (or perhaps "MUST").''
*#* ACCEPTED PARTIAL. This makes sense as an informative reference and a MAY, but since vCard makes no such SHOULD statement for TEL values, neither should/will hCard. In addition, as a Wikipedia URL that is subject to drastic change, we cannot make that a normative reference.
*#** I take your point about Wikipedia - here's [http://www.itu.int/rec/T-REC-E.123-200102-I/en a more definitive ITU-E.123 URL]; but it's for a chargeable document. Using "SHOULD" or "MUST" in hCard will not affect compatibility with or conversion to vCard. [[User:AndyMabbett|Andy Mabbett]]

* {{OpenIssue}} 2006-11-24 raised by [[User:AndyMabbett|Andy Mabbett]]
*# A suggested work-around for the lack of a gender property is to represent gender implicitly in the honorific-prefix field, e.g. Mr. for male, and Ms. for female. This approach does has the limitation that "Mr." and "Ms." (or "Miss"/ "Mrs.") conflicts with a higher-ranking, gender-neutral honorific, such as "Dr." or "Rev." for the person, as it is unusual (and sometimes, outside the USA, invalid) to refer to someone as "Mr. Dr." or "Mrs. Rev." for example. Note also that some cultures or religions regard such titles as offensive, or at least disdain them.

* {{OpenIssue}} 2006-12-07 raised by RyanKing.
*# ''hCard org-fn matching should use organization-name, if given.''
*# originally [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007337.html raised on uf-discuss] by David Janes.

* {{OpenIssue}} 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.
*# (Paraphrased) By including organisations and places, as well as people, hCards have lost semantic specificity (see cited mailing list post for details).
*#* [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009102.html Apparently intentional], but possibly requiring further extension. [[User:AndyMabbett|Andy Mabbett]]

* 2006-12-15 raised by [[User:WizardIsHungry|WizardIsHungry]]
*# ''[Moved from a user talk page] Hey, why is hiding semi-useful information using CSS bad? The Geo and Address stuff wouldn't be enough to contact me, but I would like there so bookmarklets, crawlers, greasemonkey etc can manipulate it. Is there a policy on using CSS hiding of fields? Thanks :)''
*#* I guess we can't rely that anything that consumes hCards is normalizing it to a particular format instead of just taking all the xml inside the hcard classed block and sticking it somewhere. If it does just store it as a string, then generating html from it will yield the same hidden fields. Perhaps hiding fields by applying a stylesheet to the relevant hcard styles is ok, but not hiding them using in-line CSS styling. Feedback? --[[User:WizardIsHungry|Jon Williams]] 10:28, 22 Dec 2006 (PST)
*#* Furthermore, [[hcard-example1-steps]] shows using inline CSS to hide fields. What gives? I still think this is an open issue; particularly the distinction between external stylesheet hiding and inline rules though. --[[User:WizardIsHungry|Jon Williams]] 13:33, 5 Jan 2007 (PST)
*#* Should this be on [[microformats-issues]]? --[[User:WizardIsHungry|Jon Williams]] 13:37, 5 Jan 2007 (PST)
*#** The example you cite is the first of several steps, which refine and improve the first step's suboptimal hCard.
*#*** The question is: ''why is this considered suboptimal if it is ok to hide the entire card?'''
*#**** REJECTED CLOSED TOO THEORETICAL. It is not OK to hide the entire card. Without further concrete examples with real world URLs on the web, this issue is closed.
*#***** Here are a number of examples of hiding the entire card, taken from [[hcard-examples-in-wild]]: [http://www.meryl.net/] [http://www.fberriman.com/] [http://www.fberriman.com/] [http://www.last.fm/user/Crok/?scrobbling=t1] -- Could someone link to where this was discussed and decided in the past, as it seems like this is being governed by fiat. Even if you don't care to have consensus, but could you at least justify this? This stonewalling is rather rude. --[[User:WizardIsHungry|Jon Williams]] 13:24, 9 Jan 2007 (PST)
*#* [[hcard-brainstorming#CSS_Styles]] explicitly permits this. I'm going with what they say.

=== 2007 ===

* 2007-01-22 raised by [[User:Christina Hope|Christina Hope]].
*# ''What is the easiest way to display an hCard all on one line with spacing. Currently I am using this - but I know that there has to be an easier/ simpler way to do it. Examples: (1) <pre><nowiki>

Christina Hope& nbsp;& nbsp;& nbsp;
Information Technology& nbsp;& nbsp;& nbsp;
Website Coordinator& nbsp;& nbsp;& nbsp;

 x3408 & nbsp;& nbsp;& nbsp;
<a href="mailto:chope@example.com">chope@example.com</a>
</nowiki></pre>''

:: Try <pre><nowiki>
Christina Hope
Information Technology
Website Coordinator
<abbr class="tel" title="+44123 456 7890 x 3408"> x3408</abbr>
<a class="email" href="mailto:chope@example.com">chope@example.com</a>
</nowiki></pre>

::Note: apply classes to existing elements; use abbr to give the phone number in full, in international format. Also, use CSS, not non- breaking spaces, for spacing.

::[[User:AndyMabbett|Andy Mabbett]] 08:34, 22 Jan 2007 (PST)

* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. abbr-design-pattern would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>

<abbr class="type" title="home">Casa</abbr> (preferido):
+1.415.555.1212

</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]

* 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# ''Proposal to use the class attribute for qname prefixed type values (and others such as dtstart values), AKA meta classes.'' <pre><nowiki>
Home (preferred): +1.415.555.1212
Casa (preferido): +1.415.555.1212
</nowiki></pre>
*#* REJECTED DUPLICATE ETC. Class attributes for type values [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was tried and rejected] and in addition, [[qnames-considered-harmful]].
*#* Clarified proposal, leaving REJECTED.

* {{OpenIssue}} 2007-01-30 raised by [[User:AndyMabbett|Andy Mabbett]]
*# Many sites, not least Wikipedia, publish co-ordinates as degrees-minutes-seconds (e.g. [http://en.wikipedia.org/wiki/Birmingham]). Should [[geo]] be extended to allow for this, with parsers making the conversion to digital values?

* {{OpenIssue}} 2007-02-02 raised by [[User::DerrickPallas|Derrick Pallas]]
*# [[adr]] says that all of it's properties are singular; however, "street-address" is listed as zero-or-more.

* {{OpenIssue}} 2007-02-25 [http://microformats.org/wiki?title=adr&diff=next&oldid=13732 raised elsewhere] by [[User:JamesCraig]]
*#internationalisation Note: <code>country-code</code> may be missing. Usually a postal-code prefix such as "FIN-00630 Helsinki" or "L-4750 Petange" (Luxembourg).

* {{OpenIssue}} 2007-03-19 raised by [[User::ChristinaHope|Christina Hope]]
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL?

* {{OpenIssue}} 2007-03-26 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Parsers (Operator, Tails) currently expect <code>adr</code> to have one or more children. It is not clear from the spec that that's mandatory; nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity. See [[hcard-brainstorming#ADR with no children]] for discussion.

* {{OpenIssue}} 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)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)

* {{OpenIssue}} 2007-04-09 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Why is [[geo]] still a draft, when it's included in the already-published [[hcard|hCard]] spec?

*{{OpenIssue}} 2007-04-19 raised by [[User:AndyMabbett|Andy Mabbett]]
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style , using the <code>abbr-design-pattern</code> if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?

*{{OpenIssue}} 2007-04-24 raised by [[User:Singpolyma|singpolyma]]
*# ''What is the 'Label' property for''

*{{OpenIssue}} 2007-05-08 raised by Tantek as a result of a message from [[User:AndyMabbett|Andy Mabbett]] on microformats-new
*#''How do you distinguish a '''place''' vs. an '''organization''' hCard, both from the perspective of a publisher (author) wishing to express the particular semantic, and from the perspective of a parser (developer) wishing to discern the difference? This is different from the 2006-12-15 issue on semantic specificity because this issue is *specifically* about place vs. org, rather than conflating that with person.''
*#Note: mailing list post cited in 2006-12-15 issue is quite clear; it says "''when a spider finds an hCard, it can't tell if it is a person, company, organization, or place.''".

* {{OpenIssue}} 2007-08-03 raised by [http://www.kaply.com/weblog/ MikeKaply].
*# ''Issue 1: When using the value design pattern, should the data be extracted completely (including HTML tags) or just text content? In general, the value pattern seems to imply taking the data exactly.''

* {{OpenIssue}} 2007-11-04 raised by [http://www.tomota.de/ RalfEngels].
*# ''Issue 1: The section Organization Contact Info is exeedingly vague. It says "I must not set the N property" and later on it says that I could set it to an empty value. Which of both is true? Must not or empty?''
*# ''Issue 2: Same section. It does not cover e.g. Mr Fischer (N=Fischer) from the Fischer AG (ORG=Fischer). Could you re-formulate it stating that if the N attribute is missing the hcard is regarded as the card of a company.''
*# ''Issue 3: Grouping as specified by rfc2425 and supported by vcard cannote be expressed. Grouping allows you to express the relation between different values.''
*# ''Issue 4: Implied n optimization:
the typical case list specifies a (space) in the first and last line. In the middle lines it specifies a (comma). I guess this should mean (comma)(space) instead.
In addition it contradicts with the previous text where you state that the separating character is a (whitespace)''

== Template ==

Please use this format (copy and paste this to the end of the list to add your issues):
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

== Related Pages ==
{{hcard-related-pages}}

hcard-issues

2007-11-04T17:25:17Z

RalfEngels: /* 2007 */

<h1> hCard issues </h1>

These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See also related [[hcalendar-issues]].

__TOC__

== Closed Issues ==
Resolved issues that have no further actions to take. These will likely be moved to a separate page like [[hcard-issues-closed]].

* ...

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items. As issues are resolved, they will be moved from the top of the [[hcard-issues#Issues|Issues list]] to the bottom of this section.

* 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.
*#* 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.

== Issues ==
Please add new issues to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2005 ===
* 2005-06-21 raised by Hixie
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCards must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
*#*A: ACCEPTED RESOLVED. See [[hcard-parsing]] for how hCards must be parsed. For errors/unexpected content/missing content, please provide specific examples.

* 2005-06-30 raised by Jack L. Wolfgang II. Please feel free to move these to the FAQs if they are better suited there.
*# ''Handling middle names and suffixes: How does one handle middle initials/names in the hCard format and suffixes that are not honorific suffixes (e.g. Jr., Sr., II, III, etc. as opposed to Ph.D., Esq., M.D., etc.)?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]; 2006-11-16 updated by [[User:AndyMabbett|Andy Mabbett]]) hCard is based of the RFC2426 spec. I you want to use a middle initial it can be expanded using the abbr element. <code><abbr title="[MiddleName]" class="additional-name">M</abbr></code>. Honorific Suffixes in the RFC include Jr., Esq. and other inherited suffixes, so I would just use <code><abbr class="honorific-suffix" title="Junior">Jr.</abbr></code> etc.
*# ''Handling different types of addresses: How does one handle the TYPE (e.g. postal, work, etc.) specification for addresses as specified in RFC 2426 Section 3.2.1?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]) If you want to add a type to certain elements, including address and telephone it may be done in the following manner:
<pre><nowiki>

work:
...

</nowiki></pre>
<pre><nowiki>

work:
123.456.7890

</nowiki></pre>
the TYPE needs to be a sub-element of the property (adr, tel, etc) NOTE: EMAIL does NOT have many TYPE attributes, only INTERNET and X400

* 2005-07-22 raised by DanConnolly
*# ''...in my cellphone/sidekick address book, I have a number of entries for companies. I wrote [http://dev.w3.org/cvsweb/2001/palmagent/asHCard.xsl asHCard.xsl] to convert the data from RDF to hCard, but I don't know what to do with entries for companies, since FN is mandatory in hCard.''
*#*A: ACCEPTED FAQ. This should be an FAQ. "How do I write an hCard for a company?" The vCard specification is silent on this point (entries for companies). Thus there are two options as far as the hCard standard is concerned:
*#*# Set "fn" and "org" to the same value. E.g. <code>W3C</code> (recommended)
*#*# Set "org" as usual, and set "fn" explicitly to empty. E.g. <code>W3C</code> or
*#*#* Simply have no "fn", and on the parsing side, if there is no "fn" present, but there is an "org" property, then duplicate the "org" value as "fn"
*#*The last two options are effectively the same and are both not explicit and easily confusable with a "missing data" condition. Thus option 1 is preferred. For converting applications (hCard to vCard), they ''may'' consider using proprietary extensions to make the distinction explicit in generated vCards, based on either case 1 or 2 above. E.g. Apple's Address Book application supports the property: <code>X-ABShowAs:COMPANY</code>
*#*We are looking for descriptions of how other vCard supporting applications treat "company" vCards differently from "person" vCards. Please provide descriptions here:
*#** Address Book / MacOSX.3:
*#*** Export (e.g. drag & drop to desktop, view in text editor)
*#**** Sets "FN" and "ORG" to the name of the company
*#**** Sets proprietary <code>X-ABShowAs:COMPANY</code>
*#*** Import (e.g. edit in text editor, drag & drop from desktop)
*#**** By setting "FN" and "ORG' to the same name (e.g. Banana Computers Inc.)
*#**** And removing any proprietary properties (e.g. X-ABShowAs)
*#**** Address Book user interface showed new vCard as a "company" contact rather an a person
*#** Address Book MacOSX.4:
*#*** same results as above -RyanKing
*#** The Danger Hiptop (aka T-Mobile Sidekick) address book:
*#*** Export (e.g. [http://lists.w3.org/Archives/Public/www-archive/2005Sep/0007.html email to a mailing list])
*#**** Sets "FN" to the empty string and puts the company name in "ORG".
*#*** Import - could not find a way to import a .vcf, by email, IM, or other means into the Sidekick.
*#** Contacts / Outlook 2003 Windows
*#*** Export (e.g. Highlight contact, File, Save As, vcard)
*#**** Sets "N" and "ORG to the name of the company
*#**** Sets "FN" to value in "File as:"
*#** Add another vCard app here.

* 2005-07-23 raised by DanConnolly
*# ''Are class names case sensitive or not? [[hcard]] says "If names in the source schema are case-insensitive, then use an all lowercase equivalent."''
*#* A: ACCEPTED FAQ. Class names are case sensitive per the HTML4 specification. Hence hCard explicitly specifies the case of class name to use for source schema names that are case-insensitive.
*# ''...but I find example data with class="Given-Name"''
*#* A: ACCEPTED RESOLVED. That is from an older preliminary version of the hCard spec which used mixed case class names. Such class names are no longer valid hCard. Please note which examples (URLs) are using the older class names and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the lower-case style, this is a hold-over from the original design, X2V has been updated.
*# ''..and code that supports it [data with class="Given-Name"].''
*#* A: ACCEPTED RESOLVED. Any code supporting the older class name(s) is for backward compatibility only, and should be phased out. Any new hCard code SHOULD NOT support such mixed case class names.
*#** [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html rfc2629xslt.html] uses Street-Address, Family-Name, etc.
*#*** A: By [http://greenbytes.de/tech/webdav/ Julian Reschke] Fixed rfc2629.xslt (2005-10-29)
*#** [http://suda.co.uk/projects/X2V/ X2V] Version 0.5.1 2005-07-08 supports Family-Name etc.
*#*** A: By [http://suda.co.uk Brian Suda] I agree that the upper-case class names can be removed from the code, this was a hold-over and will be trimmed.
*# ''The ul/ol stuff for multiple values of a property seems to be in the X2V code and in [[hcard-brainstorming]] but not in the [[hcard]] spec.''
*#* A. ACCEPTED RESOLVED. This needs to be added to the spec. 2005-11-08 Update: the way multiple values has been updated to work much better and not require ul/ol.
*# ''the [[hcard-profile]] says country-name but X2V and lots of the data I've seen says country''
*#* A. ACCEPTED RESOLVED. RFC 2426 clearly says "country name" in both the prose and the grammar, thus "country-name" is the correct class name to use. If X2V uses just "country", it needs to be fixed to use "country-name", and any such examples as well. Please note which examples (URLs) are using the class name "country" and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the proper country-name, X2V will support this in the next iteration when i fix several bugs at once.

* 2005-08-12 raised by [http://home.alltel.net/jackwolfgang/contact/ Jack L. Wolfgang II]. Use of mailto transport functionality for the E-Mail address field.
*# ''As stated in the [[hcard-brainstorming]] document, mailto is abused by spammers. As a result, many organizations have moved to form-based contacts as opposed to mailtos. According to [http://www.ietf.org/rfc/rfc2426.txt RFC 2426], Section 3.3.2, "A non-standard value can also be specified." Does this refer to a non-standard e-mail address value or type value?''
*#* A: ACCEPTED FAQ. Type value.

* 2005-10-30 raised by [http://greenbytes.de/tech/webdav/ Julian Reschke].
*# ''Several implementations'' '''(Which ones? Please provide links.)''' ''seem to assume that any class attribute that contains the substring "vcard" indeed signals the presence of vcard information. Not so: there are examples'' '''(What examples? Please provide links.)''' ''of where a token in the class attribute indeed only ''starts with'' "vcard", in which it should be ignored. Implementations using XPath (such as XSLT or Greasemonkey scripts) should be advised to do a <code>contains(concat(@class,' '),'vcard ')</code>.
*#* REJECTED VAGUE. Which implementations? And which examples?
*#*''(Note: the code <code>contains(concat(@class,' '),'vcard ')</code> is broken see [[parsing-microformats#Parsing_class_values]] for a correct example --[[User:RobertBachmann|Robert Bachmann]])''

* 2005-12-08 raised by [http://www.heatonarts.com Kenny Heaton].
*# ''The specification gives no way to to declare a telephone extension, as in (800) 234-5678 ext. 101''
*#* ACCEPTED FAQ. What is the best way to declare a telephone extension in a "tel" property? (also seems like it would be a vCard FAQ).

=== 2006 ===

* 2006-01-21 raised by [http://inspire.server101.com/ben/resume/ Ben Boyle].
*# ''Have run into issues trying to use definition lists with hCard, specifically around nesting requirements for tel where the DT element takes a class "type" (e.g. Telephone, Facsimile) and the DD element marks the value. It is invalid to place any other elements within a DL that wrap around the DT/DD pairs so there is no available element to assign the class "tel" to. XHTML2 proposes a DI element that will resolve this issue. I am hoping for an interim solution for those that wish to use definition lists, perhaps that "any class that would be placed on the DI parent (in XHTML2) must instead be placed on the first DT element". I realise this will cause headaches for those implementing hCard parsers. I'd also like to note this may affect other (current or future) microformats and relates to the general hassle of definition lists in current (X)HTML recommendations. For your consideration - thanks!''
*#* REJECTED WORKAROUND AVAILABLE. Either don't use definition lists in this manner (because the description of a definition should go completely in the DD element, and thus you should be able to put the class on that), or use separate DLs in the cases where you would otherwise have needed a DI element.

* {{OpenIssue}} 2006-01-23 raised by David Janes (?).
* ''Issue 1: Specifying Authoritative or Canonical or Official Hcard''
** Use of rel="me" only specifies an alternate version, not necessarily the canonical version
** Suggestion: use rel="me self". Adopt "self" semantics from Atom which means "the", or controversially "alternate, equivalent" version
*** The combined use of rel="me" and rel="self" may conflict with their definitions in the [http://www.gmpg.org/xfn/11#me XFN Profile] and RFC 4287 respectively. See [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008443.html the mailing list discussion on rel="me self"] for more information. From [[User:RCanine|Ryan Cannon]].
** Suggestion: use rel="via". Per RFC 4287, via "signifies that the IRI in the value of the href attribute identifies a resource that is the source of the information provided in the containing element." from [[User:RCanine|Ryan Cannon]].
** Other suggestions? "authoritative", "canonical"?
** Problems with this suggestion?
** How does this relate to authentication/trust issues? Is this a different problem with a different scope?
*** (microformats-discuss list) Joe Andrieu: The concept behind an "authoritative" hCard rather than "definitive" or "canonical" one was that "authoritative" would explicitly be a ''claim'' by the author of the hCard regarding its authority in describing the subject of the hCard, i.e., use ''this'' hCard as the one true source of this individual's contact information.
*** To summarize: authentication/trust is a separate topic.
** What exactly is the scope of the problem to solve here?
*** (IRC) (10:47:44) sreynen: for example, all of the examples I've seen involve a single person publishing multiple hCards of himself
*** (IRC) (10:48:13) sreynen: yet many people are talking about 3rd parties publishing hCards and pointing back to the subject's own hCard
** rel="me" must be symmetrical, per the XFN spec. What exactly does this mean for this use?
** "me" (and, depending on usage, "self") are not appropriate for content referring to third- parties. [[User:AndyMabbett|Andy Mabbett]]
''TODO:'' please add appropriate context and history of this issue from the mailing list. Sign your name to your comments.

* {{OpenIssue}} 2006-01-28 raised by [http://rbach.priv.at/Microformats-IRC/2006-01-28#T075222 Tantek on #microformats]
*# ''Is hCard is really appropriate for a named phone bridge, or do we need something else for a named phone numbers that are neither people nor organizations (the current two precise semantics that can be defined by hCard). For example see the "Zakim" hCard on http://www.w3.org/2005/12/allgroupoverview.html''

*2006-02-03 raised by Brian
*# We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

* 2006-02-13 raised by [http://microformats.org/wiki/User:Eron_Wright Eron Wright]
*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''
*#* REJECTED POSTPONED. Not in vCard. There is no "altitude" component in vCard (RFC 2426), and thus (certainly for now) there won't be any in hCard. If a new version of vCard were to come out with altitude, then we would add it to hCard. At some point we may also consider adding explicit extensions beyond vCard, but if we were to do so, we would capture them first on the [[hcard-brainstorming]] page. See also [[geo-extension-elevation]].

* 2006-02-19 raised by Miika Mäkinen.
*# ''Couldn't the types for tel numbers be specified in a class? Now, for a phone number one needs to add the type as "visible" text, which is not always preferred. For example, type "Work", many times more suitable label could be "Office" or similar and sometimes you might not want to display any type information at all.''
*#* REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was attempted], and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the ''visible'' markup. Note that you can use abbreviations, e.g. <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> in order to present the type in a way that may better fit in with the rest of your presentation.

* 2006-02-23 raised by [http://www.thefutureoftheweb.com/ Jesse Skinner] and [http://www.thefutureoftheweb.com/blog/2006/1/hcard#comment1 Ben Buchanan].
*# ''Are multiple URLs allowed? The [http://microformats.org/wiki/hcard#Property_List Property List] suggests not, whereas email and tel have multiple type/value pairs. However, the [http://microformats.org/wiki/hcard-parsing#finding_hCard_properties parsing page] suggests multiple URLs are OK. Either way, it seems clear that a type cannot be associated with a URL. So how exactly does hCard deal with multiple URLs?''
*#* RESOLVED FAQ: Multiple URLs are allowed. Some consuming agents (Apple's AddressBook.app among them) don't have an interface for producing multiple URLs, but they are still valid in vCard and therefore hCard. --[[User:RyanKing|RyanKing]] 17:58, 12 Jun 2006 (PDT)

* {{OpenIssue}} 2006-03-07 raised by [http://tantek.com Tantek].
*# ''Issue 1: In 99% of the cases I am finding the need to explicitly do "n" markup, the person has a three word fn which is in the form "given-name additional-name(or initial) family-name". Should we make three word fn's into another shorthand notation to make this easier for authors?''

* 2006-04-06 raised by [[User:Evan|Evan]].
*# ''What is the relationship between the CATEGORY property and [[rel-tag]]? Can you add a tag to an hCard? How can you add a tag to a particular hcard on a page without tagging the other cards on a page?''
*#* ACCEPTED. Categories can optionally be represented as tags. The classname 'category' should always be used, but rel="tag" can optionally be used (in addition to the category classname). In the case that a rel-tag tag is used, the tag (as defined by [[rel-tag]]) is used for the category. Examples: (1) <code><nowiki>food</nowiki></code> and (2) <code><nowiki><a class="category" rel="tag" href="http://example.com/food">Food!</a></nowiki></code>. --[[User:RyanKing|RyanKing]] 15:16, 13 Jun 2006 (PDT)

* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].
*# ''When someone looks at the [[hcard|hCard]] pages, one sees no collection of real-world publishing of contact data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the [[process]] nor the hcard pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

* 2006-11-16 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''The "type" for "tel" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)].''
*#*A: REJECTED. This is a vCard issue, as the "type" taxonomy for "tel" is determined by vCard. We are not presently extending hCard beyond the properties and values in vCard.
*#** ''I'm not clear how you can "reject" a provably factual statement. What's the process of suggesting an update to vCard? [[User:AndyMabbett|Andy Mabbett]]''
*#***A: ACCEPTED PARTIAL RESOLVED. Unfortunately it is not clear what the process is for updating vCard. However, we can at least capture suggestions for improvement to vCard from this community which may be helpful once the process for updating vCard is understood. I've created [[vcard-suggestions]] for this purpose and added this suggestion. - Tantek
*#**** The vCard spec is updated by RFC, for example [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770]. [[User:AndyMabbett|Andy Mabbett]] 06:22, 12 Jan 2007 (PST)

* 2006-11-23 raised by [[User:AndyMabbett|Andy Mabbett]]
*# The specification should be "stand alone", and not normally require reference to the vCard specification.
*#*A: ACCEPTED PARTIAL. Agreed that [[hcard|hCard]] should be usable by typical web authors without having to dig through the vCard specification. Precise implementation of parsing etc. hCard properties however will likely require programmers to reference the specifics/grammars in the vCard specification which we will NOT replicate in the hCard specification in order to avoid inevitable introduction of errors due to duplication. And that being said, ''informative'' explanations may be a good idea, while the vCard property/value definitions are kept as ''normative''.
*#** Yes; my meaning was with reference to hCard publishing, not parsing-into-vCards. [[User:AndyMabbett|Andy Mabbett]]
*# ''The specification should state that "telephone numbers SHOULD adhere to [http://en.wikipedia.org/wiki/E.123 ITU-T Recommendation E.123]" (or perhaps "MUST").''
*#* ACCEPTED PARTIAL. This makes sense as an informative reference and a MAY, but since vCard makes no such SHOULD statement for TEL values, neither should/will hCard. In addition, as a Wikipedia URL that is subject to drastic change, we cannot make that a normative reference.
*#** I take your point about Wikipedia - here's [http://www.itu.int/rec/T-REC-E.123-200102-I/en a more definitive ITU-E.123 URL]; but it's for a chargeable document. Using "SHOULD" or "MUST" in hCard will not affect compatibility with or conversion to vCard. [[User:AndyMabbett|Andy Mabbett]]

* {{OpenIssue}} 2006-11-24 raised by [[User:AndyMabbett|Andy Mabbett]]
*# A suggested work-around for the lack of a gender property is to represent gender implicitly in the honorific-prefix field, e.g. Mr. for male, and Ms. for female. This approach does has the limitation that "Mr." and "Ms." (or "Miss"/ "Mrs.") conflicts with a higher-ranking, gender-neutral honorific, such as "Dr." or "Rev." for the person, as it is unusual (and sometimes, outside the USA, invalid) to refer to someone as "Mr. Dr." or "Mrs. Rev." for example. Note also that some cultures or religions regard such titles as offensive, or at least disdain them.

* {{OpenIssue}} 2006-12-07 raised by RyanKing.
*# ''hCard org-fn matching should use organization-name, if given.''
*# originally [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007337.html raised on uf-discuss] by David Janes.

* {{OpenIssue}} 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.
*# (Paraphrased) By including organisations and places, as well as people, hCards have lost semantic specificity (see cited mailing list post for details).
*#* [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009102.html Apparently intentional], but possibly requiring further extension. [[User:AndyMabbett|Andy Mabbett]]

* 2006-12-15 raised by [[User:WizardIsHungry|WizardIsHungry]]
*# ''[Moved from a user talk page] Hey, why is hiding semi-useful information using CSS bad? The Geo and Address stuff wouldn't be enough to contact me, but I would like there so bookmarklets, crawlers, greasemonkey etc can manipulate it. Is there a policy on using CSS hiding of fields? Thanks :)''
*#* I guess we can't rely that anything that consumes hCards is normalizing it to a particular format instead of just taking all the xml inside the hcard classed block and sticking it somewhere. If it does just store it as a string, then generating html from it will yield the same hidden fields. Perhaps hiding fields by applying a stylesheet to the relevant hcard styles is ok, but not hiding them using in-line CSS styling. Feedback? --[[User:WizardIsHungry|Jon Williams]] 10:28, 22 Dec 2006 (PST)
*#* Furthermore, [[hcard-example1-steps]] shows using inline CSS to hide fields. What gives? I still think this is an open issue; particularly the distinction between external stylesheet hiding and inline rules though. --[[User:WizardIsHungry|Jon Williams]] 13:33, 5 Jan 2007 (PST)
*#* Should this be on [[microformats-issues]]? --[[User:WizardIsHungry|Jon Williams]] 13:37, 5 Jan 2007 (PST)
*#** The example you cite is the first of several steps, which refine and improve the first step's suboptimal hCard.
*#*** The question is: ''why is this considered suboptimal if it is ok to hide the entire card?'''
*#**** REJECTED CLOSED TOO THEORETICAL. It is not OK to hide the entire card. Without further concrete examples with real world URLs on the web, this issue is closed.
*#***** Here are a number of examples of hiding the entire card, taken from [[hcard-examples-in-wild]]: [http://www.meryl.net/] [http://www.fberriman.com/] [http://www.fberriman.com/] [http://www.last.fm/user/Crok/?scrobbling=t1] -- Could someone link to where this was discussed and decided in the past, as it seems like this is being governed by fiat. Even if you don't care to have consensus, but could you at least justify this? This stonewalling is rather rude. --[[User:WizardIsHungry|Jon Williams]] 13:24, 9 Jan 2007 (PST)
*#* [[hcard-brainstorming#CSS_Styles]] explicitly permits this. I'm going with what they say.

=== 2007 ===

* 2007-01-22 raised by [[User:Christina Hope|Christina Hope]].
*# ''What is the easiest way to display an hCard all on one line with spacing. Currently I am using this - but I know that there has to be an easier/ simpler way to do it. Examples: (1) <pre><nowiki>

Christina Hope& nbsp;& nbsp;& nbsp;
Information Technology& nbsp;& nbsp;& nbsp;
Website Coordinator& nbsp;& nbsp;& nbsp;

 x3408 & nbsp;& nbsp;& nbsp;
<a href="mailto:chope@example.com">chope@example.com</a>
</nowiki></pre>''

:: Try <pre><nowiki>
Christina Hope
Information Technology
Website Coordinator
<abbr class="tel" title="+44123 456 7890 x 3408"> x3408</abbr>
<a class="email" href="mailto:chope@example.com">chope@example.com</a>
</nowiki></pre>

::Note: apply classes to existing elements; use abbr to give the phone number in full, in international format. Also, use CSS, not non- breaking spaces, for spacing.

::[[User:AndyMabbett|Andy Mabbett]] 08:34, 22 Jan 2007 (PST)

* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. abbr-design-pattern would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>

<abbr class="type" title="home">Casa</abbr> (preferido):
+1.415.555.1212

</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]

* 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# ''Proposal to use the class attribute for qname prefixed type values (and others such as dtstart values), AKA meta classes.'' <pre><nowiki>
Home (preferred): +1.415.555.1212
Casa (preferido): +1.415.555.1212
</nowiki></pre>
*#* REJECTED DUPLICATE ETC. Class attributes for type values [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was tried and rejected] and in addition, [[qnames-considered-harmful]].
*#* Clarified proposal, leaving REJECTED.

* {{OpenIssue}} 2007-01-30 raised by [[User:AndyMabbett|Andy Mabbett]]
*# Many sites, not least Wikipedia, publish co-ordinates as degrees-minutes-seconds (e.g. [http://en.wikipedia.org/wiki/Birmingham]). Should [[geo]] be extended to allow for this, with parsers making the conversion to digital values?

* {{OpenIssue}} 2007-02-02 raised by [[User::DerrickPallas|Derrick Pallas]]
*# [[adr]] says that all of it's properties are singular; however, "street-address" is listed as zero-or-more.

* {{OpenIssue}} 2007-02-25 [http://microformats.org/wiki?title=adr&diff=next&oldid=13732 raised elsewhere] by [[User:JamesCraig]]
*#internationalisation Note: <code>country-code</code> may be missing. Usually a postal-code prefix such as "FIN-00630 Helsinki" or "L-4750 Petange" (Luxembourg).

* {{OpenIssue}} 2007-03-19 raised by [[User::ChristinaHope|Christina Hope]]
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL?

* {{OpenIssue}} 2007-03-26 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Parsers (Operator, Tails) currently expect <code>adr</code> to have one or more children. It is not clear from the spec that that's mandatory; nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity. See [[hcard-brainstorming#ADR with no children]] for discussion.

* {{OpenIssue}} 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)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)

* {{OpenIssue}} 2007-04-09 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Why is [[geo]] still a draft, when it's included in the already-published [[hcard|hCard]] spec?

*{{OpenIssue}} 2007-04-19 raised by [[User:AndyMabbett|Andy Mabbett]]
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style , using the <code>abbr-design-pattern</code> if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?

*{{OpenIssue}} 2007-04-24 raised by [[User:Singpolyma|singpolyma]]
*# ''What is the 'Label' property for''

*{{OpenIssue}} 2007-05-08 raised by Tantek as a result of a message from [[User:AndyMabbett|Andy Mabbett]] on microformats-new
*#''How do you distinguish a '''place''' vs. an '''organization''' hCard, both from the perspective of a publisher (author) wishing to express the particular semantic, and from the perspective of a parser (developer) wishing to discern the difference? This is different from the 2006-12-15 issue on semantic specificity because this issue is *specifically* about place vs. org, rather than conflating that with person.''
*#Note: mailing list post cited in 2006-12-15 issue is quite clear; it says "''when a spider finds an hCard, it can't tell if it is a person, company, organization, or place.''".

* {{OpenIssue}} 2007-08-03 raised by [http://www.kaply.com/weblog/ MikeKaply].
*# ''Issue 1: When using the value design pattern, should the data be extracted completely (including HTML tags) or just text content? In general, the value pattern seems to imply taking the data exactly.''

* {{OpenIssue}} 2007-11-04 raised by [http://www.tomota.de/ RalfEngels].
*# ''Issue 1: The section Organization Contact Info is exeedingly vague. It says "I must not set the N property" and later on it says that I could set it to an empty value. Which of both is true? Must not or empty?''
*# ''Issue 2: Same section. It does not cover e.g. Mr Fischer (N=Fischer) from the Fischer AG (ORG=Fischer). Could you re-formulate it stating that if the N attribute is missing the hcard is regarded as the card of a company.''
*# ''Issue 3: Section "type subproperty values". The hcard example is the first place that shows a span with the type value. No further explanation how the value fields should be handled is given. The value only ever appears in examples in the whole specification.''
*# ''Issue 4: Grouping as specified by rfc2425 and supported by vcard cannote be expressed. Grouping allows you to express the relation between different values.''
*# ''Issue 5: Implied n optimization:
the typical case list specifies a (space) in the first and last line. In the middle lines it specifies a (comma). I guess this should mean (comma)(space) instead.
In addition it contradicts with the previous text where you state that the separating character is a (whitespace)''

== Template ==

Please use this format (copy and paste this to the end of the list to add your issues):
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

== Related Pages ==
{{hcard-related-pages}}

hcard-issues

2007-11-04T15:22:21Z

RalfEngels: /* 2007 */

<h1> hCard issues </h1>

These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See also related [[hcalendar-issues]].

__TOC__

== Closed Issues ==
Resolved issues that have no further actions to take. These will likely be moved to a separate page like [[hcard-issues-closed]].

* ...

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items. As issues are resolved, they will be moved from the top of the [[hcard-issues#Issues|Issues list]] to the bottom of this section.

* 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.
*#* 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.

== Issues ==
Please add new issues to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2005 ===
* 2005-06-21 raised by Hixie
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCards must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
*#*A: ACCEPTED RESOLVED. See [[hcard-parsing]] for how hCards must be parsed. For errors/unexpected content/missing content, please provide specific examples.

* 2005-06-30 raised by Jack L. Wolfgang II. Please feel free to move these to the FAQs if they are better suited there.
*# ''Handling middle names and suffixes: How does one handle middle initials/names in the hCard format and suffixes that are not honorific suffixes (e.g. Jr., Sr., II, III, etc. as opposed to Ph.D., Esq., M.D., etc.)?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]; 2006-11-16 updated by [[User:AndyMabbett|Andy Mabbett]]) hCard is based of the RFC2426 spec. I you want to use a middle initial it can be expanded using the abbr element. <code><abbr title="[MiddleName]" class="additional-name">M</abbr></code>. Honorific Suffixes in the RFC include Jr., Esq. and other inherited suffixes, so I would just use <code><abbr class="honorific-suffix" title="Junior">Jr.</abbr></code> etc.
*# ''Handling different types of addresses: How does one handle the TYPE (e.g. postal, work, etc.) specification for addresses as specified in RFC 2426 Section 3.2.1?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]) If you want to add a type to certain elements, including address and telephone it may be done in the following manner:
<pre><nowiki>

work:
...

</nowiki></pre>
<pre><nowiki>

work:
123.456.7890

</nowiki></pre>
the TYPE needs to be a sub-element of the property (adr, tel, etc) NOTE: EMAIL does NOT have many TYPE attributes, only INTERNET and X400

* 2005-07-22 raised by DanConnolly
*# ''...in my cellphone/sidekick address book, I have a number of entries for companies. I wrote [http://dev.w3.org/cvsweb/2001/palmagent/asHCard.xsl asHCard.xsl] to convert the data from RDF to hCard, but I don't know what to do with entries for companies, since FN is mandatory in hCard.''
*#*A: ACCEPTED FAQ. This should be an FAQ. "How do I write an hCard for a company?" The vCard specification is silent on this point (entries for companies). Thus there are two options as far as the hCard standard is concerned:
*#*# Set "fn" and "org" to the same value. E.g. <code>W3C</code> (recommended)
*#*# Set "org" as usual, and set "fn" explicitly to empty. E.g. <code>W3C</code> or
*#*#* Simply have no "fn", and on the parsing side, if there is no "fn" present, but there is an "org" property, then duplicate the "org" value as "fn"
*#*The last two options are effectively the same and are both not explicit and easily confusable with a "missing data" condition. Thus option 1 is preferred. For converting applications (hCard to vCard), they ''may'' consider using proprietary extensions to make the distinction explicit in generated vCards, based on either case 1 or 2 above. E.g. Apple's Address Book application supports the property: <code>X-ABShowAs:COMPANY</code>
*#*We are looking for descriptions of how other vCard supporting applications treat "company" vCards differently from "person" vCards. Please provide descriptions here:
*#** Address Book / MacOSX.3:
*#*** Export (e.g. drag & drop to desktop, view in text editor)
*#**** Sets "FN" and "ORG" to the name of the company
*#**** Sets proprietary <code>X-ABShowAs:COMPANY</code>
*#*** Import (e.g. edit in text editor, drag & drop from desktop)
*#**** By setting "FN" and "ORG' to the same name (e.g. Banana Computers Inc.)
*#**** And removing any proprietary properties (e.g. X-ABShowAs)
*#**** Address Book user interface showed new vCard as a "company" contact rather an a person
*#** Address Book MacOSX.4:
*#*** same results as above -RyanKing
*#** The Danger Hiptop (aka T-Mobile Sidekick) address book:
*#*** Export (e.g. [http://lists.w3.org/Archives/Public/www-archive/2005Sep/0007.html email to a mailing list])
*#**** Sets "FN" to the empty string and puts the company name in "ORG".
*#*** Import - could not find a way to import a .vcf, by email, IM, or other means into the Sidekick.
*#** Contacts / Outlook 2003 Windows
*#*** Export (e.g. Highlight contact, File, Save As, vcard)
*#**** Sets "N" and "ORG to the name of the company
*#**** Sets "FN" to value in "File as:"
*#** Add another vCard app here.

* 2005-07-23 raised by DanConnolly
*# ''Are class names case sensitive or not? [[hcard]] says "If names in the source schema are case-insensitive, then use an all lowercase equivalent."''
*#* A: ACCEPTED FAQ. Class names are case sensitive per the HTML4 specification. Hence hCard explicitly specifies the case of class name to use for source schema names that are case-insensitive.
*# ''...but I find example data with class="Given-Name"''
*#* A: ACCEPTED RESOLVED. That is from an older preliminary version of the hCard spec which used mixed case class names. Such class names are no longer valid hCard. Please note which examples (URLs) are using the older class names and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the lower-case style, this is a hold-over from the original design, X2V has been updated.
*# ''..and code that supports it [data with class="Given-Name"].''
*#* A: ACCEPTED RESOLVED. Any code supporting the older class name(s) is for backward compatibility only, and should be phased out. Any new hCard code SHOULD NOT support such mixed case class names.
*#** [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html rfc2629xslt.html] uses Street-Address, Family-Name, etc.
*#*** A: By [http://greenbytes.de/tech/webdav/ Julian Reschke] Fixed rfc2629.xslt (2005-10-29)
*#** [http://suda.co.uk/projects/X2V/ X2V] Version 0.5.1 2005-07-08 supports Family-Name etc.
*#*** A: By [http://suda.co.uk Brian Suda] I agree that the upper-case class names can be removed from the code, this was a hold-over and will be trimmed.
*# ''The ul/ol stuff for multiple values of a property seems to be in the X2V code and in [[hcard-brainstorming]] but not in the [[hcard]] spec.''
*#* A. ACCEPTED RESOLVED. This needs to be added to the spec. 2005-11-08 Update: the way multiple values has been updated to work much better and not require ul/ol.
*# ''the [[hcard-profile]] says country-name but X2V and lots of the data I've seen says country''
*#* A. ACCEPTED RESOLVED. RFC 2426 clearly says "country name" in both the prose and the grammar, thus "country-name" is the correct class name to use. If X2V uses just "country", it needs to be fixed to use "country-name", and any such examples as well. Please note which examples (URLs) are using the class name "country" and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the proper country-name, X2V will support this in the next iteration when i fix several bugs at once.

* 2005-08-12 raised by [http://home.alltel.net/jackwolfgang/contact/ Jack L. Wolfgang II]. Use of mailto transport functionality for the E-Mail address field.
*# ''As stated in the [[hcard-brainstorming]] document, mailto is abused by spammers. As a result, many organizations have moved to form-based contacts as opposed to mailtos. According to [http://www.ietf.org/rfc/rfc2426.txt RFC 2426], Section 3.3.2, "A non-standard value can also be specified." Does this refer to a non-standard e-mail address value or type value?''
*#* A: ACCEPTED FAQ. Type value.

* 2005-10-30 raised by [http://greenbytes.de/tech/webdav/ Julian Reschke].
*# ''Several implementations'' '''(Which ones? Please provide links.)''' ''seem to assume that any class attribute that contains the substring "vcard" indeed signals the presence of vcard information. Not so: there are examples'' '''(What examples? Please provide links.)''' ''of where a token in the class attribute indeed only ''starts with'' "vcard", in which it should be ignored. Implementations using XPath (such as XSLT or Greasemonkey scripts) should be advised to do a <code>contains(concat(@class,' '),'vcard ')</code>.
*#* REJECTED VAGUE. Which implementations? And which examples?
*#*''(Note: the code <code>contains(concat(@class,' '),'vcard ')</code> is broken see [[parsing-microformats#Parsing_class_values]] for a correct example --[[User:RobertBachmann|Robert Bachmann]])''

* 2005-12-08 raised by [http://www.heatonarts.com Kenny Heaton].
*# ''The specification gives no way to to declare a telephone extension, as in (800) 234-5678 ext. 101''
*#* ACCEPTED FAQ. What is the best way to declare a telephone extension in a "tel" property? (also seems like it would be a vCard FAQ).

=== 2006 ===

* 2006-01-21 raised by [http://inspire.server101.com/ben/resume/ Ben Boyle].
*# ''Have run into issues trying to use definition lists with hCard, specifically around nesting requirements for tel where the DT element takes a class "type" (e.g. Telephone, Facsimile) and the DD element marks the value. It is invalid to place any other elements within a DL that wrap around the DT/DD pairs so there is no available element to assign the class "tel" to. XHTML2 proposes a DI element that will resolve this issue. I am hoping for an interim solution for those that wish to use definition lists, perhaps that "any class that would be placed on the DI parent (in XHTML2) must instead be placed on the first DT element". I realise this will cause headaches for those implementing hCard parsers. I'd also like to note this may affect other (current or future) microformats and relates to the general hassle of definition lists in current (X)HTML recommendations. For your consideration - thanks!''
*#* REJECTED WORKAROUND AVAILABLE. Either don't use definition lists in this manner (because the description of a definition should go completely in the DD element, and thus you should be able to put the class on that), or use separate DLs in the cases where you would otherwise have needed a DI element.

* {{OpenIssue}} 2006-01-23 raised by David Janes (?).
* ''Issue 1: Specifying Authoritative or Canonical or Official Hcard''
** Use of rel="me" only specifies an alternate version, not necessarily the canonical version
** Suggestion: use rel="me self". Adopt "self" semantics from Atom which means "the", or controversially "alternate, equivalent" version
*** The combined use of rel="me" and rel="self" may conflict with their definitions in the [http://www.gmpg.org/xfn/11#me XFN Profile] and RFC 4287 respectively. See [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008443.html the mailing list discussion on rel="me self"] for more information. From [[User:RCanine|Ryan Cannon]].
** Suggestion: use rel="via". Per RFC 4287, via "signifies that the IRI in the value of the href attribute identifies a resource that is the source of the information provided in the containing element." from [[User:RCanine|Ryan Cannon]].
** Other suggestions? "authoritative", "canonical"?
** Problems with this suggestion?
** How does this relate to authentication/trust issues? Is this a different problem with a different scope?
*** (microformats-discuss list) Joe Andrieu: The concept behind an "authoritative" hCard rather than "definitive" or "canonical" one was that "authoritative" would explicitly be a ''claim'' by the author of the hCard regarding its authority in describing the subject of the hCard, i.e., use ''this'' hCard as the one true source of this individual's contact information.
*** To summarize: authentication/trust is a separate topic.
** What exactly is the scope of the problem to solve here?
*** (IRC) (10:47:44) sreynen: for example, all of the examples I've seen involve a single person publishing multiple hCards of himself
*** (IRC) (10:48:13) sreynen: yet many people are talking about 3rd parties publishing hCards and pointing back to the subject's own hCard
** rel="me" must be symmetrical, per the XFN spec. What exactly does this mean for this use?
** "me" (and, depending on usage, "self") are not appropriate for content referring to third- parties. [[User:AndyMabbett|Andy Mabbett]]
''TODO:'' please add appropriate context and history of this issue from the mailing list. Sign your name to your comments.

* {{OpenIssue}} 2006-01-28 raised by [http://rbach.priv.at/Microformats-IRC/2006-01-28#T075222 Tantek on #microformats]
*# ''Is hCard is really appropriate for a named phone bridge, or do we need something else for a named phone numbers that are neither people nor organizations (the current two precise semantics that can be defined by hCard). For example see the "Zakim" hCard on http://www.w3.org/2005/12/allgroupoverview.html''

*2006-02-03 raised by Brian
*# We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

* 2006-02-13 raised by [http://microformats.org/wiki/User:Eron_Wright Eron Wright]
*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''
*#* REJECTED POSTPONED. Not in vCard. There is no "altitude" component in vCard (RFC 2426), and thus (certainly for now) there won't be any in hCard. If a new version of vCard were to come out with altitude, then we would add it to hCard. At some point we may also consider adding explicit extensions beyond vCard, but if we were to do so, we would capture them first on the [[hcard-brainstorming]] page. See also [[geo-extension-elevation]].

* 2006-02-19 raised by Miika Mäkinen.
*# ''Couldn't the types for tel numbers be specified in a class? Now, for a phone number one needs to add the type as "visible" text, which is not always preferred. For example, type "Work", many times more suitable label could be "Office" or similar and sometimes you might not want to display any type information at all.''
*#* REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was attempted], and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the ''visible'' markup. Note that you can use abbreviations, e.g. <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> in order to present the type in a way that may better fit in with the rest of your presentation.

* 2006-02-23 raised by [http://www.thefutureoftheweb.com/ Jesse Skinner] and [http://www.thefutureoftheweb.com/blog/2006/1/hcard#comment1 Ben Buchanan].
*# ''Are multiple URLs allowed? The [http://microformats.org/wiki/hcard#Property_List Property List] suggests not, whereas email and tel have multiple type/value pairs. However, the [http://microformats.org/wiki/hcard-parsing#finding_hCard_properties parsing page] suggests multiple URLs are OK. Either way, it seems clear that a type cannot be associated with a URL. So how exactly does hCard deal with multiple URLs?''
*#* RESOLVED FAQ: Multiple URLs are allowed. Some consuming agents (Apple's AddressBook.app among them) don't have an interface for producing multiple URLs, but they are still valid in vCard and therefore hCard. --[[User:RyanKing|RyanKing]] 17:58, 12 Jun 2006 (PDT)

* {{OpenIssue}} 2006-03-07 raised by [http://tantek.com Tantek].
*# ''Issue 1: In 99% of the cases I am finding the need to explicitly do "n" markup, the person has a three word fn which is in the form "given-name additional-name(or initial) family-name". Should we make three word fn's into another shorthand notation to make this easier for authors?''

* 2006-04-06 raised by [[User:Evan|Evan]].
*# ''What is the relationship between the CATEGORY property and [[rel-tag]]? Can you add a tag to an hCard? How can you add a tag to a particular hcard on a page without tagging the other cards on a page?''
*#* ACCEPTED. Categories can optionally be represented as tags. The classname 'category' should always be used, but rel="tag" can optionally be used (in addition to the category classname). In the case that a rel-tag tag is used, the tag (as defined by [[rel-tag]]) is used for the category. Examples: (1) <code><nowiki>food</nowiki></code> and (2) <code><nowiki><a class="category" rel="tag" href="http://example.com/food">Food!</a></nowiki></code>. --[[User:RyanKing|RyanKing]] 15:16, 13 Jun 2006 (PDT)

* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].
*# ''When someone looks at the [[hcard|hCard]] pages, one sees no collection of real-world publishing of contact data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the [[process]] nor the hcard pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

* 2006-11-16 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''The "type" for "tel" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)].''
*#*A: REJECTED. This is a vCard issue, as the "type" taxonomy for "tel" is determined by vCard. We are not presently extending hCard beyond the properties and values in vCard.
*#** ''I'm not clear how you can "reject" a provably factual statement. What's the process of suggesting an update to vCard? [[User:AndyMabbett|Andy Mabbett]]''
*#***A: ACCEPTED PARTIAL RESOLVED. Unfortunately it is not clear what the process is for updating vCard. However, we can at least capture suggestions for improvement to vCard from this community which may be helpful once the process for updating vCard is understood. I've created [[vcard-suggestions]] for this purpose and added this suggestion. - Tantek
*#**** The vCard spec is updated by RFC, for example [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770]. [[User:AndyMabbett|Andy Mabbett]] 06:22, 12 Jan 2007 (PST)

* 2006-11-23 raised by [[User:AndyMabbett|Andy Mabbett]]
*# The specification should be "stand alone", and not normally require reference to the vCard specification.
*#*A: ACCEPTED PARTIAL. Agreed that [[hcard|hCard]] should be usable by typical web authors without having to dig through the vCard specification. Precise implementation of parsing etc. hCard properties however will likely require programmers to reference the specifics/grammars in the vCard specification which we will NOT replicate in the hCard specification in order to avoid inevitable introduction of errors due to duplication. And that being said, ''informative'' explanations may be a good idea, while the vCard property/value definitions are kept as ''normative''.
*#** Yes; my meaning was with reference to hCard publishing, not parsing-into-vCards. [[User:AndyMabbett|Andy Mabbett]]
*# ''The specification should state that "telephone numbers SHOULD adhere to [http://en.wikipedia.org/wiki/E.123 ITU-T Recommendation E.123]" (or perhaps "MUST").''
*#* ACCEPTED PARTIAL. This makes sense as an informative reference and a MAY, but since vCard makes no such SHOULD statement for TEL values, neither should/will hCard. In addition, as a Wikipedia URL that is subject to drastic change, we cannot make that a normative reference.
*#** I take your point about Wikipedia - here's [http://www.itu.int/rec/T-REC-E.123-200102-I/en a more definitive ITU-E.123 URL]; but it's for a chargeable document. Using "SHOULD" or "MUST" in hCard will not affect compatibility with or conversion to vCard. [[User:AndyMabbett|Andy Mabbett]]

* {{OpenIssue}} 2006-11-24 raised by [[User:AndyMabbett|Andy Mabbett]]
*# A suggested work-around for the lack of a gender property is to represent gender implicitly in the honorific-prefix field, e.g. Mr. for male, and Ms. for female. This approach does has the limitation that "Mr." and "Ms." (or "Miss"/ "Mrs.") conflicts with a higher-ranking, gender-neutral honorific, such as "Dr." or "Rev." for the person, as it is unusual (and sometimes, outside the USA, invalid) to refer to someone as "Mr. Dr." or "Mrs. Rev." for example. Note also that some cultures or religions regard such titles as offensive, or at least disdain them.

* {{OpenIssue}} 2006-12-07 raised by RyanKing.
*# ''hCard org-fn matching should use organization-name, if given.''
*# originally [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007337.html raised on uf-discuss] by David Janes.

* {{OpenIssue}} 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.
*# (Paraphrased) By including organisations and places, as well as people, hCards have lost semantic specificity (see cited mailing list post for details).
*#* [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009102.html Apparently intentional], but possibly requiring further extension. [[User:AndyMabbett|Andy Mabbett]]

* 2006-12-15 raised by [[User:WizardIsHungry|WizardIsHungry]]
*# ''[Moved from a user talk page] Hey, why is hiding semi-useful information using CSS bad? The Geo and Address stuff wouldn't be enough to contact me, but I would like there so bookmarklets, crawlers, greasemonkey etc can manipulate it. Is there a policy on using CSS hiding of fields? Thanks :)''
*#* I guess we can't rely that anything that consumes hCards is normalizing it to a particular format instead of just taking all the xml inside the hcard classed block and sticking it somewhere. If it does just store it as a string, then generating html from it will yield the same hidden fields. Perhaps hiding fields by applying a stylesheet to the relevant hcard styles is ok, but not hiding them using in-line CSS styling. Feedback? --[[User:WizardIsHungry|Jon Williams]] 10:28, 22 Dec 2006 (PST)
*#* Furthermore, [[hcard-example1-steps]] shows using inline CSS to hide fields. What gives? I still think this is an open issue; particularly the distinction between external stylesheet hiding and inline rules though. --[[User:WizardIsHungry|Jon Williams]] 13:33, 5 Jan 2007 (PST)
*#* Should this be on [[microformats-issues]]? --[[User:WizardIsHungry|Jon Williams]] 13:37, 5 Jan 2007 (PST)
*#** The example you cite is the first of several steps, which refine and improve the first step's suboptimal hCard.
*#*** The question is: ''why is this considered suboptimal if it is ok to hide the entire card?'''
*#**** REJECTED CLOSED TOO THEORETICAL. It is not OK to hide the entire card. Without further concrete examples with real world URLs on the web, this issue is closed.
*#***** Here are a number of examples of hiding the entire card, taken from [[hcard-examples-in-wild]]: [http://www.meryl.net/] [http://www.fberriman.com/] [http://www.fberriman.com/] [http://www.last.fm/user/Crok/?scrobbling=t1] -- Could someone link to where this was discussed and decided in the past, as it seems like this is being governed by fiat. Even if you don't care to have consensus, but could you at least justify this? This stonewalling is rather rude. --[[User:WizardIsHungry|Jon Williams]] 13:24, 9 Jan 2007 (PST)
*#* [[hcard-brainstorming#CSS_Styles]] explicitly permits this. I'm going with what they say.

=== 2007 ===

* 2007-01-22 raised by [[User:Christina Hope|Christina Hope]].
*# ''What is the easiest way to display an hCard all on one line with spacing. Currently I am using this - but I know that there has to be an easier/ simpler way to do it. Examples: (1) <pre><nowiki>

Christina Hope& nbsp;& nbsp;& nbsp;
Information Technology& nbsp;& nbsp;& nbsp;
Website Coordinator& nbsp;& nbsp;& nbsp;

 x3408 & nbsp;& nbsp;& nbsp;
<a href="mailto:chope@example.com">chope@example.com</a>
</nowiki></pre>''

:: Try <pre><nowiki>
Christina Hope
Information Technology
Website Coordinator
<abbr class="tel" title="+44123 456 7890 x 3408"> x3408</abbr>
<a class="email" href="mailto:chope@example.com">chope@example.com</a>
</nowiki></pre>

::Note: apply classes to existing elements; use abbr to give the phone number in full, in international format. Also, use CSS, not non- breaking spaces, for spacing.

::[[User:AndyMabbett|Andy Mabbett]] 08:34, 22 Jan 2007 (PST)

* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. abbr-design-pattern would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>

<abbr class="type" title="home">Casa</abbr> (preferido):
+1.415.555.1212

</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]

* 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# ''Proposal to use the class attribute for qname prefixed type values (and others such as dtstart values), AKA meta classes.'' <pre><nowiki>
Home (preferred): +1.415.555.1212
Casa (preferido): +1.415.555.1212
</nowiki></pre>
*#* REJECTED DUPLICATE ETC. Class attributes for type values [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was tried and rejected] and in addition, [[qnames-considered-harmful]].
*#* Clarified proposal, leaving REJECTED.

* {{OpenIssue}} 2007-01-30 raised by [[User:AndyMabbett|Andy Mabbett]]
*# Many sites, not least Wikipedia, publish co-ordinates as degrees-minutes-seconds (e.g. [http://en.wikipedia.org/wiki/Birmingham]). Should [[geo]] be extended to allow for this, with parsers making the conversion to digital values?

* {{OpenIssue}} 2007-02-02 raised by [[User::DerrickPallas|Derrick Pallas]]
*# [[adr]] says that all of it's properties are singular; however, "street-address" is listed as zero-or-more.

* {{OpenIssue}} 2007-02-25 [http://microformats.org/wiki?title=adr&diff=next&oldid=13732 raised elsewhere] by [[User:JamesCraig]]
*#internationalisation Note: <code>country-code</code> may be missing. Usually a postal-code prefix such as "FIN-00630 Helsinki" or "L-4750 Petange" (Luxembourg).

* {{OpenIssue}} 2007-03-19 raised by [[User::ChristinaHope|Christina Hope]]
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL?

* {{OpenIssue}} 2007-03-26 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Parsers (Operator, Tails) currently expect <code>adr</code> to have one or more children. It is not clear from the spec that that's mandatory; nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity. See [[hcard-brainstorming#ADR with no children]] for discussion.

* {{OpenIssue}} 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)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)

* {{OpenIssue}} 2007-04-09 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Why is [[geo]] still a draft, when it's included in the already-published [[hcard|hCard]] spec?

*{{OpenIssue}} 2007-04-19 raised by [[User:AndyMabbett|Andy Mabbett]]
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style , using the <code>abbr-design-pattern</code> if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?

*{{OpenIssue}} 2007-04-24 raised by [[User:Singpolyma|singpolyma]]
*# ''What is the 'Label' property for''

*{{OpenIssue}} 2007-05-08 raised by Tantek as a result of a message from [[User:AndyMabbett|Andy Mabbett]] on microformats-new
*#''How do you distinguish a '''place''' vs. an '''organization''' hCard, both from the perspective of a publisher (author) wishing to express the particular semantic, and from the perspective of a parser (developer) wishing to discern the difference? This is different from the 2006-12-15 issue on semantic specificity because this issue is *specifically* about place vs. org, rather than conflating that with person.''
*#Note: mailing list post cited in 2006-12-15 issue is quite clear; it says "''when a spider finds an hCard, it can't tell if it is a person, company, organization, or place.''".

* {{OpenIssue}} 2007-08-03 raised by [http://www.kaply.com/weblog/ MikeKaply].
*# ''Issue 1: When using the value design pattern, should the data be extracted completely (including HTML tags) or just text content? In general, the value pattern seems to imply taking the data exactly.''

* {{OpenIssue}} 2007-11-04 raised by [http://www.tomota.de/ RalfEngels].
*# ''Issue 1: The section Organization Contact Info is exeedingly vague. It says "I must not set the N property" and later on it says that I could set it to an empty value. Which of both is true? Must not or empty?''
*# ''Issue 2: Same section. It does not cover e.g. Mr Fischer (N=Fischer) from the Fischer AG (ORG=Fischer). Could you re-formulate it stating that if the N attribute is missing the hcard is regarded as the card of a company.''
*# ''Issue 3: Section "type subproperty values". The hcard example is the first place that shows a span with the type value. No further explanation how the value fields should be handled is given. The value only ever appears in examples in the whole specification.''
*# ''Issue 4: Grouping as specified by rfc2425 and supported by vcard cannote be expressed. Grouping allows you to express the relation between different values.''

== Template ==

Please use this format (copy and paste this to the end of the list to add your issues):
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

== Related Pages ==
{{hcard-related-pages}}

hcard-issues

2007-11-04T13:24:33Z

RalfEngels: /* 2007 */

<h1> hCard issues </h1>

These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See also related [[hcalendar-issues]].

__TOC__

== Closed Issues ==
Resolved issues that have no further actions to take. These will likely be moved to a separate page like [[hcard-issues-closed]].

* ...

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items. As issues are resolved, they will be moved from the top of the [[hcard-issues#Issues|Issues list]] to the bottom of this section.

* 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.
*#* 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.

== Issues ==
Please add new issues to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2005 ===
* 2005-06-21 raised by Hixie
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCards must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
*#*A: ACCEPTED RESOLVED. See [[hcard-parsing]] for how hCards must be parsed. For errors/unexpected content/missing content, please provide specific examples.

* 2005-06-30 raised by Jack L. Wolfgang II. Please feel free to move these to the FAQs if they are better suited there.
*# ''Handling middle names and suffixes: How does one handle middle initials/names in the hCard format and suffixes that are not honorific suffixes (e.g. Jr., Sr., II, III, etc. as opposed to Ph.D., Esq., M.D., etc.)?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]; 2006-11-16 updated by [[User:AndyMabbett|Andy Mabbett]]) hCard is based of the RFC2426 spec. I you want to use a middle initial it can be expanded using the abbr element. <code><abbr title="[MiddleName]" class="additional-name">M</abbr></code>. Honorific Suffixes in the RFC include Jr., Esq. and other inherited suffixes, so I would just use <code><abbr class="honorific-suffix" title="Junior">Jr.</abbr></code> etc.
*# ''Handling different types of addresses: How does one handle the TYPE (e.g. postal, work, etc.) specification for addresses as specified in RFC 2426 Section 3.2.1?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]) If you want to add a type to certain elements, including address and telephone it may be done in the following manner:
<pre><nowiki>

work:
...

</nowiki></pre>
<pre><nowiki>

work:
123.456.7890

</nowiki></pre>
the TYPE needs to be a sub-element of the property (adr, tel, etc) NOTE: EMAIL does NOT have many TYPE attributes, only INTERNET and X400

* 2005-07-22 raised by DanConnolly
*# ''...in my cellphone/sidekick address book, I have a number of entries for companies. I wrote [http://dev.w3.org/cvsweb/2001/palmagent/asHCard.xsl asHCard.xsl] to convert the data from RDF to hCard, but I don't know what to do with entries for companies, since FN is mandatory in hCard.''
*#*A: ACCEPTED FAQ. This should be an FAQ. "How do I write an hCard for a company?" The vCard specification is silent on this point (entries for companies). Thus there are two options as far as the hCard standard is concerned:
*#*# Set "fn" and "org" to the same value. E.g. <code>W3C</code> (recommended)
*#*# Set "org" as usual, and set "fn" explicitly to empty. E.g. <code>W3C</code> or
*#*#* Simply have no "fn", and on the parsing side, if there is no "fn" present, but there is an "org" property, then duplicate the "org" value as "fn"
*#*The last two options are effectively the same and are both not explicit and easily confusable with a "missing data" condition. Thus option 1 is preferred. For converting applications (hCard to vCard), they ''may'' consider using proprietary extensions to make the distinction explicit in generated vCards, based on either case 1 or 2 above. E.g. Apple's Address Book application supports the property: <code>X-ABShowAs:COMPANY</code>
*#*We are looking for descriptions of how other vCard supporting applications treat "company" vCards differently from "person" vCards. Please provide descriptions here:
*#** Address Book / MacOSX.3:
*#*** Export (e.g. drag & drop to desktop, view in text editor)
*#**** Sets "FN" and "ORG" to the name of the company
*#**** Sets proprietary <code>X-ABShowAs:COMPANY</code>
*#*** Import (e.g. edit in text editor, drag & drop from desktop)
*#**** By setting "FN" and "ORG' to the same name (e.g. Banana Computers Inc.)
*#**** And removing any proprietary properties (e.g. X-ABShowAs)
*#**** Address Book user interface showed new vCard as a "company" contact rather an a person
*#** Address Book MacOSX.4:
*#*** same results as above -RyanKing
*#** The Danger Hiptop (aka T-Mobile Sidekick) address book:
*#*** Export (e.g. [http://lists.w3.org/Archives/Public/www-archive/2005Sep/0007.html email to a mailing list])
*#**** Sets "FN" to the empty string and puts the company name in "ORG".
*#*** Import - could not find a way to import a .vcf, by email, IM, or other means into the Sidekick.
*#** Contacts / Outlook 2003 Windows
*#*** Export (e.g. Highlight contact, File, Save As, vcard)
*#**** Sets "N" and "ORG to the name of the company
*#**** Sets "FN" to value in "File as:"
*#** Add another vCard app here.

* 2005-07-23 raised by DanConnolly
*# ''Are class names case sensitive or not? [[hcard]] says "If names in the source schema are case-insensitive, then use an all lowercase equivalent."''
*#* A: ACCEPTED FAQ. Class names are case sensitive per the HTML4 specification. Hence hCard explicitly specifies the case of class name to use for source schema names that are case-insensitive.
*# ''...but I find example data with class="Given-Name"''
*#* A: ACCEPTED RESOLVED. That is from an older preliminary version of the hCard spec which used mixed case class names. Such class names are no longer valid hCard. Please note which examples (URLs) are using the older class names and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the lower-case style, this is a hold-over from the original design, X2V has been updated.
*# ''..and code that supports it [data with class="Given-Name"].''
*#* A: ACCEPTED RESOLVED. Any code supporting the older class name(s) is for backward compatibility only, and should be phased out. Any new hCard code SHOULD NOT support such mixed case class names.
*#** [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html rfc2629xslt.html] uses Street-Address, Family-Name, etc.
*#*** A: By [http://greenbytes.de/tech/webdav/ Julian Reschke] Fixed rfc2629.xslt (2005-10-29)
*#** [http://suda.co.uk/projects/X2V/ X2V] Version 0.5.1 2005-07-08 supports Family-Name etc.
*#*** A: By [http://suda.co.uk Brian Suda] I agree that the upper-case class names can be removed from the code, this was a hold-over and will be trimmed.
*# ''The ul/ol stuff for multiple values of a property seems to be in the X2V code and in [[hcard-brainstorming]] but not in the [[hcard]] spec.''
*#* A. ACCEPTED RESOLVED. This needs to be added to the spec. 2005-11-08 Update: the way multiple values has been updated to work much better and not require ul/ol.
*# ''the [[hcard-profile]] says country-name but X2V and lots of the data I've seen says country''
*#* A. ACCEPTED RESOLVED. RFC 2426 clearly says "country name" in both the prose and the grammar, thus "country-name" is the correct class name to use. If X2V uses just "country", it needs to be fixed to use "country-name", and any such examples as well. Please note which examples (URLs) are using the class name "country" and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the proper country-name, X2V will support this in the next iteration when i fix several bugs at once.

* 2005-08-12 raised by [http://home.alltel.net/jackwolfgang/contact/ Jack L. Wolfgang II]. Use of mailto transport functionality for the E-Mail address field.
*# ''As stated in the [[hcard-brainstorming]] document, mailto is abused by spammers. As a result, many organizations have moved to form-based contacts as opposed to mailtos. According to [http://www.ietf.org/rfc/rfc2426.txt RFC 2426], Section 3.3.2, "A non-standard value can also be specified." Does this refer to a non-standard e-mail address value or type value?''
*#* A: ACCEPTED FAQ. Type value.

* 2005-10-30 raised by [http://greenbytes.de/tech/webdav/ Julian Reschke].
*# ''Several implementations'' '''(Which ones? Please provide links.)''' ''seem to assume that any class attribute that contains the substring "vcard" indeed signals the presence of vcard information. Not so: there are examples'' '''(What examples? Please provide links.)''' ''of where a token in the class attribute indeed only ''starts with'' "vcard", in which it should be ignored. Implementations using XPath (such as XSLT or Greasemonkey scripts) should be advised to do a <code>contains(concat(@class,' '),'vcard ')</code>.
*#* REJECTED VAGUE. Which implementations? And which examples?
*#*''(Note: the code <code>contains(concat(@class,' '),'vcard ')</code> is broken see [[parsing-microformats#Parsing_class_values]] for a correct example --[[User:RobertBachmann|Robert Bachmann]])''

* 2005-12-08 raised by [http://www.heatonarts.com Kenny Heaton].
*# ''The specification gives no way to to declare a telephone extension, as in (800) 234-5678 ext. 101''
*#* ACCEPTED FAQ. What is the best way to declare a telephone extension in a "tel" property? (also seems like it would be a vCard FAQ).

=== 2006 ===

* 2006-01-21 raised by [http://inspire.server101.com/ben/resume/ Ben Boyle].
*# ''Have run into issues trying to use definition lists with hCard, specifically around nesting requirements for tel where the DT element takes a class "type" (e.g. Telephone, Facsimile) and the DD element marks the value. It is invalid to place any other elements within a DL that wrap around the DT/DD pairs so there is no available element to assign the class "tel" to. XHTML2 proposes a DI element that will resolve this issue. I am hoping for an interim solution for those that wish to use definition lists, perhaps that "any class that would be placed on the DI parent (in XHTML2) must instead be placed on the first DT element". I realise this will cause headaches for those implementing hCard parsers. I'd also like to note this may affect other (current or future) microformats and relates to the general hassle of definition lists in current (X)HTML recommendations. For your consideration - thanks!''
*#* REJECTED WORKAROUND AVAILABLE. Either don't use definition lists in this manner (because the description of a definition should go completely in the DD element, and thus you should be able to put the class on that), or use separate DLs in the cases where you would otherwise have needed a DI element.

* {{OpenIssue}} 2006-01-23 raised by David Janes (?).
* ''Issue 1: Specifying Authoritative or Canonical or Official Hcard''
** Use of rel="me" only specifies an alternate version, not necessarily the canonical version
** Suggestion: use rel="me self". Adopt "self" semantics from Atom which means "the", or controversially "alternate, equivalent" version
*** The combined use of rel="me" and rel="self" may conflict with their definitions in the [http://www.gmpg.org/xfn/11#me XFN Profile] and RFC 4287 respectively. See [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008443.html the mailing list discussion on rel="me self"] for more information. From [[User:RCanine|Ryan Cannon]].
** Suggestion: use rel="via". Per RFC 4287, via "signifies that the IRI in the value of the href attribute identifies a resource that is the source of the information provided in the containing element." from [[User:RCanine|Ryan Cannon]].
** Other suggestions? "authoritative", "canonical"?
** Problems with this suggestion?
** How does this relate to authentication/trust issues? Is this a different problem with a different scope?
*** (microformats-discuss list) Joe Andrieu: The concept behind an "authoritative" hCard rather than "definitive" or "canonical" one was that "authoritative" would explicitly be a ''claim'' by the author of the hCard regarding its authority in describing the subject of the hCard, i.e., use ''this'' hCard as the one true source of this individual's contact information.
*** To summarize: authentication/trust is a separate topic.
** What exactly is the scope of the problem to solve here?
*** (IRC) (10:47:44) sreynen: for example, all of the examples I've seen involve a single person publishing multiple hCards of himself
*** (IRC) (10:48:13) sreynen: yet many people are talking about 3rd parties publishing hCards and pointing back to the subject's own hCard
** rel="me" must be symmetrical, per the XFN spec. What exactly does this mean for this use?
** "me" (and, depending on usage, "self") are not appropriate for content referring to third- parties. [[User:AndyMabbett|Andy Mabbett]]
''TODO:'' please add appropriate context and history of this issue from the mailing list. Sign your name to your comments.

* {{OpenIssue}} 2006-01-28 raised by [http://rbach.priv.at/Microformats-IRC/2006-01-28#T075222 Tantek on #microformats]
*# ''Is hCard is really appropriate for a named phone bridge, or do we need something else for a named phone numbers that are neither people nor organizations (the current two precise semantics that can be defined by hCard). For example see the "Zakim" hCard on http://www.w3.org/2005/12/allgroupoverview.html''

*2006-02-03 raised by Brian
*# We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

* 2006-02-13 raised by [http://microformats.org/wiki/User:Eron_Wright Eron Wright]
*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''
*#* REJECTED POSTPONED. Not in vCard. There is no "altitude" component in vCard (RFC 2426), and thus (certainly for now) there won't be any in hCard. If a new version of vCard were to come out with altitude, then we would add it to hCard. At some point we may also consider adding explicit extensions beyond vCard, but if we were to do so, we would capture them first on the [[hcard-brainstorming]] page. See also [[geo-extension-elevation]].

* 2006-02-19 raised by Miika Mäkinen.
*# ''Couldn't the types for tel numbers be specified in a class? Now, for a phone number one needs to add the type as "visible" text, which is not always preferred. For example, type "Work", many times more suitable label could be "Office" or similar and sometimes you might not want to display any type information at all.''
*#* REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was attempted], and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the ''visible'' markup. Note that you can use abbreviations, e.g. <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> in order to present the type in a way that may better fit in with the rest of your presentation.

* 2006-02-23 raised by [http://www.thefutureoftheweb.com/ Jesse Skinner] and [http://www.thefutureoftheweb.com/blog/2006/1/hcard#comment1 Ben Buchanan].
*# ''Are multiple URLs allowed? The [http://microformats.org/wiki/hcard#Property_List Property List] suggests not, whereas email and tel have multiple type/value pairs. However, the [http://microformats.org/wiki/hcard-parsing#finding_hCard_properties parsing page] suggests multiple URLs are OK. Either way, it seems clear that a type cannot be associated with a URL. So how exactly does hCard deal with multiple URLs?''
*#* RESOLVED FAQ: Multiple URLs are allowed. Some consuming agents (Apple's AddressBook.app among them) don't have an interface for producing multiple URLs, but they are still valid in vCard and therefore hCard. --[[User:RyanKing|RyanKing]] 17:58, 12 Jun 2006 (PDT)

* {{OpenIssue}} 2006-03-07 raised by [http://tantek.com Tantek].
*# ''Issue 1: In 99% of the cases I am finding the need to explicitly do "n" markup, the person has a three word fn which is in the form "given-name additional-name(or initial) family-name". Should we make three word fn's into another shorthand notation to make this easier for authors?''

* 2006-04-06 raised by [[User:Evan|Evan]].
*# ''What is the relationship between the CATEGORY property and [[rel-tag]]? Can you add a tag to an hCard? How can you add a tag to a particular hcard on a page without tagging the other cards on a page?''
*#* ACCEPTED. Categories can optionally be represented as tags. The classname 'category' should always be used, but rel="tag" can optionally be used (in addition to the category classname). In the case that a rel-tag tag is used, the tag (as defined by [[rel-tag]]) is used for the category. Examples: (1) <code><nowiki>food</nowiki></code> and (2) <code><nowiki><a class="category" rel="tag" href="http://example.com/food">Food!</a></nowiki></code>. --[[User:RyanKing|RyanKing]] 15:16, 13 Jun 2006 (PDT)

* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].
*# ''When someone looks at the [[hcard|hCard]] pages, one sees no collection of real-world publishing of contact data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the [[process]] nor the hcard pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

* 2006-11-16 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''The "type" for "tel" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)].''
*#*A: REJECTED. This is a vCard issue, as the "type" taxonomy for "tel" is determined by vCard. We are not presently extending hCard beyond the properties and values in vCard.
*#** ''I'm not clear how you can "reject" a provably factual statement. What's the process of suggesting an update to vCard? [[User:AndyMabbett|Andy Mabbett]]''
*#***A: ACCEPTED PARTIAL RESOLVED. Unfortunately it is not clear what the process is for updating vCard. However, we can at least capture suggestions for improvement to vCard from this community which may be helpful once the process for updating vCard is understood. I've created [[vcard-suggestions]] for this purpose and added this suggestion. - Tantek
*#**** The vCard spec is updated by RFC, for example [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770]. [[User:AndyMabbett|Andy Mabbett]] 06:22, 12 Jan 2007 (PST)

* 2006-11-23 raised by [[User:AndyMabbett|Andy Mabbett]]
*# The specification should be "stand alone", and not normally require reference to the vCard specification.
*#*A: ACCEPTED PARTIAL. Agreed that [[hcard|hCard]] should be usable by typical web authors without having to dig through the vCard specification. Precise implementation of parsing etc. hCard properties however will likely require programmers to reference the specifics/grammars in the vCard specification which we will NOT replicate in the hCard specification in order to avoid inevitable introduction of errors due to duplication. And that being said, ''informative'' explanations may be a good idea, while the vCard property/value definitions are kept as ''normative''.
*#** Yes; my meaning was with reference to hCard publishing, not parsing-into-vCards. [[User:AndyMabbett|Andy Mabbett]]
*# ''The specification should state that "telephone numbers SHOULD adhere to [http://en.wikipedia.org/wiki/E.123 ITU-T Recommendation E.123]" (or perhaps "MUST").''
*#* ACCEPTED PARTIAL. This makes sense as an informative reference and a MAY, but since vCard makes no such SHOULD statement for TEL values, neither should/will hCard. In addition, as a Wikipedia URL that is subject to drastic change, we cannot make that a normative reference.
*#** I take your point about Wikipedia - here's [http://www.itu.int/rec/T-REC-E.123-200102-I/en a more definitive ITU-E.123 URL]; but it's for a chargeable document. Using "SHOULD" or "MUST" in hCard will not affect compatibility with or conversion to vCard. [[User:AndyMabbett|Andy Mabbett]]

* {{OpenIssue}} 2006-11-24 raised by [[User:AndyMabbett|Andy Mabbett]]
*# A suggested work-around for the lack of a gender property is to represent gender implicitly in the honorific-prefix field, e.g. Mr. for male, and Ms. for female. This approach does has the limitation that "Mr." and "Ms." (or "Miss"/ "Mrs.") conflicts with a higher-ranking, gender-neutral honorific, such as "Dr." or "Rev." for the person, as it is unusual (and sometimes, outside the USA, invalid) to refer to someone as "Mr. Dr." or "Mrs. Rev." for example. Note also that some cultures or religions regard such titles as offensive, or at least disdain them.

* {{OpenIssue}} 2006-12-07 raised by RyanKing.
*# ''hCard org-fn matching should use organization-name, if given.''
*# originally [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007337.html raised on uf-discuss] by David Janes.

* {{OpenIssue}} 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.
*# (Paraphrased) By including organisations and places, as well as people, hCards have lost semantic specificity (see cited mailing list post for details).
*#* [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009102.html Apparently intentional], but possibly requiring further extension. [[User:AndyMabbett|Andy Mabbett]]

* 2006-12-15 raised by [[User:WizardIsHungry|WizardIsHungry]]
*# ''[Moved from a user talk page] Hey, why is hiding semi-useful information using CSS bad? The Geo and Address stuff wouldn't be enough to contact me, but I would like there so bookmarklets, crawlers, greasemonkey etc can manipulate it. Is there a policy on using CSS hiding of fields? Thanks :)''
*#* I guess we can't rely that anything that consumes hCards is normalizing it to a particular format instead of just taking all the xml inside the hcard classed block and sticking it somewhere. If it does just store it as a string, then generating html from it will yield the same hidden fields. Perhaps hiding fields by applying a stylesheet to the relevant hcard styles is ok, but not hiding them using in-line CSS styling. Feedback? --[[User:WizardIsHungry|Jon Williams]] 10:28, 22 Dec 2006 (PST)
*#* Furthermore, [[hcard-example1-steps]] shows using inline CSS to hide fields. What gives? I still think this is an open issue; particularly the distinction between external stylesheet hiding and inline rules though. --[[User:WizardIsHungry|Jon Williams]] 13:33, 5 Jan 2007 (PST)
*#* Should this be on [[microformats-issues]]? --[[User:WizardIsHungry|Jon Williams]] 13:37, 5 Jan 2007 (PST)
*#** The example you cite is the first of several steps, which refine and improve the first step's suboptimal hCard.
*#*** The question is: ''why is this considered suboptimal if it is ok to hide the entire card?'''
*#**** REJECTED CLOSED TOO THEORETICAL. It is not OK to hide the entire card. Without further concrete examples with real world URLs on the web, this issue is closed.
*#***** Here are a number of examples of hiding the entire card, taken from [[hcard-examples-in-wild]]: [http://www.meryl.net/] [http://www.fberriman.com/] [http://www.fberriman.com/] [http://www.last.fm/user/Crok/?scrobbling=t1] -- Could someone link to where this was discussed and decided in the past, as it seems like this is being governed by fiat. Even if you don't care to have consensus, but could you at least justify this? This stonewalling is rather rude. --[[User:WizardIsHungry|Jon Williams]] 13:24, 9 Jan 2007 (PST)
*#* [[hcard-brainstorming#CSS_Styles]] explicitly permits this. I'm going with what they say.

=== 2007 ===

* 2007-01-22 raised by [[User:Christina Hope|Christina Hope]].
*# ''What is the easiest way to display an hCard all on one line with spacing. Currently I am using this - but I know that there has to be an easier/ simpler way to do it. Examples: (1) <pre><nowiki>

Christina Hope& nbsp;& nbsp;& nbsp;
Information Technology& nbsp;& nbsp;& nbsp;
Website Coordinator& nbsp;& nbsp;& nbsp;

 x3408 & nbsp;& nbsp;& nbsp;
<a href="mailto:chope@example.com">chope@example.com</a>
</nowiki></pre>''

:: Try <pre><nowiki>
Christina Hope
Information Technology
Website Coordinator
<abbr class="tel" title="+44123 456 7890 x 3408"> x3408</abbr>
<a class="email" href="mailto:chope@example.com">chope@example.com</a>
</nowiki></pre>

::Note: apply classes to existing elements; use abbr to give the phone number in full, in international format. Also, use CSS, not non- breaking spaces, for spacing.

::[[User:AndyMabbett|Andy Mabbett]] 08:34, 22 Jan 2007 (PST)

* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. abbr-design-pattern would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>

<abbr class="type" title="home">Casa</abbr> (preferido):
+1.415.555.1212

</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]

* 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# ''Proposal to use the class attribute for qname prefixed type values (and others such as dtstart values), AKA meta classes.'' <pre><nowiki>
Home (preferred): +1.415.555.1212
Casa (preferido): +1.415.555.1212
</nowiki></pre>
*#* REJECTED DUPLICATE ETC. Class attributes for type values [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was tried and rejected] and in addition, [[qnames-considered-harmful]].
*#* Clarified proposal, leaving REJECTED.

* {{OpenIssue}} 2007-01-30 raised by [[User:AndyMabbett|Andy Mabbett]]
*# Many sites, not least Wikipedia, publish co-ordinates as degrees-minutes-seconds (e.g. [http://en.wikipedia.org/wiki/Birmingham]). Should [[geo]] be extended to allow for this, with parsers making the conversion to digital values?

* {{OpenIssue}} 2007-02-02 raised by [[User::DerrickPallas|Derrick Pallas]]
*# [[adr]] says that all of it's properties are singular; however, "street-address" is listed as zero-or-more.

* {{OpenIssue}} 2007-02-25 [http://microformats.org/wiki?title=adr&diff=next&oldid=13732 raised elsewhere] by [[User:JamesCraig]]
*#internationalisation Note: <code>country-code</code> may be missing. Usually a postal-code prefix such as "FIN-00630 Helsinki" or "L-4750 Petange" (Luxembourg).

* {{OpenIssue}} 2007-03-19 raised by [[User::ChristinaHope|Christina Hope]]
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL?

* {{OpenIssue}} 2007-03-26 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Parsers (Operator, Tails) currently expect <code>adr</code> to have one or more children. It is not clear from the spec that that's mandatory; nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity. See [[hcard-brainstorming#ADR with no children]] for discussion.

* {{OpenIssue}} 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)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)

* {{OpenIssue}} 2007-04-09 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Why is [[geo]] still a draft, when it's included in the already-published [[hcard|hCard]] spec?

*{{OpenIssue}} 2007-04-19 raised by [[User:AndyMabbett|Andy Mabbett]]
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style , using the <code>abbr-design-pattern</code> if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?

*{{OpenIssue}} 2007-04-24 raised by [[User:Singpolyma|singpolyma]]
*# ''What is the 'Label' property for''

*{{OpenIssue}} 2007-05-08 raised by Tantek as a result of a message from [[User:AndyMabbett|Andy Mabbett]] on microformats-new
*#''How do you distinguish a '''place''' vs. an '''organization''' hCard, both from the perspective of a publisher (author) wishing to express the particular semantic, and from the perspective of a parser (developer) wishing to discern the difference? This is different from the 2006-12-15 issue on semantic specificity because this issue is *specifically* about place vs. org, rather than conflating that with person.''
*#Note: mailing list post cited in 2006-12-15 issue is quite clear; it says "''when a spider finds an hCard, it can't tell if it is a person, company, organization, or place.''".

* {{OpenIssue}} 2007-08-03 raised by [http://www.kaply.com/weblog/ MikeKaply].
*# ''Issue 1: When using the value design pattern, should the data be extracted completely (including HTML tags) or just text content? In general, the value pattern seems to imply taking the data exactly.''

* {{OpenIssue}} 2007-11-04 raised by [http://www.tomota.de/ RalfEngels].
*# ''Issue 1: The section Organization Contact Info is exeedingly vague. It says "I must not set the N property" and later on it says that I could set it to an empty value. Which of both is true? Must not or empty?''
*# ''Issue 2: Same section. It does not cover e.g. Mr Fischer (N=Fischer) from the Fischer AG (ORG=Fischer). Could you re-formulate it stating that if the N attribute is missing the hcard is regarded as the card of a company.''
*# ''Issue 3: Section "type subproperty values". The hcard example is the first place that shows a span with the type value. No further explanation how the value fields should be handled is given. The value only ever appears in examples in the whole specification.''

== Template ==

Please use this format (copy and paste this to the end of the list to add your issues):
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

== Related Pages ==
{{hcard-related-pages}}

hcard-issues

2007-11-04T10:45:15Z

RalfEngels: /* 2007 */

<h1> hCard issues </h1>

These are externally raised issues about [[hcard|hCard]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

'''IMPORTANT''': Please read the [[hcard-faq|hCard FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]

For matters relating to the vCard specification itself, see [[vcard-errata]] and [[vcard-suggestions]].

See also related [[hcalendar-issues]].

__TOC__

== Closed Issues ==
Resolved issues that have no further actions to take. These will likely be moved to a separate page like [[hcard-issues-closed]].

* ...

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items. As issues are resolved, they will be moved from the top of the [[hcard-issues#Issues|Issues list]] to the bottom of this section.

* 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.
*#* 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.

== Issues ==
Please add new issues to the '''bottom''' of the list by copy and pasting the [[hcard-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

=== 2005 ===
* 2005-06-21 raised by Hixie
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how hCards must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle unexpected content or missing content?
*#*A: ACCEPTED RESOLVED. See [[hcard-parsing]] for how hCards must be parsed. For errors/unexpected content/missing content, please provide specific examples.

* 2005-06-30 raised by Jack L. Wolfgang II. Please feel free to move these to the FAQs if they are better suited there.
*# ''Handling middle names and suffixes: How does one handle middle initials/names in the hCard format and suffixes that are not honorific suffixes (e.g. Jr., Sr., II, III, etc. as opposed to Ph.D., Esq., M.D., etc.)?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]; 2006-11-16 updated by [[User:AndyMabbett|Andy Mabbett]]) hCard is based of the RFC2426 spec. I you want to use a middle initial it can be expanded using the abbr element. <code><abbr title="[MiddleName]" class="additional-name">M</abbr></code>. Honorific Suffixes in the RFC include Jr., Esq. and other inherited suffixes, so I would just use <code><abbr class="honorific-suffix" title="Junior">Jr.</abbr></code> etc.
*# ''Handling different types of addresses: How does one handle the TYPE (e.g. postal, work, etc.) specification for addresses as specified in RFC 2426 Section 3.2.1?''
*#*A: ACCEPTED FAQ. By [http://suda.co.uk Brian Suda] (2005-11-08 updated by [http://tantek.com/log/ Tantek]) If you want to add a type to certain elements, including address and telephone it may be done in the following manner:
<pre><nowiki>

work:
...

</nowiki></pre>
<pre><nowiki>

work:
123.456.7890

</nowiki></pre>
the TYPE needs to be a sub-element of the property (adr, tel, etc) NOTE: EMAIL does NOT have many TYPE attributes, only INTERNET and X400

* 2005-07-22 raised by DanConnolly
*# ''...in my cellphone/sidekick address book, I have a number of entries for companies. I wrote [http://dev.w3.org/cvsweb/2001/palmagent/asHCard.xsl asHCard.xsl] to convert the data from RDF to hCard, but I don't know what to do with entries for companies, since FN is mandatory in hCard.''
*#*A: ACCEPTED FAQ. This should be an FAQ. "How do I write an hCard for a company?" The vCard specification is silent on this point (entries for companies). Thus there are two options as far as the hCard standard is concerned:
*#*# Set "fn" and "org" to the same value. E.g. <code>W3C</code> (recommended)
*#*# Set "org" as usual, and set "fn" explicitly to empty. E.g. <code>W3C</code> or
*#*#* Simply have no "fn", and on the parsing side, if there is no "fn" present, but there is an "org" property, then duplicate the "org" value as "fn"
*#*The last two options are effectively the same and are both not explicit and easily confusable with a "missing data" condition. Thus option 1 is preferred. For converting applications (hCard to vCard), they ''may'' consider using proprietary extensions to make the distinction explicit in generated vCards, based on either case 1 or 2 above. E.g. Apple's Address Book application supports the property: <code>X-ABShowAs:COMPANY</code>
*#*We are looking for descriptions of how other vCard supporting applications treat "company" vCards differently from "person" vCards. Please provide descriptions here:
*#** Address Book / MacOSX.3:
*#*** Export (e.g. drag & drop to desktop, view in text editor)
*#**** Sets "FN" and "ORG" to the name of the company
*#**** Sets proprietary <code>X-ABShowAs:COMPANY</code>
*#*** Import (e.g. edit in text editor, drag & drop from desktop)
*#**** By setting "FN" and "ORG' to the same name (e.g. Banana Computers Inc.)
*#**** And removing any proprietary properties (e.g. X-ABShowAs)
*#**** Address Book user interface showed new vCard as a "company" contact rather an a person
*#** Address Book MacOSX.4:
*#*** same results as above -RyanKing
*#** The Danger Hiptop (aka T-Mobile Sidekick) address book:
*#*** Export (e.g. [http://lists.w3.org/Archives/Public/www-archive/2005Sep/0007.html email to a mailing list])
*#**** Sets "FN" to the empty string and puts the company name in "ORG".
*#*** Import - could not find a way to import a .vcf, by email, IM, or other means into the Sidekick.
*#** Contacts / Outlook 2003 Windows
*#*** Export (e.g. Highlight contact, File, Save As, vcard)
*#**** Sets "N" and "ORG to the name of the company
*#**** Sets "FN" to value in "File as:"
*#** Add another vCard app here.

* 2005-07-23 raised by DanConnolly
*# ''Are class names case sensitive or not? [[hcard]] says "If names in the source schema are case-insensitive, then use an all lowercase equivalent."''
*#* A: ACCEPTED FAQ. Class names are case sensitive per the HTML4 specification. Hence hCard explicitly specifies the case of class name to use for source schema names that are case-insensitive.
*# ''...but I find example data with class="Given-Name"''
*#* A: ACCEPTED RESOLVED. That is from an older preliminary version of the hCard spec which used mixed case class names. Such class names are no longer valid hCard. Please note which examples (URLs) are using the older class names and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the lower-case style, this is a hold-over from the original design, X2V has been updated.
*# ''..and code that supports it [data with class="Given-Name"].''
*#* A: ACCEPTED RESOLVED. Any code supporting the older class name(s) is for backward compatibility only, and should be phased out. Any new hCard code SHOULD NOT support such mixed case class names.
*#** [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html rfc2629xslt.html] uses Street-Address, Family-Name, etc.
*#*** A: By [http://greenbytes.de/tech/webdav/ Julian Reschke] Fixed rfc2629.xslt (2005-10-29)
*#** [http://suda.co.uk/projects/X2V/ X2V] Version 0.5.1 2005-07-08 supports Family-Name etc.
*#*** A: By [http://suda.co.uk Brian Suda] I agree that the upper-case class names can be removed from the code, this was a hold-over and will be trimmed.
*# ''The ul/ol stuff for multiple values of a property seems to be in the X2V code and in [[hcard-brainstorming]] but not in the [[hcard]] spec.''
*#* A. ACCEPTED RESOLVED. This needs to be added to the spec. 2005-11-08 Update: the way multiple values has been updated to work much better and not require ul/ol.
*# ''the [[hcard-profile]] says country-name but X2V and lots of the data I've seen says country''
*#* A. ACCEPTED RESOLVED. RFC 2426 clearly says "country name" in both the prose and the grammar, thus "country-name" is the correct class name to use. If X2V uses just "country", it needs to be fixed to use "country-name", and any such examples as well. Please note which examples (URLs) are using the class name "country" and hopefully we can get them fixed.
*#** A: By [http://suda.co.uk Brian Suda] I have fixed all the references in the [[hcard-brainstorming]] page to reflect the proper country-name, X2V will support this in the next iteration when i fix several bugs at once.

* 2005-08-12 raised by [http://home.alltel.net/jackwolfgang/contact/ Jack L. Wolfgang II]. Use of mailto transport functionality for the E-Mail address field.
*# ''As stated in the [[hcard-brainstorming]] document, mailto is abused by spammers. As a result, many organizations have moved to form-based contacts as opposed to mailtos. According to [http://www.ietf.org/rfc/rfc2426.txt RFC 2426], Section 3.3.2, "A non-standard value can also be specified." Does this refer to a non-standard e-mail address value or type value?''
*#* A: ACCEPTED FAQ. Type value.

* 2005-10-30 raised by [http://greenbytes.de/tech/webdav/ Julian Reschke].
*# ''Several implementations'' '''(Which ones? Please provide links.)''' ''seem to assume that any class attribute that contains the substring "vcard" indeed signals the presence of vcard information. Not so: there are examples'' '''(What examples? Please provide links.)''' ''of where a token in the class attribute indeed only ''starts with'' "vcard", in which it should be ignored. Implementations using XPath (such as XSLT or Greasemonkey scripts) should be advised to do a <code>contains(concat(@class,' '),'vcard ')</code>.
*#* REJECTED VAGUE. Which implementations? And which examples?
*#*''(Note: the code <code>contains(concat(@class,' '),'vcard ')</code> is broken see [[parsing-microformats#Parsing_class_values]] for a correct example --[[User:RobertBachmann|Robert Bachmann]])''

* 2005-12-08 raised by [http://www.heatonarts.com Kenny Heaton].
*# ''The specification gives no way to to declare a telephone extension, as in (800) 234-5678 ext. 101''
*#* ACCEPTED FAQ. What is the best way to declare a telephone extension in a "tel" property? (also seems like it would be a vCard FAQ).

=== 2006 ===

* 2006-01-21 raised by [http://inspire.server101.com/ben/resume/ Ben Boyle].
*# ''Have run into issues trying to use definition lists with hCard, specifically around nesting requirements for tel where the DT element takes a class "type" (e.g. Telephone, Facsimile) and the DD element marks the value. It is invalid to place any other elements within a DL that wrap around the DT/DD pairs so there is no available element to assign the class "tel" to. XHTML2 proposes a DI element that will resolve this issue. I am hoping for an interim solution for those that wish to use definition lists, perhaps that "any class that would be placed on the DI parent (in XHTML2) must instead be placed on the first DT element". I realise this will cause headaches for those implementing hCard parsers. I'd also like to note this may affect other (current or future) microformats and relates to the general hassle of definition lists in current (X)HTML recommendations. For your consideration - thanks!''
*#* REJECTED WORKAROUND AVAILABLE. Either don't use definition lists in this manner (because the description of a definition should go completely in the DD element, and thus you should be able to put the class on that), or use separate DLs in the cases where you would otherwise have needed a DI element.

* {{OpenIssue}} 2006-01-23 raised by David Janes (?).
* ''Issue 1: Specifying Authoritative or Canonical or Official Hcard''
** Use of rel="me" only specifies an alternate version, not necessarily the canonical version
** Suggestion: use rel="me self". Adopt "self" semantics from Atom which means "the", or controversially "alternate, equivalent" version
*** The combined use of rel="me" and rel="self" may conflict with their definitions in the [http://www.gmpg.org/xfn/11#me XFN Profile] and RFC 4287 respectively. See [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008443.html the mailing list discussion on rel="me self"] for more information. From [[User:RCanine|Ryan Cannon]].
** Suggestion: use rel="via". Per RFC 4287, via "signifies that the IRI in the value of the href attribute identifies a resource that is the source of the information provided in the containing element." from [[User:RCanine|Ryan Cannon]].
** Other suggestions? "authoritative", "canonical"?
** Problems with this suggestion?
** How does this relate to authentication/trust issues? Is this a different problem with a different scope?
*** (microformats-discuss list) Joe Andrieu: The concept behind an "authoritative" hCard rather than "definitive" or "canonical" one was that "authoritative" would explicitly be a ''claim'' by the author of the hCard regarding its authority in describing the subject of the hCard, i.e., use ''this'' hCard as the one true source of this individual's contact information.
*** To summarize: authentication/trust is a separate topic.
** What exactly is the scope of the problem to solve here?
*** (IRC) (10:47:44) sreynen: for example, all of the examples I've seen involve a single person publishing multiple hCards of himself
*** (IRC) (10:48:13) sreynen: yet many people are talking about 3rd parties publishing hCards and pointing back to the subject's own hCard
** rel="me" must be symmetrical, per the XFN spec. What exactly does this mean for this use?
** "me" (and, depending on usage, "self") are not appropriate for content referring to third- parties. [[User:AndyMabbett|Andy Mabbett]]
''TODO:'' please add appropriate context and history of this issue from the mailing list. Sign your name to your comments.

* {{OpenIssue}} 2006-01-28 raised by [http://rbach.priv.at/Microformats-IRC/2006-01-28#T075222 Tantek on #microformats]
*# ''Is hCard is really appropriate for a named phone bridge, or do we need something else for a named phone numbers that are neither people nor organizations (the current two precise semantics that can be defined by hCard). For example see the "Zakim" hCard on http://www.w3.org/2005/12/allgroupoverview.html''

*2006-02-03 raised by Brian
*# We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

* 2006-02-13 raised by [http://microformats.org/wiki/User:Eron_Wright Eron Wright]
*# ''Few systems contemplate the altitude component of a coordinate, yet it exists. Altitude becomes important when working with 3D mapping software such as Google Earth. Indeed, the geocoding service that Google Earth uses returns a three-dimensional coordinate. I suggest that hCard provide explicit support for altitude.''
*#* REJECTED POSTPONED. Not in vCard. There is no "altitude" component in vCard (RFC 2426), and thus (certainly for now) there won't be any in hCard. If a new version of vCard were to come out with altitude, then we would add it to hCard. At some point we may also consider adding explicit extensions beyond vCard, but if we were to do so, we would capture them first on the [[hcard-brainstorming]] page. See also [[geo-extension-elevation]].

* 2006-02-19 raised by Miika Mäkinen.
*# ''Couldn't the types for tel numbers be specified in a class? Now, for a phone number one needs to add the type as "visible" text, which is not always preferred. For example, type "Work", many times more suitable label could be "Office" or similar and sometimes you might not want to display any type information at all.''
*#* REJECTED TRIED ALREADY. Using class names for the "type" of a tel or adr [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was attempted], and failed in many situations. In addition, the "type" information is actual data, not just a property name, and thus deserves to be in the ''visible'' markup. Note that you can use abbreviations, e.g. <code><nowiki><abbr class="type" title="work">W:</abbr></nowiki></code> in order to present the type in a way that may better fit in with the rest of your presentation.

* 2006-02-23 raised by [http://www.thefutureoftheweb.com/ Jesse Skinner] and [http://www.thefutureoftheweb.com/blog/2006/1/hcard#comment1 Ben Buchanan].
*# ''Are multiple URLs allowed? The [http://microformats.org/wiki/hcard#Property_List Property List] suggests not, whereas email and tel have multiple type/value pairs. However, the [http://microformats.org/wiki/hcard-parsing#finding_hCard_properties parsing page] suggests multiple URLs are OK. Either way, it seems clear that a type cannot be associated with a URL. So how exactly does hCard deal with multiple URLs?''
*#* RESOLVED FAQ: Multiple URLs are allowed. Some consuming agents (Apple's AddressBook.app among them) don't have an interface for producing multiple URLs, but they are still valid in vCard and therefore hCard. --[[User:RyanKing|RyanKing]] 17:58, 12 Jun 2006 (PDT)

* {{OpenIssue}} 2006-03-07 raised by [http://tantek.com Tantek].
*# ''Issue 1: In 99% of the cases I am finding the need to explicitly do "n" markup, the person has a three word fn which is in the form "given-name additional-name(or initial) family-name". Should we make three word fn's into another shorthand notation to make this easier for authors?''

* 2006-04-06 raised by [[User:Evan|Evan]].
*# ''What is the relationship between the CATEGORY property and [[rel-tag]]? Can you add a tag to an hCard? How can you add a tag to a particular hcard on a page without tagging the other cards on a page?''
*#* ACCEPTED. Categories can optionally be represented as tags. The classname 'category' should always be used, but rel="tag" can optionally be used (in addition to the category classname). In the case that a rel-tag tag is used, the tag (as defined by [[rel-tag]]) is used for the category. Examples: (1) <code><nowiki>food</nowiki></code> and (2) <code><nowiki><a class="category" rel="tag" href="http://example.com/food">Food!</a></nowiki></code>. --[[User:RyanKing|RyanKing]] 15:16, 13 Jun 2006 (PDT)

* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].
*# ''When someone looks at the [[hcard|hCard]] pages, one sees no collection of real-world publishing of contact data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the [[process]] nor the hcard pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''There should be some way to say that the URL of an hCard or hCalendar event is the URL of the page itself, without having to include a redundant, and accessibility-damaging link to that page, on the page itself.''
*#* Quite often I see "a" webpage accessible with several different URLs. Typically 1 URL is the "preferred" URL, expected to have a long lifetime. Sometimes other URLs are "convenience" URLs that may have been linked to in the past, but are expected to go away soon, which resolve to the same file (the "latest version"). Then there are "archive" URLs that show an exact copy of that webpage as it appeared some time in the past. I think we want to always use the "preferred" URL, no matter which of those URLs we happen to stumble upon first -- so the URL is not actually redundant. (How exactly is it "accessibility-damaging" for a page to link to itself? Could you explain or add a link to an explanation?) --[[User:DavidCary|DavidCary]] 17:44, 5 Apr 2007 (PDT)
*#**"''How exactly is it "accessibility-damaging" for a page to link to itself?''" - Novice user clicks on link; nothing (it appears) happens. Repeat ad infinitum, until user leaves site to do something else. [[User:AndyMabbett|Andy Mabbett]] 02:43, 6 Apr 2007 (PDT)
*#*A: ACCEPTED THEORETICAL. While I tend to agree with the accessibility guidelines/issues noted herein in theory, to make this a real world issue worthy of higher priority, we need documentation of examples in the wild where the URL of an hCard or hCalendar event is the URL of the page itself, so that we can use those examples to inform brainstorming towards a solution. [[User:Tantek|Tantek]] 15:11, 10 Apr 2007 (PDT)
*#** Examples in the wild where the URL of an hCard is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes] page at SXSW 2007 (1 of 1000+ bands). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCard for The Pipettes to indicate that the page itself is the URL for the hCard.
*#** Examples in the wild where the URL of an hCalendar event is the URL of the page itself:
*#*** [http://2007.sxsw.com/music/showcases/band/999918.html The Pipettes at La Zona Rosa] page at SXSW 2007 (1 of 1000+ concerts, yes, same page as the page for The Pipettes the org). There are no links to the page itself on the page to markup with class="url". Thus it would be nice to have a way for the hCalendar event for The Pipettes at La Zona Rosa to indicate that the page itself is the URL for the hCalendar event.
*#** This is also an [[hreview-issues|hReview issue]] and any other microformat which has a "url" property. Examples where the URL of an (potential) hReview *item* is the URL of the page itself:
*#*** [http://www.amazon.com/exec/obidos/ASIN/0553380958 Snow Crash (Bantam Spectra Book) (Paperback) on Amazon] (millions of potential hReview items/products with reviews on their item pages).

* 2006-11-16 raised by [[User:AndyMabbett|Andy Mabbett]]
*# ''The "type" for "tel" lacks a "textphone" option (for the devices used by, e.g., people who are deaf or have speech difficulties. Example: [http://www.birmingham.gov.uk/contact Birmingham City Council (303 1119)].''
*#*A: REJECTED. This is a vCard issue, as the "type" taxonomy for "tel" is determined by vCard. We are not presently extending hCard beyond the properties and values in vCard.
*#** ''I'm not clear how you can "reject" a provably factual statement. What's the process of suggesting an update to vCard? [[User:AndyMabbett|Andy Mabbett]]''
*#***A: ACCEPTED PARTIAL RESOLVED. Unfortunately it is not clear what the process is for updating vCard. However, we can at least capture suggestions for improvement to vCard from this community which may be helpful once the process for updating vCard is understood. I've created [[vcard-suggestions]] for this purpose and added this suggestion. - Tantek
*#**** The vCard spec is updated by RFC, for example [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770]. [[User:AndyMabbett|Andy Mabbett]] 06:22, 12 Jan 2007 (PST)

* 2006-11-23 raised by [[User:AndyMabbett|Andy Mabbett]]
*# The specification should be "stand alone", and not normally require reference to the vCard specification.
*#*A: ACCEPTED PARTIAL. Agreed that [[hcard|hCard]] should be usable by typical web authors without having to dig through the vCard specification. Precise implementation of parsing etc. hCard properties however will likely require programmers to reference the specifics/grammars in the vCard specification which we will NOT replicate in the hCard specification in order to avoid inevitable introduction of errors due to duplication. And that being said, ''informative'' explanations may be a good idea, while the vCard property/value definitions are kept as ''normative''.
*#** Yes; my meaning was with reference to hCard publishing, not parsing-into-vCards. [[User:AndyMabbett|Andy Mabbett]]
*# ''The specification should state that "telephone numbers SHOULD adhere to [http://en.wikipedia.org/wiki/E.123 ITU-T Recommendation E.123]" (or perhaps "MUST").''
*#* ACCEPTED PARTIAL. This makes sense as an informative reference and a MAY, but since vCard makes no such SHOULD statement for TEL values, neither should/will hCard. In addition, as a Wikipedia URL that is subject to drastic change, we cannot make that a normative reference.
*#** I take your point about Wikipedia - here's [http://www.itu.int/rec/T-REC-E.123-200102-I/en a more definitive ITU-E.123 URL]; but it's for a chargeable document. Using "SHOULD" or "MUST" in hCard will not affect compatibility with or conversion to vCard. [[User:AndyMabbett|Andy Mabbett]]

* {{OpenIssue}} 2006-11-24 raised by [[User:AndyMabbett|Andy Mabbett]]
*# A suggested work-around for the lack of a gender property is to represent gender implicitly in the honorific-prefix field, e.g. Mr. for male, and Ms. for female. This approach does has the limitation that "Mr." and "Ms." (or "Miss"/ "Mrs.") conflicts with a higher-ranking, gender-neutral honorific, such as "Dr." or "Rev." for the person, as it is unusual (and sometimes, outside the USA, invalid) to refer to someone as "Mr. Dr." or "Mrs. Rev." for example. Note also that some cultures or religions regard such titles as offensive, or at least disdain them.

* {{OpenIssue}} 2006-12-07 raised by RyanKing.
*# ''hCard org-fn matching should use organization-name, if given.''
*# originally [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007337.html raised on uf-discuss] by David Janes.

* {{OpenIssue}} 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.
*# (Paraphrased) By including organisations and places, as well as people, hCards have lost semantic specificity (see cited mailing list post for details).
*#* [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009102.html Apparently intentional], but possibly requiring further extension. [[User:AndyMabbett|Andy Mabbett]]

* 2006-12-15 raised by [[User:WizardIsHungry|WizardIsHungry]]
*# ''[Moved from a user talk page] Hey, why is hiding semi-useful information using CSS bad? The Geo and Address stuff wouldn't be enough to contact me, but I would like there so bookmarklets, crawlers, greasemonkey etc can manipulate it. Is there a policy on using CSS hiding of fields? Thanks :)''
*#* I guess we can't rely that anything that consumes hCards is normalizing it to a particular format instead of just taking all the xml inside the hcard classed block and sticking it somewhere. If it does just store it as a string, then generating html from it will yield the same hidden fields. Perhaps hiding fields by applying a stylesheet to the relevant hcard styles is ok, but not hiding them using in-line CSS styling. Feedback? --[[User:WizardIsHungry|Jon Williams]] 10:28, 22 Dec 2006 (PST)
*#* Furthermore, [[hcard-example1-steps]] shows using inline CSS to hide fields. What gives? I still think this is an open issue; particularly the distinction between external stylesheet hiding and inline rules though. --[[User:WizardIsHungry|Jon Williams]] 13:33, 5 Jan 2007 (PST)
*#* Should this be on [[microformats-issues]]? --[[User:WizardIsHungry|Jon Williams]] 13:37, 5 Jan 2007 (PST)
*#** The example you cite is the first of several steps, which refine and improve the first step's suboptimal hCard.
*#*** The question is: ''why is this considered suboptimal if it is ok to hide the entire card?'''
*#**** REJECTED CLOSED TOO THEORETICAL. It is not OK to hide the entire card. Without further concrete examples with real world URLs on the web, this issue is closed.
*#***** Here are a number of examples of hiding the entire card, taken from [[hcard-examples-in-wild]]: [http://www.meryl.net/] [http://www.fberriman.com/] [http://www.fberriman.com/] [http://www.last.fm/user/Crok/?scrobbling=t1] -- Could someone link to where this was discussed and decided in the past, as it seems like this is being governed by fiat. Even if you don't care to have consensus, but could you at least justify this? This stonewalling is rather rude. --[[User:WizardIsHungry|Jon Williams]] 13:24, 9 Jan 2007 (PST)
*#* [[hcard-brainstorming#CSS_Styles]] explicitly permits this. I'm going with what they say.

=== 2007 ===

* 2007-01-22 raised by [[User:Christina Hope|Christina Hope]].
*# ''What is the easiest way to display an hCard all on one line with spacing. Currently I am using this - but I know that there has to be an easier/ simpler way to do it. Examples: (1) <pre><nowiki>

Christina Hope& nbsp;& nbsp;& nbsp;
Information Technology& nbsp;& nbsp;& nbsp;
Website Coordinator& nbsp;& nbsp;& nbsp;

 x3408 & nbsp;& nbsp;& nbsp;
<a href="mailto:chope@example.com">chope@example.com</a>
</nowiki></pre>''

:: Try <pre><nowiki>
Christina Hope
Information Technology
Website Coordinator
<abbr class="tel" title="+44123 456 7890 x 3408"> x3408</abbr>
<a class="email" href="mailto:chope@example.com">chope@example.com</a>
</nowiki></pre>

::Note: apply classes to existing elements; use abbr to give the phone number in full, in international format. Also, use CSS, not non- breaking spaces, for spacing.

::[[User:AndyMabbett|Andy Mabbett]] 08:34, 22 Jan 2007 (PST)

* {{OpenIssue}} 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# RFC2426 'type' values cannot be localized/internationalized in hCard. In the example below, there is no solution to mark the Spanish version with a type of 'home' since the RFC2426 values are defined in English. abbr-design-pattern would suggest using abbr, but 'Casa' is not an abbreviated form of 'home', therefore the currently recommended version (below) is not valid.<pre><nowiki>

<abbr class="type" title="home">Casa</abbr> (preferido):
+1.415.555.1212

</nowiki></pre>
*#* REJECTED. TOO LITTLE INFORMATION. Please provide the precise URL to the specific statement on the accessify forum discussion that asserts that using abbr is not valid. Please also provide a precise URL to a *real world* (as opposed to an artificially constructed test case) example in the wild of an non-English hCard which attempts to specify RFC2426 type information on a "tel" property and fails to do so.
*#* REOPENED and clarified (Also removed Accessify reference pulled from [[http://microformats.org/wiki?title=accessibility&oldid=12943 original raising]]).
*#*# Though erroneously first raised on the accessibility page, this is not an accessibility issue. It is an HTML semantics issue for internationalization. <code>abbr[title]</code> should be an expanded form of <code>abbr</code> contents, in the same language.
*#*# There are real-world non-English examples in the current Mac OS 10.5 (Leopard) developer seed. This code example illustrates the point sufficiently.
*#*# Please leave the clarification as-is even if you feel you must RE-REJECT (add-on, don't revert). My original points were lost when they were taken out of context and moved here. -[[User::JamesCraig|JamesCraig]]

* 2007-01-26 raised by [[User::JamesCraig|JamesCraig]].
*# ''Proposal to use the class attribute for qname prefixed type values (and others such as dtstart values), AKA meta classes.'' <pre><nowiki>
Home (preferred): +1.415.555.1212
Casa (preferido): +1.415.555.1212
</nowiki></pre>
*#* REJECTED DUPLICATE ETC. Class attributes for type values [http://microformats.org/wiki/hcard-parsing#ISSUE_2 was tried and rejected] and in addition, [[qnames-considered-harmful]].
*#* Clarified proposal, leaving REJECTED.

* {{OpenIssue}} 2007-01-30 raised by [[User:AndyMabbett|Andy Mabbett]]
*# Many sites, not least Wikipedia, publish co-ordinates as degrees-minutes-seconds (e.g. [http://en.wikipedia.org/wiki/Birmingham]). Should [[geo]] be extended to allow for this, with parsers making the conversion to digital values?

* {{OpenIssue}} 2007-02-02 raised by [[User::DerrickPallas|Derrick Pallas]]
*# [[adr]] says that all of it's properties are singular; however, "street-address" is listed as zero-or-more.

* {{OpenIssue}} 2007-02-25 [http://microformats.org/wiki?title=adr&diff=next&oldid=13732 raised elsewhere] by [[User:JamesCraig]]
*#internationalisation Note: <code>country-code</code> may be missing. Usually a postal-code prefix such as "FIN-00630 Helsinki" or "L-4750 Petange" (Luxembourg).

* {{OpenIssue}} 2007-03-19 raised by [[User::ChristinaHope|Christina Hope]]
*# ''Does Microsoft Outlook 2003 allow the use of the "role" property? I have added it to all of my hCards and it is not appearing. Am I doing something wrong?''
*#** URL?

* {{OpenIssue}} 2007-03-26 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Parsers (Operator, Tails) currently expect <code>adr</code> to have one or more children. It is not clear from the spec that that's mandatory; nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity. See [[hcard-brainstorming#ADR with no children]] for discussion.

* {{OpenIssue}} 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)
*#* Note also the forthcoming [http://www.euref-iag.net/ European Terrestrial Reference System 89 schema] (See also [http://en.wikipedia.org/wiki/European_Terrestrial_Reference_System_1989 Etrs89 on Wikipedia]. [[User:AndyMabbett|Andy Mabbett]] 03:11, 5 Apr 2007 (PDT)

* {{OpenIssue}} 2007-04-09 raised by [[User:AndyMabbett|Andy Mabbett]]
*#Why is [[geo]] still a draft, when it's included in the already-published [[hcard|hCard]] spec?

*{{OpenIssue}} 2007-04-19 raised by [[User:AndyMabbett|Andy Mabbett]]
*#How should we handle [http://en.wikipedia.org/wiki/Old_Style_and_New_Style_dates Old Style and New Style dates] (i.e. Julian calendar vs. Gregorian), in DoB? For instance, [http://en.wikipedia.org/wiki/Boris_Pasternak Boris Pasternak], born "10 February [O.S. January 29] 1890". Should the hCard spec. specify New Style , using the <code>abbr-design-pattern</code> if necessary: <nowiki><abbr title="1890-02-10">29 January 1890</abbr></nowiki>?

*{{OpenIssue}} 2007-04-24 raised by [[User:Singpolyma|singpolyma]]
*# ''What is the 'Label' property for''

*{{OpenIssue}} 2007-05-08 raised by Tantek as a result of a message from [[User:AndyMabbett|Andy Mabbett]] on microformats-new
*#''How do you distinguish a '''place''' vs. an '''organization''' hCard, both from the perspective of a publisher (author) wishing to express the particular semantic, and from the perspective of a parser (developer) wishing to discern the difference? This is different from the 2006-12-15 issue on semantic specificity because this issue is *specifically* about place vs. org, rather than conflating that with person.''
*#Note: mailing list post cited in 2006-12-15 issue is quite clear; it says "''when a spider finds an hCard, it can't tell if it is a person, company, organization, or place.''".

* {{OpenIssue}} 2007-08-03 raised by [http://www.kaply.com/weblog/ MikeKaply].
*# ''Issue 1: When using the value design pattern, should the data be extracted completely (including HTML tags) or just text content? In general, the value pattern seems to imply taking the data exactly.''

* {{OpenIssue}} 2007-11-04 raised by [http://www.tomota.de/ RalfEngels].
*# ''Issue 1: The section Organization Contact Info is exeedingly vague. It says "I must not set the N property" and later on it says that I could set it to an empty value. Which of both is true? Must not or empty?''
*# ''Issue 2: Same section. It does not cover e.g. Mr Fischer (N=Fischer) from the Fischer AG (ORG=Fischer). Could you re-formulate it stating that if the N attribute is missing the hcard is regarded as the card of a company.''

== Template ==

Please use this format (copy and paste this to the end of the list to add your issues):
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

== Related Pages ==
{{hcard-related-pages}}