Microformats Wiki - User contributions [en]

recipe-issues

2008-10-02T15:58:33Z

CiaranMc: Comments on units issues

<h1> Recipe issues</h1>
{{TOC-right}}

This page reflects externally raised issues about [[recipe]] as well as the discussion that occurs on the microformats-new list (especially [http://microformats.org/discuss/mail/microformats-new/2007-September/000864.html here], [http://microformats.org/discuss/mail/microformats-new/2008-April/001599.html here], [http://microformats.org/discuss/mail/microformats-new/2008-June/001629.html here] and [http://microformats.org/discuss/mail/microformats-discuss/2008-September/012509.html here]). 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. Please read this page carfully ''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]

== issues ==
<span id="Issues">Please add new issues</span> to the '''bottom''' of this section by copy and pasting the [[recipe-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

{{OpenIssue}} Measure
*The abbr design pattern should be used to mark up measures, such as lbs and kg, measures are also not restricted to ingredients as they describe temperature too, as such should the sup element be used in the presentation of the degree symbol, within the abbr? See [http://www.bbc.co.uk/weather/5day.shtml?id=1081 BBC weather example] [[User:Lee Jordan|Lee Jordan]] 20:00, 4 Feb 2008 (GMT)
**The linked example doesn't include a SUP tag, the degree symbol can just be used as normal in most cases [[User:CiaranMc|Ciaran McNulty]]
*Conversion is tricky and is important, you've found a great recipe but it's measured in "cups". temperature is usually handled well by recipe authors, unless "gas mark" is used. The lang attribute (optional) could be used to denote the intentional language convention of the markup, to aid parsers "convert on the fly"? Is there currently a sematic way of marking up content as being metric or imperial? (complications come in mixed measure conventions in the same text section, so lang= on the abbr rather than the ul would help). A browser could then know the text was originally written in metric and convert to imperial if the user agent was en-GB, or a DOM script equally could aid conversion from cups to oz based on that? As an Englishman reading American text I find it hard to know what a "cup" is and then there are the Europeans to consider. Lang attributes might not be useful as for example en-US and en-GB measure distance in miles for example, rel="us-volume" (cups), rel="gb-volume" (tablespoons)? [[User:Lee Jordan|Lee Jordan]] 20:15, 4 Feb 2008 (GMT)
**Volume->weight conversions won't be possible without a substantially more complex markup (e.g. 1 cup of sugar weighs substantially more than 1 cup of flour) [[User:CiaranMc|Ciaran McNulty]]

===template===
{{issues-format}}

== closed issues ==
{{ClosedIssue}} <code>entry-title</code> and <code>entry-summary</code> are not always semantically right and may not be good class names.
* <code>title</code> and <code>summary</code> already used for a different purpose (in [[hCard]] and [[hCalendar]]/[[hReview]]/[[hListing]]). [[accepted-limitations-of-microformats#Microformat_Namespacing_Issue More | Read more]].
* <code>recipe-title</code> and <code>recipe-summary</code> suggested.
* Changed to <code>recipe-title</code> and <code>recipe-summary</code> for now.
{{ClosedIssue}} Scope of Recipes
*Is this intended for only food recipes, or also recipes for, say, glue, paint, dyes and other chemicals? [[User:AndyMabbett|Andy Mabbett]] 14:53, 16 Nov 2006 (PST)
** +1 Wondered the same. I'd like to see this extended as a general recipe for anything that can be created in a defined way/order, rather than just edible food.[[User:Phae|Frances Berriman]]
** Agreed. This format could apply to a set of methods and materials, including cooking, science experiments, craft making, building, etc. - essentially any how-to or tutorial. [[User:IamCam|Cameron Perry]]
** However, now I view my addition of 'calories per serving' as suspect, ;) though I guess it could still apply, since it's just a unit of energy. [[User:JohnLeMasney|John LeMasney]]
***Recipe for Nitroglycerine (not recommended by Weight Watchers) ? [[User:AndyMabbett|Andy Mabbett]] 10:43, 1 Feb 2007 (PST)
** The scope is determined by the [[recipe-examples]] research that is done, other musings are purely theoretical and thus discouraged. So far this means recipes means only food recipes. In addition, "recipe" in common vernacular applies primarily to food. Other uses are certainly outside the common 80/20 (note that 80/20 does note mean there are no non-food cases, merely that they are outside the 80). If you want to pursue other types of recipes, e.g. "chemical-recipes" - start that as a separate research effort per the [[process]]. [[User:Tantek|Tantek]] 07:39, 15 Mar 2007 (PDT)
*** Work is continuing on the recipe format now with the scope limited to food-based items only. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
*Is it possible to have special structure for the details of the operations in the cooking. For Eg. I invite you to have a look at the following Page [http://www.anthus.com/Recipes/CompCook.html]. Should it be possible to have special markup for the operations? Or is that going too far? Maybe we could keep this open ended so that it could be included when sites would actually be interested in including the same... Anyway the article makes for some interesting reading though it is from 1985 ;-) [[User:SudarshanP|SudarshanP]] 06:46, 26 Jun 2007 (PDT)
** I think this could be considered out of scope. It's the sort of thing that would be detailed in the descriptive narrative, but I'm not sure there's evidence from the examples that this type of behaviour is common enough to warrant specific properties to hold it. [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)

== resolved issues ==
{{ResolvedIssue}} Alternative Ingredients
We need a way to markup alternative ingredients.
* This is not entirely straight-forward. We should put this off for a future revision.
{{ResolvedIssue}} Photo
The 'photo' property should be usable for elements containing the element <code><img></code>.
* This format reuses the 'photo' property of [[hCard]] so we can't change the way it is parsed in the recipe format without also changing the way it is pased in hCard ([[hcard#Human_vs._Machine_readable|Human_vs._Machine_readable]]). This is an hCard problem and should not be discussed here.
{{ResolvedIssue}} Reliance on Measure Microformat
Mark-up of quantity would be enhanced by use of a [[measure]] microformat. However, such a format does not yet exist outside of brainstorming. It must be decided whether quantity is useful/parsable ''enough'' without explicit mark-up of values and units.
*Quantities play a key part in recipes, so do we feel the recipe format will rely on quantities so heavily that the measure microformat needs to be completed first, or do we feel it can exist without it and use of measure can be optional in the first version? [[User:Phae|Phae]] 08:44, 3 Oct 2007 (PDT)
**The former. [[User:AndyMabbett|Andy Mabbett]] 13:10, 4 Feb 2008 (PST)
**The use of a measure microformat should be optional. Otherwise it will prevent people from using less specific measurements like "a handful" or "a bottle" or just "some". [[User:Yde|Yde]] 08:59, 30 May 2008 (PDT)
* The ‘quantity’ of an ingredient should be considered as a string which parsers may attempt to understand as required. A future ‘measurement’ format will be an obvious compound part in recipes, but it is not required for recipe to be specified usefully. [http://microformats.org/discuss/mail/microformats-new/2007-September/000867.html], [http://microformats.org/discuss/mail/microformats-new/2008-April/001600.html]

== related pages ==
* [[recipe]]
* [[recipe-examples]]
* [[recipe-formats]]
* [[recipe-brainstorming]]

hresume-issues

2008-08-29T10:50:41Z

CiaranMc: /* Issues */

<h1> hResume issues </h1>

These are externally raised issues about [[hresume|hResume]] 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. 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/log/ Tantek]

See related [[hcalendar-issues]].
See related [[hcard-issues]].

__TOC__

== Issues ==

* {{OpenIssue}} 2007-10-02 raised by [[User:JeffMcNeill|jeffmcneill]].
*# ''Support for Awards and for Service sections are not currently implemented''
*#* I have attempted to use the Experience tag, however am unclear whether this will break things. Please see [http://jeffmcneill.com/microformats/hresume-jeffmcneill.html the example here]. --[[User:JeffMcNeill|jeffmcneill]] 04:09, 2 Oct 2007 (PDT)

* {{OpenIssue}} 2007-06-21 raised by [[User:Steve_Ganz|Steve Ganz]].
*# ''rel-tag can be difficult to implement for "skill" ''
*#* In Draft, version 0.1 it is required that each "skill" be marked up with rel-tag. While this is a good idea, and easy to do for individuals, it poses some challenges in the real world for large publishers of user generated resume data. If rel-tag was optional for "skills", it would be easier to implement.
*#* +1, expecting a resume author to link out to a hypothetical tagspace is an unnecessary barrier to entry. In reality authors end up linking to places like WikiPedia, which is not a real tagspace as defined in rel-tag. We should look at a more complex skill format for both this and the issue below opened by NTollervey. --[[User:CiaranMc|Ciaran McNulty]]

* {{OpenIssue}} 2007-01-04 raised by [[User:NTollervey|ntoll]].
*# ''With regard to the "skill" attributes in a resume: often skills have an indication of the level of attainment - be it as a descriptive "tag" or a duration denoting the length of experience of the referenced skill. In fact, abstracting out a "skill" microformat might be useful for re-use in the job-listing (Vacancy?) microformat. That way, job requirements can be married to CVs. Although not a job-site, I like Sourceforge.net's skill inventory feature (that captures both a level and length of experience) although I think its implementation is horrendous.''

* {{OpenIssue}} 2006-10-19 raised by [[RyanKing]].
*# ''There's currently no way to say 'present' in hCalendar''
*#* Many job experience listings will include jobs that the person is presently working at. Ciaran McNulty [http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html correctly pointed out] that a blank DTEND does not indicate that the event is still ongoing. We need to find an easy way to make this work in hResume.
*#* Any solution should also be a valid hCalendar, which makes things even more difficult. One possible solution would be to use an event without a DTEND for the current period of employment but have some extra class that indicates that within the semantics of hResume it's an ongoing event and let the hCalendar version just indicate the start of the employment. --[[User:CiaranMc|Ciaran McNulty]]

* {{OpenIssue}} 2006-10-19 raised by [[User:Steve_Ganz|Steve Ganz]].
*# ''There's currently no way to distinguish different hCard types in hResume''
*#* In Draft, version 0.1 it is specified that a parent element of <code>address</code> should be used to the distinguish an hCard as the subject's contact info. This proves problematic to implement because <code>address</code> cannot contain block level elements. To avoid sacrificing semantic value by restricting the child elements of an hCard to inline elements, we need to settle on an alternate method to classify a subject's hCard as thier contact info.
*#* In any given experience there may be one or more hCards. One which would be the subject's hCard for that experience and the other for a supervisor or manager, etc. We need a way to distinguish different hCards in a given experience.
:::* Agreed, when adding my references in hCard to the bottom of my hResume it became apparent there was no way I could mark 'my' hCard as the one belonging to the subject of the hResume. Perhaps @class="hcard subject" as a child of the hResume? [[User:CiaranMc|Ciaran McNulty]]

== Template ==

{{issues-format}}

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

hresume-examples-in-wild

2008-04-30T14:55:19Z

CiaranMc: /* New Examples */

<h1>hResume examples in the wild</h1>

This page is '''informative'''.

The following sites have published '''hResumes''', and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing, etc.

__TOC__

== New Examples ==
If you have an hResume on your own page, feel free to add it to the '''top''' of this list. Please be sure to include at least one URL to a page on your site that includes actual [[hresume|hResume]] markup. Examples added without a URL to a page with hResume markup may be removed.

* [[User:MarkNg|Mark Ng]] has marked up his [http://www.markng.co.uk/cv CV] with hResume.
* [[User:SidRoberts|Sid Roberts]] has marked up his [http://www.sidroberts.co.uk/cv/ CV] with hResume.
* [http://bergantinedesign.us/about/resume Joseph Bergantine] has marked up his resume with hResume
* [[User:NathanChase|Nathan Chase]] has marked up [http://www.nathanchase.com/resume.html his resume] with hResume.
* [[User:WikiObert|Alberto Ramacciotti]] has marked up an italian and an english version of his h[http://obertfsp.com/cv.html Resume].
* [[User:JaredEssig|Jared Essig]] has styled and marked up his h[http://prochor.us/resume Resume].
* [[User:Dreamisle|David Millar]] has *hopefully successfully* marked up [http://thegriddle.net/pages/resume his Resume] with hResume.
* [[User:Bczerniak|Brad Czerniak]] has created [http://brad.hawidu.com his Resume] with hResume.
* [[User:BenDodson|Ben Dodson]] has marked up [http://bendodson.com/cv/ his CV] with hResume.
* [[User:Twoplayer|Stephen Kelly]] has marked up his [http://www.twoplayer.net/stephen-kelly/cv.php CV] with hResume.
* [[User:MattWilliams|Matt Williams]] has marked up his [http://mattwilliamsnyc.com/resume/ resume] with hResume.
* [[User:Niall Kennedy|Niall Kennedy]] has marked up his [http://www.niallkennedy.com/about/resume.html résumé] with hResume.
* [[User:ManasTungare|Manas Tungare]] has marked up his [http://manas.tungare.name/resume/ Résumé] with hResume.
* [[User:Eferraiuolo|Eric Ferraiuolo]] has marked up his [http://eric.ferraiuolo.name/resume/ Resume] with hReesume
* [[User:ChristopheDucamp|Christophe Ducamp]] has marked up his [http://www.elanceur.org/CV_ChristopheDucampFr.html C.V.] with hResume
* [[User:RichardDavies|Richard Davies]] has marked up his [http://www.richarddavies.us/resume/ resume] as an hResume.
* [[User:JeffMcNeill|jeffmcneill]] has marked up [http://jeffmcneill.com/microformats/hresume-jeffmcneill.html his resume] with hResume
* Actor [[User:DavidSwain|David Swain]] has marked up his [http://davidswain.co.uk/cv cv] as an hResume.
* [[User:CiaranMc|Ciaran McNulty]] has marked up his [http://ciaranmcnulty.com/cv/html CV] as an hResume.
* [[User:RobCrowther|Rob Crowther]] has marked up his [http://www.dotrob.com/cv.html resume] as an hResume.
* [[User:Ajaswa|Andrew Jaswa]] has marked up his [http://www.gotkicked.net/hresume resume] as an hResume.
* [[User:ScottWallick|Scott Allan Wallick]] has [http://scottwallick.com/about/resume/ his resume] as an hResume.
* Ed Lau has [http://www.edlabs.net/ his resume] marked up with hResume.
* [[User:AndySmith|Andy Smith]] has marked up [http://ymkm.com/AndySmith.html his CV] with hResume.
* [[User:BruceDailey|Bruce Dailey]] has marked up his [http://www.jciti.com/cv/cv.php resume] as an hResume.
* [[User:JesseNewland|Jesse Newland]] has marked up his [http://resume.jnewland.com resume] as an hResume.
* [[User:Harriyott|Simon Harriyott]] has his [http://harriyott.com/cv.aspx curriculum vitae] as an hResume.
* [[User:BradT|Brad Touesnard]] has scraped together [http://brad.touesnard.com/documents/resume/ his resume] with the [http://brad.touesnard.com/projects/wordpress/linkedin-hresume/ LinkedIn hResume for Wordpress] plugin.
* [[User:ChadL|Chad Lindstrom]] has extended his [http://chadlindstrom.ca/resume/ resume] with hResume.
* Dawn Waswick has marked up [http://www.miniminx.com/portfolio/resume.cfm her CV] with hResume.
* [[User:Rolandinsh|Rolands Umbrovskis]] has [http://www.rolandinsh.lv/?ro=hResume marked up his CV] with hResume.
* [http://linkedin.com/ LinkedIn] has ~9 million Public Profiles marked up in hResume, e.g. [http://www.linkedin.com/in/steveganz Steve Ganz's Public Profile].
* [http://steinhardt.nyu.edu/ NYU Steinhardt] has [http://steinhardt.nyu.edu/faculty_bios/list/Faculty 240+ faculty bios marked up], e.g. [http://steinhardt.nyu.edu/faculty_bios/view/Susan_Murray]. ([[User:WizardIsHungry|Jon Williams]])
* [[User:ClintAndrewHall|Clint Hall]] has marked up his [http://www.clintandrewhall.com/resume.html resume] as an hResume.
* [[User:Csarven|Sarven Capadisli]] has marked up his [http://www.csarven.ca/cv Curriculum Vitae] as an hResume.
* [[User:Jax|Xavier Roy]] has marked his [http://xavierroy.com/resume/ resume] with hResume
* [[User:SanchTheFat|Robert O'Rourke]] has marked up his [http://robert.o-rourke.org/ CV] with hResume.
* [[User:Keri Henare|Keri Henare]] has marked up [http://www.kerihenare.com/cv/ his Curriculum Vitae] using hResume.
* [[User:Kwilson|Kenn Wilson]] has marked up [http://www.six23.net/resume/kenn-wilson.html his resume] using hResume, following [[User:Ralph Brandi|Ralph Brandi]]'s method of using object.include.
* [[User:Ralph Brandi|Ralph Brandi]] has [http://www.brandi.org/ralph/resume/ marked up his resume] with hResume, additionally using the object.include method to associate one description with three hCalendar experiences.
* [[User:Pat Ramsey|Pat Ramsey]] has his [http://www.patramsey.net/resume.html resume] marked up as an hResume.
* [[User:Wim Le Page|Wim Le Page]] has also marked up [http://adrem.ua.ac.be/~wlepage/curriculum-vitae/ his curriculum vitae] as an hResume.
* [[user:Jonathan Arkell|Jonathan Arkell]] has posted an [http://portfolio.jonnay.net/cv/ hResume] on his portfolio website.
* [http://steve.ganz.name/hresume/ Steve Ganz - hResume 0.1]
* [[User:Dave Cardwell|Dave Cardwell]] has marked up [http://davecardwell.co.uk/cv/ his curriculum vitae] as an hResume.
* [[User:EdwardOConnor|Edward O'Connor]]'s [http://edward.oconnor.cx/resume/ resume] is in hResume, and has some experimental JavaScript in it to extract a skill summary from the resume.
* [[User:Lindsey Simon|Lindsey Simon]] has his [http://www.commoner.com/~lsimon/lindsey_simon_resume.html resume] marked up as an hResume - with lots of thanks to Pat Ramsey.
* [[User:Ben Ward|Ben Ward]] has published [http://ben-ward.co.uk/cv his CV] with hResume.
* [http://www.kelleychambers.com Kelley Chambers] has published her [http://www.kelleychambers.com/resume resume] via [http://www.ssdesigninteractive.com/ssdesign/?p=96 Sajid Saiyed's Microformat hResume Plugin for Wordpress].
* [[User:Fishy5|Brennan Falkner]] used hResume to markup his [http://my.usf.edu/bbcswebdav/users/bfalker/resume.html resume].
* [http://www.zachary.com/creemer/resume.html David Creemer's resume] uses hResume, with thanks to Pat Ramsey for the CSS.
* [[User:ChristophBurgdorfer|Christoph Burgdorfer]] has integrated his hResume into a [http://emcons.net/index.php mashup].

== Examples with some problems ==

If you find a problem with any example in any other section, please move it here, and note the precise problem and cite the section of the [[hresume|hResume spec]] that appears to be violated. If the example that was moved here is yours, and you want to improve it, see the [[hresume-faq|hResume FAQ]], or raise any queries on [[hresume-issues|hResume Issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you. 

* Inga Scholes had <nowiki>http://inga-art.co.uk/cv</nowiki> her CV marked up with hResume.
** '''invalid''' - hResume version missing as of 2007-10-28.
* [[User:RudyDesjardins|Rudy Desjardins]] has marked up his [http://rudy.theendless.org/resume/index.html resume] as an hResume.
** '''Invalid''' : hCard seems invalid
* [[User:MattBosworth|Matt Bosworth]] has marked up his chronological [http://www.codetastic.com/resume-chrono.html resume] and his functional [http://www.codetastic.com/resume-functional.html resume] with hResume.
** '''Invalid''' -- hCalendar's summaries to be specified
* [[User:AndrewPendrick|Andrew Pendrick]] has marked up his [http://www.andrewpendrick.co.uk/cv.html resume] as an hResume.
**'''Invalid''' - hCalendars's summaries to be specified (per Operator).[[User:ChristopheDucamp|xtof]]
* [[User:WebOrganics|Martin McEvoy]] has cobbled together his [http://weborganics.co.uk/hResume/ resume] as a hResume.
**'''Invalid''' - Three hCalendars have empty summary; several tags are invalid (per Operator). [[User:AndyMabbett|Andy Mabbett]] 22:48, 1 Sep 2007 (PDT)
* [[User:DmytroShteflyuk|Dmytro Shteflyuk]] has marked up [http://kpumuk.info/curriculum-vitae/ his resume] as an hResume.
** Invalid; job titles contain hCards without a "fn" (either directly or via object). --[[User:Gazza|Gazza]] 04:27, 1 May 2007 (PDT)
* [[user:Izo|Mathieu Drouet]] has posted an [http://izo.aucuneid.com/hresume.html hResume].
** ''Incorrect root class name hResume? -- [[DavidJanes]]''
* [[User:Stauciuc|Sergiu Sebastian Tauciuc]] has his [http://www.sergiutauciuc.ro/en/cv.html curriculum vitae] as an hResume.
** '''Invalid''' - no contact vCard specified. [[User:AndyMabbett|Andy Mabbett]] 04:05, 10 Mar 2007 (PST)

== Reviewed Examples ==

If you have reviewed a New Example (and you are not the author of the example) and believe it to be valid, go ahead and move it here.
* ...

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

hresume-examples-in-wild

2008-04-30T14:54:44Z

CiaranMc: /* New Examples */

<h1>hResume examples in the wild</h1>

This page is '''informative'''.

The following sites have published '''hResumes''', and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing, etc.

__TOC__

== New Examples ==
If you have an hResume on your own page, feel free to add it to the '''top''' of this list. Please be sure to include at least one URL to a page on your site that includes actual [[hresume|hResume]] markup. Examples added without a URL to a page with hResume markup may be removed.

* [[User:MarkNg|Mark Ng]] has marked up his [http://www.markng.co.uk/cv CV] with hResume.
* [[User:SidRoberts|Sid Roberts]] has marked up his [http://www.sidroberts.co.uk/cv/ CV] with hResume.
* [http://bergantinedesign.us/about/resume Joseph Bergantine] has marked up his resume with hResume
* [[User:NathanChase|Nathan Chase]] has marked up [http://www.nathanchase.com/resume.html his resume] with hResume.
* [[User:WikiObert|Alberto Ramacciotti]] has marked up an italian and an english version of his h[http://obertfsp.com/cv.html Resume].
* [[User:JaredEssig|Jared Essig]] has styled and marked up his h[http://prochor.us/resume Resume].
* [[User:Dreamisle|David Millar]] has *hopefully successfully* marked up [http://thegriddle.net/pages/resume his Resume] with hResume.
* [[User:Bczerniak|Brad Czerniak]] has created [http://brad.hawidu.com his Resume] with hResume.
* [[User:BenDodson|Ben Dodson]] has marked up [http://bendodson.com/cv/ his CV] with hResume.
* [[User:Twoplayer|Stephen Kelly]] has marked up his [http://www.twoplayer.net/stephen-kelly/cv.php CV] with hResume.
* [[User:MattWilliams|Matt Williams]] has marked up his [http://mattwilliamsnyc.com/resume/ resume] with hResume.
* [[User:Niall Kennedy|Niall Kennedy]] has marked up his [http://www.niallkennedy.com/about/resume.html résumé] with hResume.
* [[User:ManasTungare|Manas Tungare]] has marked up his [http://manas.tungare.name/resume/ Résumé] with hResume.
* [[User:Eferraiuolo|Eric Ferraiuolo]] has marked up his [http://eric.ferraiuolo.name/resume/ Resume] with hReesume
* [[User:ChristopheDucamp|Christophe Ducamp]] has marked up his [http://www.elanceur.org/CV_ChristopheDucampFr.html C.V.] with hResume
* [[User:RichardDavies|Richard Davies]] has marked up his [http://www.richarddavies.us/resume/ resume] as an hResume.
* [[User:JeffMcNeill|jeffmcneill]] has marked up [http://jeffmcneill.com/microformats/hresume-jeffmcneill.html his resume] with hResume
* Actor [[User:DavidSwain|David Swain]] has marked up his [http://davidswain.co.uk/cv cv] as an hResume.
* [[User:CiaranMc|Ciaran McNulty]] has marked up his [http://ciaranmcnulty.com/cv/html CV as an hResume.
* [[User:RobCrowther|Rob Crowther]] has marked up his [http://www.dotrob.com/cv.html resume] as an hResume.
* [[User:Ajaswa|Andrew Jaswa]] has marked up his [http://www.gotkicked.net/hresume resume] as an hResume.
* [[User:ScottWallick|Scott Allan Wallick]] has [http://scottwallick.com/about/resume/ his resume] as an hResume.
* Ed Lau has [http://www.edlabs.net/ his resume] marked up with hResume.
* [[User:AndySmith|Andy Smith]] has marked up [http://ymkm.com/AndySmith.html his CV] with hResume.
* [[User:BruceDailey|Bruce Dailey]] has marked up his [http://www.jciti.com/cv/cv.php resume] as an hResume.
* [[User:JesseNewland|Jesse Newland]] has marked up his [http://resume.jnewland.com resume] as an hResume.
* [[User:Harriyott|Simon Harriyott]] has his [http://harriyott.com/cv.aspx curriculum vitae] as an hResume.
* [[User:BradT|Brad Touesnard]] has scraped together [http://brad.touesnard.com/documents/resume/ his resume] with the [http://brad.touesnard.com/projects/wordpress/linkedin-hresume/ LinkedIn hResume for Wordpress] plugin.
* [[User:ChadL|Chad Lindstrom]] has extended his [http://chadlindstrom.ca/resume/ resume] with hResume.
* Dawn Waswick has marked up [http://www.miniminx.com/portfolio/resume.cfm her CV] with hResume.
* [[User:Rolandinsh|Rolands Umbrovskis]] has [http://www.rolandinsh.lv/?ro=hResume marked up his CV] with hResume.
* [http://linkedin.com/ LinkedIn] has ~9 million Public Profiles marked up in hResume, e.g. [http://www.linkedin.com/in/steveganz Steve Ganz's Public Profile].
* [http://steinhardt.nyu.edu/ NYU Steinhardt] has [http://steinhardt.nyu.edu/faculty_bios/list/Faculty 240+ faculty bios marked up], e.g. [http://steinhardt.nyu.edu/faculty_bios/view/Susan_Murray]. ([[User:WizardIsHungry|Jon Williams]])
* [[User:ClintAndrewHall|Clint Hall]] has marked up his [http://www.clintandrewhall.com/resume.html resume] as an hResume.
* [[User:Csarven|Sarven Capadisli]] has marked up his [http://www.csarven.ca/cv Curriculum Vitae] as an hResume.
* [[User:Jax|Xavier Roy]] has marked his [http://xavierroy.com/resume/ resume] with hResume
* [[User:SanchTheFat|Robert O'Rourke]] has marked up his [http://robert.o-rourke.org/ CV] with hResume.
* [[User:Keri Henare|Keri Henare]] has marked up [http://www.kerihenare.com/cv/ his Curriculum Vitae] using hResume.
* [[User:Kwilson|Kenn Wilson]] has marked up [http://www.six23.net/resume/kenn-wilson.html his resume] using hResume, following [[User:Ralph Brandi|Ralph Brandi]]'s method of using object.include.
* [[User:Ralph Brandi|Ralph Brandi]] has [http://www.brandi.org/ralph/resume/ marked up his resume] with hResume, additionally using the object.include method to associate one description with three hCalendar experiences.
* [[User:Pat Ramsey|Pat Ramsey]] has his [http://www.patramsey.net/resume.html resume] marked up as an hResume.
* [[User:Wim Le Page|Wim Le Page]] has also marked up [http://adrem.ua.ac.be/~wlepage/curriculum-vitae/ his curriculum vitae] as an hResume.
* [[user:Jonathan Arkell|Jonathan Arkell]] has posted an [http://portfolio.jonnay.net/cv/ hResume] on his portfolio website.
* [http://steve.ganz.name/hresume/ Steve Ganz - hResume 0.1]
* [[User:Dave Cardwell|Dave Cardwell]] has marked up [http://davecardwell.co.uk/cv/ his curriculum vitae] as an hResume.
* [[User:EdwardOConnor|Edward O'Connor]]'s [http://edward.oconnor.cx/resume/ resume] is in hResume, and has some experimental JavaScript in it to extract a skill summary from the resume.
* [[User:Lindsey Simon|Lindsey Simon]] has his [http://www.commoner.com/~lsimon/lindsey_simon_resume.html resume] marked up as an hResume - with lots of thanks to Pat Ramsey.
* [[User:Ben Ward|Ben Ward]] has published [http://ben-ward.co.uk/cv his CV] with hResume.
* [http://www.kelleychambers.com Kelley Chambers] has published her [http://www.kelleychambers.com/resume resume] via [http://www.ssdesigninteractive.com/ssdesign/?p=96 Sajid Saiyed's Microformat hResume Plugin for Wordpress].
* [[User:Fishy5|Brennan Falkner]] used hResume to markup his [http://my.usf.edu/bbcswebdav/users/bfalker/resume.html resume].
* [http://www.zachary.com/creemer/resume.html David Creemer's resume] uses hResume, with thanks to Pat Ramsey for the CSS.
* [[User:ChristophBurgdorfer|Christoph Burgdorfer]] has integrated his hResume into a [http://emcons.net/index.php mashup].

== Examples with some problems ==

If you find a problem with any example in any other section, please move it here, and note the precise problem and cite the section of the [[hresume|hResume spec]] that appears to be violated. If the example that was moved here is yours, and you want to improve it, see the [[hresume-faq|hResume FAQ]], or raise any queries on [[hresume-issues|hResume Issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you. 

* Inga Scholes had <nowiki>http://inga-art.co.uk/cv</nowiki> her CV marked up with hResume.
** '''invalid''' - hResume version missing as of 2007-10-28.
* [[User:RudyDesjardins|Rudy Desjardins]] has marked up his [http://rudy.theendless.org/resume/index.html resume] as an hResume.
** '''Invalid''' : hCard seems invalid
* [[User:MattBosworth|Matt Bosworth]] has marked up his chronological [http://www.codetastic.com/resume-chrono.html resume] and his functional [http://www.codetastic.com/resume-functional.html resume] with hResume.
** '''Invalid''' -- hCalendar's summaries to be specified
* [[User:AndrewPendrick|Andrew Pendrick]] has marked up his [http://www.andrewpendrick.co.uk/cv.html resume] as an hResume.
**'''Invalid''' - hCalendars's summaries to be specified (per Operator).[[User:ChristopheDucamp|xtof]]
* [[User:WebOrganics|Martin McEvoy]] has cobbled together his [http://weborganics.co.uk/hResume/ resume] as a hResume.
**'''Invalid''' - Three hCalendars have empty summary; several tags are invalid (per Operator). [[User:AndyMabbett|Andy Mabbett]] 22:48, 1 Sep 2007 (PDT)
* [[User:DmytroShteflyuk|Dmytro Shteflyuk]] has marked up [http://kpumuk.info/curriculum-vitae/ his resume] as an hResume.
** Invalid; job titles contain hCards without a "fn" (either directly or via object). --[[User:Gazza|Gazza]] 04:27, 1 May 2007 (PDT)
* [[user:Izo|Mathieu Drouet]] has posted an [http://izo.aucuneid.com/hresume.html hResume].
** ''Incorrect root class name hResume? -- [[DavidJanes]]''
* [[User:Stauciuc|Sergiu Sebastian Tauciuc]] has his [http://www.sergiutauciuc.ro/en/cv.html curriculum vitae] as an hResume.
** '''Invalid''' - no contact vCard specified. [[User:AndyMabbett|Andy Mabbett]] 04:05, 10 Mar 2007 (PST)

== Reviewed Examples ==

If you have reviewed a New Example (and you are not the author of the example) and believe it to be valid, go ahead and move it here.
* ...

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

representative-hcard-brainstorming

2008-03-25T17:27:21Z

CiaranMc: /* contact hcard */

<h1>representative hCard brainstorming</h1>
{{TOC-right}}
Proposals for indicating on pages that represent individual people which [[hcard|hCards]] represents that person. Part of the [[representative-hcard]] effort.

== summary ==
* [[representative-hcard-authoring]] for the current best proposal for how to publish a representative hCard
* [[representative-hcard-parsing]] for the current best proposal for how to find a representative hCard on a page.

== proposals ==
Ways to auto discover the representative hCard for a page, that is the hCard that is the person (or organization) that the page represents.

=== url uid source and rel me ===
By Ryan King, Tantek Çelik 2007-10-23.

The basic technique for finding the representative hCard for a page:
# '''uid=url=source'''. use the first hCard on the page which has uid=url=source. That is, the <code>uid</code> property value of the hCard is also a <code>url</code> property value for the hCard, and that URL is the URL of the page as well.
# '''rel="me" on class="url"'''. otherwise use the first hCard which has a rel="me" class="url". That is, the first hCard that has a <code>url</code> property on an <code>a href</code> which also has <code>rel="me"</code>. Since a [[rel-me]] hyperlink {{must}} be from a page that represents a person to another page that represents the same person, if that "to" page is a <code>url</code> property value for an hCard then that hCard {{must}} be representative of both the "to" page and the page that the hCard is on. 
# otherwise no representative hCard can be identified.

=== rel me and url source else first ===
Originally collaboratively evolved on the [[hcard-brainstorming]] page:
# '''rel="me" on class="url"'''. check to see if there is an hCard with a "url" property on a rel="me" hyperlink (since rel="me" only works from a whole page to a whole page, if an hCard contains such a URL, then that hCard must represent the page. see [http://gmpg.org/xfn/and/#idconsolidation XFN identity consolidation] for more details.), and uses it if it finds it. (if there is more than one such hCard on the page? for now use the first such hCard.)
# '''url=source'''. check to see if there is an hCard with a "url" property that points to the current page, and use it if you find it. similar to the above rel="me" case, if an hCard is pointing to the current page, then it is likely that the hCard is about the current page. (if there is more than one such hCard on the page? for now use the first such hCard.)
# otherwise use the first hCard you find (which in cases of profile URLs which have a single hCard like on [http://flickr.com Flickr] and [http://technorati.com/ Technorati], will work as expected). (what about pages that don't represent individual people but have hCards? won't this result in false positives?)

==== user scenario ====
User scenario:
Here is a scenario that outlines a proposed representative hCard auto-discovery process:

# I (as user) give the URL of my homepage or hCard or other profile URL, to a site that wants a profile icon
# That site goes and gets it (e.g. using [[hKit]]), and then:
## checks to see if there is an hCard with a "url" property on a rel="me" hyperlink (since rel="me" only works from a whole page to a whole page, if an hCard contains such a URL, then that hCard must represent the page. see [http://gmpg.org/xfn/and/#idconsolidation XFN identity consolidation] for more details.), and uses it if it finds it. (if there is more than one such hCard on the page? for now use the first such hCard.)
## checks to see if there is an hCard with a "url" property that points to the current page, and uses it if it finds it. similar to the above rel="me" case, if an hCard is pointing to the current page, then it is likely that the hCard is about the current page. (if there is more than one such hCard on the page? for now use the first such hCard.)
## checks to see if there is an <nowiki><address></nowiki> hCard (thus meaning contact for the page), and uses it if it finds it. (what if there is more than one such hCard on the page? e.g. such as the multiple address hCards for hAtom entries. for now use the first such hCard.)
## otherwise uses the first hCard it finds (which in cases of profile URLs which have a single hCard like on [http://flickr.com Flickr] and [http://technorati.com/ Technorati], will work as expected).
# The site looks in the hCard for a "logo" property and uses the first one if it finds any.
# Otherwise it looks for a "photo" property and uses the first one if it finds any.
# Otherwise the site uses a default icon, but subscribes to the URL with the hCard and checks it for a "logo" or "photo", say, once a day.

===class=representative vcard===
Use of an additional class name, say <code>class="representative vcard"</code> (as an alternative to, or in addition to, the above patterns), would deal with the problems with the above proposals, as raised on [[representative-hcard-issues]]. It would also be quickly reusable for <code>class="representative vevent"</code> and other such microformats. A rule would require only one use of <code>class="representative"</code>, per microformat, per page. [[User:AndyMabbett|Andy Mabbett]] 16:10, 2 Feb 2008 (PST)

* As per Semantic XHTML Design Principles, wouldn't id="representative" be better than a class? [[User:TobyInk|TobyInk]] 09:01, 18 Feb 2008 (PST)

**A page could have a representative hCard and a representative hCalendar (or some other pair of representative microformats); but ID can only be used once. A workaround (I state this for the record, not as a recommendation) would be <code>ID="representative-hcard"</code>, etc. [[User:AndyMabbett|Andy Mabbett]] 09:31, 18 Feb 2008 (PST)

== author hcard / contact hcard ==

[[User:TobyInk|TobyInk]] 10:24, 22 Mar 2008 (PDT):

Related to the concept of a representative hCard are the concept of the author hcard and contact hcard for a page. In many cases, all three will be the same hCard, though sometime they will differ. Here are some ideas for how to identify the author and contact hcards. (This section perhaps should be spun off as its own page?)

=== author hcard ===

An hCard linked to with rel="author" (for hysterical raisins, rev="made" should also be recognised), is the author hCard. A page may have multiple authors. rel="author" and rev="made" are defined by HTML 5.

hAtom already uses class="author vcard" to identify the feed author, which also has the advantage (or maybe limitation) that it does not have an existing 'applies to the whole page' semantic like rel does (consider a page of blog posts with different authors).

=== contact hcard ===

An hCard found in an <address> element represents the contact for the page, or for a major section of the page.

It is important to note that <address> is block level and may only contain inline elements, so is very hard to include into existing designs.

== related pages ==
* {{representative-hcard-related-pages}}

representative-hcard-brainstorming

2008-03-25T17:25:55Z

CiaranMc: /* author hcard */

<h1>representative hCard brainstorming</h1>
{{TOC-right}}
Proposals for indicating on pages that represent individual people which [[hcard|hCards]] represents that person. Part of the [[representative-hcard]] effort.

== summary ==
* [[representative-hcard-authoring]] for the current best proposal for how to publish a representative hCard
* [[representative-hcard-parsing]] for the current best proposal for how to find a representative hCard on a page.

== proposals ==
Ways to auto discover the representative hCard for a page, that is the hCard that is the person (or organization) that the page represents.

=== url uid source and rel me ===
By Ryan King, Tantek Çelik 2007-10-23.

The basic technique for finding the representative hCard for a page:
# '''uid=url=source'''. use the first hCard on the page which has uid=url=source. That is, the <code>uid</code> property value of the hCard is also a <code>url</code> property value for the hCard, and that URL is the URL of the page as well.
# '''rel="me" on class="url"'''. otherwise use the first hCard which has a rel="me" class="url". That is, the first hCard that has a <code>url</code> property on an <code>a href</code> which also has <code>rel="me"</code>. Since a [[rel-me]] hyperlink {{must}} be from a page that represents a person to another page that represents the same person, if that "to" page is a <code>url</code> property value for an hCard then that hCard {{must}} be representative of both the "to" page and the page that the hCard is on. 
# otherwise no representative hCard can be identified.

=== rel me and url source else first ===
Originally collaboratively evolved on the [[hcard-brainstorming]] page:
# '''rel="me" on class="url"'''. check to see if there is an hCard with a "url" property on a rel="me" hyperlink (since rel="me" only works from a whole page to a whole page, if an hCard contains such a URL, then that hCard must represent the page. see [http://gmpg.org/xfn/and/#idconsolidation XFN identity consolidation] for more details.), and uses it if it finds it. (if there is more than one such hCard on the page? for now use the first such hCard.)
# '''url=source'''. check to see if there is an hCard with a "url" property that points to the current page, and use it if you find it. similar to the above rel="me" case, if an hCard is pointing to the current page, then it is likely that the hCard is about the current page. (if there is more than one such hCard on the page? for now use the first such hCard.)
# otherwise use the first hCard you find (which in cases of profile URLs which have a single hCard like on [http://flickr.com Flickr] and [http://technorati.com/ Technorati], will work as expected). (what about pages that don't represent individual people but have hCards? won't this result in false positives?)

==== user scenario ====
User scenario:
Here is a scenario that outlines a proposed representative hCard auto-discovery process:

# I (as user) give the URL of my homepage or hCard or other profile URL, to a site that wants a profile icon
# That site goes and gets it (e.g. using [[hKit]]), and then:
## checks to see if there is an hCard with a "url" property on a rel="me" hyperlink (since rel="me" only works from a whole page to a whole page, if an hCard contains such a URL, then that hCard must represent the page. see [http://gmpg.org/xfn/and/#idconsolidation XFN identity consolidation] for more details.), and uses it if it finds it. (if there is more than one such hCard on the page? for now use the first such hCard.)
## checks to see if there is an hCard with a "url" property that points to the current page, and uses it if it finds it. similar to the above rel="me" case, if an hCard is pointing to the current page, then it is likely that the hCard is about the current page. (if there is more than one such hCard on the page? for now use the first such hCard.)
## checks to see if there is an <nowiki><address></nowiki> hCard (thus meaning contact for the page), and uses it if it finds it. (what if there is more than one such hCard on the page? e.g. such as the multiple address hCards for hAtom entries. for now use the first such hCard.)
## otherwise uses the first hCard it finds (which in cases of profile URLs which have a single hCard like on [http://flickr.com Flickr] and [http://technorati.com/ Technorati], will work as expected).
# The site looks in the hCard for a "logo" property and uses the first one if it finds any.
# Otherwise it looks for a "photo" property and uses the first one if it finds any.
# Otherwise the site uses a default icon, but subscribes to the URL with the hCard and checks it for a "logo" or "photo", say, once a day.

===class=representative vcard===
Use of an additional class name, say <code>class="representative vcard"</code> (as an alternative to, or in addition to, the above patterns), would deal with the problems with the above proposals, as raised on [[representative-hcard-issues]]. It would also be quickly reusable for <code>class="representative vevent"</code> and other such microformats. A rule would require only one use of <code>class="representative"</code>, per microformat, per page. [[User:AndyMabbett|Andy Mabbett]] 16:10, 2 Feb 2008 (PST)

* As per Semantic XHTML Design Principles, wouldn't id="representative" be better than a class? [[User:TobyInk|TobyInk]] 09:01, 18 Feb 2008 (PST)

**A page could have a representative hCard and a representative hCalendar (or some other pair of representative microformats); but ID can only be used once. A workaround (I state this for the record, not as a recommendation) would be <code>ID="representative-hcard"</code>, etc. [[User:AndyMabbett|Andy Mabbett]] 09:31, 18 Feb 2008 (PST)

== author hcard / contact hcard ==

[[User:TobyInk|TobyInk]] 10:24, 22 Mar 2008 (PDT):

Related to the concept of a representative hCard are the concept of the author hcard and contact hcard for a page. In many cases, all three will be the same hCard, though sometime they will differ. Here are some ideas for how to identify the author and contact hcards. (This section perhaps should be spun off as its own page?)

=== author hcard ===

An hCard linked to with rel="author" (for hysterical raisins, rev="made" should also be recognised), is the author hCard. A page may have multiple authors. rel="author" and rev="made" are defined by HTML 5.

hAtom already uses class="author vcard" to identify the feed author, which also has the advantage (or maybe limitation) that it does not have an existing 'applies to the whole page' semantic like rel does (consider a page of blog posts with different authors).

=== contact hcard ===

An hCard found in an <address> element represents the contact for the page, or for a major section of the page.

== related pages ==
* {{representative-hcard-related-pages}}

figure-examples

2007-09-25T13:21:10Z

CiaranMc: /* The Problem */

<h1>Figure examples</h1>

'''This page documents examples of mark up for figures like images, captions and data tables in webpages and the class-names that they've used ''' - [[User:Chris_Messina|Chris Messina]]

== The Problem ==
There are no HTML tags for identifying or marking up supporting content like illustrative images (as in encyclopaedic references), photographs and their captions, credits or licenses (as in news articles) or data tables. Typically this content can be found in close proximity to the relevant information, but oftentimes mixed with other elements.

The goal of this effort is to document and reflect the real-world needs of such design patterns while paying close attention to the types of data that people are using in this supportive role and also paying close attention to the existing class names and presentational styles that go along with such formats.

== Participants ==
* [[User:Chris_Messina | Chris Messina]]
* [[User:EdwardOConnor | Edward O'Connor]]
* [[User:AaronGustafson | Aaron Gustafson]]
* ...

== Real-World Examples ==

These are examples and implementations in the wild of various efforts at marking up figures in web pages, blog posts and articles.

=== CNET ===

CNET uses <code>cnet-image-div</code>, '''<code>float-left</code>''', <code>cnet-image</code>, '''<code>image-credit</code>''' and '''<code>image-caption</code>''' to mark up supporting photographs and artwork.

See this example: [http://blogs.cnet.com/8301-13504_1-9758731-15.html?tag=cnetfd.blogs.item Why I recommend the iPhone -- and don't.]

=== HTML5 ===

HTML5 introduces a new tag called [http://www.whatwg.org/specs/web-apps/current-work/multipage/section-embedded.html#figure "figure"], which represents a block-level image, along with a caption:

<pre>
<figure id="fig2">
<legend>Figure 2. Install Mozilla XForms dialog</legend>
<img alt="A Web site is requesting permission to install the following item:
Mozilla XForms 0.7 Unsigned"
src="installdialog.jpg" border="0" height="317" hspace="5" vspace="5" width="331" />
</figure>
</pre>

This is slightly different from the broader goal of this effort, but nevertheless points to current work on this topic.

== Existing Practices ==

In many cases, classes that are used exclusively for alignment and positioning are documented herein order to have an accurate sense for how people mark up this kind of content in practice.

=== [http://factoryjoe.com/blog FactoryCity Blog] ===

* uses a series of <code>figure</code> classes to markup figures.
* the approach used is to mark up block level figures with both <code>figure</code> and either <code>figure-a</code> or <code>figure-c</code> classes.
* <code>figure-b</code> and <code>figure-d</code> are used for inline figures aligned right and left, respectively
* the a, b, c, d pattern is modeled after the top, right, bottom, left order of CSS attribute values
* Paul Wilkins [http://microformats.org/discuss/mail/microformats-discuss/2007-August/010421.html suggested more semantic names for these classes on µf-discuss]

=== [http://getk2.com K2 WordPress Theme] ===

* The K2 [http://kaytwo.googlecode.com/svn/trunk/style.css stylesheet] includes the following figure-related CSS:

<pre>
.center {
text-align: center;
}

.alignright {
float: right;
}

.alignleft {
float: left
}

img.center, img[align="center"] {
display: block;
margin-left: auto;
margin-right: auto;
}

img.alignright, img[align="right"] {
padding: 4px;
margin: 0 0 2px 7px;
display: inline;
}

img.alignleft, img[align="left"] {
padding: 4px;
margin: 0 7px 2px 0;
display: inline;
}

img.noborder {
border: none !important;
}
</pre>

=== [http://code.google.com/p/habari/ Habari K2 Theme] ===

Similar to K2, the [http://habari.googlecode.com/svn/trunk/htdocs/user/themes/k2/style.css Habari K2] instance supports the following classes:

<pre>
.center {
text-align: center;
}

.alignright {
float: right;
}

.alignleft {
float: left
}

img.center, img[align="center"] {
display: block;
margin-left: auto;
margin-right: auto;
}

img.alignright, img[align="right"] {
padding: 4px;
margin: 0 0 2px 7px;
display: inline;
}

img.alignleft, img[align="left"] {
padding: 4px;
margin: 0 7px 2px 0;
display: inline;
}

img.noborder {
border: none !important;
}
</pre>

=== [http://webrevolutionary.com/coldblue ColdBlue WordPress Theme] ===

* includes the classes <code>float-left</code> or <code>float-right</code> for aligning figures

=== [http://edward.oconnor.cx/ Edward O'Connor's blog] ===

* POSH figure markup, based on several inputs:
** HTML5's figure element
** RFC 2629's figure element
** [http://microformats.org/discuss/mail/microformats-discuss/2007-August/010421.html Paul Wilkins' class names]
* Documented in [http://edward.oconnor.cx/2007/04/marking-up-figures Marking up figures], [http://edward.oconnor.cx/2007/08/figure-markup-redux Figure markup redux], and described in [http://edward.oconnor.cx/profiles/figures XMDP]

=== Revenue Watch Institute (website forthcoming) ===

During the development of the new website for Revenue Watch, this was what we cam up with to handle figures:

<pre>
<div class="figure">
<img src="/path/to/img.jpg" alt="" />
<p class="credit"><abbr class="type" title="Phtotograph">Photo</abbr> by <cite>Bob Johnson</cite></p>
<p class="caption"><em class="title">Figure 1</em> Cras rutrum, enim at placerat varius, nisi massa consectetuer.</p>
</div>
</pre>

* Figures can be categorized as types using the "type" <code>class</code> (here type is embedded in the credit line, using [[abbr-design-pattern|the <code>ABBR</code> design pattern]]) - current recommendations: "photograph" or "illustration" (these could possibly be extended to include other options such as "chart," "line-art", etc.) (optional)
* The "title" <code>class</code> can be added to any element within the figure (optional)
* Credit for the figure is denoted with the "credit" <code>class</code> (optional)
* A caption is also available (optional)

Default styles:

<pre>
.figure {
margin: 0 0 1.5em;
}
.figure p {
margin: 0;
width: auto;
}
.figure .credit {
font-size: .8em;
text-align: right;
}
.figure .credit cite {
font-style: inherit;
}
.figure .caption {
font-style: italic;
font-size: 1.1em;
}
.figure .title {
font-style: normal;
font-weight: bold;
}
.figure .title:after {
content: ":";
}
</pre>

No presentational information is added to the figures. The presentation is determined via script as a progressive enhancement (ALA article forthcoming).

Tables receive no figure-related styles, but graphs, charts, and maps do.

====Comments====
Why is "credit" not an hCard? Also, for pictures of places any geo/ hcard microformat included in the caption should be understood to be associated with the figure. There is debate elsewhere, about whether coordinates should be for the camera position, or the object photographed; with consensus coming down on the side of the former [http://commons.wikimedia.org/wiki/Commons_talk:Geocoding#Geotagging_the_camera_or_the_Objekt], [http://commons.wikimedia.org/wiki/Commons_talk:Geocoding#Camera_vs_object_location]. That said, the whole "figure" div could be an hcard, with the picture being part of that; and a separate hCard for the photographer included. Complex... [[User:AndyMabbett|Andy Mabbett]] 16:52, 21 Aug 2007 (PDT)

I like the idea of the hCard <em>if</em> there is more information available other than just the name. If you are just putting the person's name, I still don't see the point of making that an hCard. Add some additional data (a link, email address, etc.) and I think you have an argument. Otherwise I think it's a waste of markup and simply clutters the results of whatever hCards might exist elsewhere on the page. As for geo-data, I think that sort of information may be useful, but I think I'd prefer to see that embedded within a <code>longdesc</code> page with more info on the image. Inside an article it seems superfluous to me. A <code>longdesc</code> page for an image could include much more data about where it was taken, by whom (possibly even a full hCard of the creator), etc.
[[User:AaronGustafson|Aaron Gustafson]] 18:24, 22 Aug 2007 (EDT)

== Further discussion ==

A few blog posts capture the essence of this discussion well:

* [http://factoryjoe.com/blog/2007/02/26/a-design-pattern-for-image-and-figure-alignment/ A design pattern for image and figure alignment]
* [http://edward.oconnor.cx/2007/04/marking-up-figures Marking up figures]
* [http://www.css3.info/styling-figures-with-css3/ Styling figures with CSS3]
* [http://www.simplebits.com/notebook/2005/07/10/figures.html When Floated Figures Attack!]
* [http://www.pearsonified.com/2007/06/how-to-format-images-for-feed-readers.php How to Format Images for Feed Readers]

hresume-examples-in-wild

2007-08-29T09:31:27Z

CiaranMc: Adding new hResume example

<h1>hResume examples in the wild</h1>

This page is '''informative'''.

The following sites have published '''hResumes''', and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing, etc.

__TOC__

== New Examples ==

If you have an hResume on your own page, feel free to add it to the '''top''' of this list. Please be sure to include at least one URL to a page on your site that includes actual [[hresume|hResume]] markup. Examples added without a URL to a page with hResume markup may be removed.
* [[User:CiaranMc|Ciaran McNulty]] has marked up his [http://ciaranmcnulty.com/assets/files/Ciaran_McNulty_CV.html resume] as an hResume.
* [[User:RichardDavies|Richard Davies]] has marked up his [http://www.richarddavies.us/resume/ resume] as an hResume.
* [[User:RudyDesjardins|Rudy Desjardins]] has marked up his [http://rudy.theendless.org/resume/index.html resume] as an hResume.
* [[User:AndrewPendrick|Andrew Pendrick]] has marked up his [http://www.andrewpendrick.co.uk/cv.html resume] as an hResume.
* [[User:MattBosworth|Matt Bosworth]] has marked up his chronological [http://www.codetastic.com/resume-chrono.html resume] and his functional [http://www.codetastic.com/resume-functional.html resume] with hResume.
* [[User:RobCrowther|Rob Crowther]] has marked up his [http://www.dotrob.com/cv.html resume] as an hResume.
* [[User:Ajaswa|Andrew Jaswa]] has marked up his [http://www.gotkicked.net/hresume resume] as an hResume.
* [[User:ScottWallick|Scott Allan Wallick]] has [http://scottwallick.com/about/resume/ his resume] as an hResume.
* Ed Lau has [http://www.edlabs.net/ his resume] marked up with hResume.
* [[User:AndySmith|Andy Smith]] has marked up [http://ymkm.com/AndySmith.html his CV] with hResume.
* [[User:BenDodson|Ben Dodson]] has marked up [http://www.bendodson.com/developer/cv/html/ his CV] with hResume.
* [[User:BruceDailey|Bruce Dailey]] has marked up his [http://www.jciti.com/cv/cv.php resume] as an hResume.
* Inga Scholes has [http://inga-art.co.uk/cv her CV] marked up with hResume.
* [[User:JesseNewland|Jesse Newland]] has marked up his [http://resume.jnewland.com resume] as an hResume.
* [[User:Harriyott|Simon Harriyott]] has his [http://harriyott.com/cv.aspx curriculum vitae] as an hResume.
* [[User:BradT|Brad Touesnard]] has scraped together [http://brad.touesnard.com/documents/resume/ his resume] with the [http://brad.touesnard.com/projects/wordpress/linkedin-hresume/ LinkedIn hResume for Wordpress] plugin.
* [[User:ChadL|Chad Lindstrom]] has extended his [http://chadlindstrom.ca/resume/ resume] with hResume.
* Dawn Waswick has marked up [http://www.miniminx.com/portfolio/resume.cfm her CV] with hResume.
* [[User:Rolandinsh|Rolands Umbrovskis]] has [http://www.rolandinsh.lv/?ro=hResume marked up his CV] with hResume.
* [http://linkedin.com/ LinkedIn] has ~9 million Public Profiles marked up in hResume, e.g. [http://www.linkedin.com/in/steveganz Steve Ganz's Public Profile].
* [http://steinhardt.nyu.edu/ NYU Steinhardt] has [http://steinhardt.nyu.edu/faculty_bios/list/Faculty 240+ faculty bios marked up], e.g. [http://steinhardt.nyu.edu/faculty_bios/view/Susan_Murray]. ([[User:WizardIsHungry|Jon Williams]])
* [[User:ClintAndrewHall|Clint Hall]] has marked up his [http://www.clintandrewhall.com/resume.html resume] as an hResume.
* [[User:Csarven|Sarven Capadisli]] has marked up his [http://www.csarven.ca/cv Curriculum Vitae] as an hResume.
* [[User:Jax|Xavier Roy]] has marked his [http://xavierroy.com/resume/ resume] with hResume
* [[User:SanchTheFat|Robert O'Rourke]] has marked up his [http://robert.o-rourke.org/ CV] with hResume.
* [[User:Keri Henare|Keri Henare]] has marked up [http://www.kerihenare.com/cv/ his Curriculum Vitae] using hResume.
* [[User:Kwilson|Kenn Wilson]] has marked up [http://www.six23.net/resume/kenn-wilson.html his resume] using hResume, following [[User:Ralph Brandi|Ralph Brandi]]'s method of using object.include.
* [[User:Ralph Brandi|Ralph Brandi]] has [http://www.brandi.org/ralph/resume/ marked up his resume] with hResume, additionally using the object.include method to associate one description with three hCalendar experiences.
* [[User:Pat Ramsey|Pat Ramsey]] has his [http://www.patramsey.net/resume.html resume] marked up as an hResume.
* [[User:Wim Le Page|Wim Le Page]] has also marked up [http://adrem.ua.ac.be/~wlepage/curriculum-vitae/ his curriculum vitae] as an hResume.
* [[user:Jonathan Arkell|Jonathan Arkell]] has posted an [http://portfolio.jonnay.net/cv/ hResume] on his portfolio website.
* [http://steve.ganz.name/hresume/ Steve Ganz - hResume 0.1]
* [[User:Dave Cardwell|Dave Cardwell]] has marked up [http://davecardwell.co.uk/cv/ his curriculum vitae] as an hResume.
* [[User:EdwardOConnor|Edward O'Connor]]'s [http://edward.oconnor.cx/resume/ resume] is in hResume, and has some experimental JavaScript in it to extract a skill summary from the resume.
* [[User:Lindsey Simon|Lindsey Simon]] has his [http://www.commoner.com/~lsimon/lindsey_simon_resume.html resume] marked up as an hResume - with lots of thanks to Pat Ramsey.
* [[User:Ben Ward|Ben Ward]] has published [http://ben-ward.co.uk/cv his CV] with hResume.
* [http://www.kelleychambers.com Kelley Chambers] has published her [http://www.kelleychambers.com/resume resume] via [http://www.ssdesigninteractive.com/ssdesign/?p=96 Sajid Saiyed's Microformat hResume Plugin for Wordpress].
* [[User:Fishy5|Brennan Falkner]] used hResume to markup his [http://my.usf.edu/bbcswebdav/users/bfalker/resume.html resume].
* [http://www.zachary.com/creemer/resume.html David Creemer's resume] uses hResume, with thanks to Pat Ramsey for the CSS.
* [[User:ChristophBurgdorfer|Christoph Burgdorfer]] has integrated his hResume into a [http://emcons.net/index.php mashup].

== Examples with some problems ==
If you find a problem with any example in any other section, please move it here, and note the precise problem and cite the section of the [[hresume|hResume spec]] that appears to be violated. If the example that was moved here is yours, and you want to improve it, see the [[hresume-faq|hResume FAQ]], or raise any queries on [[hresume-issues|hResume Issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you.
* [[User:DmytroShteflyuk|Dmytro Shteflyuk]] has marked up [http://kpumuk.info/curriculum-vitae/ his resume] as an hResume.
** Invalid; job titles contain hCards without a "fn" (either directly or via object). --[[User:Gazza|Gazza]] 04:27, 1 May 2007 (PDT)
* [[user:Izo|Mathieu Drouet]] has posted an [http://izo.aucuneid.com/hresume.html hResume].
** ''Incorrect root class name hResume? -- [[DavidJanes]]''
* [[User:Stauciuc|Sergiu Sebastian Tauciuc]] has his [http://www.sergiutauciuc.ro/en/cv.html curriculum vitae] as an hResume.
** Invalid - no contact vCard specified. [[User:AndyMabbett|Andy Mabbett]] 04:05, 10 Mar 2007 (PST)

== Reviewed Examples ==
If you have reviewed a New Example (and you are not the author of the example) and believe it to be valid, go ahead and move it here.
* ...

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

hresume-issues

2007-06-04T15:16:48Z

CiaranMc: Note on hCard disambiguation in hResume

<h1> hResume issues </h1>

These are externally raised issues about [[hresume|hResume]] 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. 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/log/ Tantek]

See related [[hcalendar-issues]].
See related [[hcard-issues]].

__TOC__

== Issues ==

* {{OpenIssue}} 2007-01-04 raised by [[User:NTollervey|ntoll]].
*# ''With regard to the "skill" attributes in a resume: often skills have an indication of the level of attainment - be it as a descriptive "tag" or a duration denoting the length of experience of the referenced skill. In fact, abstracting out a "skill" microformat might be useful for re-use in the job-listing (Vacancy?) microformat. That way, job requirements can be married to CVs. Although not a job-site, I like Sourceforge.net's skill inventory feature (that captures both a level and length of experience) although I think its implementation is horrendous.''

* {{OpenIssue}} 2006-10-19 raised by [[RyanKing]].
*# ''There's currently no way to say 'present' in hCalendar''
*#* Many job experience listings will include jobs that the person is presently working at. Ciaran McNulty [http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html correctly pointed out] that a blank DTEND does not indicate that the event is still ongoing. We need to find an easy way to make this work in hResume.

* {{OpenIssue}} 2006-10-19 raised by [[Steve Ganz]].
*# ''There's currently no way to distinguish different hCard types in hResume''
*#* In Draft, version 0.1 it is specified that a parent element of <code>address</code> should be used to the distinguish an hCard as the subject's contact info. This proves problematic to implement because <code>address</code> cannot contain block level elements. To avoid sacrificing semantic value by restricting the child elements of an hCard to inline elements, we need to settle on an alternate method to classify a subject's hCard as thier contact info.
*#* In any given experience there may be one or more hCards. One which would be the subject's hCard for that experience and the other for a supervisor or manager, etc. We need a way to distinguish different hCards in a given experience.
:::* Agreed, when adding my references in hCard to the bottom of my hResume it became apparent there was no way I could mark 'my' hCard as the one belonging to the subject of the hResume. Perhaps @class="hcard subject" as a child of the hResume? [[User:CiaranMc|Ciaran McNulty]]

== 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 ==
{{hresume-related-pages}}

hcalendar-issues

2007-05-12T08:25:14Z

CiaranMc: /* Issues */

<h1>hCalendar issues</h1>

These are externally raised issues about [[hcalendar|hCalendar]] 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 [[hcalendar-faq|hCalendar 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]

Please add new issues to the '''top''' of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

See related [[hcard-issues]].

__TOC__

== Issues ==

And add new issues to the top of the list:

* {{OpenIssue}} 2007-05-12 A pertinent point from the [http://microformats.org/wiki?title=hcalendar-issues&oldid=16115 22 Feb 2007 version] of hcalendar issues. Worth keeping and addressing:

:* 2007-01-20 raised by [[User:AndyMabbett|Andy Mabbett]]
:: Where <code>DTEND</code> is a date, and not a date-time, it is required to be the day after the end of the event, thus: <code><nowiki>
<abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code>. However, "29 April 2007" is '''''not''''' an abbreviation of 2007-04-30; it is an abbreviation of 2007-04-29. The markup as shown is semantically incorrect and likely to cause problems for users and user-agents which read the title attribute, and not the text value, of the <code>abbr</code> element.
::[[User:Webf2|Webf2]] 23:23, 11 May 2007 (PDT)
::*The ISO date 2007-04-30 is directly equivalent to 2007-04-30 00:00:00, which is why it's used as the end time of an event occuring on 2007-04-29. In this fuller context then you can view it as an abbreviation of 'the end of 29 April 2007'. Authors uncomfortable with this could use <nowiki><abbr class="dtend" title="2007-04-29 23:59:59">29 April 2007</abbr></nowiki>, or be more specific with their times.
:::[[User:CiaranMc|Ciaran McNulty]] 09:21, 12 May 2007 [GMT]

* {{OpenIssue}} 2007-01-07 raised by [[User:Webf|Webf]]
*# ''Looking for a mechanism for specifying a dtstart without using <nowiki><abbr></nowiki>. Would be used where there are a number of events (as in the [http://www.webfeet.org/events.html Webfeet events lists]) where you do not want to have the visible date repeated''
*#* <code>abbr</code> is the correct - and only - element to use, unless you wish to display the raw ISO-formatted date-time to the user. Use it with the [[include-pattern]], thus:

<code>
<pre>
<nowiki>
<dt id="D20070120">
<abbr class="dtstart" title="20070120">
Saturday, 20 January 2007
</abbr>
</dt>
<dd>
<span class="vevent">
<object class="include" data="#D20070120"></object>
[Details of first event]
</span>

<span class="vevent">
<object class="include" data="#D20070120"></object>
[Details of second event]
</span>
</dd>
</nowiki>
</pre>
</code>

:but please note that you should validate your HTML - it has over 3,000 errors! The high number of hCalendar microformats (>500) is causing parsers such as Firefox's Tails and Operator to respond very slowly. You should use CSS, not non-breaking spaces and multiple line-breaks, to layout your page - this will reduce it's size and enable parsers to work more quickly. You will need to style <code>object .include</code> to <code>display:none</code> [[User:AndyMabbett|Andy Mabbett]] 04:10, 16 Jan 2007 (PST)

:Thanks Andy!
:* This use of <code>object</code> is a proposal at this stage? It does not seem to be mentioned in the [[hCalendar|hCalendar]] page and only marked 'under consideration' in [[include-pattern#Specifications_Using|Include Pattern]]
:* Re: '>500 entries', I would think that User Agents ''should'' be able to deal with this. The linked page displays a collection of events (not all pages will have so many :-) however I would expect a User Agent to worry mainly about the events visible on the screen (really, a ''small'' part of the whole page).
:** Brainstorming a little, I would hope that the UA could track an event I've inserted ino my calendar and notice any changes, such as the event being postponed/cancelled, pick up this info and update my calendar. Worth thinking what implications this might bring to the markup.
:** I'm thinking though that the primary effort with a UA would be making sure the 99.99% pages which ''do not'' include hCalendar markup are not slowed down!
:* Re: <code>abbr</code> as the ''only'' way, I can see <code>abbr</code> used within the [[hCalendar|hCalendar]] page and, yes, it looks a exceptionally neat way of rolling up some markup but I don't see it defined as a mandatory for marking up an event.
:** Am I missing some rationale? Why is <code>abbr</code> the ''only'' option?
:** Should the spec be written up more formally? should hCalendar be more relaxed? My take is that <code>abbr</code> is OK but it would be wrong for it to be mandatory. Think that screen readers may be reading the expanded content (as with <code><nowiki><abbr title="Web Accessibility Initiative">WAI</abbr></nowiki></code>). The underlying issue is that [[hCalendar|hCalendar]] seems to want <code>abbr</code> to <em>disambiguate</em> a displayed date and this is not really the same as an abbreviation. UA's should be liberal when looking for a <code>class="dtstart"</code>, after all they <em>do</em> know that they are within an event markup as they have met the <code>class="vevent"</code>....
:*Feel free to move the above thoughts to a brainstorming area. I might come back to the other points later - but maybe better in a talk page. :-) [[User:Webf|Webf]] 13:23, 21 Jan 2007 (PST)

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|AndyMabbett]]
*# ''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.''

* {{OpenIssue}} 2006-09-22 raised by [[User:AndyMabbett|AndyMabbett]]
*# ''How are Julian dates to be displayed? So far as I am aware, ISO8601 has no facility for marking up Julian dates, so should the form <pre><nowiki><abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr> </nowiki></pre> be used? If so, that should be indicated, via an example.''

* {{OpenIssue}} 2006-08-14 raised by [[User:Elias|Elias Sinderson]]
*# ''Issue 1: Although ISO 8601 allows both basic (sans delimiters) and extended formats, the extended format (where hyphens and colons are explicitly added) is broadly preferred for the web. While RFC 2445 specifies that the basic form be used in in iCalendar date / time fields, the W3C has published a technical [http://www.w3.org/TR/NOTE-datetime note] (submitted by Reuters), which recommends that the extended (delimited) format be used, and the [http://www.w3.org/TR/html401/types.html#h-6.11 HTML 4.0 spec] uses the extended format. Further, RFC 3339 defines a ISO 8601 profile for dates and time representations on the internet that future specs SHOULD use; recommending a fully delimited representation (see sec. 5.6). Lastly, it should be noted that the [http://www.w3.org/TR/xmlschema-2/#date xsd:date] and [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] types are specified as being the ISO 8601 extended format. So, given that hCalendar is based on iCalendar, it is understandable that it allows both formats, however this is clearly a case in which it would be very reasonable to require users to upconvert the format into the least ambiguous and most easily parsed / validated representation. Think of the children.''

* {{OpenIssue}} 2006-04-13 raised by Tantek
*# ''Need to add a section on "Property Exceptions" like that in [[hcard|hCard]] to document how to publish / handle the '''METHOD''' property and potentially others. I.e. typically publishers may omit the METHOD property, however, converters whose function is to convert [[hcalendar|hCalendar]] to iCalendar for consumption/subscription by a calendar aggregator, should probably insert a default '''METHOD:PUBLISH''' on the '''VCALENDAR''' object in the resultant .ics stream.''

* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].
*# ''When someone looks at the [[hcalendar]] pages, one sees no collection of real-world publishing of event 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 hcalendar pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''

* {{OpenIssue}} 2006-03-07 raised by [[User:Ragdoll|Justin McDowell]]
*# ''Issue 1: I'd love to see a Property List, similar to what is seen in the hCard spec, that lists all the available properties and sub-properties in a nice, compact list. This saves a lot of time and is really useful for quickly and easily getting aquainted with the possibilities of vCalendar.''
*#* See [[hcalendar-cheatsheet]] . [[User:Leikam|Michael Leikam]] 2007-01-29

* 2005-07-27 raised by Paolo Massa
*# ''I tried to add a hcalendar event in my blog but it rendered orribly. The problem was I already have a 'class="summary' in my normal HTML (it is the title of the posts) and my CSS displays it bigger and bold. In this way the summary of the event was as big as the titles of the posts, destroying readability. The problem is Overloading of class attributes, it might be the case that a blogger already use, for example, class="summary" for different purposes. What can be a solution? Providing in every microformat wiki page a CSS file that users can download and insert in their blog as additional CSS. This CSS file will "shield" attribute "inside" microformats from being interpreted as "normal" attributes. For example for the hCalendar microformats the relative CSS could be something like:

.vevent .summary {

//remove all the previously set properties, for example:

text-decoration: none;

font-size: 100%;

...

}

Since the hCalendar microformat is the following,

<span class="vevent">

<a class="url" href="http://www.web2con.com/">

<span class="summary">Web 2.0 Conference</span>:

...

I hope to have been clear but I'm not so sure ;-)''

* 2005-07-21 raised by Neil Jensen
*# ''should we create a vfreebusy class for HTML representations of freebusy data? Discussion [http://microformats.org/wiki/hcalendar-brainstorming#Free.2FBusy_information on hCalendar brainstorming]. Additional background: [http://www.ifreebusy.com/cyclical/blog/calendar/3.html here].''

* 2005-07-11 raised by Kragen
*# ''The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about [[xfolk|xFolk]].''
*#* REJECTED. Lack of use case. We should not add additional "ways of referencing the event URL" unless you can show a concrete real world example on the Web which requires it.

== Template ==
Please use this format (copy and paste this to the beginning 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.''

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items.
* 2006-02-17 raised by [[User:Mark Mansour|Mark Mansour]] - notes are summarized [[hcalendar-irc-meetup-20060225|here]]
*# Should vcalendar be a class? Section 4.4 of RFC2445 says: "The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together." Also the vcalendar class would allow properties on the calendar itself such as METHOD and CALSCALE (I don't think VERSION and PRODID are particularly relevant).
*#* ACCEPTED SPECUPDATE/FAQ. Is this a case of fixing something that isn't broken? Note that "iCalendar object" != "vcalendar". This is a bit confusing so read RFC 2445 carefully in that regard. In addition, the [[hcalendar|hCalendar]] spec should say *precisely* how to generate VCALENDAR properties in their absence.
*# How are axis and headers going to be handled?
*#* ACCEPTED. This is documented in [[hcalendar-brainstorming]] but MUST be moved to [[hcalendar|hCalendar]] proper as the editors and implementers have all agreed on it (months ago). Add this as a [[to-do]] for Tantek.
*# There has been talk that table axis and headers should be used to capture calendar information in a more compact format, but no example are available. Does anyone have examples or should we try to invent some?
*#* REJECTED. Please RTFM. Searching the [[hcalendar|hCalendar]] spec for *either* "axis" or "headers" would have found the following example in the wild: [http://we05.com/ Web Essentials 05] has marked up their [http://we05.com/program.cfm program schedule table with hCalendar], using the 'axis' and 'headers' attributes.
*# Should embeded components be allowed? [[RyanKing]] has already noted that vJournal overlaps blog-posts (although not yet accepted), but should the components to-do, free/busy, timezone, alarms be allowed? They all considered as just as relevant by the ical spec as events are (my interpretation).
*#* ACCEPTED SPECUPDATE/FAQ. Another [[to-do]] for Tantek. Explicitly specify which additional iCalendar objects (in addition to VEVENT) are permitted in hCalendar. Current additional candidates: VTODO (many examples of this info on the web), VFREEBUSY (already at least one site publishing this info), VALARM (maybe, seems harmless enough, but without a compelling real world use case we should probably omit it). Currently dropping: VTIMEZONE (terrible construct), VJOURNAL (obsoleted by [[hatom|hAtom]]).
*# Validation of the hCalendar tests. The hCalendar tests have been available for a while now, but only Brian Suda and I have made contributions to their content. Does anyone else have thoughts and should we try to make these the beginning of 'official' hCalendar tests?
*#* ACCEPT PARTIAL. We probably need an hCalendar ''validator'' before we can declare any set of tests to be official.
*# The use of fragments is unclear. Fragment interpretation seems to be agent dependant. Fragments usually denote a heading or marker, like a goto statement for HTML. Unfortunately it may jump in the middle of elements (rather to the beginning of an element). How should this be handled. i.e.
<pre>
<a name="myfrag">heading</a>
<div class="vevent">
<div class="description">A nice event</div>
<abbr class="dtstart" title="2005-10-05">October 5</abbr>
</div>
</pre>
*#* ACCEPTED. We should clarify to converters how to interpret a fragement id. The interpretations are all consistent. It points to the element that is to be converted. If that element is empty then so is the conversion. There is no issue here other than a need for more documentation.
* 2006-02-01 raised by [[RyanKing]]
*# ''Issue 1: Given that now, or soon will have hAtom, should we disallow vJournal, so that we don't have 2 blog-post formats?''
*#* ACCEPTED. Yes, we should expliclty DROP "vjournal" from [[hcalendar|hCalendar]].
* 2006-01-04 raised by [[User:CGranade|CGranade]]
*# ''...''
*# ''All examples in XHTML. XHTML should not be the only host to microformats, and thus it should not be the only example host language. Rather, examples in Atom, RSS, RDF, etc. should also be provided.''
*#* ACCEPTED. This is definitely something to be added to *-examples pages for each microformat.
* 2005-10-14 raised by [[User:MarkoMrdjenovic|MarkoMrdjenovic]]
*# ''UID has to be present in iCal events if they want to be used in Microsoft Outlook. [Suggestion:] it should probably be added to the vevent tag as html attribute id. There is also the problem of converters - x2v has UID commented out. [http://www.ietf.org/rfc/rfc2445.txt RFC] recommends use of addr format for uids which is problematic in html id (does not validate). [[User:HenriBergius|HenriBergius]] pointed out some calendaring software crashes when @ is in the UID, so some other form of identification should be used - along the lines of dtstart-dtend-hash(title,summary)-sample-org''.
*#* ACCEPTED-PARTIAL. Yes, it appears RFC2445 requires UID. However, typical mentions of events by web authors do not provide anything equivalent to a UID, nor should we require authors to do so. Thus we must come up with an algorithm for implied UID, similar to some of the other properties. We REJECT the use of the html 'id' attributre as a substitute for UID as they are of different scopes and thus such a translation will likely be problematic. As part of this algorithm, we MUST disallow "@" signs since the issue points out that such UIDs crash some calendaring software.
*# ''DTSTAMP also has to be present in iCal event for Microsoft Outlook. I think DTSTAMP should be user visible information so implementation with class="dtstamp" is fine. x2v already supports it so it should just be added to the standard and examples. The converters might also think of a way to force (create) dtstamp if it's not present.'' [Suggestion:] why not set DTSTAMP to DTSTART if not explicitly defined? -- [[DimitriGlazkov]]
*#* ACCEPTED. We should come up with a way to encourage/synthesize/imply DTSTAMP property values.
*# ''Here is an example from Midgard CMS (which will be easy to change according to bergie on irc):''
*#* For more discussion of this, please see [http://microformats.org/wiki/hcalendar-brainstorming#UID_handling hCalendar brainstorming: UID handling]
<pre><nowiki>
<li class="vevent" id="2678c3f94af4a49f9ccbb69b92a82aba-midgardGuid">
<abbr class="dtstart" title="2005-10-20T14:34:45Z">Torstai 20. Lokakuu 17:34</abbr> -
<abbr class="dtend" title="2005-10-20T15:33:56Z">18:33</abbr>
<a class="url" href="/bergie/another-calendar/82457028ba83407451edd8aaeaa40622.html">
<span class="summary">From the other cal</span>
</a>
<abbr class="dtstamp" title="2005-10-14T12:16:45Z">Torstai 14. Lokakuu 12:16</abbr>
</li></nowiki></pre>
* 2005-09-29 raised by RyanKing
*# ''How does one use ATTENDEE?''
*#* ACCEPTED. Another [[to-do]] for Tantek - document how to use ATTENDEE with [[hcard|hCard]].

* 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 hCalendars 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?
*#* ACCEPTED. Another [[to-do]] for Tantek, write-up [[hcalendar-parsing]] that documents precisely how user agents are to parse [[hcalendar|hCalendar]] markup.
* 2005-02-22 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html on the whatwg list]:
*# ''There is no copyright statement and no patent statement.''
*#* ACCEPTED. I have updated [[hcalendar]] (and [[hcard]], and all other MicroFormats) with a standard copyright statement and patent statement.

* 2005-02-18 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
*# ''...''
*# ''...''
*# ''...''
*# ''...''
*# ''...''
*# ''...''
*# ''I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.''
*#* ACCEPT-PARTIAL. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class]. And yes, class names can and should be used for user-defined semantics. [[hcalendar|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
*#* ''Would it be more in the spirit of HTML to define these classes in a [http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3 metadata profile], so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of [[microformats]] specifications in general? (If not, why not?)''
*#** ACCEPTED. Yes, all [[microformats]] that introduce new classnames SHOULD include an [http://gmpg.org/xmdp/ XMDP] profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
*#*** ''Ok, but in order to refer to a profile, it needs a URI. Tantek writes in [http://microformats.org/discuss/mail/microformats-discuss/2005-July/000407.html a message of Jul 21] "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?''
*#**** ACCEPTED. See [[profile-uris]]; this is moving from Tantek's [[to-do]] list, to both provide profiles and URLs (probably at gmpg.org) for those profiles for hCalendar etc.

== Closed Issues ==
Resolved issues that have no further actions to take.

* 2006-01-04 raised by [[User:CGranade|CGranade]]
*# ''Interactions with strong namespacing. So far, it seems that hCalendar cannot be embedded into non-XHTML schemas that are also strongly namespaced (e.g.: RDF, Atom) without a resultant validation error, as the <code>class</code> attribute is ''not'' portable across schemas.''
*#* REJECTED. The class attribute is used on XHTML elements, which are XML, which can be embedded in any other XML. The issue as raised doesn't make sense.

* 2005-02-18 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
*# ''There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.''
*#* REJECTED (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
*# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
*#* REJECTED (out of scope). Extension properties are outside the current scope of hCalendar.
*# ''The use of <abbr> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.''
*#* REJECTED (false statement). This is simply a false statement. See this article for an explanation of this use of <abbr>: [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
*# ''You have to create a complex set of rules for all possible uses of legacy markup within <span class="vcalendar"> which can easily be implemented incorrectly.''
*#* REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
*# ''There are styling and tooltip issues that are unresolved.''
*#* REJECTED (empty statements). See the [[hcalendar-faq|hCalendar FAQ]] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
*#* REJECTED (empty statements, invalid comparator). Please state specific examples which show the perceived complexity. The comparison "more complicated" requires two items, no second item was provided.

== Related Pages ==
{{hcalendar-related-pages}}
* [[accessibility-issues#hCaledar|hCalendar accessibility issues]]

hcalendar-issues

2007-05-12T08:24:39Z

CiaranMc: /* Issues */

<h1>hCalendar issues</h1>

These are externally raised issues about [[hcalendar|hCalendar]] 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 [[hcalendar-faq|hCalendar 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]

Please add new issues to the '''top''' of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

See related [[hcard-issues]].

__TOC__

== Issues ==

And add new issues to the top of the list:

* {{OpenIssue}} 2007-05-12 A pertinent point from the [http://microformats.org/wiki?title=hcalendar-issues&oldid=16115 22 Feb 2007 version] of hcalendar issues. Worth keeping and addressing:

:* 2007-01-20 raised by [[User:AndyMabbett|Andy Mabbett]]
:: Where <code>DTEND</code> is a date, and not a date-time, it is required to be the day after the end of the event, thus: <code><nowiki>
<abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code>. However, "29 April 2007" is '''''not''''' an abbreviation of 2007-04-30; it is an abbreviation of 2007-04-29. The markup as shown is semantically incorrect and likely to cause problems for users and user-agents which read the title attribute, and not the text value, of the <code>abbr</code> element.
::[[User:Webf2|Webf2]] 23:23, 11 May 2007 (PDT)
::*The ISO date 2007-04-30 is directly equivalent to 2007-04-30 00:00:00, which is why it's used as the end time of an event occuring on 2007-04-29. In this fuller context then you can view it as an abbreviation of 'the end of 29 April 2007'. Authors uncomfortable with this could use <nowiki><abbr class="dtend" title="2007-04-30 23:59:59">29 April 2007</abbr></nowiki>, or be more specific with their times.
:::[[User:CiaranMc|Ciaran McNulty]] 09:21, 12 May 2007 [GMT]

* {{OpenIssue}} 2007-01-07 raised by [[User:Webf|Webf]]
*# ''Looking for a mechanism for specifying a dtstart without using <nowiki><abbr></nowiki>. Would be used where there are a number of events (as in the [http://www.webfeet.org/events.html Webfeet events lists]) where you do not want to have the visible date repeated''
*#* <code>abbr</code> is the correct - and only - element to use, unless you wish to display the raw ISO-formatted date-time to the user. Use it with the [[include-pattern]], thus:

<code>
<pre>
<nowiki>
<dt id="D20070120">
<abbr class="dtstart" title="20070120">
Saturday, 20 January 2007
</abbr>
</dt>
<dd>
<span class="vevent">
<object class="include" data="#D20070120"></object>
[Details of first event]
</span>

<span class="vevent">
<object class="include" data="#D20070120"></object>
[Details of second event]
</span>
</dd>
</nowiki>
</pre>
</code>

:but please note that you should validate your HTML - it has over 3,000 errors! The high number of hCalendar microformats (>500) is causing parsers such as Firefox's Tails and Operator to respond very slowly. You should use CSS, not non-breaking spaces and multiple line-breaks, to layout your page - this will reduce it's size and enable parsers to work more quickly. You will need to style <code>object .include</code> to <code>display:none</code> [[User:AndyMabbett|Andy Mabbett]] 04:10, 16 Jan 2007 (PST)

:Thanks Andy!
:* This use of <code>object</code> is a proposal at this stage? It does not seem to be mentioned in the [[hCalendar|hCalendar]] page and only marked 'under consideration' in [[include-pattern#Specifications_Using|Include Pattern]]
:* Re: '>500 entries', I would think that User Agents ''should'' be able to deal with this. The linked page displays a collection of events (not all pages will have so many :-) however I would expect a User Agent to worry mainly about the events visible on the screen (really, a ''small'' part of the whole page).
:** Brainstorming a little, I would hope that the UA could track an event I've inserted ino my calendar and notice any changes, such as the event being postponed/cancelled, pick up this info and update my calendar. Worth thinking what implications this might bring to the markup.
:** I'm thinking though that the primary effort with a UA would be making sure the 99.99% pages which ''do not'' include hCalendar markup are not slowed down!
:* Re: <code>abbr</code> as the ''only'' way, I can see <code>abbr</code> used within the [[hCalendar|hCalendar]] page and, yes, it looks a exceptionally neat way of rolling up some markup but I don't see it defined as a mandatory for marking up an event.
:** Am I missing some rationale? Why is <code>abbr</code> the ''only'' option?
:** Should the spec be written up more formally? should hCalendar be more relaxed? My take is that <code>abbr</code> is OK but it would be wrong for it to be mandatory. Think that screen readers may be reading the expanded content (as with <code><nowiki><abbr title="Web Accessibility Initiative">WAI</abbr></nowiki></code>). The underlying issue is that [[hCalendar|hCalendar]] seems to want <code>abbr</code> to <em>disambiguate</em> a displayed date and this is not really the same as an abbreviation. UA's should be liberal when looking for a <code>class="dtstart"</code>, after all they <em>do</em> know that they are within an event markup as they have met the <code>class="vevent"</code>....
:*Feel free to move the above thoughts to a brainstorming area. I might come back to the other points later - but maybe better in a talk page. :-) [[User:Webf|Webf]] 13:23, 21 Jan 2007 (PST)

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|AndyMabbett]]
*# ''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.''

* {{OpenIssue}} 2006-09-22 raised by [[User:AndyMabbett|AndyMabbett]]
*# ''How are Julian dates to be displayed? So far as I am aware, ISO8601 has no facility for marking up Julian dates, so should the form <pre><nowiki><abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr> </nowiki></pre> be used? If so, that should be indicated, via an example.''

* {{OpenIssue}} 2006-08-14 raised by [[User:Elias|Elias Sinderson]]
*# ''Issue 1: Although ISO 8601 allows both basic (sans delimiters) and extended formats, the extended format (where hyphens and colons are explicitly added) is broadly preferred for the web. While RFC 2445 specifies that the basic form be used in in iCalendar date / time fields, the W3C has published a technical [http://www.w3.org/TR/NOTE-datetime note] (submitted by Reuters), which recommends that the extended (delimited) format be used, and the [http://www.w3.org/TR/html401/types.html#h-6.11 HTML 4.0 spec] uses the extended format. Further, RFC 3339 defines a ISO 8601 profile for dates and time representations on the internet that future specs SHOULD use; recommending a fully delimited representation (see sec. 5.6). Lastly, it should be noted that the [http://www.w3.org/TR/xmlschema-2/#date xsd:date] and [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] types are specified as being the ISO 8601 extended format. So, given that hCalendar is based on iCalendar, it is understandable that it allows both formats, however this is clearly a case in which it would be very reasonable to require users to upconvert the format into the least ambiguous and most easily parsed / validated representation. Think of the children.''

* {{OpenIssue}} 2006-04-13 raised by Tantek
*# ''Need to add a section on "Property Exceptions" like that in [[hcard|hCard]] to document how to publish / handle the '''METHOD''' property and potentially others. I.e. typically publishers may omit the METHOD property, however, converters whose function is to convert [[hcalendar|hCalendar]] to iCalendar for consumption/subscription by a calendar aggregator, should probably insert a default '''METHOD:PUBLISH''' on the '''VCALENDAR''' object in the resultant .ics stream.''

* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].
*# ''When someone looks at the [[hcalendar]] pages, one sees no collection of real-world publishing of event 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 hcalendar pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''

* {{OpenIssue}} 2006-03-07 raised by [[User:Ragdoll|Justin McDowell]]
*# ''Issue 1: I'd love to see a Property List, similar to what is seen in the hCard spec, that lists all the available properties and sub-properties in a nice, compact list. This saves a lot of time and is really useful for quickly and easily getting aquainted with the possibilities of vCalendar.''
*#* See [[hcalendar-cheatsheet]] . [[User:Leikam|Michael Leikam]] 2007-01-29

* 2005-07-27 raised by Paolo Massa
*# ''I tried to add a hcalendar event in my blog but it rendered orribly. The problem was I already have a 'class="summary' in my normal HTML (it is the title of the posts) and my CSS displays it bigger and bold. In this way the summary of the event was as big as the titles of the posts, destroying readability. The problem is Overloading of class attributes, it might be the case that a blogger already use, for example, class="summary" for different purposes. What can be a solution? Providing in every microformat wiki page a CSS file that users can download and insert in their blog as additional CSS. This CSS file will "shield" attribute "inside" microformats from being interpreted as "normal" attributes. For example for the hCalendar microformats the relative CSS could be something like:

.vevent .summary {

//remove all the previously set properties, for example:

text-decoration: none;

font-size: 100%;

...

}

Since the hCalendar microformat is the following,

<span class="vevent">

<a class="url" href="http://www.web2con.com/">

<span class="summary">Web 2.0 Conference</span>:

...

I hope to have been clear but I'm not so sure ;-)''

* 2005-07-21 raised by Neil Jensen
*# ''should we create a vfreebusy class for HTML representations of freebusy data? Discussion [http://microformats.org/wiki/hcalendar-brainstorming#Free.2FBusy_information on hCalendar brainstorming]. Additional background: [http://www.ifreebusy.com/cyclical/blog/calendar/3.html here].''

* 2005-07-11 raised by Kragen
*# ''The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about [[xfolk|xFolk]].''
*#* REJECTED. Lack of use case. We should not add additional "ways of referencing the event URL" unless you can show a concrete real world example on the Web which requires it.

== Template ==
Please use this format (copy and paste this to the beginning 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.''

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items.
* 2006-02-17 raised by [[User:Mark Mansour|Mark Mansour]] - notes are summarized [[hcalendar-irc-meetup-20060225|here]]
*# Should vcalendar be a class? Section 4.4 of RFC2445 says: "The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together." Also the vcalendar class would allow properties on the calendar itself such as METHOD and CALSCALE (I don't think VERSION and PRODID are particularly relevant).
*#* ACCEPTED SPECUPDATE/FAQ. Is this a case of fixing something that isn't broken? Note that "iCalendar object" != "vcalendar". This is a bit confusing so read RFC 2445 carefully in that regard. In addition, the [[hcalendar|hCalendar]] spec should say *precisely* how to generate VCALENDAR properties in their absence.
*# How are axis and headers going to be handled?
*#* ACCEPTED. This is documented in [[hcalendar-brainstorming]] but MUST be moved to [[hcalendar|hCalendar]] proper as the editors and implementers have all agreed on it (months ago). Add this as a [[to-do]] for Tantek.
*# There has been talk that table axis and headers should be used to capture calendar information in a more compact format, but no example are available. Does anyone have examples or should we try to invent some?
*#* REJECTED. Please RTFM. Searching the [[hcalendar|hCalendar]] spec for *either* "axis" or "headers" would have found the following example in the wild: [http://we05.com/ Web Essentials 05] has marked up their [http://we05.com/program.cfm program schedule table with hCalendar], using the 'axis' and 'headers' attributes.
*# Should embeded components be allowed? [[RyanKing]] has already noted that vJournal overlaps blog-posts (although not yet accepted), but should the components to-do, free/busy, timezone, alarms be allowed? They all considered as just as relevant by the ical spec as events are (my interpretation).
*#* ACCEPTED SPECUPDATE/FAQ. Another [[to-do]] for Tantek. Explicitly specify which additional iCalendar objects (in addition to VEVENT) are permitted in hCalendar. Current additional candidates: VTODO (many examples of this info on the web), VFREEBUSY (already at least one site publishing this info), VALARM (maybe, seems harmless enough, but without a compelling real world use case we should probably omit it). Currently dropping: VTIMEZONE (terrible construct), VJOURNAL (obsoleted by [[hatom|hAtom]]).
*# Validation of the hCalendar tests. The hCalendar tests have been available for a while now, but only Brian Suda and I have made contributions to their content. Does anyone else have thoughts and should we try to make these the beginning of 'official' hCalendar tests?
*#* ACCEPT PARTIAL. We probably need an hCalendar ''validator'' before we can declare any set of tests to be official.
*# The use of fragments is unclear. Fragment interpretation seems to be agent dependant. Fragments usually denote a heading or marker, like a goto statement for HTML. Unfortunately it may jump in the middle of elements (rather to the beginning of an element). How should this be handled. i.e.
<pre>
<a name="myfrag">heading</a>
<div class="vevent">
<div class="description">A nice event</div>
<abbr class="dtstart" title="2005-10-05">October 5</abbr>
</div>
</pre>
*#* ACCEPTED. We should clarify to converters how to interpret a fragement id. The interpretations are all consistent. It points to the element that is to be converted. If that element is empty then so is the conversion. There is no issue here other than a need for more documentation.
* 2006-02-01 raised by [[RyanKing]]
*# ''Issue 1: Given that now, or soon will have hAtom, should we disallow vJournal, so that we don't have 2 blog-post formats?''
*#* ACCEPTED. Yes, we should expliclty DROP "vjournal" from [[hcalendar|hCalendar]].
* 2006-01-04 raised by [[User:CGranade|CGranade]]
*# ''...''
*# ''All examples in XHTML. XHTML should not be the only host to microformats, and thus it should not be the only example host language. Rather, examples in Atom, RSS, RDF, etc. should also be provided.''
*#* ACCEPTED. This is definitely something to be added to *-examples pages for each microformat.
* 2005-10-14 raised by [[User:MarkoMrdjenovic|MarkoMrdjenovic]]
*# ''UID has to be present in iCal events if they want to be used in Microsoft Outlook. [Suggestion:] it should probably be added to the vevent tag as html attribute id. There is also the problem of converters - x2v has UID commented out. [http://www.ietf.org/rfc/rfc2445.txt RFC] recommends use of addr format for uids which is problematic in html id (does not validate). [[User:HenriBergius|HenriBergius]] pointed out some calendaring software crashes when @ is in the UID, so some other form of identification should be used - along the lines of dtstart-dtend-hash(title,summary)-sample-org''.
*#* ACCEPTED-PARTIAL. Yes, it appears RFC2445 requires UID. However, typical mentions of events by web authors do not provide anything equivalent to a UID, nor should we require authors to do so. Thus we must come up with an algorithm for implied UID, similar to some of the other properties. We REJECT the use of the html 'id' attributre as a substitute for UID as they are of different scopes and thus such a translation will likely be problematic. As part of this algorithm, we MUST disallow "@" signs since the issue points out that such UIDs crash some calendaring software.
*# ''DTSTAMP also has to be present in iCal event for Microsoft Outlook. I think DTSTAMP should be user visible information so implementation with class="dtstamp" is fine. x2v already supports it so it should just be added to the standard and examples. The converters might also think of a way to force (create) dtstamp if it's not present.'' [Suggestion:] why not set DTSTAMP to DTSTART if not explicitly defined? -- [[DimitriGlazkov]]
*#* ACCEPTED. We should come up with a way to encourage/synthesize/imply DTSTAMP property values.
*# ''Here is an example from Midgard CMS (which will be easy to change according to bergie on irc):''
*#* For more discussion of this, please see [http://microformats.org/wiki/hcalendar-brainstorming#UID_handling hCalendar brainstorming: UID handling]
<pre><nowiki>
<li class="vevent" id="2678c3f94af4a49f9ccbb69b92a82aba-midgardGuid">
<abbr class="dtstart" title="2005-10-20T14:34:45Z">Torstai 20. Lokakuu 17:34</abbr> -
<abbr class="dtend" title="2005-10-20T15:33:56Z">18:33</abbr>
<a class="url" href="/bergie/another-calendar/82457028ba83407451edd8aaeaa40622.html">
<span class="summary">From the other cal</span>
</a>
<abbr class="dtstamp" title="2005-10-14T12:16:45Z">Torstai 14. Lokakuu 12:16</abbr>
</li></nowiki></pre>
* 2005-09-29 raised by RyanKing
*# ''How does one use ATTENDEE?''
*#* ACCEPTED. Another [[to-do]] for Tantek - document how to use ATTENDEE with [[hcard|hCard]].

* 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 hCalendars 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?
*#* ACCEPTED. Another [[to-do]] for Tantek, write-up [[hcalendar-parsing]] that documents precisely how user agents are to parse [[hcalendar|hCalendar]] markup.
* 2005-02-22 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html on the whatwg list]:
*# ''There is no copyright statement and no patent statement.''
*#* ACCEPTED. I have updated [[hcalendar]] (and [[hcard]], and all other MicroFormats) with a standard copyright statement and patent statement.

* 2005-02-18 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
*# ''...''
*# ''...''
*# ''...''
*# ''...''
*# ''...''
*# ''...''
*# ''I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.''
*#* ACCEPT-PARTIAL. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class]. And yes, class names can and should be used for user-defined semantics. [[hcalendar|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
*#* ''Would it be more in the spirit of HTML to define these classes in a [http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3 metadata profile], so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of [[microformats]] specifications in general? (If not, why not?)''
*#** ACCEPTED. Yes, all [[microformats]] that introduce new classnames SHOULD include an [http://gmpg.org/xmdp/ XMDP] profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
*#*** ''Ok, but in order to refer to a profile, it needs a URI. Tantek writes in [http://microformats.org/discuss/mail/microformats-discuss/2005-July/000407.html a message of Jul 21] "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?''
*#**** ACCEPTED. See [[profile-uris]]; this is moving from Tantek's [[to-do]] list, to both provide profiles and URLs (probably at gmpg.org) for those profiles for hCalendar etc.

== Closed Issues ==
Resolved issues that have no further actions to take.

* 2006-01-04 raised by [[User:CGranade|CGranade]]
*# ''Interactions with strong namespacing. So far, it seems that hCalendar cannot be embedded into non-XHTML schemas that are also strongly namespaced (e.g.: RDF, Atom) without a resultant validation error, as the <code>class</code> attribute is ''not'' portable across schemas.''
*#* REJECTED. The class attribute is used on XHTML elements, which are XML, which can be embedded in any other XML. The issue as raised doesn't make sense.

* 2005-02-18 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
*# ''There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.''
*#* REJECTED (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
*# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
*#* REJECTED (out of scope). Extension properties are outside the current scope of hCalendar.
*# ''The use of <abbr> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.''
*#* REJECTED (false statement). This is simply a false statement. See this article for an explanation of this use of <abbr>: [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
*# ''You have to create a complex set of rules for all possible uses of legacy markup within <span class="vcalendar"> which can easily be implemented incorrectly.''
*#* REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
*# ''There are styling and tooltip issues that are unresolved.''
*#* REJECTED (empty statements). See the [[hcalendar-faq|hCalendar FAQ]] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
*#* REJECTED (empty statements, invalid comparator). Please state specific examples which show the perceived complexity. The comparison "more complicated" requires two items, no second item was provided.

== Related Pages ==
{{hcalendar-related-pages}}
* [[accessibility-issues#hCaledar|hCalendar accessibility issues]]

hcalendar-issues

2007-05-12T08:22:12Z

CiaranMc: /* Issues */

<h1>hCalendar issues</h1>

These are externally raised issues about [[hcalendar|hCalendar]] 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 [[hcalendar-faq|hCalendar 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]

Please add new issues to the '''top''' of the list. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

See related [[hcard-issues]].

__TOC__

== Issues ==

And add new issues to the top of the list:

* {{OpenIssue}} 2007-05-12 A pertinent point from the [http://microformats.org/wiki?title=hcalendar-issues&oldid=16115 22 Feb 2007 version] of hcalendar issues. Worth keeping and addressing:

:* 2007-01-20 raised by [[User:AndyMabbett|Andy Mabbett]]
:: Where <code>DTEND</code> is a date, and not a date-time, it is required to be the day after the end of the event, thus: <code><nowiki>
<abbr class="dtend" title="2007-04-30">29 April 2007</abbr></nowiki></code>. However, "29 April 2007" is '''''not''''' an abbreviation of 2007-04-30; it is an abbreviation of 2007-04-29. The markup as shown is semantically incorrect and likely to cause problems for users and user-agents which read the title attribute, and not the text value, of the <code>abbr</code> element.
::[[User:Webf2|Webf2]] 23:23, 11 May 2007 (PDT)
::*The ISO date 2007-04-30 is directly equivalent to 2007-04-30 00:00:00, which is why it's used as the end time of an event occuring on 2007-04-29. In this fuller context then you can view it as an abbreviation of 'the end of 29 April 2007'.
:::[[User:CiaranMc|Ciaran McNulty]] 09:21, 12 May 2007 [GMT]

* {{OpenIssue}} 2007-01-07 raised by [[User:Webf|Webf]]
*# ''Looking for a mechanism for specifying a dtstart without using <nowiki><abbr></nowiki>. Would be used where there are a number of events (as in the [http://www.webfeet.org/events.html Webfeet events lists]) where you do not want to have the visible date repeated''
*#* <code>abbr</code> is the correct - and only - element to use, unless you wish to display the raw ISO-formatted date-time to the user. Use it with the [[include-pattern]], thus:

<code>
<pre>
<nowiki>
<dt id="D20070120">
<abbr class="dtstart" title="20070120">
Saturday, 20 January 2007
</abbr>
</dt>
<dd>
<span class="vevent">
<object class="include" data="#D20070120"></object>
[Details of first event]
</span>

<span class="vevent">
<object class="include" data="#D20070120"></object>
[Details of second event]
</span>
</dd>
</nowiki>
</pre>
</code>

:but please note that you should validate your HTML - it has over 3,000 errors! The high number of hCalendar microformats (>500) is causing parsers such as Firefox's Tails and Operator to respond very slowly. You should use CSS, not non-breaking spaces and multiple line-breaks, to layout your page - this will reduce it's size and enable parsers to work more quickly. You will need to style <code>object .include</code> to <code>display:none</code> [[User:AndyMabbett|Andy Mabbett]] 04:10, 16 Jan 2007 (PST)

:Thanks Andy!
:* This use of <code>object</code> is a proposal at this stage? It does not seem to be mentioned in the [[hCalendar|hCalendar]] page and only marked 'under consideration' in [[include-pattern#Specifications_Using|Include Pattern]]
:* Re: '>500 entries', I would think that User Agents ''should'' be able to deal with this. The linked page displays a collection of events (not all pages will have so many :-) however I would expect a User Agent to worry mainly about the events visible on the screen (really, a ''small'' part of the whole page).
:** Brainstorming a little, I would hope that the UA could track an event I've inserted ino my calendar and notice any changes, such as the event being postponed/cancelled, pick up this info and update my calendar. Worth thinking what implications this might bring to the markup.
:** I'm thinking though that the primary effort with a UA would be making sure the 99.99% pages which ''do not'' include hCalendar markup are not slowed down!
:* Re: <code>abbr</code> as the ''only'' way, I can see <code>abbr</code> used within the [[hCalendar|hCalendar]] page and, yes, it looks a exceptionally neat way of rolling up some markup but I don't see it defined as a mandatory for marking up an event.
:** Am I missing some rationale? Why is <code>abbr</code> the ''only'' option?
:** Should the spec be written up more formally? should hCalendar be more relaxed? My take is that <code>abbr</code> is OK but it would be wrong for it to be mandatory. Think that screen readers may be reading the expanded content (as with <code><nowiki><abbr title="Web Accessibility Initiative">WAI</abbr></nowiki></code>). The underlying issue is that [[hCalendar|hCalendar]] seems to want <code>abbr</code> to <em>disambiguate</em> a displayed date and this is not really the same as an abbreviation. UA's should be liberal when looking for a <code>class="dtstart"</code>, after all they <em>do</em> know that they are within an event markup as they have met the <code>class="vevent"</code>....
:*Feel free to move the above thoughts to a brainstorming area. I might come back to the other points later - but maybe better in a talk page. :-) [[User:Webf|Webf]] 13:23, 21 Jan 2007 (PST)

* {{OpenIssue}} 2006-10-21 raised by [[User:AndyMabbett|AndyMabbett]]
*# ''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.''

* {{OpenIssue}} 2006-09-22 raised by [[User:AndyMabbett|AndyMabbett]]
*# ''How are Julian dates to be displayed? So far as I am aware, ISO8601 has no facility for marking up Julian dates, so should the form <pre><nowiki><abbr class="dtstart" title="[Gregorian date]">[Julian date]</abbr> </nowiki></pre> be used? If so, that should be indicated, via an example.''

* {{OpenIssue}} 2006-08-14 raised by [[User:Elias|Elias Sinderson]]
*# ''Issue 1: Although ISO 8601 allows both basic (sans delimiters) and extended formats, the extended format (where hyphens and colons are explicitly added) is broadly preferred for the web. While RFC 2445 specifies that the basic form be used in in iCalendar date / time fields, the W3C has published a technical [http://www.w3.org/TR/NOTE-datetime note] (submitted by Reuters), which recommends that the extended (delimited) format be used, and the [http://www.w3.org/TR/html401/types.html#h-6.11 HTML 4.0 spec] uses the extended format. Further, RFC 3339 defines a ISO 8601 profile for dates and time representations on the internet that future specs SHOULD use; recommending a fully delimited representation (see sec. 5.6). Lastly, it should be noted that the [http://www.w3.org/TR/xmlschema-2/#date xsd:date] and [http://www.w3.org/TR/xmlschema-2/#dateTime xsd:dateTime] types are specified as being the ISO 8601 extended format. So, given that hCalendar is based on iCalendar, it is understandable that it allows both formats, however this is clearly a case in which it would be very reasonable to require users to upconvert the format into the least ambiguous and most easily parsed / validated representation. Think of the children.''

* {{OpenIssue}} 2006-04-13 raised by Tantek
*# ''Need to add a section on "Property Exceptions" like that in [[hcard|hCard]] to document how to publish / handle the '''METHOD''' property and potentially others. I.e. typically publishers may omit the METHOD property, however, converters whose function is to convert [[hcalendar|hCalendar]] to iCalendar for consumption/subscription by a calendar aggregator, should probably insert a default '''METHOD:PUBLISH''' on the '''VCALENDAR''' object in the resultant .ics stream.''

* {{OpenIssue}} 2006-04-10 raised by [[User:ScottReynen|Scott Reynen]].
*# ''When someone looks at the [[hcalendar]] pages, one sees no collection of real-world publishing of event 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 hcalendar pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places.''

* {{OpenIssue}} 2006-03-07 raised by [[User:Ragdoll|Justin McDowell]]
*# ''Issue 1: I'd love to see a Property List, similar to what is seen in the hCard spec, that lists all the available properties and sub-properties in a nice, compact list. This saves a lot of time and is really useful for quickly and easily getting aquainted with the possibilities of vCalendar.''
*#* See [[hcalendar-cheatsheet]] . [[User:Leikam|Michael Leikam]] 2007-01-29

* 2005-07-27 raised by Paolo Massa
*# ''I tried to add a hcalendar event in my blog but it rendered orribly. The problem was I already have a 'class="summary' in my normal HTML (it is the title of the posts) and my CSS displays it bigger and bold. In this way the summary of the event was as big as the titles of the posts, destroying readability. The problem is Overloading of class attributes, it might be the case that a blogger already use, for example, class="summary" for different purposes. What can be a solution? Providing in every microformat wiki page a CSS file that users can download and insert in their blog as additional CSS. This CSS file will "shield" attribute "inside" microformats from being interpreted as "normal" attributes. For example for the hCalendar microformats the relative CSS could be something like:

.vevent .summary {

//remove all the previously set properties, for example:

text-decoration: none;

font-size: 100%;

...

}

Since the hCalendar microformat is the following,

<span class="vevent">

<a class="url" href="http://www.web2con.com/">

<span class="summary">Web 2.0 Conference</span>:

...

I hope to have been clear but I'm not so sure ;-)''

* 2005-07-21 raised by Neil Jensen
*# ''should we create a vfreebusy class for HTML representations of freebusy data? Discussion [http://microformats.org/wiki/hcalendar-brainstorming#Free.2FBusy_information on hCalendar brainstorming]. Additional background: [http://www.ifreebusy.com/cyclical/blog/calendar/3.html here].''

* 2005-07-11 raised by Kragen
*# ''The specification of class="url" as <a href="..."> should be a "should", not a "must". Other ways of referencing the event URL, such as <iframe src="..."> and <embed src="...">, shoul be mentioned. At present X2V doesn't appear to handle them. This came up in a discussion about [[xfolk|xFolk]].''
*#* REJECTED. Lack of use case. We should not add additional "ways of referencing the event URL" unless you can show a concrete real world example on the Web which requires it.

== Template ==
Please use this format (copy and paste this to the beginning 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.''

== Resolved Issues ==
Issues that are resolved but may have outstanding [[to-do]] items.
* 2006-02-17 raised by [[User:Mark Mansour|Mark Mansour]] - notes are summarized [[hcalendar-irc-meetup-20060225|here]]
*# Should vcalendar be a class? Section 4.4 of RFC2445 says: "The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together." Also the vcalendar class would allow properties on the calendar itself such as METHOD and CALSCALE (I don't think VERSION and PRODID are particularly relevant).
*#* ACCEPTED SPECUPDATE/FAQ. Is this a case of fixing something that isn't broken? Note that "iCalendar object" != "vcalendar". This is a bit confusing so read RFC 2445 carefully in that regard. In addition, the [[hcalendar|hCalendar]] spec should say *precisely* how to generate VCALENDAR properties in their absence.
*# How are axis and headers going to be handled?
*#* ACCEPTED. This is documented in [[hcalendar-brainstorming]] but MUST be moved to [[hcalendar|hCalendar]] proper as the editors and implementers have all agreed on it (months ago). Add this as a [[to-do]] for Tantek.
*# There has been talk that table axis and headers should be used to capture calendar information in a more compact format, but no example are available. Does anyone have examples or should we try to invent some?
*#* REJECTED. Please RTFM. Searching the [[hcalendar|hCalendar]] spec for *either* "axis" or "headers" would have found the following example in the wild: [http://we05.com/ Web Essentials 05] has marked up their [http://we05.com/program.cfm program schedule table with hCalendar], using the 'axis' and 'headers' attributes.
*# Should embeded components be allowed? [[RyanKing]] has already noted that vJournal overlaps blog-posts (although not yet accepted), but should the components to-do, free/busy, timezone, alarms be allowed? They all considered as just as relevant by the ical spec as events are (my interpretation).
*#* ACCEPTED SPECUPDATE/FAQ. Another [[to-do]] for Tantek. Explicitly specify which additional iCalendar objects (in addition to VEVENT) are permitted in hCalendar. Current additional candidates: VTODO (many examples of this info on the web), VFREEBUSY (already at least one site publishing this info), VALARM (maybe, seems harmless enough, but without a compelling real world use case we should probably omit it). Currently dropping: VTIMEZONE (terrible construct), VJOURNAL (obsoleted by [[hatom|hAtom]]).
*# Validation of the hCalendar tests. The hCalendar tests have been available for a while now, but only Brian Suda and I have made contributions to their content. Does anyone else have thoughts and should we try to make these the beginning of 'official' hCalendar tests?
*#* ACCEPT PARTIAL. We probably need an hCalendar ''validator'' before we can declare any set of tests to be official.
*# The use of fragments is unclear. Fragment interpretation seems to be agent dependant. Fragments usually denote a heading or marker, like a goto statement for HTML. Unfortunately it may jump in the middle of elements (rather to the beginning of an element). How should this be handled. i.e.
<pre>
<a name="myfrag">heading</a>
<div class="vevent">
<div class="description">A nice event</div>
<abbr class="dtstart" title="2005-10-05">October 5</abbr>
</div>
</pre>
*#* ACCEPTED. We should clarify to converters how to interpret a fragement id. The interpretations are all consistent. It points to the element that is to be converted. If that element is empty then so is the conversion. There is no issue here other than a need for more documentation.
* 2006-02-01 raised by [[RyanKing]]
*# ''Issue 1: Given that now, or soon will have hAtom, should we disallow vJournal, so that we don't have 2 blog-post formats?''
*#* ACCEPTED. Yes, we should expliclty DROP "vjournal" from [[hcalendar|hCalendar]].
* 2006-01-04 raised by [[User:CGranade|CGranade]]
*# ''...''
*# ''All examples in XHTML. XHTML should not be the only host to microformats, and thus it should not be the only example host language. Rather, examples in Atom, RSS, RDF, etc. should also be provided.''
*#* ACCEPTED. This is definitely something to be added to *-examples pages for each microformat.
* 2005-10-14 raised by [[User:MarkoMrdjenovic|MarkoMrdjenovic]]
*# ''UID has to be present in iCal events if they want to be used in Microsoft Outlook. [Suggestion:] it should probably be added to the vevent tag as html attribute id. There is also the problem of converters - x2v has UID commented out. [http://www.ietf.org/rfc/rfc2445.txt RFC] recommends use of addr format for uids which is problematic in html id (does not validate). [[User:HenriBergius|HenriBergius]] pointed out some calendaring software crashes when @ is in the UID, so some other form of identification should be used - along the lines of dtstart-dtend-hash(title,summary)-sample-org''.
*#* ACCEPTED-PARTIAL. Yes, it appears RFC2445 requires UID. However, typical mentions of events by web authors do not provide anything equivalent to a UID, nor should we require authors to do so. Thus we must come up with an algorithm for implied UID, similar to some of the other properties. We REJECT the use of the html 'id' attributre as a substitute for UID as they are of different scopes and thus such a translation will likely be problematic. As part of this algorithm, we MUST disallow "@" signs since the issue points out that such UIDs crash some calendaring software.
*# ''DTSTAMP also has to be present in iCal event for Microsoft Outlook. I think DTSTAMP should be user visible information so implementation with class="dtstamp" is fine. x2v already supports it so it should just be added to the standard and examples. The converters might also think of a way to force (create) dtstamp if it's not present.'' [Suggestion:] why not set DTSTAMP to DTSTART if not explicitly defined? -- [[DimitriGlazkov]]
*#* ACCEPTED. We should come up with a way to encourage/synthesize/imply DTSTAMP property values.
*# ''Here is an example from Midgard CMS (which will be easy to change according to bergie on irc):''
*#* For more discussion of this, please see [http://microformats.org/wiki/hcalendar-brainstorming#UID_handling hCalendar brainstorming: UID handling]
<pre><nowiki>
<li class="vevent" id="2678c3f94af4a49f9ccbb69b92a82aba-midgardGuid">
<abbr class="dtstart" title="2005-10-20T14:34:45Z">Torstai 20. Lokakuu 17:34</abbr> -
<abbr class="dtend" title="2005-10-20T15:33:56Z">18:33</abbr>
<a class="url" href="/bergie/another-calendar/82457028ba83407451edd8aaeaa40622.html">
<span class="summary">From the other cal</span>
</a>
<abbr class="dtstamp" title="2005-10-14T12:16:45Z">Torstai 14. Lokakuu 12:16</abbr>
</li></nowiki></pre>
* 2005-09-29 raised by RyanKing
*# ''How does one use ATTENDEE?''
*#* ACCEPTED. Another [[to-do]] for Tantek - document how to use ATTENDEE with [[hcard|hCard]].

* 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 hCalendars 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?
*#* ACCEPTED. Another [[to-do]] for Tantek, write-up [[hcalendar-parsing]] that documents precisely how user agents are to parse [[hcalendar|hCalendar]] markup.
* 2005-02-22 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003124.html on the whatwg list]:
*# ''There is no copyright statement and no patent statement.''
*#* ACCEPTED. I have updated [[hcalendar]] (and [[hcard]], and all other MicroFormats) with a standard copyright statement and patent statement.

* 2005-02-18 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
*# ''...''
*# ''...''
*# ''...''
*# ''...''
*# ''...''
*# ''...''
*# ''I dislike the entire system of using class names as markup. Class names should be reserved for user-defined semantics.''
*#* ACCEPT-PARTIAL. When specific elements are available, they should be used instead of class names, but even then class names work well to "subclass" specific elements. This is thoroughly discussed in the essay [http://tantek.com/log/2002/12.html#L20021216 A Touch of Class]. And yes, class names can and should be used for user-defined semantics. [[hcalendar|hCalendar]] is one such user, and it is reasonable for users to use each others class names.
*#* ''Would it be more in the spirit of HTML to define these classes in a [http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.3 metadata profile], so that "User agents may... perform some activity based on known conventions for that profile"? Should this be a part of [[microformats]] specifications in general? (If not, why not?)''
*#** ACCEPTED. Yes, all [[microformats]] that introduce new classnames SHOULD include an [http://gmpg.org/xmdp/ XMDP] profile (which itself is a microformat for defining HTML metadata profiles) that defines those classnames.
*#*** ''Ok, but in order to refer to a profile, it needs a URI. Tantek writes in [http://microformats.org/discuss/mail/microformats-discuss/2005-July/000407.html a message of Jul 21] "This is precisely the reason that GMPG was founded and created, to provide permanent URLs/homes for microformat profiles." How does one cause GMPG to issue a profile URL?''
*#**** ACCEPTED. See [[profile-uris]]; this is moving from Tantek's [[to-do]] list, to both provide profiles and URLs (probably at gmpg.org) for those profiles for hCalendar etc.

== Closed Issues ==
Resolved issues that have no further actions to take.

* 2006-01-04 raised by [[User:CGranade|CGranade]]
*# ''Interactions with strong namespacing. So far, it seems that hCalendar cannot be embedded into non-XHTML schemas that are also strongly namespaced (e.g.: RDF, Atom) without a resultant validation error, as the <code>class</code> attribute is ''not'' portable across schemas.''
*#* REJECTED. The class attribute is used on XHTML elements, which are XML, which can be embedded in any other XML. The issue as raised doesn't make sense.

* 2005-02-18 raised by Matt Raymond [http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2005-February/003116.html on the whatwg list]:
*# ''There is no way for some reading the markup to tell if a class name is the name of an attribute or simply the name of a class used for styling.''
*#* REJECTED (strawman, poor assumption). There is no need to differentiate in the general case. In the specific case, a vocabulary is defined within a context.
*# ''As a result of the above, user agents would not be able to reliably allow users to access extension properties such as "x-mozilla-alarm-default-length" (which is an actual extension used in Sunbird).''
*#* REJECTED (out of scope). Extension properties are outside the current scope of hCalendar.
*# ''The use of <abbr> for dates is incorrect. "August 5th, 2004" is not the abbreviation of 2004-09-05. In fact, the opposite is closer to the truth.''
*#* REJECTED (false statement). This is simply a false statement. See this article for an explanation of this use of <abbr>: [http://tantek.com/log/2005/01.html#d26t0100 Human vs. ISO8601 dates problem solved]
*# ''You have to create a complex set of rules for all possible uses of legacy markup within <span class="vcalendar"> which can easily be implemented incorrectly.''
*#* REJECTED (false statements, strawman). There is no legacy markup. There is no need to create rules for all possible uses of legacy markup. There is no need to create a complex set of rules.
*# ''There are styling and tooltip issues that are unresolved.''
*#* REJECTED (empty statements). See the [[hcalendar-faq|hCalendar FAQ]] for answers to specific styling and tooltip questions. Otherwise, please raise specific issues here with clear valid examples.
*# ''hCalendar/hCard is more complicated for webmasters to read and understand and more complicated for developers to implement.''
*#* REJECTED (empty statements, invalid comparator). Please state specific examples which show the perceived complexity. The comparison "more complicated" requires two items, no second item was provided.

== Related Pages ==
{{hcalendar-related-pages}}
* [[accessibility-issues#hCaledar|hCalendar accessibility issues]]

vcard-suggestions

2007-04-13T15:26:46Z

CiaranMc: /* Deceased */

<h1> vCard suggestions </h1>

As a result of experience using [[hcard|hCard]] to markup people, organizations, and contact information in general on [[hcard-examples-in-wild|real world websites]], we have discovered a few aspects of RFC 2426 vCard that could be improved. Thus we are documenting suggestions for improving vCard here as we find them, organized by RFC 2426 section number for improvements to current properties, and a "new" section for new properties.

; Authors: Tantek Çelik, [[User:AndyMabbett|Andy Mabbett]]

== Suggestions for Existing Properties ==

Suggestions for improvement could include new features and other such more major changes to the specification, organized under headings that reflect RFC 2426 vCard section numbers and heading. For documentation of errors, corrections, errata for vCard, please see [[vcard-errata]].

=== 3.3.1 TEL Type Definition ===

* 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)]. It may be good to consider adding a "textphone" value to the "type" for "TEL".
** +0 Tantek: I think a rethinking of the taxonomy of TEL types is merited, but I am uncertain whether it is worth growing the existing limited taxonomy or instead permitting user defined TEL types and thus allowing for natural evolution of a folksonomy of TEL types.
** +1 [[User:AndyMabbett|Andy Mabbett]]: There are a limited number of types. Note also the cell vs. mobile issue.

== Suggestions for New Properties ==

===Gender===
*There is no Card property for gender. A workaround: add the tag/category "male", "female", etc. See also [[hcard-faq#How_is_gender_represented|earlier discussion]] and [[genealogy-brainstorming#Gender]].
** -1 Tantek: I think tags/categories are good enough for now.
** +1 [[User:AndyMabbett|Andy Mabbett]]:Tags are often not appropriate, as per the cited discussion.

===Deceased===
*There is no way to mark up a person as being deceased - either by a "deceased" flag or date-of-death. A workaround: add the tag/category "deceased". See also [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007324.html mailing list post on tagging for 'deceased']
** -1 Tantek: I think tags/categories are good enough for now.
** +1 [[User:AndyMabbett|Andy Mabbett]]: Tags are often not appropriate, as per the cited e-mail. DoD is more specific (and often used in real life biographies and obituaries e.g [http://en.wikipedia.org/wiki/Vincent_van_Gogh van Gogh on Wikipedia]). Note also Wikipedia's [http://en.wikipedia.org/wiki/Wikipedia:Persondata Persondata] which aligns very closely with hCard, but has additional date and place of birth & death fields. [[User:AndyMabbett|Andy Mabbett]] 13:06, 28 Jan 2007 (PST)
** +1 for date-of-death [[User:CiaranMc|Ciaran McNulty]]: Date-of-death is useful information in some applications (specifically genealogy).
** -1 for 'deceased' flag [[User:CiaranMc|Ciaran McNulty]]: Tagging can cover this sort of binary flag.

===Instant Messaging===
*See [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770].

===Elevation===
*See [[geo-elevation-examples]]

== Suggestions for handling encodings ==
The vCard standard specifies that US-ASCII is assumed to be the encoding in the absence of a MIME content type header or a CHARSET parameter that indicates otherwise. This was an unfortunate choice. vCard .vcf files stored on a local filesystem do not contain a MIME header and the only way to reliably use an encoding other than ASCII is to tag each field with the "CHARSET=" label. This makes the vCard stream more complicated than necessary. This could be simplified by a revision of the standard that specifies UTF-8 as the default encoding. This could work safely with existing vCard .vcf files, which do not contain a MIME content header. The first vCard VERSION field would be the same encoded as either ASCII or UTF-8, so readers could easily determine which encoding to default to.

Furthermore, those creating vCard readers should be encouraged to support vCard .vcf files that begin with a UTF-8 BOM sequence. If the first three bytes of the file are 0xEF 0xBB 0xBF, the text file is UTF-8 encoded, and the vCard reader should assume UTF-8 is the default. Unfortunately many readers today fail to recognize the UTF-8 BOM and view the file as a corrupt vCard.

==Note==
On 2006-11-24, Paul Hoffman of the [http://www.imc.org/ Internet Mail Consortium], responsible for the development and promotion the vCard standard, wrote in response to an e-mail from [[User:AndyMabbett|Andy Mabbett]] informing him of this web page:
<blockquote>
There has been almost no interest in revising the vCard standard. This is due to lack of momentum, not the lack of good suggestions.
</blockquote>

== See Also ==

* [[vcard-errata|vCard errata]]
* [[hcard|hCard]]
* [http://www.imc.org/imc-vcard/ vCard mailing list] - a place to raise these issues, and where similar issues can be found.

hcard-examples-rfc2426

2006-11-17T10:28:33Z

CiaranMc:

<h1>hCard examples</h1>

Example [[hcard|hCards]].

== Authors ==
* [http://tantek.com/log Tantek Çelik]
* Brian Suda

== Instructive Examples ==

=== Authors of Pages and Posts ===
[http://www.w3.org/TR/html401/struct/global.html#h-7.5.6 Per the HTML4.01 specification], authors should be using the <code><address></code> element to indicate the "contact information for a document or a major part of a document." E.g.

<pre><nowiki>
<address>
<a href="http://tantek.com/">Tantek Çelik</a>
</address>
</nowiki></pre>

By adding [[hcard|hCard]] to such existing semantic XHTML, you can explicitly indicate the name of the person, their URL, etc.:

<pre><nowiki>
<address class="vcard">
<a class="fn url" href="http://tantek.com/">Tantek Çelik</a>
</address>
</nowiki></pre>

This could be displayed as:

[http://tantek.com/ Tantek Çelik]

This works not only for whole pages, but also for "major part[s]" of pages, e.g. blog posts.

See the [http://microformats.org/blog/ microformats.org blog] (view the source) for a live example. The author of every blog post on the microformats.org blog is marked up as an <code><address class="vcard"></code> element like the example shown above.

=== References to People and Organizations ===

A common pattern in blog posts is to link mentions of people's names to their blogs, and/or organizations to their home pages. E.g.:

<pre><nowiki>
<cite><a href="http://meyerweb.com/">Eric Meyer</a></cite> wrote a post
(<cite><a href="http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/">Tax Relief</a></cite>)
about an unintentionally humorous letter he received from the
<a href="http://irs.gov/">Internal Revenue Service</a>.
</nowiki></pre>

By adding hCard to such markup, you can explicitly indicate both the person and the organization by name and URL:

<pre><nowiki>
<cite class="vcard"><a class="fn url" href="http://meyerweb.com/">Eric Meyer</a></cite> wrote a post
(<cite><a href="http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/">Tax Relief</a></cite>)
about an unintentionally humorous letter he received from the
<span class="vcard"><a class="fn org url" href="http://irs.gov/">Internal Revenue Service</a></span>.
</nowiki></pre>

Note the class names "fn org url" on the hyperlink surrounding the IRS. Using the same value (or element for that matter) for "fn" and "org" indicates that the hCard describes an organization rather than a person.

This could be displayed as:

''[http://meyerweb.com/ Eric Meyer]'' wrote a post (''[http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/ Tax Relief]'') about an unintentionally humorous letter
he received from the [http://irs.gov/ Internal Revenue Service].

=== hCard and XFN ===
==== References to People in Blog Posts ====

In the above example, one person (the blogger) is referring to another person (Eric Meyer). In addition to using hCard to explicitly mark up the reference as a person, the blogger can use [http://gmpg.org/xfn/ XFN] (the XHTML Friends Network) to indicate their relationship to Eric Meyer, e.g.:

<pre><nowiki>
<cite class="vcard"><a class="fn url" rel="friend colleague met" href="http://meyerweb.com/">Eric Meyer</a></cite> wrote a post
(<cite><a href="http://meyerweb.com/eric/thoughts/2005/12/16/tax-relief/">Tax Relief</a></cite>)
about an unintentionally humorous letter he received from the
<span class="vcard"><a class="fn org url" href="http://irs.gov/">Internal Revenue Service</a></span>.
</nowiki></pre>

It would be displayed the same as the previous example.

==== References to People in Blogrolls ====

Many bloggers are using XFN (often using an easy user interface like that built into [http://wordpress.org WordPress]) to explicitly indicate their relationships to the people in their blogrolls:

<pre><nowiki>
<ul>
<li><a href="http://meyerweb.com" rel="friend colleague met">Eric Meyer</a></li>
<li><a href="http://photomatt.net" rel="friend colleague met">Matt Mullenweg</a></li>
</ul>
</nowiki></pre>

By adding hCard markup to an XFN Friendly blogroll, you can explicitly indicate the name and URL of the person in addition to their relationship:

<pre><nowiki>
<ul>
<li class="vcard"><a class="fn url" href="http://meyerweb.com" rel="friend colleague met">Eric Meyer</a></li>
<li class="vcard"><a class="fn url" href="http://photomatt.net" rel="friend colleague met">Matt Mullenweg</a></li>
</ul>
</nowiki></pre>

This could be displayed as:
* [http://meyerweb.com Eric Meyer]
* [http://photomatt.net Matt Mullenweg]

For more information on XFN, see the [http://gmpg.org/xfn/ XFN home page], [http://gmpg.org/xfn/join joining XFN], and [http://gmpg.org/xfn/background background on XFN].

This technique is used in the [http://factorycity.net/projects/wp-microformatted-blogroll/ WP Microformatted Blogroll] plugin.

=== New Types of Contact Info ===

Since vCard was designed, there have been numerous other services that provide individuals with addresses or other means of contact, e.g. instant messaging, voip, etc.

Does this mean that vCard (and hence hCard) must be extended to represent these?

Thanks to the flexibility of the URL property, the answer is no, no extensions are necessary. Instead, we use the proper URL for the service which identifies the service (protocol, machine, and/or path), and place the individual's address inside that.

==== AOL Instant Messenger (AIM) ====

AOL Instant Messenger (AIM) ids can be represented using the <code>aim:</code> protocol. Many who publish their AIM ids do so with clickable URLs e.g.:

<pre><nowiki>
<a href="aim:goim?screenname=ShoppingBuddy">IM with the AIM ShoppingBuddy</a>
</nowiki></pre>

Thus for hCard, we will adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="aim:goim?screenname=ShoppingBuddy">IM with the AIM ShoppingBuddy</a>
</nowiki></pre>

==== Yahoo Messenger ====

Similarly, Yahoo Instant Messenger (YIM) ids can be represented using the <code>ymsgr:</code> protocol. And similarly many publish their YIM ids as clickable URLs e.g.:

<pre><nowiki>
<a href="ymsgr:sendIM?SomeYahooFriend">IM with SomeYahooFriend</a>
</nowiki></pre>

Again, for hCard, we will adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="ymsgr:sendIM?SomeYahooFriend">IM with SomeYahooFriend</a>
</nowiki></pre>

==== MSN Messenger ====

<strike>Unfortunately, AFAIK, there is no hacked up defacto protocol for opening an MSN IM session with an MSN userid (which themselves are just email addresses). Thus we must simply resort to marking them up as email addresses, and expect that consumers may use some heuristic, such as "hotmail.com email addresses are also MSN IM ids". -Tantek</strike>

MSN Messenger (MSNIM) ids can be represented using the <code>msnim:</code> protocol. And similarly many publish their MSNIM ids as clickable URLs e.g.:

<pre><nowiki>
<a href="msnim:chat?contact=joebob@hotmail.com">IM with joebob@hotmail.com</a>
</nowiki></pre>

For hCard, we will adopt this existing content publisher behavior, and simply capture it as another URL for the hCard:

<pre><nowiki>
<a class="url" href="msnim:chat?contact=joebob@hotmail.com">IM with joebob@hotmail.com</a>
</nowiki></pre>

Updated 14 May 2006 - [http://www.wackomenace.co.uk/ Ruben]

Ruben, I tried this, and "msnim:" is an unrecognized protocol on MacOSX.4 (this is with the latest MSN Messenger for Mac installed and running and logged int). Could you provide links to documentation about "msnim:" and links to actual pages that publish their MSNIM ids this way? I don't know of any - [http://tantek.com/ Tantek]

: Tantek, Wikipedia's [http://en.wikipedia.org/wiki/History_of_Windows_Live_Messenger History of Windows Live Messenger] states that MSN Messenger 7.5 for Windows, among other things, introduced: "the msnim protocol handler, allowing Web sites to provide links which automatically add a contact or start conversations (for example clicking on link msnim:chat?contact=login@passport.net will start chat conversation with user login@passport.net).". The Mac version is notoriously lagging behind, sadly. --''[[User:Chucker|chucker]] 11:33, 29 Jun 2006 (PDT)''

==== XMPP (Jabber) ====

[http://www.xmpp.org/ Extensible Messaging and Presence Protocol (XMPP)] ids can be represented using the <code>xmpp:</code> protocol, e.g.:

<pre><nowiki>
<a class="url" href="xmpp:username@jabberservice.com">IM with username@jammerservice.com</a>
</nowiki></pre>

The protocol allows much richer URLs, see [http://www.faqs.org/rfcs/rfc4622.html RFC4622].

There are not many current [http://wiki.jabber.org/index.php/XMPP_URIs#Jabber_Clients clients supporting the protocol].

==== Site profiles ====
Bloggers often indicate their identity on content hosting services using the URL to their home page, feed or profile on those services. By labeling them as URL properties, these additional facets of identity can be publish in an hCard as well.

* [http://del.icio.us delicious]:
** <code><a class="url" href="http://del.icio.us/rbach">Robert Bachmann's links</a></code>
* [http://flickr.com Flickr]:
** <code><a class="url" href="http://flickr.com/photos/tantek/">See my photos</a></code>
** <code><a class="url" href="http://flickr.com/people/tantek/">Flickr profile</a></code>
* [http://technorati.com/ Technorati]:
** <code><a class="url" href="http://technorati.com/profile/tantek/">Technorati profile</a></code>
* Add more here...
** ....

=== Organizations and Departments ===

Departments are marked up using the "organization-unit" class name inside the "org" element, with the "organization-name" specifically marked up to distinguish it from the department:

<pre><nowiki>
<div class="vcard">
<div class="org fn">
<div class="organization-name">Sprinkler Fitters U.A. Local 483</div>
<div class="organization-unit">Apprenticeship Training Center</div>
</div>
</div>
</nowiki></pre>

The department may also be part of the address, in which case, you may want to explicitly mark it up as the "extended-address" in addition to the "organization-unit".

<pre><nowiki>
<div class="vcard">
<div class="adr">
<div class="org fn">
<div class="organization-name">Sprinkler Fitters U.A. Local 483</div>
<div class="organization-unit extended-address">Apprenticeship Training Center</div>
</div>
<div class="street-address">2531 Barrington Court</div>
<span class="locality">Hayward</span>,
<abbr title="California" class="region">CA</abbr>
<span class="postal-code">94545</span>
</div>
</div>
</nowiki></pre>

Note that by nesting the org inside the address we avoided having to duplicate the department name.

== RFC 2426 examples in hCard ==

These are 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

Mark Pilgrim has made these hCard examples available as separate files:
* http://diveintomark.org/projects/greasemonkey/hcard/tests/

=== 2.4.2 VCARD ===

<pre><nowiki>
AGENT:BEGIN:VCARD\nFN:Joe Friday\nTEL:+1-919-555-7878\n
TITLE:Area Administrator\, Assistant\n EMAIL\;TYPE=INTERNET:\n
jfriday@host.com\nEND:VCARD\n
</nowiki></pre>

This vCard fragment has one property whose value is another vCard, and could be represented as an hCard fragment with an embedded hCard, literally (with the unnecessary type=internet default omitted, and the implied n optimization):

<pre><nowiki>
<div class="agent vcard">
<a class="email fn" href="mailto:jfriday@host.com">Joe Friday</a>
<div class="tel">+1-919-555-7878</div>
<div class="title">Area Administrator, Assistant</div>
</div>
</nowiki></pre>

this hCard could be displayed as:

[mailto:jfriday@host.com Joe Friday]<br />
+1-919-555-7878<br />
Area Administrator, Assistant

=== 3.1.1 FN Type Definition ===

<pre><nowiki>
FN:Mr. John Q. Public\, Esq.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn">Mr. John Q. Public, Esq.</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Mr. John Q. Public, Esq.

=== 3.1.2 N Type Definition ===

==== Example 1 ====

<pre><nowiki>
N:Public;John;Quinlan;Mr.;Esq.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n">
<span class="honorific-prefix">Mr.</span>
<span class="given-name">John</span>
<span class="additional-name">Quinlan</span>
<span class="family-name">Public</span>,
<span class="honorific-suffix">Esq.</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Mr. John Quinlan Public, Esq.

==== Example 2 ====

<pre><nowiki>
N:Stevenson;John;Philip,Paul;Dr.;Jr.,M.D.,A.C.P.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n">
<span class="honorific-prefix">Dr.</span>
<span class="given-name">John</span>
<span class="additional-name">Philip</span>
<span class="additional-name">Paul</span>
<span class="family-name">Stevenson</span>,
<span class="honorific-suffix">Jr.</span>,
<span class="honorific-suffix">M.D.</span>,
<span class="honorific-suffix">A.C.P.</span>
</span>
</nowiki></pre>

this hCard fragment would be displayed as:

Dr. John Philip Paul Stevenson, Jr., M.D., A.C.P.

=== 3.1.3 NICKNAME Type Definition ===

==== Example 1 ====

<pre><nowiki>
NICKNAME:Robbie
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="nickname">Robbie</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Robbie

==== Example 2 ====

<pre><nowiki>
NICKNAME:Jim,Jimmie
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="nickname">Jim</span>,
<span class="nickname">Jimmie</span>
</nowiki></pre>

this hCard fragment would be displayed as:

Jim, Jimmie

=== 3.1.4 PHOTO Type Definition ===

==== Example 1 ====
<pre><nowiki>
PHOTO;VALUE=uri:http://www.abc.com/pub/photos/jqpublic.gif
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<img class="photo" src="http://www.abc.com/pub/photos/jqpublic.gif" alt="" />
</nowiki></pre>

==== Example 2 ====
<pre><nowiki>
PHOTO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...remainder of "B" encoded binary data...>
</nowiki></pre>

this vCard fragment as an hCard fragment (line breaks inserted into src value for readability):

<pre><nowiki>
<img class="photo" src="data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
...remainder of B encoded binary data..." alt="" />
</nowiki></pre>

=== 3.1.5 BDAY Type Definition ===

==== Example 1 ====

<pre><nowiki>
BDAY:1996-04-15
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="bday" title="1996-04-15">April 15, 1996</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="bday" title="1996-04-15">April 15, 1996</abbr>

==== Example 2 ====

<pre><nowiki>
BDAY:1953-10-15T23:10:00Z
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="bday" title="1953-10-15T23:10:00Z">Oct 15, 1953</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="bday" title="1953-10-15T23:10:00Z">Oct 15, 1953</abbr>

==== Example 3 ====

<pre><nowiki>
BDAY:1987-09-27T08:30:00-06:00
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="bday" title="1987-09-27T08:30:00-06:00">Sept 9, 1987</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="bday" title="1987-09-27T08:30:00-06:00">Sept 9, 1987</abbr>

=== 3.2.1 ADR Type Definition ===

<pre><nowiki>
ADR;TYPE=dom,home,postal,parcel:;;123 Main
Street;Any Town;CA;91921-1234
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<div class="adr">
<abbr class="type" title="dom">US</abbr>
<span class="type">home</span> address, for
<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">shipments</abbr>:
<div class="street-address">123 Main Street</div>
<span class="locality">Any Town</span>, <span class="region">CA</span>,
<span class="postal-code">91921-1234</span>
</div>
</nowiki></pre>

this hCard fragment could be displayed as:

<div class="adr">
<abbr class="type" title="dom">US</abbr>
<span class="type">home</span> address, for
<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">shipments</abbr>:
<div class="street-address">123 Main Street</div>
<span class="locality">Any Town</span>, <span class="region">CA</span>,
<span class="postal-code">91921-1234</span>
</div>

=== 3.2.2 LABEL Type Definition ===

<pre><nowiki>
LABEL;TYPE=dom,home,postal,parcel:Mr.John Q. Public\, Esq.\n
Mail Drop: TNE QB\n123 Main Street\nAny Town\, CA 91921-1234
\nU.S.A.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
Please use the following address label for
<div class="label">
<abbr class="type" title="dom">local delivery</abbr>
<abbr class="type" title="home">to my home</abbr>
<abbr class="type" title="postal">of mail</abbr>
<abbr class="type" title="parcel">and packages:</abbr>
<pre>
Mr.John Q. Public, Esq.
Mail Drop: TNE QB
123 Main Street
Any Town, CA 91921-1234
U.S.A.
</pre>
</div>
</nowiki></pre>

'''Note:''' the above hCard fragment uses a <pre> tag inside a property value to capture/represent explicit carriage returns ("\n" characters) from the vCard fragment.

this hCard fragment could be displayed as:

Please use the following address label for
<abbr class="type" title="dom">local delivery</abbr>
<abbr class="type" title="home">to my home</abbr>
<abbr class="type" title="postal">of mail</abbr>
<abbr class="type" title="parcel">and packages:</abbr>
<pre>
Mr.John Q. Public, Esq.
Mail Drop: TNE QB
123 Main Street
Any Town, CA 91921-1234
U.S.A.
</pre>

=== 3.3.1 TEL Type Definition ===

<pre><nowiki>
TEL;TYPE=work,voice,pref,msg:+1-213-555-1234
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="tel">
<abbr class="type" title="pref">my</abbr>
<span class="type">work</span>
<abbr class="type" title="voice">phone</abbr>, with
<abbr class="type" title="msg">voicemail</abbr>:
<span class="value">+1-213-555-1234</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

my work phone, with voicemail: +1-213-555-1234

=== 3.3.2 EMAIL Type Definition ===

==== Example 1 ====

<pre><nowiki>
EMAIL;TYPE=internet:jqpublic@xyz.dom1.com
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<a class="email" href="mailto:jqpublic@xyz.dom1.com">email jqpublic</a>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:jqpublic@xyz.dom1.com email jqpublic]

==== Example 2 ====

<pre><nowiki>
EMAIL;TYPE=internet:jdoe@isp.net
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<a class="email" href="mailto:jdoe@isp.net">email jdoe</a>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:jdoe@isp.net email jdoe]

==== Example 3 ====

<pre><nowiki>
EMAIL;TYPE=internet,pref:jane_doe@abc.com
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<a class="email" href="mailto:jane_doe@abc.com">
<abbr class="type" title="pref">preferred</abbr>
email for jane_doe
</a>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:jane_doe@abc.com preferred email for jane_doe]

=== 3.3.3 MAILER Type Definition ===

<pre><nowiki>
MAILER:PigeonMail 2.1
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
Jane Doe uses <span class="mailer">PigeonMail 2.1</span> for email.
</nowiki></pre>

this hCard fragment could be displayed as:

Jane Doe uses <span class="mailer">PigeonMail 2.1</span> for email.

=== 3.4.1 TZ Type Definition ===

==== Example 1 ====

<pre><nowiki>
TZ:-05:00
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="tz">-05:00</span>
</nowiki></pre>

this hCard fragment could be displayed as:

-05:00
==== Example 2 ====

<pre><nowiki>
TZ;VALUE=text:-05:00; EST; Raleigh/North America
;This example has a single value, not a structure text value.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="tz"
title="-05:00; EST; Raleigh/North America;This example has a single value, not a structure text value.">
EST
</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="tz" title="-05:00; EST; Raleigh/North America;This example has a single value, not a structure text value.">EST</abbr>

=== 3.4.2 GEO Type Definition ===

<pre><nowiki>
GEO:37.386013;-122.082932
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="geo">
<span class="latitude">37.386013</span>,
<span class="longitude">-122.082932</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

37.386013, -122.082932

=== 3.5.1 TITLE Type Definition ===

<pre><nowiki>
TITLE:Director\, Research and Development
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="title">Director, Research and Development</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Director, Research and Development

=== 3.5.2 ROLE Type Definition ===

<pre><nowiki>
ROLE:Programmer
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="role">Programmer</span>
</nowiki></pre>

this hCard fragment could be displayed as:

Programmer

=== 3.5.3 LOGO Type Definition ===

==== Example 1 ====

<pre><nowiki>
LOGO;VALUE=uri:http://www.abc.com/pub/logos/abccorp.jpg
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<img class="logo" src="http://www.abc.com/pub/logos/abccorp.jpg" alt="my logo" />
</nowiki></pre>

this hCard fragment could be displayed as (note: I used a real URL for the image):

http://microformats.org/img/mf-lg-ora.gif

==== Example 2 ====

<pre><nowiki>
LOGO;ENCODING=b;TYPE=JPEG:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of "B" encoded binary data...>
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<img class="logo" src="data:image/jpeg;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
...remainder of B encoded binary data..." alt="" />
</nowiki></pre>

no display equivalent given, since data: URL from original example is incomplete.

=== 3.5.4 AGENT Type Definition ===

==== Example 1 ====

<pre><nowiki>
AGENT;VALUE=uri:
CID:JQPUBLIC.part3.960129T083020.xyzMail@host3.com
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<a class="agent" href="CID:JQPUBLIC.part3.960129T083020.xyzMail@host3.com">JQPUBLIC</a>
</nowiki></pre>

this hCard fragment could be displayed as:

JQPUBLIC

==== Example 2 ====

<pre><nowiki>
AGENT:BEGIN:VCARD\nFN:Susan Thomas\nTEL:+1-919-555-
1234\nEMAIL\;INTERNET:sthomas@host.com\nEND:VCARD\n
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="agent vcard">
<a class="email fn n" href="mailto:sthomas@host.com">Susan Thomas</a>,
<span class="tel">+1-919-555-1234</span>
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

[mailto:sthomas@host.com Susan Thomas], +1-919-555-1234

Note: the vCard in the AGENT property vCard fragment is actually invalid since it lacks an "N" property. However, the hCard version *is* valid, since I added the "n" class name to the example.

=== 3.5.5 ORG Type Definition ===

<pre><nowiki>
ORG:ABC\, Inc.;North American Division;Marketing
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="org">
<span class="organization-name">ABC, Inc.</span>,
<span class="organization-unit">North American Division</span>,
<span class="organization-unit">Marketing</span>,
</span>
</nowiki></pre>

this hCard fragment could be displayed as:

ABC, Inc., North American Division, Marketing

=== 3.6.1 CATEGORIES Type Definition ===

==== Example 1 ====

<pre><nowiki>
CATEGORIES:TRAVEL AGENT
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="category">TRAVEL AGENT</span>
</nowiki></pre>

this hCard fragment could be displayed as:

TRAVEL AGENT

==== Example 2 ====

<pre><nowiki>
CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="category">INTERNET</span>,
<span class="category">IETF</span>,
<span class="category">INDUSTRY</span>,
<span class="category">INFORMATION TECHNOLOGY</span>
</nowiki></pre>

this hCard fragment would be displayed as:

INTERNET, IETF, INDUSTRY, INFORMATION TECHNOLOGY

=== 3.6.2 NOTE Type Definition ===

<pre><nowiki>
NOTE:This fax number is operational 0800 to 1715
EST\, Mon-Fri.
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<p class="note">This fax number is operational 0800 to 1715 EST, Mon-Fri.</p>
</nowiki></pre>

this hCard fragment could be displayed as:

This fax number is operational 0800 to 1715 EST, Mon-Fri.

=== 3.6.3 PRODID Type Definition ===

<pre><nowiki>
PRODID:-//ONLINE DIRECTORY//NONSGML Version 1//EN
</nowiki></pre>

Note, this vCard property actually doesn't make sense as a hCard property, since it really should be filled in by whatever code transforms the hCard into a vCard, e.g. Brian Suda's X2V.

=== 3.6.4 REV Type Definition ===

==== Example 1 ====

<pre><nowiki>
REV:1995-10-31T22:27:10Z
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="rev" title="1995-10-31T22:27:10Z">Updated: 10/31 10:27p</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="rev" title="1995-10-31T22:27:10Z">Updated: 10/31 10:27p</abbr>

==== Example 2 ====

<pre><nowiki>
REV:1997-11-15
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<abbr class="rev" title="1997-11-15">Updated: November 15</abbr>
</nowiki></pre>

this hCard fragment could be displayed as:

<abbr class="rev" title="1997-11-15">Updated: November 15</abbr>

=== 3.6.5 SORT-STRING Type Definition ===

==== Example 1 ====

<pre><nowiki>
FN:Rene van der Harten
N:van der Harten;Rene;J.;Sir;R.D.O.N.
SORT-STRING:Harten
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n"
<span class="honorific-prefix">Sir</span>
<span class="fn">
<span class="given-name">Rene</span>
<span class="family-name">
van der <span class="sort-string">Harten</span>
</span>
</span>
(<span class="additional-name">J.</span>),
<span class="honorific-suffix">R.D.O.N.</span>
</span>
</nowiki></pre>

Note: The string "Harten" was NOT repeated in the hCard, even though it WAS repeated in the vCard (3 times! In N, FN, and SORT-STRING). The "SORT-STRING" property provides another good demonstration of how hCard enables better adherence to the [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_1:_DRY DRY principle] than vCard.

this hCard fragment could be displayed as:

Sir Rene van der Harten (J.), R.D.O.N.

==== Example 2 ====

<pre><nowiki>
FN:Robert Pau Shou Chang
N:Pau;Shou Chang;Robert
SORT-STRING:Pau
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn n">
<span class="additional-name">Robert</span>
<span class="family-name sort-string">Pau</span>
<span class="given-name">Shou Chang</span>
</span>
</nowiki></pre>

Note: Not only was the string "Pau" was NOT repeated in the hCard (better [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_1:_DRY DRY principle] adherence again), even though it WAS repeated in the vCard, but in this case since the "family-name" and "sort-string" are the same, we were able to use [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_2:_element_conservation element conservation] and use only one element for both properties.

this hCard fragment could be displayed as:

Robert Pau Shou Chang

==== Example 3 ====

<pre><nowiki>
FN:Osamu Koura
N:Koura;Osamu
SORT-STRING:Koura
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn">
Osamu <span class="sort-string">Koura</span>
</span>
</nowiki></pre>

Note: This example, in addition to illustrating better support for the [http://microformats.org/wiki/hcard-example1-steps#hCard_example_iteration_1:_DRY DRY principle], also makes use of the [http://microformats.org/wiki/hcard#Implied_.22N.22_Optimization Implied "N" Optimization].

this hCard fragment could be displayed as:

Osamu Koura

==== Example 4 ====

<pre><nowiki>
FN:Oscar del Pozo
N:del Pozo Triscon;Oscar
SORT-STRING:Pozo
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="n">
<span class="fn">
<span class="given-name">Oscar</span>
del <span class="sort-string">Pozo</span>
</span>
<span class="family-name" style="display:none">
del Pozo Triscon
</span>
</span>
</nowiki></pre>

Note: This example unfortunately could not completely adhere to the DRY principle due to the "FN" using a *substring* of the family-name, and in addition thus had to hide the extra "family-name" string value using CSS display:none, which in general should be avoided. Suggestion welcome for improvements on this hCard fragement.

this hCard fragment could be displayed as:

Oscar del Pozo

==== Example 5 ====

<pre><nowiki>
FN:Christine d'Aboville
N:d'Aboville;Christine
SORT-STRING:Aboville
</nowiki></pre>

this vCard fragment as an hCard fragment:

<pre><nowiki>
<span class="fn">
Christine d'<span class="sort-string">Aboville</span>
</span>
</nowiki></pre>

Note: This example re-demonstrates the same hCard advantages/efficiencies demonstrated in [http://microformats.org/wiki/hcard-examples#Example_3_3 example 3] above.

this hCard fragment could be displayed as:

Christine d'Aboville

=== 3.6.6 SOUND Type Definition ===

==== Example 1 ====

<pre><nowiki>
SOUND;TYPE=BASIC;VALUE=uri:CID:JOHNQPUBLIC.part8.
19960229T080000.xyzMail@host1.com
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<object class="sound" type="audio/basic"
data="CID:JOHNQPUBLIC.part8.19960229T080000.xyzMail@host1.com">
pronounciation of "JOHN Q PUBLIC"
</object>
</nowiki></pre>

this hCard fragment would probably be displayed as

pronounciation of "JOHN Q PUBLIC"

unless your browser supports the MIME type "audio/basic" (defined in [http://www.rfc-editor.org/rfc/rfc2046.txt RFC2046 section 4.3]) and has some way of retrieving "CID:" urls.

==== Example 2 ====
<pre><nowiki>
SOUND;TYPE=BASIC;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
<...the remainder of "B" encoded binary data...>
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<object class="sound"
data="data:audio/basic;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcN
AQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bm
ljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
...the remainder of "B" encoded binary data...">
pronounciation
</object>
</nowiki></pre>

no display equivalent given, since data: URL from original example is incomplete.

=== 3.6.7 UID Type Definition ===

<pre><nowiki>
UID:19950401-080045-40000F192713-0052
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
Unique id:
<span class="uid">19950401-080045-40000F192713-0052</span>
</nowiki></pre>

this hCard fragment could be displayed as

Unique id:19950401-080045-40000F192713-0052

Note: in practice I don't think I've seen globally unique IDs for "contact info" records published on the web, but perhaps I am not considering enough examples.

=== 3.6.8 URL Type Definition ===

<pre><nowiki>
URL:http://www.swbyps.restaurant.french/~chezchic.html
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<a class="url" href="http://www.swbyps.restaurant.french/~chezchic.html">Chez Chic</a>
</nowiki></pre>

this hCard fragment could be displayed as

[http://www.swbyps.restaurant.french/~chezchic.html Chez Chic]

=== 3.7.1 CLASS Type Definition ===

==== Example 1 ====

<pre><nowiki>
CLASS:PUBLIC
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="class">PUBLIC</span>
</nowiki></pre>

this hCard fragment could be displayed as

PUBLIC

==== Example 2 ====

<pre><nowiki>
CLASS:PRIVATE
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="class">PRIVATE</span>
</nowiki></pre>

this hCard fragment could be displayed as

PRIVATE

==== Example 3 ====

<pre><nowiki>
CLASS:CONFIDENTIAL
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<span class="class">CONFIDENTIAL</span>
</nowiki></pre>

this hCard fragment could be displayed as

CONFIDENTIAL

=== 3.7.2 KEY Type Definition ===

<pre><nowiki>
KEY;ENCODING=b:MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQA
wdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENbW11bmljYX
Rpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNj
E5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYD
VQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAx
MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz
Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ
EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2
dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB
EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau
+hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIP
mx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSoi//y
rZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7
UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==
</nowiki></pre>

this vCard fragment as an hCard fragment

<pre><nowiki>
<object class="key" type="application/octet-stream"
data="data:application/octet-stream;base64,MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQA
wdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENbW11bmljYX
Rpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZvcm1hdGlvbiBTeXN0
ZW1zMRwwGgYDVQQDExNyb290Y2EubmV0c2NhcGUuY29tMB4XDTk3MDYwNj
E5NDc1OVoXDTk3MTIwMzE5NDc1OVowgYkxCzAJBgNVBAYTAlVTMSYwJAYD
VQQKEx1OZXRzY2FwZSBDb21tdW5pY2F0aW9ucyBDb3JwLjEYMBYGA1UEAx
MPVGltb3RoeSBBIEhvd2VzMSEwHwYJKoZIhvcNAQkBFhJob3dlc0BuZXRz
Y2FwZS5jb20xFTATBgoJkiaJk/IsZAEBEwVob3dlczBcMA0GCSqGSIb3DQ
EBAQUAA0sAMEgCQQC0JZf6wkg8pLMXHHCUvMfL5H6zjSk4vTTXZpYyrdN2
dXcoX49LKiOmgeJSzoiFKHtLOIboyludF90CgqcxtwKnAgMBAAGjNjA0MB
EGCWCGSAGG+EIBAQQEAwIAoDAfBgNVHSMEGDAWgBT84FToB/GV3jr3mcau
+hUMbsQukjANBgkqhkiG9w0BAQQFAAOBgQBexv7o7mi3PLXadkmNP9LcIP
mx93HGp0Kgyx1jIVMyNgsemeAwBM+MSlhMfcpbTrONwNjZYW8vJDSoi//y
rZlVt9bJbs7MNYZVsyF1unsqaln4/vy6Uawfg8VUMk1U7jt8LYpo4YULU7
UZHPYVUaSgVttImOHZIKi4hlPXBOhcUQ==">
Key
</object>

</nowiki></pre>

this hCard fragment could be displayed as

Key

Note: Because of the lack of a TYPE value in the RFC2426 example, I substituted application/octet-stream. Clearly for it to be of some use, the type specified must be some sort of key or certificate mime type.

=== 7. Authors' Addresses ===

<pre><nowiki>
BEGIN:vCard
VERSION:3.0
FN:Frank Dawson
ORG:Lotus Development Corporation
ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive
;Raleigh;NC;27613-3502;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-919-676-9515
TEL;TYPE=FAX,WORK:+1-919-676-9564
EMAIL;TYPE=INTERNET,PREF:Frank_Dawson@Lotus.com
EMAIL;TYPE=INTERNET:fdawson@earthlink.net
URL:http://home.earthlink.net/~fdawson
END:vCard

BEGIN:vCard
VERSION:3.0
FN:Tim Howes
ORG:Netscape Communications Corp.
ADR;TYPE=WORK:;;501 E. Middlefield Rd.;Mountain View;
CA; 94043;U.S.A.
TEL;TYPE=VOICE,MSG,WORK:+1-415-937-3419
TEL;TYPE=FAX,WORK:+1-415-528-4164
EMAIL;TYPE=INTERNET:howes@netscape.com
END:vCard
</nowiki></pre>

Note that both of these vCards are invalid since they lack the REQUIRED "N" property which is quite ironic, since these are the vCards of the authors themselves.

Nonetheless, these vCards can be represented by the following hCards:

<pre><nowiki>
<div class="vcard">
<a class="url fn" href="http://home.earthlink.net/~fdawson">Frank Dawson</a>
<div class="org">Lotus Development Corporation</div>
<div class="adr">
<span class="type">work</span> address
(<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">packages</abbr>):
<div class="street-address">6544 Battleford Drive</div>
<span class="locality">Raleigh</span>
<span class="region">NC</span>
<span class="postal-code">27613-3502</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-919-676-9515</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-919-676-9564</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
<a class="email" href="mailto:Frank_Dawson@Lotus.com">
<span class="type">pref<span>erred</span> email</span>
</a>,
<a class="email" href="mailto:fdawson@earthlink.net">
alternate email
</a>
</div>
<div class="vcard">
<a class="email fn" href="mailto:howes@netscape.com">Tim Howes</a>
<div class="org">Netscape Communications Corp.</div>
<div class="adr">
<span class="type">work</span> address:
<div class="street-address">501 E. Middlefield Rd.</div>
<span class="locality">Mountain View</span>,
<span class="region">CA</span>
<span class="postal-code">94043</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-415-937-3419</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-415-528-4164</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
</div>
</nowiki></pre>

this hCards could be displayed as

<div class="vcard">
[http://home.earthlink.net/~fdawson Frank Dawson]
<div class="org">Lotus Development Corporation</div>
<div class="adr">
<span class="type">work</span> address
(<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">packages</abbr>):
<div class="street-address">6544 Battleford Drive</div>
<span class="locality">Raleigh</span>
<span class="region">NC</span>
<span class="postal-code">27613-3502</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-919-676-9515</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-919-676-9564</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
[mailto:Frank_Dawson@Lotus.com preferred email],
[mailto:fdawson@earthlink.net alternate email]
</div>

<div class="vcard">
[mailto:howes@netscape.com Tim Howes]
<div class="org">Netscape Communications Corp.</div>
<div class="adr">
<span class="type">work</span> address:
<div class="street-address">501 E. Middlefield Rd.</div>
<span class="locality">Mountain View</span>,
<span class="region">CA</span>
<span class="postal-code">94043</span>
<div class="country-name">U.S.A.</div>
</div>
<div class="tel">
<span class="value">+1-415-937-3419</span>
(<abbr class="type" title="WORK">w</abbr>,
<abbr class="type" title="VOICE">v</abbr><abbr class="type" title="MSG">m</abbr>)
</div>
<div class="tel">
<span class="value">+1-415-528-4164</span>
(<abbr class="type" title="WORK">w</abbr><abbr class="type" title="FAX">f</abbr>)
</div>
</div>

== Test Cases ==

These are [[hcard|hCard]] examples which have been found to be particularly useful in finding bugs in hCard parsers (e.g. X2V).

=== Problem with BDAY Information ===

this example:

<pre>

<div class="bday">
<dt>Birthday</dt>
<dd>
<abbr class="value" title="1985-10-27T00:00:00Z">October 27, 1985</abbr>
</dd>
</div>
</pre>

ought to produce "BDAY:1985-10-27T00:00:00Z" but it produces "BDAY:Birthday October 27\, 1985". interesting is that the apple addressbook is still willing to accept it in this way.

=== case-INSENSITIVITY of type values ===

* "home" vs. "Home"

this example works with X2V:

<pre>
<div class="tel">
<dt>Phone (<span class="type">home</span>)</dt>
<dd><span class="value">+438123418</span></dd>
</div>
</pre>

this does not, but should. but instead it becomes just TEL without a type in the vcard

<pre>
<div class="tel">
<dt>Phone (<span class="type">Home</span>)</dt>
<dd><span class="value">+438123418</span></dd>
</div>
</pre>

=== GEO parsing ===
The following hCard:

<pre><nowiki>
<div class="vcard">
<span class="n">
<a class="url" href="http://t37.net">
<span class="given-name">Fréderic</span>
<span class="family-name">de Villamil</span>
</a>
</span>
<span class="nickname">neuro</span>
<a class="email" href="mailto:neuroNOSPAM@t37.net">
<span class="type">pref<span>erred</span> email</span>
</a>
<span class="org">Omatis</span>
<span class="adr">
<abbr class="type" title="dom">France</abbr>
<span class="type">home</span> address
<abbr class="type" title="postal">mail</abbr> and
<abbr class="type" title="parcel">shipments</abbr>:
<span class="street-address">12 rue Danton</span>
<span class="locality">Le Kremlin-Bicetre</span>
<span class="postal-code">94270</span>
<span class="country-name">France</span>
</span>
<span class="geo">
<abbr class="latitude" title="48.816667">N 48° 81.6667</abbr>
<abbr class="longitude" title="2.366667">E 2° 36.6667</abbr>
</span>
</div>
</nowiki>
</pre>

Should be translated into the following vCard:

<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
URL:http://t37.net
ORG:Omatis;;
NICKNAME:neuro
N:de Villamil;Frederic;;Mr.;
EMAIL;TYPE=INTERNET,PREF:neuroNOSPAM@t37.net
ADR;TYPE=HOME:;;12 rue danton;le Kremlin-Bicetre;;94270;France
GEO:48.816667;2.366667
END:VCARD
</nowiki></pre>

X2V currently (2005-12-18) fails to parse/export the GEO property at all.

== Other ==

* See [[hcard-brainstorming]] for more examples (which may eventually be moved here) and analysis.

vcard-implementations

2006-10-25T16:08:53Z

CiaranMc: /* Nokia series 60 address book */

<h1> vCard implementations </h1>

In the development of [[hcard|hCard]] and proxies like X2V, we have discovered various behaviors and quirks of vCard implementations. See also the [[vcard-errata]].

__TOC__

== Contributors==
* Tantek Çelik
* Brian Suda

== Microsoft Outlook ==

version? platform?

=== single import ===
Outlook (either 2k3 or 2k7 beta) appears to only support one vCard per VCF. There are some
third-party product that attempt to fix this [http://www.sperrysoftware.com/Outlook/Vcard-Converter.asp]

=== URL handling ===

URL without non-standard TYPE param seems to be ignored.

=== ADR handling ===

Appears to not support the post-office-box sub-property of ADR.

== Windows Address Book (WAB) ==
Version 6.00.X Win98 and Win XP Pro

=== vCard ENCODING ===
UTF-8 encoded vCard import prompts error as unrecognised vCard format. US ASCII 20127 encoded vCard successfully imported

=== ADR ===
If you do NOT specify TYPE=HOME,WORK,... then no address information is imported

=== TEL ===
If you do NOT specify TYPE=HOME,WORK,... then no address information is imported

=== PHOTO ===
Does not support Images

=== NOTE ===
According to the example in the RFC spec, all commas should be escaped, but WAB does not Un-escape them, leaving \, in the notes field.

== Apple Address Book ==

On both OSX.3 and OSX.4.

=== general comments ===
* There are issues with importing UTF-8 vCards. Apple Address Book appears to treat .vcf files in the file system NOT as UTF-8, but rather perhaps Mac Roman?
** Workaround: Explicitly specify the UTF-8 charset for vCard properties/fields that have non-ASCII-7 characters.
* Importing multiple vCards with the same fn/n results in duplicate entries in the Address Book. Basically, Address Book assumes that every vCard present in a single .vcf file represents a different person, even if the fn/n are the same etc.
** Workarounds:
*** Only markup one hCard per person, per page (has potential implications for [[hresume|hResume]]).
*** Have the converting application/service (e.g. X2V), do automerging of hCards with the same fn/n and generate a .vcf stream with one vCard per unique fn/n.

=== organization vs. individual ===

Summary: FN==ORG organization semantic supported for both import and export.

For organization contact info, sets the FN and ORG to the name of the organization and N to empty on exported vCards.

Also treats imported vCards like that as organization contact info cards visibly in the UI.

=== geo (lack of support) ===

The GEO field is ignored on imported vCards. It is only saved as part of the NOTE.

=== source (lack of support) ===

The SOURCE property is not supported on imported vCards. It is only saved as part of the NOTE.

=== logo (lack of support) ===

The LOGO property is totally ignored and not even saved as part of the NOTE.

=== photo (limitations) ===

The PHOTO property can only take inline encoded data. URL values for are ignored.

=== url (limitations) ===

Only ONE URL property value is supported (whereas multiple *should* be supported, just like EMAIL).

=== adr (behaviour) ===

If you do NOT specify which type of address information it is (like HOME or WORK) it is assumed to be a WORK address.

=== categories (behaviour) ===

Behavior confirmed on versions:
* default on OSX.3
* Version 4.03 (483) on OSX.

Summary: Exports native "Groups" as vCard CATEGORIES. Ignores CATEGORIES field when importing a vCard.

The UI lets you create distinct "Groups" which you can then drag contacts into. Contacts can be in more than one group. Upon exporting a contact that is in one or more Groups, those Groups are listed in the CATEGORIES field.

However, when importing vCards, the CATEGORIES field is totally ignored by Address Book.
# It does not add vCards with a category that matches a current Group to that Group.
# It does not create new Groups for vCards with new categories.
# It does not even add the CATEGORIES to the end of the notes field.
Though presumably it SHOULD do #1 and #2. Would also be nice if it simply let you edit the groups/categories for a contact simply as a list of tags for that contact.

== Evolution ==

On Linux.

=== geo (lack of support) ===

* ichigo, Frederic to fill in details

== Nokia series 60 address book ==

=== Line endings ===

The Contacts application on Nokia series 60 handsets will only open vCards with Windows (\r\n) line endings. Any other line ending styles will cause an error message.

This is actually reasonable behaviour because the vCard spec explicitly states \r\n should be used, but many applications will accept \n delimited vCards without complaint, and may microformat services produce \n delimited output.

vcard-implementations

2006-10-24T18:32:15Z

CiaranMc: Notes on Nokia phone compatibility with vcards

hcard-issues

2006-10-22T15:13:17Z

CiaranMc: /* Issues */

<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. 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/log/ Tantek]

See related [[hcalendar-issues]].

__TOC__

== Issues ==

* 2006-10-21 raised by [[User:AndyMabbett|AndyMabbett]]
*# 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.

* 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]) 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="Middle Name" class="additional-name">M</abbr></code>. Honorific Suffixes in the RFC include Jr. Esq. and other inherited suffixes, so i would just use <code><span class="honorific-suffix">Jr.</span></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>
<span class="adr">
<span class="type">work</span>:
...
</span>
</nowiki></pre>
<pre><nowiki>
<span class="tel">
<span class="type">work</span>:
<span class="value">123.456.7890</span>
</span>
</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><span class="fn org">W3C</span></code> (recommended)
*#*# Set "org" as usual, and set "fn" explicitly to empty. E.g. <code><span class="fn"></span><span class="org">W3C</span></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) addressbook:
*#*** 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 mailto's. 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. Implemenations 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 extention, 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-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 defintion 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-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-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.

* 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 optoinally 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><span class="category">food</span></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]] 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.''

== 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.''

irc

2006-10-20T10:09:38Z

CiaranMc: /* People on irc */

__NOTOC__
= Microformats IRC =

We have an IRC channel, [irc://irc.freenode.net/microformats #microformats on the freenode network].

There's typically someone there at any point during the day, though there isn't always active discussion. Sometimes, though this is the best place to discuss issues that need lots of back and forth discussion.

== People on irc ==
A list of IRC regulars and their normal timezones. (winter/summer)

* [[User:BenWest|bewest]] (-0800/-0700)
* [[User:Adam Craven|AdamCraven]] (+0000)
* [[User:Amette|amette]] (+1000)
* [[User:B.K._DeLong|bkdelong]] (-0500/-0400)
* [[User:Ben Ward|BenWard]] (+0000)
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)
* [[User:Boneill|boneill]] (+0000)
* [[User:Brian|briansuda]] (+0000)
* [[User:ColinDDevroe|cdevroe]] (-0500/-0600)
* [[User:Cgriego|cgriego]] (-0600/-0500)
* [[User:CharlesRoper|charles_r]] (0000/+0100)
* [[User:ChrisCasciano|pnhChris]] (-0500/-0400)
* [[User:ChrisMessina|factoryjoe]] (-0800/-0700)
* [[User:ChristopherStJohn|cks]] (-0600/-0500)
* [[User:Cloud|Cloud]] (+0000)
* [[User:DanC|DanC]] (-0600/-0500)
** office hours: Wednesday afternoons, America/Chicago time
* [[User:Dave Cardwell|davecardwell]] (+0000)
* [[User:DeanEro|deanero]] (-0800/-0700)
* [[User:DimitriGlazkov|dglazkov]] (-0600/-0500)
* [[User:DrewMcLellan|drewinthehead]] (+0000/+0100)
* [[User:EdwardOConnor|hober]] (-0800/-0700)
* [[User:Enric|enric]] (-0800/-0700)
* [[User:Evan|evanpro]] (-0500)
* [[User:Fil|Fil]] (+0200)
* [[User:Grantbow|Grantbow]] (-0800/-0700)
* [[User:Hlb|hlb]] (+0800-0700)
* [[User:IanHickson|Hixie]] (-0800/-0700)
* [[User:Izo|IZO]]
* [[User:JoeGregorio|jcgregorio]]
* [[User:Jonathan_Arkell|jonnay]] (-0700/0600)
* [[User:JasonK|jkridner]]] (-0600/-0500)
* [[User:Kapowaz|kapowaz]] (+0000/+0100)
* [[User:Keri Henare|kerihenare]] (+1200)
* [http://epeus.blogspot.com/ KevinMarks] (-0800/-0700)
* [[User:Mark Mansour|Mark Mansour]] (+1100)
* [[User:MarkNormanFrancis|Mark Norman Francis]] (+0000/+0100)
* [[User:CiaranMc|McNulty]] (+0000/+0100)
* [[User:neuro|neuro`]]
* [[User:Phae|Phae]] (+0000/+0100)
* [[User:PriitLaes|plaes]] (+0200/+0300)
* [[User:DavidOsolkowski|qid]] (-0500)
* [[User:Remi|Remi]] (-0500/-0400)
* [[User:RobertBachmann|RobertBachmann]] (+0100/+0200)
** Office hours: <del>Wednesday, 18:00-20:00 UTC</del> (Currently no office hours)
* [[User:RyanKing|kingryan]] (-0800/-0700)
** [http://theryanking.com/blog/archives/2006/04/19/office-hours/ Office hours]: Wednesday, 21:00 UTC
* [[User:Csarven|csarven]] (-0500/-0400)
* [[User:Dana Benson|Snowden]] (-0800/-0700)
* [[User:Steve Ganz|SteveGanz]] (-0800/-0700)
* [[User:Tantek|Tantek]] (-0800/-0700)
* [[User:Trovster|trovster]] (-0800/-0700)
* [[User:Dan Kubb|dkubb]] (-0800/-0700)
* [[User:Ed Summers|edsu]] (-0500/-0400)
* [[User:Smackman|Steve Farrell]] (-0800/-0700)
* [[User:Enric|Enric]] (-0800/-0700)
* [[User:Charlvn|Charl]] (+0200/+0200)
* [[User:MarkoMrdjenovic|friedcell]] (+0100/+0200)
* [[User:Vant|vant]] (+0900)
* [[User:KrissWatt|VoodooChild]] (+0000/+0100)
* [[User:IwaiMasaharu|iwaim]] (+0900)
* [[User:Richard Conyard|WhiskeyM]] (+0000)
* [[User:Veeliam|William Lawrence]] (-0800/-0700)
* [[User:Ianloic|yakk]] (-0800/-0700)
* [[User:Ashley|Ashley]] (+1000)

=== Greetings ===

To display a brief description of who you are each time you join the channel, you can create a definition for your username. To do so pass the <tt>?def</tt> command using something like the following convention (be brief):

<code>?def jdoe is John Doe and can be found online at <nowiki>http://www.example.com</nowiki></code>

More information about using JiBot commands can be found on the [http://joiwiki.ito.com/joiwiki/index.cgi?jibot jibot website]

=== bots ===

* [[mfbot]]
* [[mflogbot]]
* [http://joiwiki.ito.com/joiwiki/index.cgi?jibot jibot]

== Logs ==

Available here: http://rbach.priv.at/Microformats-IRC/

Atom feed of logs available here: http://microformat.makedatamakesense.com/log_feed/

== IRC meetups ==

The idea of having IRC meetups (that is, a set time for meeting on IRC) has been suggested by [[User:RyanKing|Ryan King]], as it appears to work well for the WordPress community and may help us from time-to-time. As of yet, there are no plans to have meetups, though.

currency-examples

2006-07-19T10:01:20Z

CiaranMc: /* Ciaran McNulty */

= Currency Examples =
<p>The following are real-world examples and brainstorming for marking up currency.</p>

== The Problem ==
<p>Currency is a reasonably easy problem to solve as indicated by the [[#Existing_Practices]].</p>

<p>"Amounts" in arbitrary units is a bit harder and necessary for several applications.</p>

<p>For example, consider the work that has been done on a recipe microformat.</p>

[[recipe-examples]]

<p>Though we haven't reached this problem yet in the research, I can see it
coming:</p>

<p>Say you wanted to create a "shopping list" application which you could tell which recipes you wanted to cook, and have it automatically total up all the various amounts of ingredients and give you the net amount of stuff you wanted to pick up.</p>

<p>It would need to be able to determine precise amounts/units of each ingredient. This might turn out to be like the currency problem, or it might be more complex, given the variety of units used in recipes, English vs. metric etc. That's a case that might need a microformat. We need more research and analysis to really justify it, but I can see it within the realm of probable possibility.</p>
== Participants ==
* Ben Buchanan
* Charles Iliya Krempeaux
* Ben Ward
* Arve Bersvendsen
* Mike Stickel
* Ciaran McNulty
* [http://tantek.com/log/ Tantek Çelik]
* [http://steve.ganz.name/ Steve Ganz]
== Real-World Examples ==
''Links to public web pages, either popular or insightful''
=== [http://us.mcafee.com/root/package.asp?pkgid=100 McAfee] ===
<pre>
<span class="price">$39.99 <span class="currency">(USD)</span></span>
</pre>

=== [http://www.amazon.com/gp/product/0764597582/sr=8-9/qid=1153301402/ref=sr_1_9/002-9103678-0608852?ie=UTF8 Amazon] ===

<pre><td class="price">$34.85</td></pre>

=== [https://secure.vmp.com/signup/adv_signup.php?locale=fr_CA Bell Canada in French Canadian] ===

<pre><font size="larger"><b>Niveau de service Premium - 125 $*</b></font size></pre>

Note the placement of the dollar sign AFTER the number.

=== [https://secure.vmp.com/signup/adv_signup.php?locale=en_US Bell Canada in US English] ===

<pre><font size="larger"><b>Premium Service Level - $125*</b></font size></pre>

== Existing Practices ==

===Firefox Extension===
[http://viewmycurrency.wordpress.com/about/ Firefox Currency Converter - ViewMyCurrency]

===Greasemonkey Scripts ===
[http://nybblelabs.org.uk/projects/exchequer Exchequer]

[http://6v8.gamboni.org/Greasemonkey-Yahoo-Finance.html Yahoo! Finance Currency Converter]

[http://www.xe.com/iso4217.htm ISO 4217 Codes]

== Brainstorming ==
===Charles Iliya Krempeaux===
<p>Maybe something like...</p>

<pre>Pay me <abbr class="currency" title="CAD">$</abbr>5.00 now!</pre>

<p>Although something like the the following might be better...</p>

<pre>Pay me <span class="money"><abbr class="currency" title="CAD">$</abbr>5.00</span> now!</pre>

<p>But it might be more semantic salt than is considered necessary. Just having the abbr with the class-currency near a number might be good enough. But that's open for discussion though.</p>

=== Ben Ward ===
<p>Could pure HTML be sufficient?</p>
<pre><html lang="en-gb">
<p>My new T-Shirts cost £30, but it cost my friend in Canada <span lang="en-ca">$34</span></p>
</html></pre>

===Arve Bersvendsen ===
<pre><p lang="nb">Den kanadiske prisen på t-skjorten var <span class="currency CAD">34 $</span>.</p></pre>

=== Mike Stickel ===
<pre><span class="money"><abbr class="currency" title="CAD eng">$</abbr><span class="amount">5.00</span></span></pre>
<p>In this format the wrapping would be "money" or something similar followed by either the actual "amount" or the "currency", depending on what rules your country/language follows in regards to the order.
Since there can be a difference between different languages within countries I thought it might be a good idea to include that in the "currency" definition of the formating, eg., "CAD eng" or "CAD fr".
It could also give sites that list multiple languages a way to differentiate when they show multiple prices.</p>

=== Ciaran McNulty ===
<p>The only microformat that I've noticed currency units in is [[hListing]], and that deliberately shies away from parsing the actual values because it's too free-form in most existing Listing formats.</p>

<p>My own preference would be for something like:</p>
<pre><p class="money">This item costs
<span class="currency">GBP</span>
<span class="amount">10.00</span>
</p></pre>

<p>Which with similar parsing rules to existing formats would also allow things like:</p>
<pre><p class="money">
It'll cost you
<abbr class="currency" title="50.00">fifty</abbr>
<abbr class="amount" title="GBP">quid</abbr>
, mate!
</p></pre>
<p>Or, a more complex example with multiple languages:</p>
<pre>
<p lang="en">Price:
<span class="money">
<abbr class="currency" title="GBP">£</abbr>
<span class="amount">1,250.00</span>
</span>
<span lang="fr" class="money">
(Prix:
<span class="amount">1600,00</span>
<abbr class="currency" title="EUR">€</abbr>
)
</span>
</p></pre>

== See Also ==
* [[abbr-design-pattern]]

xfn-brainstorming

2006-07-14T14:33:32Z

CiaranMc:

<h1> XFN Brainstorming </h1>
This page is for brainstorming about various uses and details of [[XFN]].

__TOC__

== Extending family relationships ==
<cite>[http://www.gmpg.org/xfn/background The XFN: Background page]</cite> says:
<blockquote>
We considered adding "grandparent," but in the end dropped the term because it seemed unlikely to be used in the near future. It may appear in future versions of XFN.
</blockquote>

Presumably the assumption is that a grandparent won't have a website, but:

* I think it's important in some situations to capture the age difference in a relationship in a way that @rel="kin" doesn't seem to.
* Even if they don't maintain it themselves (or are deceased) there might be a URL that does a good job of representing a person.

Consider a site about one's family tree. It might have something like:

I can trace my family back to
<a href="http://en.wikipedia.org/wiki/William_I_of_England/">
William the conqueror.
</a>

In these cases it would be useful to have @rel="ancestor", and perhaps a corresponding @rel="descendant".
-CiaranMc

== Author ==
* [http://horsepigcow.com/ Tara Hunt], [http://citizenagency.com Citizen Agency, LLC.]

== Contributors ==
* [[User:ChrisMessina|ChrisMessina]]
* [http://horsepigcow.com/ Tara Hunt], [http://citizenagency.com Citizen Agency, LLC.]