hcard-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(→‎Named locations: added named location formats section, GeoRSS, featurename, lack of documentation)
No edit summary
Line 1: Line 1:
<h1> hCard Brainstorming </h1>
{{TOC-right}}
This page is for brainstorming about various uses and details of [[hcard|hCard]].  This page contains <em>proposals</em>.  For the current state please see [[hcard|hCard]].


== Authors ==
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/ Tantek Çelik] (formerly of [http://technorati.com Technorati, Inc])
== Contributors ==
* [[User:Atamido|Atamido]]
* [[User:ChrisMessina|ChrisMessina]]
* [[User:DimitriGlazkov|DimitriGlazkov]]
* [[User:AndyMabbett|Andy Mabbett]]
* ...
* ... and many others
== Problems Being Solved ==
Some of the problems that [[hcard|hCard]] helps to solve:
* having to enter business cards that go out of date (subscribe to someone's syndicated [[hcard|hCard]] instead).
* annoying "update your contact info" email from various centralized contact info services
* [[social-network-portability]] through the use of [[hcard-supporting-user-profiles|hCard supporting user profiles]] and [[hcard-xfn-supporting-friends-lists|hCard+XFN supporting friends lists]]
== Named locations ==
Most hCards contain contact information for people or organizations. But locations that aren't organizations are also deserving of their own hCard (e.g. somebody's house/apartment). This situation can be represented by combining "fn" and "extended-address".
=== "fn" and "extended-address" combination ===
Similar to [[hcard#Organization_Contact_Info|organization contact info]], if the "fn" property and an "extended-address" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn extended-address"</code>), then
# The hCard represents contact information for a place and SHOULD be treated as such.
# The author also MUST NOT set the "N" property, or set it (and any sub-properties) explicitly to the empty string "".
# Parsers SHOULD handle the missing "n" property by implying empty values for all the "n" sub-properties.
=== Examples in the wild ===
* The named location "Picnic benches" in the address "Picnic benches, South Park, San Francisco, California" in [http://adactio.com/journal/1364/ a blog post on adactio.com].
<pre><nowiki>
<span class="vcard">
<span class="adr">
  <span class="fn extended-address">Picnic benches</span>
  <span class="street-address">South Park</span>
  <span class="locality">San Francisco</span>
  <span class="region">California</span>
</span>
</span>
</nowiki></pre>
==== Potential examples in the wild ====
* The location "Phone Boxes by the Sealife Centre" [http://upcoming.yahoo.com/venue/5668/ on Upcoming] is currently marked up as "fn org":
<pre><nowiki>
<div class="vcard">
<div class="fn org">Phone Boxes by the Sealife Centre</div>
  <div class="adr">
  <span class="street-address">Marine Parade</span><br />
  <span class="locality">Brighton &amp; Hove</span>,
  <span class="region">England</span>
  <span class="postal-code">BN2 1TB</span><br />
  <span class="country">United Kingdom</span><br />
  <span class="tel">01273 606674</span>
  </div>
<div class="note">Just a meeting place, in case the venue changes.</div>
</div>
</nowiki></pre>
This could be marked up as:
<pre><nowiki>
<div class="vcard">
<div class="adr">
  <div class="fn extended-address">Phone Boxes by the Sealife Centre</div>
  <span class="street-address">Marine Parade</span><br />
  <span class="locality">Brighton &amp; Hove</span>,
  <span class="region">England</span>
  <span class="postal-code">BN2 1TB</span><br />
  <span class="country">United Kingdom</span><br />
  <span class="tel">01273 606674</span>
  </div>
<div class="note">Just a meeting place, in case the venue changes.</div>
</div>
</nowiki></pre>
=== named location formats ===
Previous named location format efforts:
==== Simple GeoRSS featurename ====
The [http://georss.org/simple Simple GeoRSS] vocabulary contains the following named location example in the "Additional Properties" section that references a <strong><code>featurename</code></strong> tag.
<blockquote><h3>Feature Type, Feature Name, and Relationship Tags</h3><p>The Feature Type, Feature Name, and Relationship tags are specified as GeoRSS elements.</p><pre><nowiki>
    &lt;georss:point&gt;45.256 -110.45&lt;/georss:point&gt;
    &lt;georss:featuretypetag&gt;city&lt;/georss:featuretypetag&gt;
    &lt;georss:relationshiptag&gt;is-centered-at&lt;/georss:relationshiptag&gt;
    &lt;georss:featurename&gt;Podunk&lt;/georss:featurename&gt;
</nowiki></pre></blockquote>
A [http://www.google.com/search?q=site%3Ageorss.org%20featurename search for featurename on georss.org] fails to find any other references however, including a definition.
An [http://lists.eogeo.org/pipermail/georss/2006-December/000895.html email on the georss list from Dec 2006] thread "featurename, other missing bits from the site" notes that "there is some updating to do" in response to a concern that "that descriptions of "featurename" are not present on GeoRSS Simple and the GeoRSS Model. GeoRSS GML makes no mention of the non-geometric properties at all."
== FN Nickname semantic ==
There are many sites (e.g. [http://flickr.com Flickr], [http://consumating.com/ Consumating]) which permit the user to '''both''' have a multi-word login/handle/alias, '''and''' not show their ''real'' name (fn, n, given-name, family-name etc.).
For the people represented by the profile pages of these sites, the best we can do is mark-up their login/handle/alias as their "nickname". Originally, we had thought that such handles etc. were single words only, and thus we created the [[hcard#Implied_.22nickname.22_Optimization|Implied nickname optimization]] accordingly, where you can markup the handle as an "fn", and have it automatically set a "nickname" property value, and empty values for all the "n" sub-values.
In order to deal with multi-word handles, similar to the [[hcard#Organization_Contact_Info|hCard Organization contact info]] method, the following is proposed:
=== "fn" and "nickname" combination ===
Due to the use of potentially multi-word nicknames/handles/usernames in content published on the Web, (e.g. on sites like [http://flickr.com Flickr] and [http://consumating.com/ Consumating]), hCard has a mechanism for specifying a multi-word "fn" that is also a "nickname" without affecting any "n" sub-properties that are otherwise specified, and explicitly implying empty defaults for "n" sub-properties.
Similar to the [[hcard#Implied_.22nickname.22_Optimization|implied "nickname" optimization]], if the "fn" property and a "nickname" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn nickname"</code>), then
# The content of the "fn" is treated as a "nickname" property value.
# Parsers should handle the missing "n" property by implying empty values for all the "n" sub-properties.
== Implied FN from N ==
Since the "n" property is more detailed and structured than the "fn" property, and [[hcard-examples-in-wild]] have shown that very often what is specified for "n" sub-properties is also specified for the "fn" property, we could add the following implied "fn" optimization which would permit sites to only use "n" and its subproperties.
In addition, some sites don't have contiguous uninterrupted text that represents the desired "fn" value, and would much rather have the "fn" implied from "n" subproperties.  E.g. "Citizen Space Citizens" on [[hcard-examples-in-wild]].
=== implied "fn" from "n" optimization ===
If an hCard has no "fn", yet has an "n" property with one or more subproperties, then the "fn" property value can be implied by concatenating the "n" subproperty values as follows, with a space between each subproperty value, and multiple subproperty instances.
* 'honorific-prefix'es (as found in document order)
* 'given-name'
* 'additional-name's (as found in document order)
* 'family-name'
* 'honorific-suffix'es (as found in document order)
== Implied N from its subproperties ==
Since the "n" subproperties are sufficiently uniquely named (that is, they are not used by any other hCard property), and "n" is one of the [[hcard-singular-properties]], it is possible to consider leaving out the "n" property itself fo the hCard, and simply directlly using the subproperties, as properties of the hCard.
=== implied "n" from its subproperties ===
If an hCard has no "fn" nor "n" properties, then the entire scope of the hCard is considered to be inside an implied "n" property. 
E.g. this markup:
<pre><nowiki>
<span class="vcard">
<span class="given-name">Tantek</span>
<span class="family-name">Çelik</span>
</span>
</nowiki></pre>
would be treated from a parsing perspective as:
<pre><nowiki>
<span class="vcard"><span class="n">
<span class="given-name">Tantek</span>
<span class="family-name">Çelik</span>
</span></span>
</nowiki></pre>
Which, with the '''implied "fn" from "n" optimization''', would then be effectively treated as:
<pre><nowiki>
<span class="vcard"><span class="fn n">
<span class="given-name">Tantek</span>
<span class="family-name">Çelik</span>
</span></span>
</nowiki></pre>
* a related request from the mailing list: http://microformats.org/discuss/mail/microformats-discuss/2007-September/010791.html
== Examples ==
* See [[hcard-examples]], which provides several illustrative instructive examples, as well as 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].
=== Using RFC2806 with hCard ===
[http://www.ietf.org/rfc/rfc2806.txt RFC 2806] defines the telephone scheme "tel:", "fax:" and "modem:" to handle phone communications with URIs in the same way, "mailto:" is defined for email. It's part of the list or registered schemes by IANA : [http://www.iana.org/assignments/uri-schemes Uniform Resource Identifier (URI) SCHEMES]
<pre><nowiki>
tel  telephone [RFC2806]
fax  fax      [RFC2806]
modem modem    [RFC2806]
</nowiki></pre>
It is practical to write your tel number like this.
<pre><nowiki>
<a class="tel"      href="tel:+1-919-555-7878">+1-919-555-7878</a>
</nowiki></pre>
or even
<pre><nowiki>
<a class="tel"      href="tel:+1-919-555-7878">Mr Smith's phone</a>
</nowiki></pre>
You can add support for "tel:" to your desktop and to your browser
* For Gnome, edit ~/.gnome/Gnome and add something to the URL Handlers section. (Dan Connolly uses this to get galeon to launch telnum from [http://dev.w3.org/cvsweb/2001/telagent/ telagent sources] for tel URIs)
* In Mozilla, [http://dizzy.mozdev.org/ Dizzy]
* In Internet Explorer, [http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp Asynchronous Pluggable Protocols]
On the CSS front… You could for example add automagically an icon. I have put the property !important for those who wants to add it to their own stylesheet in their browsers, so they know type of links when browsing.
<pre><nowiki>
a[href^="tel:"]:before {
    content: '\260f  ' !important;
    padding-left: 20px !important; }
a[href^="mailto:"]:before {
    content: '\2709  ' !important;
    padding-left: 20px !important; }
</nowiki></pre>
== Encoding "modern" attributes ==
Since vCard was first established, various interactive communication technologies and addressing schemes have been widely adopted.  Although there aren't specific properties for these technologies / addressing schemes, they can be captured as URLs or email addresses.
This has now been written up for the most part. See:
http://microformats.org/wiki/hcard-examples#New_Types_of_Contact_Info
Still to be addressed:
* iChat mac.com  addresses, simply store "@mac.com" email addresses, e.g.
** <code><nowiki>&lt;a class="email" href="mailto:steve@mac.com"&gt;...</nowiki></code>
* MSN Instant Messenger, you can simple store "@hotmail.com" or "@msn.com" or "@passport.com" email addresses.
* Internet Relay Chat (IRC), use "irc:" URLs.
== Auto-Discovery ==
=== Representative hCard discovery ===
See [[representative-hcard]].
=== vCard link rel auto-discovery ===
A similar possibility is an auto discovery link in the head of the document could point to a URL (perhaps with transform) to a vCard version of the representative hCard.
On the page with the hCard encoding, the best link would be as follows:
<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
this HTML page is an alternate view of the vCard. 
The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”.
It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.
When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page.  Therefore rel="alternate" may not be appropriate.  The problem of what rel value to use is bigger than links to vCards.
=== hCard to hCard relationships ===
There are several types of hCard to hCard relationships, that is, one hCard hyperlinking to another hCard which would beneift from the explicit rel values that described the specific relationship.
==== mini hCard to expanded hCard ====
Perhaps the most common type of hCard to hCard link is a mini hCard, e.g. from a personal home page or blog to the person's contact/about page, perhaps consisting of only a name and URL, that links to an expanded hCard.  Examples in the wild:
In this instance, possible rel values might include:
* rel="expanded"
* rel="definitive" - the problem with this is that the expanded hCard is not necessarily a definitive version.
* rel="canonical" - similarly, the expanded hCard is not necessarily at a canonical URL.  It may simply be *an* expanded version, not *the* expanded version.
The following rel values have been suggested, but are not really a good idea due to the fact that they imply a dependence to add a new rel value for any new microformat which might have a mini-version linking to a more expanded version:
* rel="author"
* rel='contact'
* rel="contactinfo"
* rel='hcard'
* rel='person'
Here are some more generic values that have been suggested which perhaps make even less sense:
* rel='microformat' - this doesn't make any sense when you imagine a world where nearly every web page contains microformats.
* rel='about' - what does "about" have to do with a person or even authorship?
* rel="profile" - should be reserved for meaning here is an [[xmdp|XMDP]] profile for the current page.
* rel='PIM' - not sure about how this makes any sense either.
==== mini hCard to remote site ====
Per the instructions in [[hcard-examples]] for [[hcard-examples#References_to_People_in_Blogrolls|marking up people in blogrolls]], you might have an hCard of your site for another person which then links to that other person's website.  Should there be a rel value that indicates this "mini-hCard" to "person" relationship?
==== mini hCards and nearby expanded hCard links ====
Some authors include mini-hCards on their pages of themselves (e.g. in their blog posts), and yet those mini-hCards don't actually point to more expanded versions.  However, sometimes they have a separate but nearby link on the same page like "about" or "contact" that does link to an expanded hCard.
E.g. on [http://factoryjoe.com/blog/ FactoryCity], blog posts have mini-hCards for "published by", e.g. (white space added for readability):
<pre><nowiki>
Published by
<span class="vcard author">
<a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
  Chris Messina
</a>
</span>
</nowiki></pre>
On those same blog pages, there is a link labeled "Contact Information" that links to http://factoryjoe.com/blog/hcard/ which has an hCard with more information like phone number, birthday etc.
=== Auto-Discovery for XFN ===
An author will typically their XFN information on a specific page, rather than all pages.  In particular, a specific page separate from the home page of their blog, and thus it would be useful to have an explicit rel value to assist in auto-discovery of XFN information.
This was suggested by Jens Alfke on 20050606 at the WWDC blogger's dinner.
== geo improvements ==
''See [[geo-brainstorming]]''
== Other use cases ==
Please add your suggestions!
hCard microformats could be used to:
*Calculate and display the subject's age "as of today".
*Calculate and display the subject's age at death (if a [[hcard-date-of-death|Date of Death]] is available)
*Generate an recurring iCal for a living subject's birthday
*Generate an recurring iCal for a dead subject's "anniversary of birth" (if a [[hcard-date-of-death|Date of Death]] is available)
*...
== Issues with vCard Applications ==
See [[vcard-implementations]].
== Open Questions ==
Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile.
<pre><nowiki>
...
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a>
...
</nowiki></pre>
-- [http://suda.co.uk/ Brian Suda]
Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example:
<pre><nowiki>
<a href="http://mywebsite.com/" class="fn n">
    <span class="given-name">John</span>
    <span class="other-names">Q.</span>
    <span class="family-name">Public</span>
</a>
</nowiki></pre>
When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN:
<pre><nowiki>
John Q. Public
    John
    Q.
    Public
</nowiki></pre>
Either the white-space is preserved or it is not. Which should the transforming applications render?
-- [http://suda.co.uk/ Brian Suda]
A: The parsing application should follow the white space collapsing rules of the mime type it retrieves.  I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.
-- [http://tantek.com/log/ Tantek]
Many of the Questions and Answers are relevant to both ["hCal"] and hCard.
Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>
<span class="agent">
<span class="vcard">
  <span class="email">
  <a class="internet" href="mailto:jfriday@host.com">
    <dfn>
      <span class="fn">Joe Friday</span>
    </dfn>
  </a>
  </span>
  <span class="tel">+1-919-555-7878</span>
  <span class="title">Area Administrator, Assistant</span>
</span>
</span>
</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]
* If the answer to the above Q is "yes", why not use the following?
<pre><nowiki>
<dfn class="fn">Joe Friday</dfn>
</nowiki></pre>
or
<pre><nowiki>
<span class="agent">
<dfn class="vcard">
  <span class="email">
  <a class="internet" href="mailto:jfriday@host.com">
    <span class="fn">Joe Friday</span>
  </a>
  </span>
  <span class="tel">+1-919-555-7878</span>
  <span class="title">Area Administrator, Assistant</span>
</dfn>
</span>
</nowiki></pre>
This would mark the entire hcard as the "defining instance".
[[User:Bob Jonkman|Bob Jonkman]] 10:07, 13 Jul 2007 (PDT)
== Applications ==
Applications that are hCard aware or can convert hCard to vCard formats.
=== Copy hCards favelet(s) ===
* I think a Favelet would work nicely here. When you find a page that is hCard friendly, you click the favlet and you get yourself a vCard. This is done!  See X2V in the implementations section of the [[hcard|hCard]] spec.
=== Distributed Commentor Icons ===
''The URL reffered to in this section is no longer available. The thoughts on using icons are however still relevant.'' [[User:WilleRaab|WilleRaab]] 16:55, 23 Jul 2007 (PDT)
* See [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hCards in your blog] for an example of hCards used for comment authors (commentors).  The system used there, "Gravatars", is a centralized site that serves commentor icons that requires login etc. 
What if we gave each commentor the option of hosting their own icon?
A distributed commentor icon implementation could work like this:
# Given the URL of a commentor, look for an <code><address></code> element with classname of "vcard" at the commentor's URL.  The <code><address></code> element is supposed to be the contact information for the page (see [[hcard-faq|hCard FAQ]] for more info), so this makes sense.
# Next, look for the first element inside that hcard that has a classname of "logo".
# Hopefully that element is an <code><img></code>, and if so, use its src to get the commentor's icon.
# Presto.  You've got distributed commentor icons!
== Spam prevention ==
hCard uses <code>mailto:</code> links, and therefore
it automatically "inherits" the disadvantage of <code>mailto:</code> links:
These links can be easily detected by emails spiders (used by spammers).
Email addresses are picked up like any other link crawled by a search engine and trustworthy crawlers may be deterred from adding emphasis while indexing these links by including rel="nofollow" (See [[rel-nofollow]]). However, email addresses used for spam are crawled by email spiders which will likely ignore this attribute.
There are ways to prevent email address detection by simple email spiders, while
still retaining full compatibility with (X)HTML applications.
One common way is to "encode" the the "m" of "mail" and "@" with character entities, yet it's unwise to follow a convention of only encoding specific characters because the email spiders can pick up on this too:
Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>
Example of the "encoded" link (with rel-nofollow added):
<pre><nowiki>
<a class="e&amp;#109;ail" rel="nofollow" href="&amp;#109;ailto:john.smith&amp;#064;example.com">john.smith&amp;#064;example.com</a>
</nowiki></pre>
Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.
''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)
=== Other prevention methods to consider ===
* Using server-side code to implement character entities randomly
* Displaying the address in a way thought to be only human readable (thus breaking the link):
** Using an image instead of text (could still be machine readable using OCR)
** Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
* Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
* Pointing to an email form or other URL instead of an email address
== Tutorials ==
* How to hCard encode entries in Popular blog software.
* Good reasons to publish your hCard
** as a business, get people to put you in their address book so they'll find you later
** as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.
* [http://24ways.org/2006/styling-hcards-with-css Styling hCards with CSS] is a text on how to use CSS to make an improved presentation of an hCards contents.
== Parsing ==
See separate [[hcard-parsing|hCard parsing]] page for current hCard parsing rules.
Add thoughts/proposals to improve/add to hCard parsing here in this section in hCard brainstorming, and be sure to include URLs to examples of hCards in the wild which could benefit from parsing rule changes.
=== Additional Semantic HTML handling ===
==== <code>acronym</code> element handling ====
Choices:
* Explicitly treat <code>acronym</code> the same as <code>abbr</code>, per semantics of the '<code>title</code>' attribute on <code>acronym</code> in particular, as defined in HTML4.01.
* Explicitly treat <code>acronym</code> the same as <code>span</code>, and discourage use of <code>acronym</code>.
==== <code>input</code> element handling ====
In [[hcard-parsing]], I've defined special-case handling for several elements according to [[hcard-parsing#more_semantic_exceptions|more semantic exceptions]], e.g. textual properties on the <code>img</code> element use the 'alt' attribute.
One element I forgot at the time was the <code>input</code> element, specifically, <code><nowiki><input type="text"></nowiki></code>. Another I forgot was the <code>textarea</code> element.
The simple suggestion is to add the following to [[hcard-parsing]], specifically to the [[hcard-parsing#all_properties|all properties]] sub-section:
* <code>&lt;input type="text" value="..."&gt;</code>: use the value of the 'value' attribute. If there is no 'value' attribute then treat the value as empty. Interactive user-agents {{must}} use the [http://www.w3.org/TR/html4/interact/forms.html#current-value current value] of the element.
** consider other input types also (e.g. checkbox, radio, hidden) and specify how to parse them as well.
* <code>&lt;textarea&gt;</code>: use the text contents of the element. Interactive user-agents {{must}} use the [http://www.w3.org/TR/html4/interact/forms.html#current-value current value] of the element.
[[User:Tantek|Tantek]]
==== forms auto-fill ====
If you go to a site that needs your contact info for something, say an ecommerce site for checkout, and if the form fields are marked up with hCard semantics per the above, then perhaps we could consider having that mean "insert hCard here".
Interactive useragents (e.g. [[operator]] on [[firefox]]) could detect such "insert hCard here" semantics in forms on pages, and let you "pre-fill" with *your* hCard info, and then all of a sudden we have a standard for forms auto-fill, rather than all the hacks that have gone into browsers since 1999 (starting with IE4.5/Mac which I'm pretty sure was the first to do forms auto-fill of an entire form with a single button press - not just auto-complete of each form field individually).
Obviously this would make sense to build into *existing* forms auto-fill features in [[Firefox]] and [[IE]], and any other browsers that support it.
For more on this, see the 2007 August blog post [http://dbaron.org/log/2007-08#e20070818a hCard autofill?] by David Baron, a Mozilla employee.
This way new sites could simply conform to the standard, rather than depend on hacks which parse label values etc. and imply things and get them wrong sometimes.
'''[[i18n]]''' advantages: hCard annotated form inputs would also be more international, thus avoiding the need for each browser to guess what is the "name" and "telephone" field in every language, so they can do forms auto-fill on any site regardless of language, not just English.
[[User:Tantek|Tantek]] 16:24, 23 Jul 2007 (PDT)
==== Background discussion: ====
Key threads:
* http://microformats.org/discuss/mail/microformats-discuss/2006-September/005951.html
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006132.html
* http://microformats.org/discuss/mail/microformats-discuss/2007-January/008312.html
Somewhat related:
* http://microformats.org/wiki/rest/forms-brainstorming
* http://microformats.org/wiki/rest/forms-examples
One key summary:
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006172.html
The options discussed in a hypothetical hCard input system so far appear to be:
1) create a new root class other than vcard to indicate a form that's
fillable with hCard data.
Proposed markup:
<pre><nowiki>
<form class="vcard-input" ...>
  <fieldset class="fn">
      <input type="text" class="given-name" name="first_name" />
      <input type="text" class="family-name" name="last_name" />
  </fieldset>
  ...
</form>
</nowiki></pre>
  Benefits:
      Doesn't overcomplicate hCard with new parsing rules,
      doesn't require rewrite of existing parsers to ignore 'unparsable' data.
  Drawbacks:
      Requires completely new parsers to be written.
      Existing parsers would ignore data even if a valid hCard could be extracted.
2) extend hCard's parsing rules to cover form elements and relying on
the FORM/INPUT semantics to indicate that stuff is inputtable.
Proposed markup:
<pre><nowiki>
<form ...>
<div class="vcard">
  <fieldset class="fn">
      <input type="text" class="given-name" name="first_name" value="Rob" />
      <input type="text" class="family-name" name="last_name" value="Manson" />
  </fieldset>
  ...
</div>
<div class="vcard">
  <fieldset class="fn">
      <input type="text" class="given-name" name="first_name" value="Scott" />
      <input type="text" class="family-name" name="last_name" value="Reynen" />
  </fieldset>
  ...
</div>
</form>
</nowiki></pre>
  Benefits:
      Small addition to existing format rather than new one.
      Semantics of an input form and the eventual display format are the same.
  Drawbacks:
      Existing parsers would/could parse forms as invalid hCards, would need re-writing.
Broader question:
* http://microformats.org/discuss/mail/microformats-discuss/2005-September/001059.html
Should this be extended beyond just hCard?
==== Key Issues/discussion points ====
* Extending parsing rules to extract value attributes from <input type="text|hidden"> fields
  - ''Negative'' : this require adding a bit of special case to existing parsers to handle these elements
  - ''Positive'' : this could help to enable uf based auto form filling
  - ''Negative'' : this could help to enable uf based auto form filling (e.g. spam automation)
* Existing server side and client side scripts use non-hCard field names so class is the most seamless extension point
  - ''Positive'' : this is in line with the current parsing model
* Many parsers (e.g. [[Operator]]) parse the loaded html not the dynamic DOM
  - ''Negative'' : parser doesn't pickup any updated form data after the page has loaded
  - e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported
* Forms may contain more than one hCard so using <FORM class="vcard"> should not be required
  - ''Positive'' : this minimises the changes to current parsing rules
* Empty values should be ignored when extracting hCards
* hCards with all empty values should be ignored when listing/extracting hCards
* Which form elements should be supported beyond input fields
  - ''Examples''
    - title select that lists mr/mrs/ms/dr/etc.
    - checkboxes to choose which addresses to use
  - ''Option'' : simplify extension to only support input fields and recommend that select's, radio buttons and checkboxes update related hidden input fields with simple javascript (e.g. onChange/Click="this.form.elements[this.className].value = this.value")
    - Unworkable.  Cannot require clientside javascript.
  - ''Positive'' : this would simplify parsing and server side form processing as only single input fields for each value need to be used/validated
  - ''Negative'' : hCard forms then require javascript if they use form elements other than basic <input type="text|hidden">
  - ''Comment'' : either way any auto form filling will be more complex beyond simple <input type="text|hidden"> fields
    - hypothetical comment assuming more complexity beyond.
[[User:RobManson|RobManson]]
=== multiple type parsing ===
* Multiple Type parsing / Type Optimization:  The spec allows for, and the [[hcard-authoring#Phone_Numbers|hcard-authoring]] demonstrate the use of multiple type designations for a single value of tel. The syntax used in the authoring examples where each seems like it could become cumbersome. As these type designations are all single 'word' strings it may be possible to implement additional parsing rules to allow for multiple types inside the same HTML element. Handling delimiters may be an issue [space, comma, etc?], and some in-the-wild usage of multiple types would need to be located and examined before considering additional parsing rules along these lines [ [[User:ChrisCasciano|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]
=== fax and modem hyperlink parsing ===
For the "tel" property in particular, when the element is:
* <code>&lt;a href="fax:..."&gt;</code> OR <code>&lt;area href="fax:..."&gt;</code> : parse the value of the 'href' attribute, omitting the "fax:" prefix and any "?" query suffix (if present), in the attribute. For details on the "fax:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "fax" in addition to any explicit subproperty type specified on the 'tel' property.
* <code>&lt;a href="modem:..."&gt;</code> OR <code>&lt;area href="modem:..."&gt;</code> : parse the value of the 'href' attribute, omitting the "modem:" prefix and any "?" query suffix (if present), in the attribute. For details on the "modem:" URL scheme, see RFC 2806.  In addition, treat this 'tel' property instance as having subproperty type "modem" in addition to any explicit subproperty type specified on the 'tel' property.
=== Ambiguous name components ===
When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.
There's currently no easy answer to this.
One implementation suggestion is a 'best-guess' algorithm, something along the lines of:
# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"
The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.
===ADR with no children===
Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect <code>adr</code> to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity.
Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:
*[http://en.wikipedia.org/wiki/Old_Street_station Old Street]
**"Place" ("locale" in the template) is a '''street'''
*[http://en.wikipedia.org/wiki/Hamstead_railway_station Hamstead]
**"Place" is a '''local district'''
*[http://en.wikipedia.org/wiki/Inverness_railway_station Inverness]
**"Place" is a '''city'''
Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:
*[http://en.wikipedia.org/wiki/Tesco Tesco]
*[http://en.wikipedia.org/wiki/BP BP]
*[http://en.wikipedia.org/wiki/Google Google]
*[http://en.wikipedia.org/wiki/Blue_Coat_Systems Blue Coat Systems]
==== implied single adr subproperty ====
I propose that, where <code>adr</code> has content, but no explicit sub-properties, there should be a default sub-property to which that content is allocated, in order that it is captured by user agents, and can later be manually tweaked (in, say, an address book programme) by users if so desired. This would satisfy the vCard requirement for child-of-adr, and adhere to the general principle to "[[be-strict|be strict in what you send but generous in what you receive]]".
*Note that there may be other reasons to consider this suggestion, such as "ease of authoring". Another way of looking at this suggestion is as a "adr/extended-address shorthand". [[User:Tantek|Tantek]] 08:28, 26 Mar 2007 (PDT)
* there is also a LABEL property which is NOT structured data, but purely a text string to be used when labeling. LABEL purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents. [[User:Brian|Brian]] 13:18, 30 Mar 2007 (UTC)
**On re-reading this, it seems that none of the adressess given in my examples meet the criteria of being "''formatted text corresponding to delivery address''". [[User:AndyMabbett|Andy Mabbett]] 03:35, 17 Apr 2007 (PDT)
Of the available sub-property options:
*street-address
*extended-address
*region
*locality
I suggest that "extended-address" is the most sensible sub-property to use, for this purpose. [[User:AndyMabbett|Andy Mabbett]] 03:57, 26 Mar 2007 (PDT)
==== implied adr subproperties ====
It may be possible for parsers to parse out adr subproperties from a contiguous adr string.  This would be an optimization for both [[adr]] and [[hcard|hCard]].
This may also be too difficult/complex to be dependable or interoperable, but it is worth at least documenting our considerations and analysis either way.
Examples:
[http://www.ibm.com/contact/employees/us/ IBM's Employee Directory] search [http://www.ibm.com/contact/employees/servlets/lookup?country=us&language=en&search_country=all&lastname=Kaply&firstname=Michael returns hCards with the "adr" property] which contain the "locality" and "country-name" data but unfortunately without being marked up as such, e.g.:
<pre><nowiki>
<td class="adr">Austin, USA</td>
</nowiki></pre>
We could first define a canonical ordering of how to parse for comma (and perhaps in some cases space) separated adr subproperties within an adr string e.g.:
* 'post-office-box'
* 'street-address'
* 'extended-address'
* 'locality'
* 'region'
* 'postal-code'
* 'country-name'
Given a dictionary of country names and abbreviations, it may be feasible to parse for a country name at the end of the adr string, and then apply country/locale specific parsing rules to the rest of the adr string.
E.g.
* from a theoretical dictionary of country names:
** US|USA|United States|United States of America|Etats-Unis d'Amerique
* parse the remainder of the adr string backwards as follows:
** preceding that, look for a 5 or 9 digit (with optional dash '-' separator between digits 5 and 6) postal-code, and if found use it for the 'postal-code'
** preceding that, look for the name of a US state (e.g. California or any of the other states or territories available from a canonical list) or 2 letter state abbreviation (e.g. CA), and if found use it for the 'region' subproperty
** preceding that, look for the name of a US city (e.g. San Francisco, Los Angeles or any other US city available from a canonical list) or common city abbreviation (e.g. SF, LA), and if found use it for the 'locality'
** preceding that, look for common extended address details, such as: #|apt|apartment|suite|ste followed by a word consisting of letters and numbers, and if found use it for the 'extended-address'
** preceding that, look for a common street name bracketed by the street number (an integer with optional fraction and/or letter), and an optional street type (av|ave|avenue|blvd|boulevard|cir|circle|pl|place|st|street), and if found use it for the 'street-address'
** preceding that, look for a common post office box, with the pobox literal string: pob|pobox|PO Box followed by a word consisting of numbers and letters, and if found use it for the 'post-office-box'
* ... other countries
The above heuristic (not quite well specified enough to be an algorithm, yet) would allow parsing of the IBM Employee Directory result documented above.
There are a lot of existing geocoder APIs that turn unstructured addresses into structured ones - we should examine these for patterns and best practices. eg [http://www.google.com/apis/maps/documentation/#Geocoding_Structured Google's geocoder] [http://exogen.case.edu/projects/geopy/ geopy calls multiple ones]
==== adr without children FAQ ====
I think for now the simplest and most interoperable (and what I think implementations already do) is to make this an FAQ (because the spec already doesn't say to do anything with adr without any subproperty)
Q: What should a parser do with an "adr" property lacking any subproperties?
A: A parser SHOULD do nothing with such an "adr" property.  A parser MAY provide the text content of such an "adr" property in the results of its parsing as a freeform value of the "adr" property.  Note that the vCard standard does not allow for any such freeform value of its "adr" property (in vCard the "adr" property MUST be structured) and thus that MAY suggestion to parsers only applies in situations (such as APIs, JSON return values) where it is possible to return a freeform value for the "adr" property.
[[User:Tantek|Tantek]] 09:20, 2 Aug 2007 (PDT)
== Birthday Reminders ==
*hCard consumers could calculate the current age of hCard subjects, from the DoB. [[User:AndyMabbett|Andy Mabbett]] 07:47, 20 Apr 2007 (PDT)
*for hCards with DoB, hCard consumers could generate and export a recurring hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:06, 20 Apr 2007 (PDT)
**If/ when [[hcard-date-of-death|Date of Death]] is added to hCard, parsers could instead generate a recurring "death-anniversary" hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:08, 20 Apr 2007 (PDT)
== Post vCard additions ==
Keeping hCard properties and values as a 1:1 representation of vCard properties and values has numerous benefits such as simplicity, stability, interoperability with the vast number of existing vCard applications etc.
However some have found vCard to be limiting in terms of the data/properties/fields they want to express in contact information.  Some implementations use vCard extensions to express such information [citation needed].
This section is for documentation of such suggested additions.  Empirical evidence of actual *real world* examples on the Web of people publishing this information would be a good step towards considering any such additions/extensions.
* '''altitude'''. From [[hcard-issues]].
**See [[geo-elevation-examples]]
* '''vat-number''' : for VAT numbers of companies, which are used a lot in Europe and they need to be published on Belgian publications (including websites).
* '''gender'''
** See [[vcard-suggestions#Gender]]
* '''date-of-death'''
** See [[hcard-date-of-death]]
Thus see (and add to): [[vcard-suggestions]]
Another path to consider is the development of another microformat which includes an hCard and then extends it with additional properties for a particular domain. In many ways [[hresume|hResume]] has already done this. Other related efforts:
* [[genealogy]]
* [[profile]]
Using hCard as a stable building block for additional microformats may seem more desirable than incrementally growing hCard itself.
Of course if vCard were extended itself, that may provide impetus to add such extensions to hCard in order to maintain the 1:1
representation of properties/values.
==Wikipedia's Persondata==
Wikipedia's [http://en.wikipedia.org/wiki/Wikipedia:Persondata Persondata] aligns very closely with hCard, but has additional date and place of birth & death fields. [[User:AndyMabbett|Andy Mabbett]] 13:02, 28 Jan 2007 (PST)
== TODO ==
* The [[hcard-profile]] needs verification and perhaps a URL for retrieving the actual XMDP, rather than as &lt;pre&gt; text on a wiki page.
* Complete translating the examples from the vCard spec into hCard, and place them on a separate hCard examples page.
* Create a "rich" but realistic hCard example, say for example for a salesperson, who wants to put a whole bunch of contact information on their website in order to be found/contacted easily.
* Provide examples of how to encode instant messaging (IM) accounts. Figure out what would the mailto: or aim: URL in hCard look like in vCard. And take a look at what vCard applications do today with IM addresses.
* Clarify contradictory copyright statements, per http://microformats.org/discuss/mail/microformats-discuss/2007-July/010243.html
== CSS Styles ==
Not only can you create semantics with the hCard values, but you can add CSS styles to them as well. You are free to style the terms in any way you want, but here we can list a few ideas for how to style terms.
If you want to encode hCard data, but do NOT want to display it in the HTML code (WARNING: This is very much recommended AGAINST, and in general against the microformat principle of marking up visible data), then you can hide that tag in CSS with the following code:
<pre><nowiki>
<span style="display: none">Hidden Data</span>
</nowiki></pre>
Transforming applications will still find the data and use it when converting hCards to vCards.
== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF.
* [http://microid.org/ MicroID in hCard]
== Accepted Suggestions ==
=== Encoding Company data as a Business Card (proposal) ===
( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )
In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.
Proposal: hCards representing a business or organization MUST set fn AND org to the same value.  Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.
Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].
See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.
=== Implied "FN and N" Optimization (proposal) ===
Right now a parser first looks for an "n" element.
And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.
BACKGROUND:
Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.
PROPOSAL:
We should consider adding one more implied optimization after the steps documented above and that is:
If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.
This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]
== Rejected Suggestions ==
Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''
Rejected.  This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>
<span class="vcard">
...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...
</span>
</nowiki></pre>
There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.
== References ==
=== Normative References ===
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC
* [http://gmpg.org/xmdp/ XMDP]
=== Informative References ===
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]
* [http://www.icao.int/mrtd/download/technical.cfm ICAO - Machine Readable Travel Documents format]
== Related Pages ==
{{hcard-related-pages}}

Revision as of 23:31, 21 November 2007

Retrieved from "http://microformats.org/wiki/index.php?title=hcard-brainstorming&oldid=23474"