Microformats Wiki - User contributions [en]

to-do

2008-08-02T06:44:28Z

IanHickson: /* Lazyweb */

{{TOC-right}}
<h1>To Do</h1>

This page is for posting [[microformats]] related shared to do items. If you want to use this page for your microformats related to-do items, create a section with your name on it. The reason we are keeping these all on the same page is to make it easier to tell when people are working on similar things, and to make it more obvious when people help out with other people's tasks. In theory this probably won't scale, but let's first see how it does in practice. :) - [http://tantek.com Tantek]

== Lazyweb ==

Just some nice things, feel free to do any of these.

=== for all microformats ===
* We have added a new mailing list called microformats-new. There may be some confusion surrounding this change, so it would be helpful to:
** Draft a message to be added to the confirm message sent when someone subscribes to any list including a welcome message, ground rules, topic for the subscribed list, and the topics for nearby lists.
** Add a faq entry somewhere on why the new list was created.
** Double check the wiki pages to make sure advice on mailing lists is accurate.
* quick and easy "how to" pages for each microformat. [[get-started]] is a good overall start.
* brief summary statements for each microformat that explain why it matters, what does it accomplish for the publisher.
* write up [http://microformats.org/discuss/ mailing-list] questions and answers in the appropriate [[faq]] pages.
* validators. See the hReview section below as there has been a request for an hReview validator in particular. See [http://norman.walsh.name/2006/04/13/validatingMicroformats Norman Walsh's blog post "Validating microformats"] for some valuable analysis and validation pseudo-code (prose description), which are useful steps towards building microformat validators.
* Submit definitions of "microformat", and individual examples, to the [http://foldoc.org Free On-line Dictionary of Computing], acording to [http://foldoc.org/editing.html the Free On-line Dictionary of Computing guidelines]
* it would be nice to replace the -in-the-wild pages with a form that accepted URL entries that would both register the site and look for valid microformatted content and for those pages with problems, would set them aside in a queue to be reviewed by the community. Having such an interface would likely be more efficient for implementors looking to have their work reviewed, and would also add to a ready-database of microformats in the wild -- which would be a great way to feed pingerati.com. [[User:Chris_Messina Chris Messina]] on 2007 Aug 31.
* check with the group and then, assuming this is accepted, remove mention of the profile="" attribute from the wiki, since HTML5 removes the need for profiles to be declared

=== hCard ===
* microformatted versions of conference pages
** Wait for confirmation from O'Reilly webmaster on revision of the [http://conferences.oreillynet.com/etel2006/ ETel] [http://conferences.oreillynet.com/pub/w/44/speakers.html speaker's page] with all the speakers marked up with [[hcard|hCard]] and links to "Add hCards to Address Book" etc., similar to the [http://tantek.com/microformats/2005/web2/speakers.html Web 2.0 speakers page which Tantek did a revision of last fall].
* vcard to hcard converter
** would be nice to have a web upload UI that would take one or more vCards from apple's address book and give them back to you as hCards
** [[User:RobertBachmann | RobertBachmann]] suggests starting points:
*** For Ruby: http://vpim.rubyforge.org/
*** For C: http://freshmeat.net/projects/libvc/
*** For Python: http://www.nongnu.org/python-pdi/
*** For PHP: http://pear.php.net/package/Contact_Vcard_Parse/
** I (Andy Pemberton) started working on this at one point, but haven't touched it in a while: [http://www.andypemberton.com/sandbox/hcardconvert/ vCard-2-hCard]
* add export support for microformats to [http://www.turingart.com/abForWeb_lan__en.htm AB to Web]
* A mash-up with google maps that will take any url with a hcard (or hcard's) and map the location(s) on a map (similar to [http://austin.adactio.com/ austin.adactio.com])
* more test cases - add to [[hcard-examples]] to begin with, then hopefully create test cases for development to be checked in with mercurial to the repository
** include class="type" without explicit value test cases, based on [[hcard#type_with_unspecified_value|hCard type with unspecified value]].

=== hCalendar ===
==== Add support to open source calendar projects ====
These are open source projects that could be potentially enhanced to support hCalendar.

* [http://www.k5n.us/webcalendar.php?topic=About WebCalendar]
* [http://phpicalendar.net/documentation/index.php?title=Main_Page PHP iCalendar]
* [http://www.vcalendar.org VCalendar]
* Investigation: [http://wiki.mozilla.org/Calendar_Talk:Lightning#hCalendar_publish_and_subscribe_support Mozilla Calendar / Lightning / Sunbird hCalendar support discussion]

=== hReview ===
* [[hreview|hReview]] support in Ecto (hey Adriaan!), requested by Andy Smith
* an [[hreview|hReview]] validator.
* a semantic, clean css star rating picker (e.g. a UI widget to rate from 1-5 stars)
** both [http://komodomedia.com/blog/index.php/2005/08/24/creating-a-star-rater-using-css/ this] and [http://factorycity.net/demos/drupal/rating/default.html this] have some flaws. Ask [[User:RyanKing|Ryan King]] for an explanation.

=== hCalendar/hCard/hReview editor ===
* onblur in the URL field (e.g. on hCalendar), goes out and tries to retrieve an object of same time (e.g. an hCalendar vevent) from that URL and uses it to autofill the form, same thing if the creator is loaded with that URL prefilled (e.g. due to a ?url=http://example.com/ in the URL that loads the creator).

=== hAtom ===
* [[hatom-issues]] needs sections for closed issues, resolved issues, and open issues sorted by year, similar to [[hcard-issues]].

=== WordPress patches for microformats ===
* submit patches for WordPress code/templates for microformats improvement
** <address class="vcard"> improvement in post author publication (e.g. home page of http://microformats.org/ )
* Wordpress plugin for microformats, specifically hReview and hCalendar
** See [http://www.surfarama.com/index.php?p=227 lazyweb request]

=== Yahoo Open Source Library Patches ===
Several of these could very much be improved with a little microformats markup. Do we just make patches and submit them? Contact Nate Koechley at Yahoo (see Tantek for contact info) to follow-up.

* [http://developer.yahoo.net/yui/ Yahoo! User Interface Library]
* [http://developer.yahoo.net/ypatterns/ Yahoo! Design Patterns Library]
* [http://www.yuiblog.com Yahoo! User Interface Blog]

=== Drupal patches for microformats ===
* [http://groups.drupal.org/microformats-in-drupal Microformat Module for Drupal] A group discussing ways to implement microformats in Drupal. Currently looking to support hAtom, hCard and hCalendar to start with. Contact digitalspaghetti at gmail dot com if you are interested in contributing to the project.

=== Adding Microformats to Existing Pages ===
* See [[advocacy#Adding_Microformats_to_Existing_Sites|advocacy: Adding microformats to existing sites]].

===rel-tagging on Wikipedia===
Somebody familiar with the "rel-tag" microformat might want to add details, and a link to the relevant page on this Wiki, to the [http://en.wikipedia.org/wiki/Tag_%28metadata%29 Wikipedia page on tagging]. [[User:AndyMabbett|Andy Mabbett]] 14:07, 3 Jan 2007 (PST)

===Glossary===
Add to the [[glossary]].

===hAtom tutorial===
Finish the [[hatom-tutorial]].

=== wiki gardening ===
* Find [[:Special:Lonelypages|orphaned]] pages, and add links to them.
* Use [[templates]] for boilerplate text and repeated lists of links
* Add keywords to the foot of pages (see [[vcard-suggestions]] for examples), so that they can be converted to tags, once this wiki allows the use of "rel" attributes. Keywords can also include synonyms to aid searching.

====Spelling====
For English-language pages only: Find British spellings of words and replace them with the US spellings per [[en-US]]. Mark such edits as "minor" with the comment: <nowiki>[[en-US]]</nowiki>

Here is a table of searches for some of the British-English spellings that have crept into English-language microformats wiki pages, along with their respective US-English spellings. If you find other British spellings, please feel free to add them to this table, with their US equivalent.

{| border="1"
|+
! [[en-GB]] !! [[en-US]]
|-
| [http://microformats.org/wiki/Special:Search?search=behaviour&go=Go behaviour] || behavior
|-
| [http://microformats.org/wiki/Special:Search?search=behaviours&go=Go behaviours] || behaviors
|-
| [http://microformats.org/wiki/Special:Search?search=centre&go=Go centre] || center
|-
| [http://microformats.org/wiki/Special:Search?search=colour&go=Go colour] || color
|-
| [http://microformats.org/wiki/Special:Search?search=colours&go=Go colours] || colors
|-
| [http://microformats.org/wiki/Special:Search?search=flavour&go=Go flavour] || flavor
|-
| [http://microformats.org/wiki/Special:Search?search=flavours&go=Go flavours] || flavors
|-
| [http://microformats.org/wiki/Special:Search?search=flavoured&go=Go flavoured] || flavored
|-
|}

[http://en.wikipedia.org/wiki/American_and_British_English_spelling_differences More American and British English spelling differences]

== Admins ==
This section is for any admins to keep track of current to-do items for admins and/or for folks to suggest to-do items for admins, in particular, having to do with suggestions for improvements to microformats.org infrastructure such as the wiki. If you do add an item to this list, please sign your username with four tildes: <nowiki>~~~~</nowiki>.

=== Website Improvements ===
* OpenID login, on behalf of a request a while ago from [[User:Chris_Messina]] (especially for comments in WordPress). [[User:Chris_Messina]] 16:50, 31 Aug 2007 (PDT)
** The plug-in is installed, but the user experience of exposing it to commenting visitors is poor. There's no other registration function, so it's not being pushed for the time being.
* Pibb integration for the #microformats IRC channel. It is relatively simple to [http://janrain.com/blog/2007/08/08/how-to-embed-pibb/ embed the Pibb chat widget] into a webpage that bridges to the #microformats IRC channel. This would allow for greater access and transparency to the IRC discussions as well as allow people to participate using only their web browser. [[User:Chris_Messina]] 16:50, 31 Aug 2007 (PDT)

=== Wiki improvements ===

* Set up a cron job to export the wiki database (without user details), and make it available in a public location.
* Upgrade MediaWiki to latest release (Done in Wiki 2.0)
** Remove wiki hacks. Avoid hacking the wiki core in future. (Done in Wiki 2.0)
** Switch to SVN-based deploy (Done in Wiki 2.0)
* Add Extensions
** Evaluate against Wikipedia's [http://en.wikipedia.org/wiki/Special:Version Version Page] for a list of currently installed extensions on the English Wikipedia.
** I'd personally advise getting [http://www.mediawiki.org/wiki/Extension:Cite Cite], [http://meta.wikimedia.org/wiki/ParserFunctions ParserFunctions] and [http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi SyntaxHighlight]. --[[User:JimboJW|JimboJW]] 13:38, 25 Sep 2007 (PDT) (Syntax Highlighting is done in Wiki 2.0)
** OpenID login, on behalf of a request a while ago from [[User:DanC]]. [[User:Tantek|Tantek]] 20:50, 20 Jul 2007 (PDT) (Planned for Wiki 2.0)
** Install creation template extension(s)(see: http://meta.wikimedia.org/wiki/Inputbox or http://www.mediawiki.org/wiki/Extension:CreateBox or http://www.mediawiki.org/wiki/Extension:CreateArticle) [[User:RobManson]] 14:00, 20 Jul 2007 (AEST)
** Some kind of [http://en.wikipedia.org/wiki/Spam_in_blogs anti-spam] (captcha? recaptcha? reverse turing tests? [http://unknowngenius.com/blog/wordpress/spam-karma/ Spam Karma?]) ~ [[User:WilleRaab|WilleRaab]] 09:43, 12 Aug 2007 (PDT)
* Encourage new users to use the preview feature to prevent a deluge of edit notifications from interrupting IRC discussions. [[User:SignpostMarv|SignpostMarv]] 09:28, 12 Aug 2007 (PDT) (Done in Wiki 2.0)
* Add the necessary styling per [http://www.w3.org/2001/06/manual/#RFC W3C Manual of Style guidelines for RFC 2119] (perhaps in a <code>w3cstyleguide.css</code> file) to our MediaWiki install's CSS, in order to enable removal of in-line styles from our [[rfc-2119#Templates|RFC 2119 Templates]]: (Done in Wiki 2.0)
:<pre><nowiki>
.RFC2119 {
text-transform: lowercase;
font-style: italic;
}
</nowiki></pre>
* Add an address element, with a <code>class=author</code> hCard, to the footer of every page, to facilitate the use of hAtom and to "include" in other microformats (Done in Wiki 2.0)
* add a class, <code>noprint</code> to the site's CSS, so that sections (such as "related pages" footers) can be made non- printing.
** ‘noprint’ isn't so semantic, but we should get a proper print stylesheet, for sure.

==== Wiki 2.0 ====

* Microformats.org Wiki Theme --[[User:BenWard|BenWard]] 18:10, 2 Jul 2008 (PDT)
** Adopt µf.org style, header, logo (Dev Status: Mostly done. Some wiki-specific styles to build)
** Better integrate wiki with main site (Dev Status: Done.)
** Adjust design to focus on wiki content (variable width) (Dev Status: Done.)
** Re-org sidebars (Dev Status: Mostly Done)
*** Add admins sidebar (quick ban list access)
*** Add ‘User’ sidebar (Prefs, Profile, Watchlist, Wiki Todo List, My Edits, etc.) (Dev Status: Done)
** Make the edit comment UI better — textarea, not single line box. (Dev Status: Might be impossible without hacking the core)
** Prioritise preview over submit when editing. (Dev Status: Done)
** Add style switches for different documents. (Dev Status: Done)
*** ‘specification’ switch, to better display the documentation for specs (Dev Status: Done.)
**** Full width (sidebars pushed down to footer), left hand note, ala W3C/WHATWG documents (Dev Status: Done)
*** Also a ‘draft’ switch that makes it clear when a spec is in work in progress (Dev Status: Done.)
** Add styles for lists with class=discussion (Dev Status: Done)
*** Better list item spacing for legibility
*** Marker graphics to highlight threading
*** Better highlighting of comment author
** New link styles for links to mailing list archive
** Remove links to Talk pages (Dev Status: Done, also, completely disabled access to talk pages)
** Add ‘Raise Issue’ link to «current-page-name»-issues (Dev Status: Button added. Need to generate link)
** Attempt to fix the =Heading 1= TOC bug (H1s should be ignored in TOC)
** Do this at same time as MediaWiki upgrade
** Change ‘last-modified’ dates into hCalendar events (Dev Status: Done)
** Mark up articles with hAtom (Dev Status: Done)
** Make content controls contextual (don't show ‘Article’ on article page, don't show ‘Edit’ on edit page) (Dev Status: Done)
** Add extension to handle HTML4 phrase elements (rather than hacking the source) (Dev Status: Done)

* Templates
** Draft - explain the meaning of draft, make clear that pages can change
** Brainstorm - Template to specify that a page is brainstorming only and none of the mark-up within should be taken as being a recommendation

===Deletions===
*Remove [http://microformats.org/wiki?title=Special:Whatlinkshere&target=delete pages awaiting deletion]

== Tantek ==
I'm keeping a few microformats related to-do items here both for my own convenience, and for folks looking to help out with small tasks. If so, just create a new section with your name, and and maybe copy the item there, and put your name next to the item in my list. We'll figure this out as we go along. Thanks, [http://tantek.com Tantek].

=== overall priority ordering ===
# Protect the community from threats (wiki damage, mailing list pain or noise), repair damage, add measures to reduce future damage
# Help publishers with established microformats: [[hcard|hCard]], [[xfn]], [[rel-tag]], [[hcalendar|hCalendar]], [[hreview|hReview]], [[xfolk|xFolk]]
# Help implementers with established microformats
# Iterate on existing established microformats, resolve issues/feedback etc.
# Wiki cleanup/gardening for existing established microformats
# Site usability of microformats.org top-down as an entry point
# Community dynamics, [[process]] and [[principles]] improvements to help guide new microformats developments
# Emerging in-demand microformats: [[hresume|hResume]], [[hlisting|hListing]], [[citation]], [[media-info]] using abovementioned process and principles improvements.
# New microformat requests
# Document microformats [[history]].
# Other

=== protect the community ===
* Analyze [[Special:Recentchanges]] and [http://microformats.org/discuss mailing-lists] and:
** add to [[mailing-lists]] policies/guidelines accordingly.
** redirect and resolve threads accordingly per guidelines
** privately email violaters kindly asking them to improve their behavior
** work with admins on next steps for individuals negatively impacting the community
** recognize noisy/distracting threads on the email list, document responses/answers to such subjects on the appropriate page(s) on the wiki, and reply to those threads with the URLs to the documentation on the wiki. Putting the responses/answers on the wiki helps by hopefully providing preemptive answers to some who might reraise the subjects on the list in the future, and helps the community quickly terminate such threads by using the answers on the wiki.
** remove noise from [[Main_Page|the wiki home page]] by simplifying/shortening it
*** <s>move exploratory discussions to a separate page (think about what to name it)</s>
*** move exploratory discussions which are failing to follow the process to a separate page from that

=== help publishers ===
==== social network portability ====
Iterate on:
* [[social-network-portability]]
* [[hcard-supporting-user-profiles]]
* [[hcard-xfn-supporting-friends-lists]]

Brainstorm updates to the [[pocket-cheat-sheet]] to better enable [[social-network-portability]], or perhaps design a new '''social network portability pocket cheat sheet''' that specifically documents:
* how to author/publish hCard user profiles - write this up in [[hcard-authoring]] first (see below) and then use that content.
* how to author/publish hCard+XFN friends lists - write this up in [[hcard-xfn-authoring]] (see below) and then use that content.
* how to parse/subscribe to hCard user profiles - write this up by updating: [[hcard-parsing]], and writing [[hcard-supporting-user-profile-parsing]] (collect this into parsing/developers tasks below)
* how to parse/subscribe to hCard+XFN friends lists - write this up by writing: [[xfn-parsing]], [[hcard-xfn-supporting-friends-list-parsing]] (collect these into parsing/developers tasks below)
** notes/thoughts on hCard+XFN supporting friends list parsing captured here for now:
*** do a full rel="me" bidirectional crawling within the domain - some sites' hCard supporting user profiles simply link to their hCard+XFN supporting friends lists with rel="me", and thus you will discover more pages with friends lists.
**** E.g. Flickr's /people/username pages have hCard for the user and link to their /people/username/contacts page with rel="me" (on the "More..." link, though they could also add rel="me" to the number inside "Your contacts (592)"). Need to get them to support hCard+XFN on the contacts themselves.
*** consider parsing within a friends list page, any links that are rel="next" and rel="prev" to iterate over the whole list.

==== foldup cheatsheet ====
'''next actions''':
* gather feedback on current foldup [[pocket-cheat-sheet|pocket cheatsheet]]
* document the [[pocket-cheat-sheet-feedback|feedback on the pocket cheatsheet]]
* give feedback to Erin, iterate, print more to have on hand, fold, distribute.
* provide printing recommendations for anyone to download and print their own
** Perhaps [http://www.visibone.com/ Visibone] can be of some use? I can recommend their current products. --[[User:Gazza|Gazza]] 06:41, 7 Apr 2007 (PDT)
* discuss with [[User:Adactio]] and Hannah how to best create a UK/A4 version of the pocket cheatsheet
** preferably well in advance of dConstruct 2008 so that local cheatsheets can be printed.

==== *-authoring microformats wiki pages ====
* [[hcard-authoring]] - '''next-actions''': add tips/instructions noted below.
** instructions for each property that is in [http://microformats.org/code/hcard/creator hCard creator] to begin with
** instructions for all other hCard properties
** a tutorial on creating an hCard for your site
*** specific instructions for common blogging platforms
** reference [[hcard-examples]] for more specific uses, and add to them accordingly
*** add an extended example to [[hcard-examples#Authors_of_Pages_and_Posts|contact info for a page]] with postal address, phone numbers, email address.
* [[hcard-xfn-authoring]] - '''next-action''': draft by starting from hCard+XFN instructions in [[hcard-examples]].
* [[hreview-authoring]] - '''next-action''': create a first draft minimal tutorial on how to author hReviews (e.g. at least for common properties) to blog reviews so that they'll be aggregated.
* [[hcalendar-authoring]] - '''next-action''': add tips/instructions for each property that is in [http://microformats.org/code/hcalendar/creator hCalendar creator].
* *-authoring for other reasonably well established microformats:
** [[xfolk-authoring]], [[hatom-authoring]]

==== help with microformat examples in the wild ====
Using the above updated [[authoring]] pages, get the community to help go over all "common" pages (both logged out and logged in states) of the following sites which have some microformats already, and verify each page is as microformatted as it can be with high fidelity [[hcalendar|hCalendar]] and [[hcard|hCard]] etc. Document full support of each implementation's microformats on the implementations page (perhaps create a separate page for each implementation, e.g. [[flickr]], [[upcoming]], [[eventful]] etc.) Document any exceptions as needed. In no particular order:
* Flickr.com (3.5m hCards)
* Upcoming.org (100k hCalendar events, 100k hCard venues)
** home page
* Eventful.com (100k hCalendar events, 100k hCard venues)
* Yahoo! Tech (300k products with hReviews)
* JudysBook.com (???k hReviews)
* ... lots more, get from "Implementations" and "Examples in the Wild" sections of specs.

==== advocacy for obvious sites ====
* [[advocacy]] - add pages/sites that obviously (no pun intended) could use microformats, update them with sample markup, find contacts for those pages to get them updated, and send requests to update their sites with microformats including sample markup. '''next-actions''': markup both twitter.com sample pages and dodgeball.com sample pages, post the changes publicly, and see which one is able to update first ;)
** dodgeball.com (hCard + XFN + hAtom for profiles, hCard + hReview for venues)
** write essay on [[open-data-more-important-than-open-source]] - and a shorthand URL too.
*** obviously doing both is ideal, however, open data is a higher priority and given limited resources, open data should be implemented before open source.
*** open data > open source
*** "open information" vs "open source"
*** i.e. please focus first on open data rather than open source, e.g. start with [[hcard|hCards]] for all organizations returned from http://wiserearth.org/organization
*** if the data is open you can always export it and consume it in any number of open source systems
*** that's why open data is MUCH more important than open source
*** adding open data (e.g. microformats) can be done by any HTML author (yes, you), whereas open sourcing requires programming expertise, resouces, support. do the simpler easier thing first (open data thru microformats) that will benefit more people sooner.
*** if the data was open, anyone could rebuild an accessible version
*** faqs / misconceptions:
**** eschipul: @tantek - creating microformats is easier. consuming microformats is unfortunately not easier.
***** A: If you think consuming microformats is not easier or hard etc., it may just be that you don't know how to do so easily, don't assume that you are an expert in something that you think is hard. Rather, if you think something is hard, then assume others may know easier methods, and ''ask'' the community how one can do it more easily. parsing in particular is something which is becoming easier and easier thanks to open source libraries like [[hkit|hKit]].
** write essay on [[open-data-more-important-than-open-apis]] - and a shorthand URL too
*** obviously doing both is ideal, however, open data is a higher priority and given limited resources, open data should be implemented before open APIs.
*** publishing/providing open data (e.g. microformats) can be done by any HTML author (yes, you), whereas providing/publishing open APIs requires programming expertise, resouces, and support. do the simpler easier thing first (open data thru microformats) that will benefit more people sooner.

=== help implementers ===
* wordpress improvements
** WP admin for new profiles
*** should simply read blog URL - '''next-action''': make sure a bug/feature request is filed with wordpress.org
*** look for hcards and parse them

* [http://gmpg.org/xfn/creator XFN Creator] localizations
** Get someone to verify the [http://gmpg.org/xfn/creator-ru XFN Creator Russian localization].
** Add it to the [http://gmpg.org/xfn/tools XFN Tools] page.
** Add rel="alternate" href="creator-ru" <link>s to the other XFN Creators.

* Conference Schedule Creator
** '''next-actions''': Review Dmitry Baranovskiy's [http://dmitry.baranovskiy.com/work/csc/ Conference Schedule Creator] and give him feedback per how well it:
*** Makes it *trivial* for conference organizers to build/edit/publish an [[hcalendar|hCalendar]] schedule for their conference, including auto-generated "Subscribe..." link which produces the proper "webcal:..." link with X2V. Note: see the "axis" and "header" attributes in HTML4, specifically in the section on Tables.

=== iterate on current microformats ===
==== in general ====
===== plain language intros =====
For [[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [[xoxo|XOXO]] to start with, write up:
* brief plain-language intro at the top (say for example, something that a non-technical person like a member of the general media/press could read and understand), similar to or better than plain language intros on W3C specs.
* followed by links to more plain-language resources, e.g. *-intro pages.
In particular for [[xoxo|XOXO]], Angus McIntyre suggested:
* As well as a syntactic example, examples of use would be useful.
* when I might want to use XOXO.
* Some simple examples right upfront would probably do a lot to help users figure out whether a particular microformat is for them or not.
These suggestions could be incorporated into the other specs as well.
===== exploratory discussions =====
* update [[exploratory-discussions]] with critical microformats as "active"
===== CSS enhancements for =====
Analyze existing microformats for opportunities to enhance CSS and propose to W3C.
* e.g. CSS datetime presentation (need to add links to my earlier work in CSS working group)
* brainstorm additional possibilities for better presentation of content using existing microformats.
===== update affiliations =====
* Start a minimal draft/spec style guide using outline of most readable/accessible spec so far
* Reference http://www.w3.org/2001/06/manual/#Editors for how to manage affiliations
* Update affiliations on [[hcard]], [[hcalendar]], [[hreview]], etc. per http://www.w3.org/2001/06/manual/#Editors
===== profile URLs =====
* write-up and document [[profile-uris|profile URLs]] for all established microformats and perhaps for some drafts as well

==== [[hcard|hCard]] ====
Combined next-actions for iteration on [[hcard|hCard]], and derived/subsetted microformats [[adr]] and [[geo]]
* [[hcard|hCard spec]] '''next-actions''':
** continue updated the spec per the inline comment about property references
** add a brief descriptive sentence for each property, similar to what [[hreview|hReview]] has. just enough so that the casual reader can avoid having to reference and read the respective sections in [[RFC2426]].
* [[hcard-profile]] '''next-actions''':
** update property definitions with more detail using semantics from [[RFC2426]]
** link from brief sentence descriptions for each property in [[hCard]] to the respective more detailed definition in the [[hcard-profile]].
** link from definitions in the [[hcard-profile]] to the specific sections in the vCard spec
* [[hcard-examples]] '''next-actions''': update with examples described below
** add examples of [[hcard|hCard]]s with work telephone, mailing address etc.
** add examples of marking up an organization vs. a person, then link to it from [http://microformats.org/wiki/hcard#Organization_Contact_Info hCard spec section on Organization Contact Info].
** add example of organization-name and organization-unit usage.
* [[hcard-issues]] and [[hcard-feedback]]. '''next-actions''': resolve all issues and incorporate all feedback.
* [[hcard-brainstorming]] '''next-actions''': determine which brainstorms proposals to resolve in April, and which later
** need property for gender (see [[hcard-faq#How_is_gender_represented|proposal in hCard FAQ]] and discussion in [[hcard-issues]]) - use tags for now, add to hCard creator
** solve [[hcard-brainstorming#Auto-Discovery|autodiscovery]] of more canonical/thorough hCard
* [[hcard-examples-in-wild]]
** help dglazkov markup: http://glazkov.com/blog/archive/2003/12/17/147.aspx
* analyze [[hcard-cheatsheet]], [[adr-cheatsheet]], [[geo-cheatsheet]] for any assertions above and beyond what the specification itself says, take into account [[hcard-brainstorming]] along similar lines, and incorporate into the spec or remove as necessary and sync-up as a result. add clarification on the cheatsheets that they are '''informative''' and reference the specification for normative requirements.

==== [[hcalendar|hCalendar]] ====
'''Next-actions''':
* itemize a complete property list similar to the [[hcard#Property_List|hCard property list]], drawing upon hCalendar experience, iCal-BASIC draft(s), ietf-calsify mailing list and other sources to derive the precise list. Separate common properties up front.
* formally document [http://microformats.org/wiki/hcalendar- brainstorming#Tabular_event_calendars]
* [[hcalendar-examples]]
** make sure all hCalendar examples that reference whole days use best international/accessible date format of YYYY-MM-DD
** add examples like [[hcard-examples]]
** flesh out and do a once over on markup/presentation of what RFC2445 examples would look like
** add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.
* need spec details and then [[hcalendar-examples]] of multi-instance [[hcalendar|hCalendar]] events
* need spec details and then [[hcalendar-examples]] of repeating events
* need to resolve all outstanding [[hcalendar-issues]] to-do items.
* create [[hcalendar-profile]] and have folks verify it. Note that it will likely need reconciliation with the [[hcard-profile]], especially since [[hcalendar|hCalendar]] normatively depends on [[hcard|hCard]]. Probably makes sense to have a combined profile which hCalendar would use.
* analyze [[hcalendar-cheatsheet]] for any assertions above and beyond what the specification itself says, take into account [[hcalendar-brainstorming]] along similar lines, and incorporate into the spec or remove as necessary and sync-up as a result. add clarification on the cheatsheets that they are '''informative''' and reference the specification for normative requirements.

==== [[hreview|hReview]] ====
'''Next-actions''':
* Write hReview 0.3 XMDP profile, and reconcile with [[hcalendar-profile]] and [[hcard-profile]]. Makes sense to have a combined profile of all three for hReview, since hReview normatively depends on hCard and hCalendar.
* Resolve all outstanding [[hreview-issues]] and [[hreview-feedback]] to-do items.

==== [[rel-tag]] ====
'''Next-actions''':
* Write [[rel-tag]] XMDP profile ([[rel-tag-profile]]) and send to [http://dbaron.org/ David Baron].
* Resolve all outstanding [[rel-tag-issues]] and [[rel-tag-feedback]] to-do items.

==== [[rel-me]] ====
'''Next-actions''':
* update rel-me examples on gmpg specifically document with examples the rel-me implict subdir rule

==== [[hatom|hAtom]] ====
'''Next-actions''':
* Clarify that "published" property values may omit seconds, and that converters to Atom are expected to imply ":00" seconds.

==== summary Examples in the Wild page ====
* need to create a summary / overall [[examples-in-the-wild]] page
** parallel the summary/overall [[implementations]] page.
** use newly reoganized content from the above "reoganizing Examples in the Wild" task

==== parsing ====
'''Next-actions''':
* Update [[semantic-xhtml]] with lists of semantic [http://www.w3.org/TR/html401/index/elements.html elements] and [http://www.w3.org/TR/html401/index/attributes.html attributes].
* Update [[hcard-brainstorming]] on element specific parsing rules
* Update X2V, hKit accordingly
* Write test cases accordingly
* Update [[hcard-parsing]] accordingly
* Draft [[hcalendar-parsing]] accordingly
* Write [[compound-parsing]] by abstracting commonalities between [[hcard-parsing]] and [[hcalendar-parsing]].
* Draft *-parsing for all reasonably well adopted microformats: [[hcalendar-parsing]], [[hreview-parsing]], [[xfolk-parsing]], [[hatom-parsing]]

=== wiki cleanup ===
==== for all microformat specs ====
'''Next-actions''':
* modularize any specs which are > 30K in order to avoid loss/corruption like [http://microformats.org/wiki?title=Special:Contributions&target=Evan Evan's 14 June edits] to [[hcard|hCard]], [[rel-tag]], and [[xoxo|XOXO]].
** [[hcard|hCard]] -
*** [[hcard-examples-in-the-wild]] group/sort by individuals, organizations, and hosting sites. Consider moving largest subsection to its own page as well.
** [[rel-tag]]
** [[xoxo]]

==== update specification section organization ====
'''Next-action''': work with Ryan, Ernie, Erin, and others who have made concrete helpful suggestions for reorganizing the information architecture / content-order / layout of specs for greater approachability/readability by a broader audience, to design an interative update to spec organizations, in particular, the introduction/boilerplate/headers. See below notes on hResume experiment in progress.

[[hresume|hResume]] has an experimental abbreviated intro/headers section, and links to more details further below, based on some ideas that Ryan King and I had for improving the readability of the microformats specifications. [[hreview|hReview]] has some similar improvements, but different. We need to:
# Figure out if the new intro/headers structure in [[hresume|hResume]] and/or [[hreview|hReview]] is an improvement, and if it could be better. Perhaps figure out the requirements for an intro/header section
#* Shorter tends to be better
#* Must be comprehensive enough to "print and read"
#* Must detail authorship/editorship
#* Must detail copyright/patent statements
# Write up a template - make it self-documenting per the requirements
# Update existing specifications with the new intro/headers structure.
## [[hcard|hCard]]
## [[hcalendar|hCalendar]]
## [[hreview|hReview]]

==== reorganizing Implementations sections ====
* sort implementations by authoring/creating/publishing, browsing/viewing, converting/importing, indexing/searching.

Hmmm... I like: '''A'''uthoring, '''B'''rowsing, '''C'''onverting, '''I'''ndexing, '''L'''ibraries (for developers), and '''P'''otential (for open source projects we want to add support to). Anybody have alternative suggestions for this vocabulary? I don't have a particularly strong preference so I'm going to go with these four until I find examples that don't fit, or someone suggests something better.

See: [http://microformats.org/wiki/hcalendar#Implementations hCalendar Implementations] for a first attempt at this. Assuming folks like that, we can go ahead with categorizing the implementations sections of other microformats specifications.

'''Next-actions''':
* [[hcard-implementations]] - re-organize by same subsections as [[hcalendar-implementations]].
* [[hreview-implementations]] - re-organize by same subsections as [[hcalendar-implementations]].
* [[hatom-implementations]] - re-organize by same subsections as [[hcalendar-implementations]].
* [[xfolk-implementations]] - re-organize by same subsections as [[hcalendar-implementations]].

==== reorg Examples in the Wild sections ====
Work with community to:
* include more *key* details per example, e.g. precise or estimates of counts for services
* collate/sort examples in the wild by
** hosting services - where users/people actively contribute to the growth (e.g. Flickr profile hCards)
** publishing services - where lots of data is published from some datasource/database (e.g. Yahoo! Local)
** companies/groups/organizations member pages (and their own) - pages for a group's site where they list members or employees (e.g. Technorati staff page)
** individiual companies/organizations contact info pages
** individual people's contact info pages
* of course at some point this won't scale, but that will be a very good problem to have, and by then I'm sure we'll have services to point to that provide queries and search results for all this data.

=== site usability ===
* figure out how to get wordpress to autopost blog posts to the microformats-announce list
** ideally use the from address of the author of the blog post
** maybe photomatt knows how to do this.

=== introduction / community ===

* microformats-discuss *
** introductory email template for new subscribers needs to direct people to [[process]] and [[how-to-play]]
* Need to add more to the [[naming-principles]], to cover in particular:
** avoid using the same name to mean two things
** avoid using two names to mean the same thing
** seek to keep the microformats vocabulary minimal, memorable, and usable.
* update and add details/simplifications to [[process]] given the past several months of experience. in particular:
** clarify requirement (MUST rather than SHOULD) of *-examples, *-formats, before any *-brainstorming.
** Add details of encouragement to experiment with simple semantic class names from *-brainstorming proposals to gain real world experience with real world content.
** note SHOULD prerequisite of use of all relevant microformats on real world web pages, along with documenting such use in respective "Examples in the Wild" sections, before proposing any new microformats.

==== posh improvement ====
* Create a page to answer the question "[[how-should-i-markup]]"
* consider creating a process/encouragement for collecting individual [[posh]] practices and examples, like a folksonomy of semantic HTML and semantic class names.

==== principles and process ====
Create the following pages and document/fill them with content from other pages, email lists, and [[presentations]].
* [[principles]] - mostly [[microformats#the_microformats_principles|documented in the microformats]] page.
* clearer statement of both copyright and patents both in specific specs and in general
* resolve [[process-issues]]

==== profiles ====
* update [[XMDP]] with new required features:
** ability for one profile to include/import another (rel="import" ?)
** ability to reference an XMDP via rel="profile" (similar to XHTML2 rel value by same name)
*** add rel="profile" to the [[xmdp-profile]].
** ability/suggestion to reference an XMDP using <a href> in addition to <link>

==== community mark ====
* Can we make "microformat" and "microformats" into [http://factoryjoe.com/blog/2006/01/14/the-case-for-community-marks/ Community Marks]?

==== document issue resolutions ====
* Prefixing has already been considered and rejected for microformats in general. Note [[naming-conventions]], limited vocabulary, and exceptions made for [[hatom|hAtom]] and how we went about doing so.

=== emerging microformats ===
* [[directions]]
* [[citation]]
* [[hlisting|hListing]]
* [[media-info]]
* [[licensing]]
'''Next-actions''' for each emerging microformat (one at a time)
* review all microformats-email on the new microformat
* determine where new microformats is "stuck" in the process
* brainstorm about how to improve process (or documentation thereof) to get the effort unstuck
* work with community to move the microformat forward through the process, iterating/clarifying the [[process]] as necessary

=== new microformat requests ===
* expense reports (really just a list of "expense" items), [http://flickr.com/photos/edyson/56774178/ requested by ED], should look at UBL as a pre-existing format
* photo-notes microformat
** clean up Subethaedit notes from working session with Greg Elin, Ryan King, Kevin Marks, Suw Charman and email to folks and figure out next steps
** iterate on [[photo-note-examples]] and start [[photo-note-formats]] and [[photo-note-brainstorming]].

=== document microformats history ===
Document microformats [[history]], including:
* dates and origins of microformats, names, terms
* examples and formats for established microformats like [[hcard|hCard]], [[hcalendar|hCalendar]], [[xfn]], [[rel-license]], [[xoxo]]

=== other ===
* Add XPath equivalents where appropriate in [[hcard-parsing]]

==Ryan==
=== wiki cleanup ===
* <s>possibly move dead proposals off of homepage?</s>

=== hCalendar/hCard/hReview creator improvements ===
* get all creators working in IE/Win, IE/Mac, Safari/OSX.3

=== other ===
* add an example of how to use DURATION in hcalendar see http://www.policyawareweb.org/2005/ftf2/paw-mtg#item15) -> verify http://svn.lifelint.com/hcalendar_tests/calendar-todo-multiple-attendees-and-alarm.xml

=== rel-payment ===
* update rel-payment to reference the IANA registry [http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02055.html]

=== hcalendar ===
* make sure we explicitly disallow 'vjournal'

== Dimitri Glazkov ==

* Figure out REST/Microformats thing
* Work on result set idea
* Implement h-creators using Web Forms 2.0

== Chris Messina ==

=== General ===

* Work on a microformat for play-lists (is it just a XOXO ordererd list of play-items?)
* Work on a microformat for play-item (take a look at [[media-info-examples]])
* Work on microformats tutorial for designers
* Add support for OpenID to micformats wiki
* <strike>Add support for [http://verselogic.net/projects/wordpress/wordpress-openid-plugin/ OpenID] to the microformats blog</strike>.
* <strike>Read GTD (at least the first two chapters)</strike>.

=== Campaigns ===

* <strike>Get Blogger to support hAtom and hCard</strike>
* <strike>Get LinkedIn to support hCard, hResume, hCalendar</strike> and XFN
* Get XING to support <strike>hCard</strike>, hCalendar, hResume and XFN
* Get <strike>Digg to support microformats</strike> (still need XFN).

=== Wishlist ===

* Microformat for "buyable items" (see [[listing-examples]] and related documents)
* Location MF -- right click "map this" (see [[geo]] and [[adr]])
* Better hCard support in the browser -- right click "IM this person...", "Add to contacts" (see [http://factoryjoe.com/blog/2006/03/20/flocktails-for-flock/ Flocktails])
* Better hCal support -- support many views of same hCal data on one page using XSLT
* We need something that a designer/web programmer can come to and leave w/ 2 examples of each microformat that they can apply right away... a "microformats styleguide for designers", if you will.
* invoicing microformat
* better microformats wiki theme
* Define flow for OpenID + XFN + hcard (see [http://diso-project.org DiSo Project])

== Robert Bachmann ==
[[User:RobertBachmann|Robert Bachmann]]

=== XSLTs ===
<ul>
<li><strong>Test scripts</strong>
<ul>
<li>Do some refactoring, split Perl code into smaller modules</li>
<li>Provide test results as HTML pages (similar to http://www.w3.org/2003/08/owl-systems/test-results-out)</li>
<li>Provide some documentation for using the test scripts</li>
</ul>
</li>
<li><strong>hAtom2Atom</strong>
<ul>
<li>
Join all hfeed's inside a page (or a fragment thereof) into one feed using [http://greenbytes.de/tech/webdav/rfc4287.html#element.source atom:source] semantics.
</li>
<li>
Extraction of <code>atom:content</code>, <code>atom:summary</code> and <code>atom:title</code>:
* <code>atom:content</code> and <code>atom:summary</code> as HTML
* <code>atom:content</code> and <code>atom:summary</code> as plain-text
* <code>atom:title</code> as XHTML
* <code>atom:title</code> as HTML
</li>
<li>Support for other XSLT engines:
* .Net System.Xml
* hAtom2Atom written using XSL 2.0?
** Do you think this would be useful? I have created a barebones version, doesn't yet take in all the parsing rules yet, but I'd be happy to share. Moving to XSL 2.0 does make things a bit cleaner and more efficient. - Matt Dertinger.
</li>
<li>Support for other output formats: (hAtom2<i>xyz</i>.xsl)
* RSS 2.0 (meanwhile use hAtom2Atom.xsl and [http://atom.geekhood.net/ atom2rss.xsl]) -- <i>+1 Matt Dertinger</i>
* RSS 1.0 (meanwhile use hAtom2Atom.xsl and [http://cvs.4suite.org/viewcvs/uogbuji/atom2rss.xslt atom2rss.xslt]) -- <i>+1 Matt Dertinger</i>
** My opinion at the moment, I neither want to produce nor to consume RSS. Atom is nicer (and should be supported by most good feed readers available today), RSS should fade away. -- Robert Bachmann
* AtomOWL (meanwhile use hAtom2Atom.xsl and [http://dannyayers.com/2005/11/22/atomowl-xslt-progress/ atom2rdfxml.xsl])-- <i>+1 Matt Dertinger</i>
** Having the possibility of GRDDL-ing hAtom to AtomOWL seems definitly interessting. I realy should implement this some day. - Robert Bachmann
* JSON?
** Does it make sense to consider a canonical representation of microformats (either case by case, or in general) in JSON? E.g. so that a JSON API that returned contact information could return an hCard-equivalent chunk of JSON. - Tantek.
*** This could enable some nice JavaScript hacks. I should give hAtom2JSON a try. - Robert Bachmann
</li>
</ul>

([[User:Singpolyma|singpolyma]] 01:02, 9 May 2006 (PDT) -- Not XSLT, but see http://xoxotools.ning.com/hatom2rss.php for hatom to RSS2.0 conversion)
</li>
</ul>

== Brian Suda ==
=== Citation Microformats ===
* Add all my notes to the Wiki
* Start the process of naming the properties using existing names

=== X2V ===
Make changes and update site (almost stable)
Get ATTENDEE and other strange attributes working
==== WARNINGS and ERROR ====
work on the warnings and error output for the pre-check in X2V

=== FAQ ===
* clean-up the MF FAQs
* clean-up FAQs from the major microformats
* pull Questions from the mailing list and document them to the FAQs and example

=== Microformats History ===
* get early work from developer.technorati site
** issues with MoinMoin full history: http://moinmoin.wikiwikiweb.de/MoinMoinQuestions/UsingTheWiki#head-9d1b1d6beedde40b92cc6c13962b5a6f5b289d10

=== additions to the wiki ===

* better explain why NOT infinitely scaling is a good thing
* better explain why microformats do NOT use namespacing

== Mark Rickerby ==

=== Current Tasks ===

* Follow up on usability review
** Edits to homepage feature box text
** Draft of [[getting-started]] page
* Review content for new pages - [[start-simple]], [[modularity]], [[reuse]], [[humans-first]]
* xoxo datatype examples
** test case lists
** transmitting key/value lists
* practical feedback on hresume

=== Wishlist ===

* hmmm

== Ernest Prabhakar ==
=== Wiki-Thon Proposal ===
Set aside several hours (probably a Friday night US PST) for focused work on the Wiki, including both physical (e.g., a room in the Bay Area) and virtual (IRC/iChat) participants.

==== Goals ====
# Improve understanding of what needs to be done for Wiki
#* IMHO - this should be done here, in [[to-do]] incrementally. -Tantek
# Tackle larger projects (~1-2 hours) than people usually have time for
#* I'd like to see these projects *documented* first on [[to-do]] before we spend 1-2 hours of a bunch of folk's collective time to go through them. -Tantek
# Motivate community to have fun with otherwise tedious "housecleaning" chores

==== Agenda (Wishlist) ====
In parallel:
* Coalesce/prioritize existing To-Do items (above)
* Review/revise desired pathways for:
** New users learning about microformats
*** e.g., intro, about, explore, tutorials, etc.
*** cf. [http://www.rubyonrails.com/ Rails] front page
****Get Excited (Why, background, motivation)
****Get Started (What, downloads, getting started)
****Get Better (How, tutorials, )
****Get Involved (Who)
** Microformat lifecycle
*** e.g., research->brainstorm->proposal->spec->maintain
*** see http://theryanking.com/microformats/method.txt --[[User:RyanKing|RyanKing]] 15:35, 22 Feb 2006 (PST)
*** ensure information easy to find, follow, and up-to-date
* Review existing specs for completeness and consistency
* Identify areas of 'bitrot' or 'hole-filling'
* Do it!

== Dan Connolly ==

[[User:DanC|DanC]] hopes to sync up on these tasks in [[irc]] roughly
weekly, during Wednesday afternoon (Chicago time) "office hours". See also my [http://esw.w3.org/topic/DanConnolly esw todo list and someday pile].

* from SxSW in Austin
** build a combined hcalendar/hcard profile; resolve issues in [[profile-uris]].
*** with XSLT transformation to RDF
** finish [[hcard-tests]]
*** figure out [[include-pattern]] boundaries

* Medium term
** sync [[hcalendar-tests]] and [http://www.w3.org/2002/12/cal/ RDF calendar] tests and CALSIFY
*** reconsider RDF calendar naming conventions
** update my CV/resume using [[hResume]] and [[citation-formats]]
*** get an answer from the CALSIFY WG re [http://lists.w3.org/Archives/Public/www-rdf-calendar/2006Apr/0006.html dtstart and date vs datetime ] 21 Apr 2006
*** refine [[hatom]] so that it's suitable for the workflow around the W3C homepage.

* from WWW2006
** follow up on GRDDL as escape valve for microformats proposals, much like CSS was an escape valve for HTML tag proposals.

* Someday pile
** set up a timezone registry based on wikipedia and semantic mediawiki. As discussed in [[datetime-design-pattern]], iCalendar's by-value timezone passing is broken. see [http://lists.w3.org/Archives/Public/www-rdf-calendar/2006Apr/0002.html reconsidering timezones in light of hCalendar and CALSIFY] and [http://dig.csail.mit.edu/breadcrumbs/node/91 Toward Semantic Web data from Wikipedia]
** noodle on a playlist format and some of the media RSS stuff like [[media-info-brainstorming]], [[media-metadata-examples]] (re playlists: XSPF, SMIL, RDF, and microformats 9 Sep 2005)
** check out that hReview bug stuff...
** noodle on [[meeting-minutes-brainstorming]] and [http://esw.w3.org/topic/MeetingRecords MeetingRecords in the esw wiki].
** noodle on clipboard scenarios, esp how RDFa works in the general case but isn't as author-friendly as domain-specific syntaxes.

[[User:DanC|DanC]] 15:39, 31 May 2006 (PDT)

== Chris Casciano ==

[[User:ChrisCasciano|ChrisCasciano]]

* get around to updating [[hatom-issues]] with some multi feed rules/exceptions.
* <del>Update textpattern plugin with simple hreview support and get a new release out</del>
* Redesign placenamehere.com and include hatom
* Follow up with technorati folks on pingerati reviews getting lost (note: this will require publishing more reviews and theen watching them through the update process)
* <del>prototype a NetNewsWire microformat extractor (CSS+AppleScript)</del>

== Drew McLellan ==

[[User:DrewMcLellan|DrewMcLellan]]

* Build an hReview profile for [http://allinthehead.com/hkit/ hKit] and test
* Update the [http://www.webstandards.org/action/dwtf/microformats/ Dreamweaver extensions] to mirror recent changes in the online builders
* <del>Publish an hCard to JSON service on [http://tools.microformatic.com/ tools.microformatic.com] using hKit.</del>
* Further develop blog comment form hCard collection ideas.
* Version of hReview creator using hKit to import business details from an hCard

== Christophe Ducamp (french localization) ==

[[Christophe Ducamp]]
* seed "microformateurs group" and invite them to update http://microformateurs.org
** write a process for newbies in order to make them write [[posh-fr|CHIC]] posts on a public blog-governed-by-wiki ([http://socialsynergyweb.net/cgi-bin/wiki/MicroFormateurs/Blog]) before publication.
** find experts for peer-reviewing
** find french CSS gurus to setup a nice Sandbox-CSS template on Wordpress
* translating the wiki
** translate red links on [[Main_Page-fr]] and synchronize
** find out microformateurs at ease on "the-wiki-way-translation", and ready to help on semi-anonymous-synchro
* community-marketing -> pinko-marketing
** public-relations towards french journalists and complete [[advocacy-fr|advocacy]] (especially [[hcard-advocacy-fr]] towards organizations.
** help to build events, workshops like barcamps and explorcamps
** update [http://fr.wikipedia.org/wiki/Microformats French-wikipedia:Microformats] and subpages via cowriting [http://fr.wikipedia.org/wiki/Discuter:Microformats on discussion page] (directly originated from the english article) + french examples to be found + local resources.
** open discussion with french wikipediens about implementing some of the english existing templates
** small gifts: accessories and free gifts ? t-shirts, localized cheat-sheet, id-hcard-openid-providing, etc.
*** create hCard, hCalendar... and all red link pages on french wikipedia
* localize [[species-fr]] and related pages
* move all contents remaining on elanceur.org -> microformateurs.org
* wiki and uf:
** write and talk with "aboutus.org" to invite them to make experiences with uf -> talk with Mark Dilley
** maintain/update http://www.communitywiki.org/MicroFormats and talk with LionKimbro
** XWiki : awaiting beta-test of new platform
*** Follow-up LudovicDubost et LaurentLunati
* setup real-life links with european [[governance-fr|governance]] members ;) may be joining dconstruct-microformats-workshop - find solution (registering fees and travel expenses -> talk with Arnaud Fontaine or search french sponsors)

== Frances Berriman ==

[[User:Phae|Frances Berriman]]

* Work on styles for [[zen-garden]] project.
* Style HTML cheatsheet to match Brian Suda's PDF.
* Write simplified help/implementation documents (how tos) for all finalised Microformats.
* Re-organise general FAQ and simplify
** (Feel free to add suggested tasks to my list below:)
*** Help converge on organization efforts ~bewest :-)

== Ben West (bewest) ==

[[User:BenWest|bewest]]
* fight spam
* help tend wiki
* documentation of semantic authoring techniques
* researching the social problems relating to authorship and publishing on the web
* development of new microformats in response to failing to meet the needs of the second with the first.

=== Expore Microformat Deployment Issues ===
How does who determine the status of work going through some stage of the process? When does a format move from draft to "full spec"? Who decides? What are the qualitative and quantitative features that characterize work in different stages, especially as a spec nears deployment as "full spec". What makes this pronouncement more than a mythical blessing? What quantitative analyses can be provided to validate deployment? Today, we have powerful agents capable of processing huge amounts of information on the web. Should we be using these to measure published marketshare? What role should tools and test suites play in deploying microformats?

=== Vocabulary ===
A lot of knowledge work is about maintaining sets of vocabulary. Now that the vocabulary is emerging, it may be time start making sure everyone is "on the same page," especially since some of the language is highly symbolic.
Terms:
* "boil the ocean" A huge task. "A phrase used in the industry to describe an attempt at something that is way too ambitious. For example, "They're trying to get their site launched by COMDEX. They could easier boil the ocean." from <http://www.netlingo.com/right.cfm?term=boil%20the%20ocean>
* microformats: more than one microformat
* microformat: see my definition on http://microformats.org/wiki/what-are-microformats#BenWest
* data fidelity: the extent to which a data format might be considered lossy. eg HTML is often seen as a lossy format because the information parsed out of a resource may not fully match the information orginally encoded. Non-lossy formats have a very high data fidelity, while lossy formats have low data fidelity. Microformats seek to increase data fidelity of html.
* market: the locus of economic forces

: See [[glossary]]. [[User:AndyMabbett|Andy Mabbett]] 13:57, 7 Dec 2006 (PST)

=== Creators ===
_Concession_: my plans involve reuse of code, which would involve non-compatible changes with the current inline model. This is a nice feature, so maybe I should be branching instead.
* <strike>Start hatom creator.</strike> http://dichotomize.com/uf/hatom/creator.html
* Code Reuse. These creators are downright handy, and I’ve reimplemented the vcard one on my own site. Instead, let’s make these widgetized. Let’s decide on a more or less canonical html structure and create some javascript that will create the desired microformat. Something as easy to use as new Microformat.hCard($('mycontainer')); would be awesome. Right now, if someone makes an improvement to the hCard creator, the other creators don’t get the benefit. Spec this out!
* About Section. Is there an official creator page? If so, let’s point to that. The about paragraph is getting longer and longer with phrases like “which is based on…” repeated over and over.
* Default all dates to “right now”. Provide an easy to use calendar type widget to change dates.
* hAtom creator: Add multiple. It’d be nice to add an arbitrary number of entries.
* hAtom creator: Optional feed enclosure. Check box to wrap the entry/entries in an hfeed.
* Edit URI: Allow someone to enter a URI and edit whatever microformat is found on the page.
* Optionals. If the format requires, say, a vcard, the creator can defer to an external URI or can trust the user to fill it in later.
* Common stylesheet. I suppose this goes with the reuseable code idea… we have many great coders, we should be reusing eachothers’ work.
* Use Amazon's ECS to pull in information about products when there is an ASIN in the item URI.

=== Information Architecture ===
'''Help Welcomed! Please leave your name'''
Add complaints to [[wiki-feedback]]!
Helping to make the wiki easier to use. I'd like to see the main page more towards a format like http://simile.mit.edu/solvent/ with the big questions right out front:
* What Is This?
* What can I do here?
* Is there a demo?
* Where can I learn more?
I'd like to change the front page to this kind of design.
==== Support Pages ====
There are several categories of things in the wiki. Can we enumerate them?
* About the Community
** Where to find information.
** Who are the stake holders?
** FAQs
* Web/Architectural Philosophy
** Community Principles
** Why are we doing this?
** XML and Namespaces
** Semantic XHTML
** Common Misconceptions
** Concession and Disposition of Criticism
** FAQs
* Specs
** Examples
** Discussion
** Exploration
** Use Cases
** Implementations
** The spec itself.

* Tips and Tricks for Authoring ([[User:BenWest|BenWest]] 15:00, 9 Dec 2006 (PST))
** how to author semantic html
** choosing class names
** using HTML's general extension mechanisms
** advocating use
** collaborating/reusing HTML
** debugging HTML: use pastebin, separate out the relevant bits.
** getting help from the community
** applying Microformats.

Can others agree and or refine this list? Should I take it to the -discuss list? How do we create consensus on how the wiki should be organized in order to make it more usable? And how can we turn that consensus into actionable changes?

The wiki should also capture wisdom that stems from discussions that don't produce microformats. For example, Chris Messina suggests a "Best Of" page suitable for capturing this kind of wisdom. I think we can think of a given microformat as being at a place in a spectrum that ranges from "not yet thought of", to "interesting but needs work," or even "rejected", and of course including all the stages familiar to the microformats processes (eg examples, brainstorming, etc...).
If there were such a page would it:
* Belong to a microformat? (eg hcard-bestof)
* or to the global namespace? (eg /wiki/wisdom/foobar-format)
(I think Chris Messina suggests that it belongs to a given microformat, but then how do we collect wisdom from non-microformats?)

Considering that the wiki page named with the microformat (i.e. /wiki/hcard) is the one that people will mostly likely look to first for learning about a particular format, I'd think it'd make more sense and create a more welcoming feel to convert these pages to an intro page introducing the format for the beginner and linking to resources like tutorials and creators. Spec pages would then be relocated to wiki/*-spec -- [[User:Cgriego|Cgriego]] 13:25, 16 Oct 2006 (PDT)

====Mike Schinkel's Comments====

My suggestion on the list was for us to use a convention that the entry page (i.e.
http://microformats.org/wiki/hcard) would be an index into a list of
(psuedo) standardized sub pages so that it would be very people to
find what is important to them. For example, is a list of potential sub pages:

* Microformat
** Specification
** Tutorial
** Examples
** Use cases
** Reference
** Discussion
** Brainstorming (might be combined w/Discussion)
** Implementations
** Related Pages
** Further Reading
** All (Uses Mediawiki's "includes" to create a page including all sub pages; very useful for printing & reading offline)

These pages would be located respectively at

* http://microformats.org/wiki/hcard/
** http://microformats.org/wiki/hcard/Specification
** http://microformats.org/wiki/hcard/Tutorial
** http://microformats.org/wiki/hcard/Examples
** http://microformats.org/wiki/hcard/Use_cases
** http://microformats.org/wiki/hcard/Reference
** http://microformats.org/wiki/hcard/Discussion
** http://microformats.org/wiki/hcard/Brainstorming
** http://microformats.org/wiki/hcard/Implementations
** http://microformats.org/wiki/hcard/Related_Pages
** http://microformats.org/wiki/hcard/Further_Reading
** http://microformats.org/wiki/hcard/All

Please note I am suggesting an architecture not a specific list of sub pages. The list of sub pages should be defined by both reviewing existing information during site reorganization, and then via discussion on the list in an attempt to discover and extract which sub pages are needed for most/all microformats.

'''NOTE''': This differs from above in that the spec if not viewed as a top level structure but instead the microformat itself and the spec would be under the microformat. In this context "microformat" is a more abstract concept and "spec" is a more concrete thing. Another way to think about it would be that each microformat would have it's own mini home page and then things like "spec" are the pages listed on its home page.

== Matt Dertinger (Thewhoo) ==

[[User:Thewhoo]]

=== hAtom2Atom ===
<ul>
<li>Support for other XSLT engines:
* hAtom2Atom written using XSL 2.0
</li>
<li>Support for other output formats: (hAtom2<i>xyz</i>.xsl)
* RSS 2.0 (meanwhile use hAtom2Atom.xsl and [http://atom.geekhood.net/ atom2rss.xsl])
* RSS 1.0 (meanwhile use hAtom2Atom.xsl and [http://cvs.4suite.org/viewcvs/uogbuji/atom2rss.xslt atom2rss.xslt])
* AtomOWL (meanwhile use hAtom2Atom.xsl and [http://dannyayers.com/2005/11/22/atomowl-xslt-progress/ atom2rdfxml.xsl])
</li>
</ul>

=== Microformats Proposals ===

* rel="disclaimer":
** Purpose: to create a semantic linkage (relationship) between a foot-note or end-note marker and the actual location of the text that the marker refers to.
* rel="external":
** Purpose: to formalize what is already in existence in the wild. The use of rel="external" to refer to a document that is external or outside of the current domain.

== Henri Bergius ==

[[User:HenriBergius|Henri Bergius]]

* Add hKit support for automatically populating contact details into [http://www.openpsa.org/version2/openpsa/contacts.html OpenPsa Contacts] CRM
* Implement Tail scripts for adding things into Midgard

== Justin Thorp ==
* Start researching examples for a To-do microformat

== [[User:MarkLentczner|Mark Lentczner]] ==

* Get Second Life's event web pages to have proper event microformats data
** Add [[hcard|hCard]] to profile pages
** Add [[hcalendar|hCalendar]] to events listings
* Start pinging pingerati.net/ping/$url when pages are updated
* Collaborate on designing how to integrate microformats, metadata and objects in [http://secondlife.com/ Second Life].

== [[User:DerrickPallas|Derrick Pallas]] ==
=== microformat proposal: dependancy ===
* looking for examples of directed graphs on the web
* applications in
** software engineering
*** automatically build library dependency trees
*** distribute security alerts to people that link to your code
** any directed, acyclic graph
*** getting dressed in the morning
*** cooking
* orthogonal to xfn
** people don't have versions
*** libfoo requires libbar-2.0 or later
** people don't have optional relationships
*** ex: at build time, compile in SSL support if present
** people don't have exclusive-or relationships
*** ex: in Gentoo, syslog, syslog-ng, and metalog satisfy virtual/syslog
*** ex: the Ruby library RMagick requires ImageMagick xor GraphicsMagick

== [[User:PaulDowney|Paul Downey]] ==
* building a generic Javascript parser
* bundling parser as a [http://tiddlywiki.org TidlyWiki] plugin for hCards
* documenting how best to microformat TiddlyWiki pages

== [[User:RobManson | Rob Manson]] ==
* chase the admins to get some creation template extensions installed for wiki (see: http://meta.wikimedia.org/wiki/Inputbox or http://www.mediawiki.org/wiki/Extension:CreateBox or http://www.mediawiki.org/wiki/Extension:CreateArticle)

== [[User:ClayNewton | Clay Newton]] ==
* Work on getting others involved in [[trade-examples]]
** Need examples from major online banking sites
** Need examples from major ecommerce sites
* Continue working on: [[trade-brainstorming]]

== [[User:BenWard | Ben Ward]] ==

=== Recurring ===

* Publish This-Week to blog
* Delete Wiki Spam

=== Currently ===

* Wiki Upgrade
** Wiki upgrade to MediaWiki 1.12
*** Status: Local testing, patch migration, data migration
** Extensions to replace code hacks
*** Written SemanticHTML extension to enable ABBR and other disabled phrase elements
*** Experimenting with OpenID plugin
** µf Wiki theme
*** Status: In progress. Blog look+feel being ported. Special µf display requirements accounted for. hCalendar footer!
* Documentation of [[machine-data]] and specification of the [[value-excerption-pattern]]

=== Next Actions ===

* Conclude new hCalendar proposals from Yahoo TV Listings experience
* Resume work on hListing microformat
* Re-org the Microformats.org front-page content
** Work with [[User:Phae]] on refreshing the microformats frontpage content
** Build new events module for the blog using Upcoming.org, rather than hard coded event data (Matt Harris may have done this…)
** Build new wiki edits module for the blog
** Combine ‘list of microformats’ into the intro text? Make intro text more friendly.
* Build a microformats activity stream
* Improve µf.org/blog OpenID support, find a good workflow for login/comment (current plug-in has an abysmal user experience)

html5

2008-07-30T22:31:09Z

IanHickson: /* New features in HTML5 */

<h1>Microformats in HTML 5</h1>

''This page is to document '''future''' use of microformats in [http://www.w3.org/html/wg/html5 HTML 5]. None of the items documented are supported now, and may change upon proper development within the microformats community, or changes in the HTML 5 specification. This page is to track HTML5 enabled enhancements to microformats, and issues that HTML5 raises. It may be used to track issues which we need to push back into the HTML 5 development process.''

If there are things that Microformats would like to mark up that aren't handled by HTML5 explicitly, please let the WHATWG know, so we can improve HTML5. This is how <code>time</code> came to be, for instance.

==New features in HTML5==

* '''<code>time</code> element for representing date times'''. In HTML5, the machine form of datetimes can be represented natively. It should be possible to replace the date-time design pattern with native HTML.
* '''<code>data-</code> naming convention for tag attributes'''. the draft specification states that any attribute that starts with "data-" will be treated as a storage area for private data.
** Note that the data-* stuff is explicitly 'not' for Microformats, at least not Microformats that ever want to be handled natively by the browser. Those attributes are defined in such a way that browsers will never do anything special with them, ever. They are intended for script authors to have a space in which they can play without ever clashing with anything the browser does.

==Issues==

* '''The <code>rev</code> attribute has been removed'''. In HTML5, <code>rel</code> and <code>rev</code> are no-longer paired, and the <code>rel</code> attribute nolonger describes the direction of a relationship. Microformats which use <code>rev</code> will need to use <code>rel</code> instead.
** Or something like data-rev="vote-for".
* '''The <code>profile</code> attribute has been removed'''. In HTML, the <code>profile</code> attribute from the <code>head</code> has been removed, with no direct replacement. This causes issues for GRDDL support. It's been suggested that profile URLs be represented in <code>link</code> elements instead, or even as a custom HTTP header.

html5

2008-07-30T22:29:31Z

IanHickson: /* New features in HTML5 */

<h1>Microformats in HTML 5</h1>

''This page is to document '''future''' use of microformats in [http://www.w3.org/html/wg/html5 HTML 5]. None of the items documented are supported now, and may change upon proper development within the microformats community, or changes in the HTML 5 specification. This page is to track HTML5 enabled enhancements to microformats, and issues that HTML5 raises. It may be used to track issues which we need to push back into the HTML 5 development process.''

==New features in HTML5==

* '''<code>time</code> element for representing date times'''. In HTML5, the machine form of datetimes can be represented natively. It should be possible to replace the date-time design pattern with native HTML.
* '''<code>data-</code> naming convention for tag attributes'''. the draft specification states that any attribute that starts with "data-" will be treated as a storage area for private data.
** Note that the data-* stuff is explicitly 'not' for Microformats, at least not Microformats that ever want to be handled natively by the browser. Those attributes are defined in such a way that browsers will never do anything special with them, ever. They are intended for script authors to have a space in which they can play without ever clashing with anything the browser does.

==Issues==

* '''The <code>rev</code> attribute has been removed'''. In HTML5, <code>rel</code> and <code>rev</code> are no-longer paired, and the <code>rel</code> attribute nolonger describes the direction of a relationship. Microformats which use <code>rev</code> will need to use <code>rel</code> instead.
** Or something like data-rev="vote-for".
* '''The <code>profile</code> attribute has been removed'''. In HTML, the <code>profile</code> attribute from the <code>head</code> has been removed, with no direct replacement. This causes issues for GRDDL support. It's been suggested that profile URLs be represented in <code>link</code> elements instead, or even as a custom HTTP header.

events/2006-03-01-w3c-plenary-microformats

2006-03-09T02:56:37Z

IanHickson: my slides

<h1>Microformats panel at W3C Plenary Day</h1>

One of several microformats [[events]].

During the [http://www.w3.org/2006/03/01-TechPlenAgenda.html W3C Plenary Day] (has [[hcard|hCard]] & [[hcalendar|hCalendar]]!) in the middle of the [http://www.w3.org/2005/12/allgroupoverview.html W3C All Group Meetings Week] in Mandelieu, FRANCE.

__TOC__

== Summary ==

This is the summary of the panel as published at http://www.w3.org/2006/03/01-TechPlenAgenda.html :

Session 3: Microformats

Description: Leveraging the widespread adoption and understanding of CSS and semantic (X)HTML among web designers and publishers, microformats are a set of simple, practical, open data formats that are designed for humans first and machines second. Microformats are designed by researching and adapting to current human web publishing behaviors and usage patterns, and then reusing bits of existing widely adopted standards. This session will demonstrate the capabilities that have been quickly developed with microformats on today's Web, review current microformats, and open discussion on what microformats and related efforts mean for the future of the Web..

Moderators: Tantek Çelik (Technorati) and Don Connolly (W3C)

Presenters and Topics:

* Ian Hickson (Google) - "A billion documents and no semantics anywhere"
* Tantek Çelik (Technorati) - "[http://tantek.com/presentations/2006/03/what-are-microformats/ What are microformats?]"
* Håkon Wium Lie (Opera) - "Cascading Markup Languages — boom!"
* Rohit Khare (CommerceNet) - "Where Angle Brackets Fear to Tread"
* Dan Connolly (W3C) - "[http://www.w3.org/2003/g/talk62/slides Microformats for practical Semantic Web deployment]"

== Session Descriptions ==

These are session descriptions from each presenter.

=== Ian Hickson ===

"A billion documents and no semantics anywhere"

The "semantics" in the title refers to the "semantics" given to the Web by
HTML, as opposed to the "semantics" that are actually put in the Web by
the humans. Microformats can document existing practices (especially based
on the data from studies of existing documents) so that the existing
content can be given "official" "semantics".

Basically my talk was "ooo look pretty shiny billion
documents lots of data that shows people use HTML not like it was intended
but we can reverse engineer microformats out of existing practices to
obtain useful information".

Slides: http://www.w3.org/2006/03/01-Hickson/Semantics.html

=== Tantek Çelik ===

"What are microformats?"

How did we get here? Picking up (hopefully) where the previous talk left off, a brief review of recent web authoring trends, a timeline of the ideas that formed microformats, and demonstrations how hCard and hCalendar are being put to good use today by publishers, browsers, and end users alike.

=== Håkon Wium Lie ===

"Cascading Markup Languages — boom!"

Cascading in CSS allows descigners to not have to provide the full presentation of a
document, they only need to supply the deltas from the html default
style sheet; cascading does the rest. In the same way, microformats
builds on the (admittantly shallow) semantics of HTML; you don't have
to create a new laguage to describe more semantics, you just provide
the deltas on top of HTML.

This is one of the design principles that CSS and microformat share,
others inlcude: simplicity, author-friendliness, an evolutionary
approach.

Boom will be provided as an example.

=== Rohit Khare ===

"Where Angle Brackets Fear to Tread"

XML has been a wild success almost everywhere in the information technology universe *except* for adding semantically-rich information to ordinary Web pages. Once upon a time, we were supposed to wish for <code><nowiki><price></nowiki></code> elements sprinkled about our HTML -- why is are we supposed to be so much more excited to see class="price" this time around? Dr. Khare will speak about his experiences with both xml and microformats in light of a recent project, hListing (for classified ads), and writing a parser and search engine for microformats in general.

=== Dan Connolly ===

"Microformats for practical Semantic Web deployment"

Microformats provide just enough structure to use semantic web technologies like RDF, OWL, and SPARQL on data in ordinary web pages. Dan will relate a few case studies and demonstrate some tools.

== Attending ==
Please add your name here if you are attending the W3C Plenary Day (whether you are speaking or not). Consider adding yourself to the [http://esw.w3.org/topic/MeetingTaxis MeetingTaxis page] as well to coordinate rides to/from Nice airport.

Alphabetically sorted by last name.

* Jonny Axelsson
* David Baron
* Tim Berners-Lee
* Bert Bos
* Tantek Çelik
* Dan Connolly
* Ian Hickson
* Rohit Khare
* Kevin Lawver
* Håkon Wium Lie
* ...
* ...

== Session Comments and Q&A ==

The meeting was video/audiotaped. Could those who have a copy please transcribe the Q&A and comments it here? Those of us who were there might remember who was each speaker and could then annotate that information as well.

* "I'm very excited about '''microformats'''. What I really want is to get all the data out of databases and expressed as part of the Semantic Web." - Tim Berners-Lee. ('''emphasis''' added)
* ...

== Thanks ==

Thanks to RobertBachmann for helping markup the [http://www.w3.org/2006/03/01-TechPlenAgenda.html W3C Plenary Day page] with [[hcard|hCard]] & [[hcalendar|hCalendar]]. Previous [http://tantek.com/microformats/2006/03-01-TechPlenAgenda.html working version of the page].

== Photos ==

[http://flickr.com/photos/maguisso/106299136/ http://static.flickr.com/49/106299136_6b263c4f7c_m.jpg]
[http://flickr.com/photos/maguisso/106299138/ http://static.flickr.com/37/106299138_7af74ad5a3_m_d.jpg]
[http://flickr.com/photos/maguisso/106299140/ http://static.flickr.com/36/106299140_439cfc31e5_m_d.jpg]
[http://flickr.com/photos/maguisso/106307608/ http://static.flickr.com/42/106307608_53a4510093_m_d.jpg]
[http://flickr.com/photos/maguisso/106307611/ http://static.flickr.com/24/106307611_b7325b42c4_m_d.jpg]
[http://flickr.com/photos/maguisso/106307607/ http://static.flickr.com/56/106307607_7b2b1e045a_m_d.jpg]

=== Photos from the W3C Technical Plenary Week ===
Taken by:
[http://glazman.org/W3C-TP-2006/ Daniel Glazman]
[http://flickr.com/photos/amyvdh/tags/techplen/ Amy van der Hiel]
[http://flickr.com/photos/ishida/tags/techplen/ Richard Ishida]
[http://www.flickr.com/photos/nicecupoftea/tags/techplen/ Libby Miller]
[http://flickr.com/photos/maguisso/tags/techplen/ Luis Villa del Campo]

* David Baron (to be linked)
* Tantek Çelik (to be uploaded)

wiki-formats

2006-03-01T11:31:05Z

IanHickson: MARKDOWN

= wiki formats =

== Authors ==

* Tantek Çelik
* Ben West

== Intro ==

Ian Hickson recently lamented to me that:
"I have yet to find a wiki that has both a nice syntax (i.e. one that looks
like text/plain as opposed to one that looks like just another obscure
markup language -- if you're going to use markup, why not just use HTML
in the first place), and that produces semantic markup (as opposed to
having tags for "bold" and "italics")."

And I have to kind of agree with him. My experience with current wiki formats is that they haven't done that good a job of "paving the cowpaths", that is, taking what people write in plain text documents, and interpreting them as structure, rather than inventing new text conventions (e.g. equal signs for headings?!?) and getting people to learn them.

This page is an attempt to catalog/document current wiki and wiki-like text formats to see if there is any chance of solving this problem.

Technically a wiki format would not be a microformat because it is not expressed in XHTML building blocks. However, many of the other [[microformats|principles of microformats]] can be applied to perhaps come up with a better solution that what wikis use today (since they all seem to use their own variant formats anyway).

== wiki software ==

=== MediaWiki ===

What you're using now.

* paragraphs
** blank line creates a new paragraph
* unordered lists
** start a line with "* " and it will put it into an unordered list.
** use multiple "*", e.g. "** " for 2nd level, for nested unordered lists.
* ordered lists
** start a line with "# " and it will put it into an ordered list.
** use multiple "#", e.g. "## " for 2nd level, for nested ordered lists.
* headings
** prefix and suffix with "=" for level 1 heading, "==" for level 2 heading etc.
* literal
** use <pre> ... </pre> tags

=== MoinMoin ===

What the [http://developers.technorati.com/ Technorati Developer's Wiki] uses. Starting with v1.3.2, MoinMoin ships with reStructuredText too.

=== Kwiki ===

* See http://www.kwiki.org/

=== Tiki Wiki ===
[http://doc.tikiwiki.org/tiki-index.php?page_ref_id=268 TikiWiki Syntax Reference] and
[http://doc.tikiwiki.org/tiki-index.php?page=Formatting%20Standards Formatting Guide]

Important Syntax:

* Lists
** * Creates an unordered list.
** # Creates a numbered list.
** ;term:definition creates a term and definition list.
** Features include nesting in a predictable manner, sections that can hide/display with a +/- symbol, and line continuation after breaks.
* Links
** JoinedWords indicate an internal wiki link.
** ((Words|Description)) inside parenthesis also indicates an internal wiki link and can include spaces and non-standard wiki link conventions. A pipe delimits the text to be used for the link.
** ))JoinedWords(( can escape the link parsing.
** External links go inside square brackets [ ] with the same convention regarding the descriptive text. Many features of this wiki also allow options to be passed, eg. nocache, after a pipe.
* Images
** {img src= width= height= align= desc= link= }
* Text formatting
** Bolding is done by placing text in between a pair of double underscores: __bolded text__
** Text is centered by placing text in between two colons: ::centered text::
** Text is colored by delimiting the color name and the text with a colon surrounded by a pair of double tildes. ~~blue:text~~
** Text is italicized by surounding the text with a double pair of single quotes: <nowiki>''italicized''</nowiki>.
** The syntax for monospaced/teletype text is: -+monospaced text+-
** Underlined text is indicated with 3 equal signs: ===underlined text===
** Text can be put in a simple box by surrounding it with the carrot: ^boxed text^
* Headings
** Headings are indicated by the presence of an exclamation mark at the beginning of the line: !My heading. Sub headings and level of nesting is indicated by the number of exclamation marks. (Same way that lists nest.) This does carry semantic purpose in the TikiWiki documentation and the maketoc module uses this feature in order to make tables of contents.

=== phpwiki ===
[http://phpwiki.sourceforge.net/phpwiki/HowToUseWiki Introduction]
and [http://phpwiki.sourceforge.net/phpwiki/TextFormattingRules Syntax Rules].

* Formatting (copied from http://phpwiki.sourceforge.net/phpwiki/TextFormattingRules, edited to make a list)
** Emphasis: _ for italics, * for bold, _* for both, = for fixed width.
** Lists: * for bullet lists, # for numbered lists, Term:<new-line> definition for definition lists.
** Preformatted text: Enclose text in <nowiki><pre></pre></nowiki> or <verbatim></verbatim>.
** Indented text: Indent the paragraph with whitespaces.
** References: JoinCapitalizedWords or use square brackets for a [page link] or URL <nowiki>[http://example.com]</nowiki>.
** Preventing linking: Prefix with "~": ~DoNotHyperlink, name links like [text | URL].
** Misc: "!", "!!", "!!!" make headings, "%%%" or "<br>" makes a linebreak, "----" makes a horizontal rule.
** Allowed HTML tags: b big i small tt em strong abbr acronym cite code dfn kbd samp var sup sub

=== Midgard Wiki (net.nemein.wiki) ===

* [http://daringfireball.net/projects/markdown/syntax Markdown] is used by default, but it can be switched to [http://www.dynarch.com/projects/htmlarea/ WYSIWYG HTML]
* Some additional [http://www.midgard-project.org/midcom-permalink-7276f817dcdefcf40d30a9ec69a7241f linking formats] are used
* See [http://www.midgard-project.org/midcom-permalink-5f8044fb6b23322ed3fe2d1ff0e50cf6 Midgard Wiki documentation]

== Other Resources ==
* See http://c2.com/cgi/wiki?WikiEngines for a list of known wikis.
* See http://tavi.sourceforge.net/WikiEngines/ComparingWikis for a table comparing wiki features (no syntax information)

Should plain text formats from other non-wiki systems be included in this exploration? What about phpbb codes? Or certain blogging tools? What about Almost Free Text ( [http://www.maplefish.com/todd/aft-refman.html#Syntax%20Overview Syntax Overview] ) and other plain text processing tools? There is a breed of hybrid wiki-blog systems like http://www.backpackit.com and http://www.basecamphq.com both by 37signals.

== Extra-wiki Formatting Conventions ==

=== Live Chats ===

This includes IRC, and sundry chat services such as AIM. There are several popular conventions to indicate a low level of formatting in plain text in various chat services. Text in between a pair of * is understood to either be an emotion or action (eg *grin*) or *emphasized* (perhaps equivalent to bolding). Text in between a pair of /forward slashes/ is many times understood to carry an italicized meaning. Text in between a pair of _underscores_ is understood to be underlined.

For example, the [http://yarrr.gnome.org/wiki/index.php/Yarrr_ChatMarkup syntax] used by the [http://yarrr.gnome.org/wiki/index.php/Main_Page Yarr (☠)] in-Wiki chat system.

== Other Standards Efforts ==
* http://tikiwiki.org/RFCWiki An RFC Draft for wiki syntax.
* http://lab.lolipop.jp/fswiki/wiki.cgi/wikistandard An attempt to establish a standard wiki syntax (for Japanese language)
* http://daringfireball.net/projects/markdown/basics This looks like it solves the problem (mostly).

== Summary ==
Apparently most wikis use a * to indicate bulleted lists. Nesting works intuitively. New paragraphs are often indicated with newlines. Several schemes uses capitalized JoinedWords to indicate an internal link, and square brackets [ ] to indicate an external link. Common problems include unexpected failure to handle nesting within certain syntax, competing formatting rules, varying degrees of semantic meaning, and arbitrary formatting codes.

Asterisks to handle unordered lists and pound signs for numbered lists probably work pretty nicely. It's common to use asterisks for lists in plain text formatting, and using a pound sign typically means "a number", and lets the user know that the system will automatically enumerate the following points. However, indicating that the following line should match the indentation of the preceeding line involves strange notation. Unfortunately, arbitrarily blocked elements such as a simple box will break the nesting and continued parsing of list items several wikis.

Likewise, although one doesn't often see exclamation points used to convey that a given line is a heading, this might work nicely as well. An exclamation point indicates importance and emphasis; having it at the beginning of the line is rare, makes the interface to the nesting behavior monotonous because it is the same as the lists, and seems just as natural (to this writer) as filling the succeeding line with dashes or equals. It also makes a lot more sense than surrounding the headline text with equal signs.

Square brackets are used in most wikis to indicate a link of some kind. However, some wikis split links into external and internal, creating a modal interface to publishing links. Furthermore, despite the standard JoinedCapitalizedWords to create an internal link (and/or create a new page), wiki systems freely allow users to ignore the convention by allowing varied alternate linking methods. An additional failing of internal linking schemes is is that wikis are many times a part of a larger content management system, and full "external" links are required anyway in order to reach components of the site. In plain text documents, it is more common to see a full url accompanied with some explaining text. Of the wikis that allow for a natural rendering of urls as links, they also allow a specialized convention to allow for the substituted text to point to the url. Perhaps a future solution would abolish the internal/external modality, parse in-line urls, and include a simple option for text substitution. For example: "<nowiki>http://www.google.com(Google) is a great search engine.</nowiki>" would show up as: "[http:www.google.com Google] is a great search engine."

== wiki formats ==

* [http://www.kwiki.org/?WaflProposal WAFL - Wiki Abstract Formatting Langauage]

== straw proposals ==

What Ian uses in his text/plain documents:

* h1:
**
<pre>
first level heading - followed by a line starting with equal signs "="
=============================================
</pre>
* h2:
**
<pre>
second level heading - followed by a line starting dashes "-"
--------
</pre>
* h3:
**
<pre>
THIRD LEVEL HEADING - ALL CAPS ON A LINE
</pre>
* p:
** a blank line to start and finish
* ol / li
** a line starting with space then a number followed immediately by a period, e.g.
<pre>
1. Here is one ordered list item
</pre>
** note that such list items may be separated by blank lines.
** note that paragraphs within a list item will be indented as much as the text after the list item marker.
** list is terminated by a non-blank line that *doesn't* start with space then a number then a period, and is outdented from where list item paragraphs are.
* ul / li
** a line starting with space then an asterisk then at least one space, e.g.
<pre>
* Here is an unordered list item
</pre>
** same notes apply respectively as those for ordered list items above.
** nested unordered list items are similar, except that their marker is further indented, and in addition to "*", other list item markers may be used such as "+" and "-".
* pre / code
** some amount of nesting with whitespace. pre / code. it's not clear what type of code (e.g. HTML or CSS).
* em
** text surrounded by a single adjacent underline on both sides, e.g.
<pre>
_at the moment_
</pre>
* blockquote and cite attribute
** a set of lines that being with "| ", and after the last one, a line that starts with " -- ", followed by the citation URL, e.g.:
<pre>
| This is a quote
| and a second line
-- http://example.com/quotation/
</pre>

Open issues:
* What's this?
** <code>-*- Mode: text; -*-</code> ''It's the Emacs mode line. Just ignore anything starting with one or more spaces and then having the form -*- ... -*-''
* how do you encode in text/plain the semantics of:
** strong ''Use *stars* instead of _underscores_''
** dfn
** dl/dt/dd
** h4, h5, h6 ''There is no H4 in this format. Only H1-H3. Just like HTML has no H7, and is limited to H1-H6.''
** table / thead, tbody, tfoot, caption / tr / td, th ''I have some pages that do tables, you just do an actual ASCII art table with proper ASCII art lines''
** hyperlinked text ''text/plain has no hyperlinks, so I always put them on the next line (pre/code style)''
** hyperlink relationships (rel attribute on hyperlinked text)
** address (possibly the "Author: " line?)
** inline code

events/2006-03-01-w3c-plenary-microformats

2006-02-20T02:05:30Z

IanHickson: /* To Do */

<h1>Microformats panel at W3C Plenary Day</h1>

During the [http://www.w3.org/2006/03/01-TechPlenAgenda.html W3C Plenary Day] in the middle of the [http://www.w3.org/2005/12/allgroupoverview.html W3C All Group Meetings Week] in Mandelieu, FRANCE.

Presenters, please see To Do section.

__TOC__

== To Do ==

* ASAP: DanC, please add [[hcalendar|hCalendar]] and [[hcard|hCard]] markup to http://www.w3.org/2006/03/01-TechPlenAgenda.html

* All presenters should confirm that presentations are done and ready. Link to them from here as soon as possible (even drafts) so we can all review and see where everyone is at.
** Ian Hickson: started looking at some of the data Google didn't publish from our last billion-document run, to see if there's anything fun to show. I think I'll show the class names coloured based on how semantic they are, maybe.
** Tantek Çelik: not done yet
** Håkon Wium Lie: status unknown
** Rohit Khare: status unknown
** Dan Connolly: status unknown

== Summary ==

This is the summary of the panel as sent to Steve Bratt as of 2006-02-17, and published at http://www.w3.org/2006/03/01-TechPlenAgenda.html :

Session 3: Microformats

Description: Leveraging the widespread adoption and understanding of CSS and semantic (X)HTML among web designers and publishers, microformats are a set of simple, practical, open data formats that are designed for humans first and machines second. Microformats are designed by researching and adapting to current human web publishing behaviors and usage patterns, and then reusing bits of existing widely adopted standards. This session will demonstrate the capabilities that have been quickly developed with microformats on today's Web, review current microformats, and open discussion on what microformats and related efforts mean for the future of the Web..

Moderators: Tantek Çelik (Technorati) and Don Connolly (W3C)

Presenters and Topics:

* Ian Hickson (Google) - "A billion documents and no semantics anywhere"
* Tantek Çelik (Technorati) - "What are microformats?"
* Håkon Wium Lie (Opera) - "Cascading Markup Languages — boom!"
* Rohit Khare (CommerceNet) - "Where Angle Brackets Fear to Tread"
* Dan Connolly (W3C) - "Microformats for practical Semantic Web deployment"

== Session Descriptions ==

These are session descriptions from each presenter.

Presenters, feel free to tweak/update your session descriptions.

=== Ian Hickson ===

"A billion documents and no semantics anywhere"

The "semantics" in the title refers to the "semantics" given to the Web by
HTML, as opposed to the "semantics" that are actually put in the Web by
the humans. Microformats can document existing practices (especially based
on the data from studies of existing documents) so that the existing
content can be given "official" "semantics".

Basically my talk will be something like "ooo look pretty shiny billion
documents lots of data that shows people use HTML not like it was intended
but we can reverse engineer microformats out of existing practices to
obtain useful information".

=== Tantek Çelik ===

"What are microformats?"

How did we get here? Picking up (hopefully) where the previous talk left off, a brief review of recent web authoring trends, a timeline of the ideas that formed microformats, and demonstrations how hCard and hCalendar are being put to good use today by publishers, browsers, and end users alike.

=== Håkon Wium Lie ===

"Cascading Markup Languages — boom!"

Cascading in CSS allows descigners to not have to provide the full presentation of a
document, they only need to supply the deltas from the html default
style sheet; cascading does the rest. In the same way, microformats
builds on the (admittantly shallow) semantics of HTML; you don't have
to create a new laguage to describe more semantics, you just provide
the deltas on top of HTML.

This is one of the design principles that CSS and microformat share,
others inlcude: simplicity, author-friendliness, an evolutionary
approach.

Boom will be provided as an example.

=== Rohit Khare ===

"Where Angle Brackets Fear to Tread"

XML has been a wild success almost everywhere in the information technology universe *except* for adding semantically-rich information to ordinary Web pages. Once upon a time, we were supposed to wish for <code><nowiki><price></nowiki></code> elements sprinkled about our HTML -- why is are we supposed to be so much more excited to see class="price" this time around? Dr. Khare will speak about his experiences with both xml and microformats in light of a recent project, hListing (for classified ads), and writing a parser and search engine for microformats in general.

=== Dan Connolly ===

"Microformats for practical Semantic Web deployment"

Microformats provide just enough structure to use semantic web technologies like RDF, OWL, and SPARQL on data in ordinary web pages. Dan will relate a few case studies and demonstrate some tools.

hcard-parsing

2005-12-15T23:02:05Z

IanHickson: /* Outstanding Issues */ Define in terms of the DOM.

= hCard parsing =

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

== introduction ==

When I first conceived of [[hcard|hCard]], it was clear to me how to unambiguously parse both for the existence of hCards in arbitrary (X)HTML (and anywhere that arbitrary (X)HTML can be embedded, e.g. RSS, Atom, "generic XML"), and hCard properties and values.

I worked directly with Brian Suda to capture these thoughts in an implementation, and Brian wrote X2V, an XSLT script that converts hCards to vCards, thus simultaneously demonstrating the parsability of hCards, and the immediate utility of hCard content interoperating with widespread existing vCard applications.

I am now documenting those thoughts directly here so that additional implementations, rather than having to reverse engineer X2V, can be built directly from these elementary concepts.
__TOC__

== scope ==

Although this page is written specifically to explain how to parse [[hcard|hCard]], the concepts and algorithms contained therein serve as an example for how other [[compound-microformat|compound microformats]] are to be parsed.

== URL handling ==

An hCard parser may begin with a URL to retrieve.

If the URL lacks a fragment identifier, then the parser should parse the entire retrieved resource for hCards.

If the URL has a fragment identifier, then the parser should parse ''only'' the node indicated by the fragment identifier and its descendants, looking for hCards, starting with the indicated node, which may itself be a single hCard.

== root class name ==

Each compound microformat starts with a root element with a relatively unique class name. By that I mean a class name which isn't simply a common word, and is unlikely to have been used outside the context of the microformat. By choosing such a root class name the microformat avoids (for all practical purposes) colliding with existing class names that may exist within the (X)HTML context. This is essential to enabling such compound microformats to be ''embedded'' inside current, existing content, as well as future content.

Fortunately this is not a new problem to solve. The root object names chosen for vCard (RFC 2426) and iCalendar (RFC 2445) similarly had to avoid such collisions and did so by choosing names that were unlikely to have been introduced into a MIME object context. The principle of ''reuse'' dictates that we should reuse the names for these root objects in those RFCs rather than invent our own. Given the same semantics, a design should reuse the names, rather than inventing a second name for the same semantic (a common design mistake made in environments that require namespaces).

In the vCard specification, the names are case-insensitive due to the (lack of) requirements of their context. (X)HTML class names are case sensitive per those specifications. Thus we are required to pick a canonical case for the class name equivalents of vCard object and property names. All lowercase is chosen to follow the precedent (i.e. ''reuse'' the pattern) set by XHTML, which similarly had to canonicalize the case of element and attribute names that it took from HTML4, which itself was case-insensitive due to its context (SGML). Additionally, reasons for avoiding mixed-case (e.g. camel case) in the context of class names may be found in the essay [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class], specifically, the section titled [http://tantek.com/log/2002/12.html#atoc_csensitivity Class sensitivity].

Thus the root class name of an [[hcard|hCard]] is "vcard".

== finding hCards ==

An (X)HTML document indicates that it may contain hCards by referencing the [[hcard-profile|hCard XMDP profile]]. See [http://gmpg.org/xmdp/description XMDP] for more details.

A parser finds hCards in an (X)HTML context by looking for elements with the root class name "vcard" just as the following CSS class selector does:
<pre>
.vcard
</pre>

For example, the following CSS style rule sets the background of all hCards to green:
<pre>
.vcard { background: green; }
</pre>

Note that the (X)HTML class attribute is a space separated set of class names.

Thus all of the following are valid hCard root elements:
* <code><div class="vcard"> </div></code>
* <code><span class="attendee vcard"> </span></code>
* <code><address class="vcard author"> </address></code>
* <code><li class="reviewer vcard first"> </li></code>

Once the root element of an hCard is found, that element and all its descendants are all that is needed to parse the hCard.

Thus it is possible for a well-formed hCard to be extracted from an overall non well-formed context, if the parser has the ability to find elements by class name within that non well-formed context.

== hCard properties ==

The complete list of class names for hCard properties are documented in the [[hcard-profile|hCard profile]].

=== forward compatible parsing ===

When parsing the contents of an hCard, any unrecongized class names must be ignored.

Similarly, unrecognized values for hCard properties must also be ignored.

=== finding hCard properties ===

To parse an hCard for an hCard property (e.g. "fn"), the parser simply looks for the first element with that class name inside the hCard.

This can also be expressed as the first element that matches this CSS selector:

<pre>
.vcard .fn
</pre>

Some properties, like "fn", should only appear once, and thus the parser stops looking for the property after it has found one occurrence. Additional occurrences are ignored.

Other properties, like "adr", "email", "url", "tel", etc., may (and often do) appear more than once, and thus the parser continues to look for each occurrence within the contents of the hCard.

=== parsing hCard properties and values ===

Once an element for a property is found, the contents of the element are used for the value.

There are several exceptions to accomodate [http://microformats.org/wiki/hcard#Semantic_XHTML_Design_Principles semantic XHTML and more semantic equivalents].

For the "email" property in particular, when the element is:
* <code><a href="mailto:..."></code> : use the value of the 'href' attribute, omitting the "mailto:" prefix and any "?" query suffix (if present), in the attribute.

For properties that may take type URL or URI, parsers MUST handle relative URLs and normalize them to their respective absolute URLs, following the containing document's language's rules for resolving relative URLs (e.g. <base> for HTML, xml:base for XML). In addition, when the element for that property is:
* <code><a href></code> : use the value of the 'href' attribute.
* <code><img src></code> : use the value of the 'src' attribute. If the 'src' is a "data:" URL, use the MIME type in that "data:" URL for the TYPE subproperty, otherwise if the the 'type' attribute is present, us that for the TYPE subproperty.
* <code><object data></code> : use the value of the 'data' attribute for the value.If the 'data' is a "data:" URL, use the MIME type in that "data:" URL for the TYPE subproperty, otherwise if the the 'type' attribute is present, us that for the TYPE subproperty.

For properties with values NOT of type URL or URI, when the element for a property is:
* <code><img alt></code> : use the value of the 'alt' attribute.

For all properties, when the element for a property is:
* <code><abbr></code>: use the value of the 'title' attribute.
** For properties which take an ISO8601 datetime value, parsers *should* pad any necessary precision (e.g. seconds), and *should* normalize any datetimes with timezone offsets, (e.g. <code>20050814T2305-0700</code>) into UTC (<code>20050815T060500Z</code>).

For all properties, if the element for a property has one or more children with a class name of "value", then concatenate the node values for all those child elements with class name of "value" in their document order, and use that concatenation as the value of the property.

==== white-space handling ====

hCard parsers should handle white-space parsing per XML white-space handling rules, with the following two additions:

# <code><pre></code> handling. Any content parsed as part of an hCard property that is inside a <pre> element must preserve all white-space per XML white-space preservation rules.
# <code><br /></code> handling. Any occurance of a <code><br /></code> inside the element(s) for a value must be treated as a carriage-return (\n) in the respective location in the value.

=== hCard sub-properties ===

There are some hCard properties whose values themselves have structure (AKA structured type value) and are composed of multiple pieces, which we refer to as sub-properties.

For example, the "n" property consists of the sub-properties "family-name", "given-name", "additional-name", "honorific-prefix", and "honorific-suffix".

E.g. from section 3.1.2 of RFC 2426, modified to include Ph.D.

<pre>
N:Public;John;Quinlan;Mr.;Esq.,Ph.D.
</pre>

In hCard this "n" property would be marked up as

<pre>
<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 class="honorific-suffix">Ph.D.</span>
</span>
</pre>

Which would be rendered as:

Mr. John Quinlan Public, Esq., Ph.D.

=== hCard property parameters ===

Some hCard properties have one or more parameters, most often "type", with an enumerated set of values. We represent the specific ''value'' of the parameter as a class name on an element inside the element representing the property.

For example, the "adr" property has a type parameter which takes the values: "dom", "intl", "post", "parcel", "home", "work", "pref".

The "type" parameter is treated like a sub-property.

To encode the "type" of an "adr" property, a nested element with class="type" is used to markup the value of the type parameter.

Example with the "tel" property with a value of type "work":

<pre>
<span class="tel">
<span class="type">work</span>:
<span class="value">+1.123.456.7890</span>
</span>
</pre>

=== Value excerpting ===

Note the element with class="value" used in the above example.

Sometimes only part of an element which is the equivalent for a property should be used for the value of the property. This typically occurs when a property has a subtype, like TEL. For this purpose, the special class name "value" is introduced to excerpt out the subset of the element that is the value of the property.

== Proposed Additions ==
These are proposed additions to hCard parsing. Implementations MAY follow these conventions in order to gain implementation experience, and SHOULD report back on the results.

=== DEL element handling ===

When dealing with an HTML document that is hCard encoded, the parser SHOULD honor the <code><del></code> element.

There are two possibilities here (adopting both may be possible):

1. Skip any occurences of <code><del></code> elements and their contents entirely inside the contents of a property.

2. If the <code><del></code> element is used for a property itself, it could be useful as a way communication the of tombstoning / obsoleting of that particular property value, and thus while a parser that is converting to a vCard SHOULD simply do what is indicated in (1), applications which parsed hCard directly (rather than only supporting vCard) COULD treat such occurences of <code><del></code> elements as a way to remove obsolete information (with user confirmation of course) from a local contact information store.

=== Plain Text Formatting of Structural/Semantic HTML ===
There are several structural/semantic elements in HTML which have useful default styling which could be converted into ASCII (AKA Plain Text) equivalents as a low resolution way of communicating that structure. Note that <code><br /></code> and <code><pre></code> are already handled in the section above titled [http://microformats.org/wiki/hcard-parsing#white-space_handling White-space Handling].

When parsing the DESCRIPTION property, hierarchically convert the following HTML tags into their plain text styling equivalents.

* <code><div></code>, <code></div></code>, <code><dl></code>, <code></dl></code>, <code><dt></code>, <code></li></code>, <code></dd></code> - Append a soft <code>\n</code> to the output. By "soft <code>\n</code>", we mean only do so if there isn't already a line break (in contrast to a "hard" (implied by default) <code>\n</code>). Two things in particular order to ensure that <code><div> <div></code> does not result in two <code>\n</code> characters in a row:
*# only output the <code>\n</code> if something other than whitespace (including <code>\n</code>) was outputted immediately previously.
*# omit any immediately subsequent whitespace characters.
* <code><li></code> - Append a soft <code>\n</code> and then </code> * </code>. (Note: Indenting the contents of the list item is not particularly practical, since that would require line-breaking, and that would depend on knowing the width of when the plain text is rendered. Wrapping to 70 characters may be a good assumption for plain text email, but is probably a very bad assumption for vCard output).
* <code></dt></code> - Append <code>:\n</code>
* <code><dd></code> - Append a soft <code>\n</code> and then </code> </code> (two space ASCII 32 characters).
* <code><h1></code>, <code></h1></code>, <code><h2></code>, <code></h2></code>, <code><h3></code>, <code></h3></code>, <code><h4></code>, <code></h4></code>, <code><h5></code>, <code></h5></code>, <code><h6></code>, <code></h6></code> - Append a soft <code>\n</code> followed by a hard <code>\n</code>. (Note: we may want to consider some conventions to indicate the heading level. Perhaps only the relative heading level inside the property matters, e.g. whatever level HTML heading is seen first is treated as a first level heading, then any subsequent HTML heading elements are treated relative to that original heading (this is because it is likely that the property is embedded somewhere deep inside an HTML document following higher heading levels). Any subsequent higher level headings should perhaps cause a warning, and then simply be treated as a first level heading. Given that, the [http://microformats.org/wiki/wiki-formats#straw_proposals straw proposal for heading syntax] from Ian Hickson is one reasonable possibility, with the only issue being that for first and second level headings, how wide to make the line of '-'s or '='s, which is a similar problem to the line-breaking problem noted above when considering indenting the contents of list-items. Thus perhaps it might be sufficient to simply set a first level heading in ALL CAPS (same as the third level heading in Ian's proposed syntax), and let second and deeper level headings be simply implied by the "one line of text with two line breaks both before and after" convention. Rarely has there been more than one level of heading found within a DESCRIPTION property, and I've never seen more than two even if it is possible.)
* <code><p></code>, <code></p></code> - Append a soft <code>\n</code> followed by a hard <code>\n</code>. (Note: Typical books indent the start of a paragraph approximately three spaces "<code> </code>", and implementations may wish to consider doing so as well. Keep in mind that on the Web, typical paragraphs do not start with a first line indent.)
* <code><q></code>, <code></q></code> - Append a double-quote '"' character.
* <code><sub></code> - Append an open parenthesis "("
* <code></sub></code> - Append a a close parenthesis ")".
* <code><sup></code> - Append an open bracket "["
* <code></sup></code> - Append a a close bracket "[". <code><sup></code> are often used for footnotes which in plain text are often formatted as bracketed numbers.
* <code><table></code>, <code></table></code>, <code><tbodygt;</code>, <code></tbody></code>, <code><thead></code>, <code></thead></code>, <code><tfoot></code>, <code></tfoot></code>, <code><tr></code>, <code></tr></code>, <code><caption></code>, <code></caption></code> - Append a soft <code>\n</code>. Of course one could try to do a lot more with representing the structure of the table, but that is almost certainly more work than it is worth, nevermind the complexities introduced by COLSPAN, ROWSPAN etc. At least by approximating the table sections and rows the table may be more readable.
* <code></td></code>, <code></th></code> - Append a space and a tab character (ASCII 32, ASCII 9 respectively). It's not clear that what subsequent application would be able to make use of this visually, but at least the tabular nature of the structure is indicated and it makes it possible to copy and paste the table into something that handles tabular content like a spreadsheet and have the tabular structure reflected.

==== More challenging elements ====
* <code><ol></code> - it would be nice to number list items inside an ordered list rather than bullet them, but keeping track of list item numbers/counts is a non-trivial piece of state information for the parser to deal with, and thus we are omitting this behavior for now.

==== Use of CSS computed styles instead of HTML default styles ====
Rather than assuming the default presentation for these elements, and using that for the basis of plain text formatting, a parser could use the respective equivalent computed style properties and use those instead. However, requiring an hCard parser to also implement Cascading Style Sheets (e.g. CSS1) is out of scope. Some environments (i.e. a browser DOM) may already provide this information, and in that case, it may be easy for an hCard parser (e.g. a clientside javascript parser) to use computed style properties. E.g. instead of the elements above, the following computed styles could be used:
* display:block - Append a soft <code>\n</code>
** text-indent (non-zero value, on an element with display:block or display:list-item) - Append a number of spaces equivalent to value of the text-ident property divided by the computed font-size property of the element.
** margin-top, margin-bottom (non-zero value, on an element with display:block or display:list-item) - Append a number of "\n" equivalent to the value divided by the computed font-size property of the element. Obviously this won't properly collapse vertical margins.
* display:list-item - Append a soft <code>\n</code> followed by " * "
* etc.
This is enough extra work that I'm not sure it is worth spending the time documenting more equivalents. The above are sufficient to illustrate the possibility.

== Outstanding Issues ==

=== Issues 3 ===

Might be worth considering defining the parsing in terms of the DOM, so that it applies to HTML and XHTML equally without ambiguity.

== Resolved Issues ==

This section is informative.

The following issues have been explored and resolved

=== Resolved as of 2005-09-16 ===

==== ISSUE 1 ====

Should we make plural sub-property names into singular versions and simply allow multiple instances? I.e. the singular honorific prefix would make more sense if it was classed as such, and the list implied by the value for honorific-suffixes could be made more explicit (and thus more easily machine parseable):

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

RESOLUTION: Adopt singular class name equivalents for plural property and sub-property names.

==== ISSUE 2 ====

Restricting the "type" sub-property values to being expressed in class names seems less than ideal. It's taking a piece of information which is very often visible in the content, and forcing it to be invisible.

Here is an example of an extensive bit of contact information on a web page:

http://www.patchlink.com/company/contact.html

<pre>
Maiilng Address
3370 N. Hayden Road, #123-175
Scottsdale, AZ 85251-6632

Physical Address
8515 E Anderson
Scottsdale, AZ 85255
</pre>

Note that the type information for each "adr" is explicit in the content. This content could be marked up like this:

<pre>
<div class="adr">
<abbr style="display:block" class="type" title="postal,parcel">Mailing Address</abbr>
<div class="street-address">3370 N. Hayden Road, #123-175</div>
<span class="locality">Scottsdale</span>, <span class="region">AZ</span>
<span class="postal-code">85251-6632</span>
</div>
<div class="adr">
<abbr style="display:block" class="type" title="work,pref">Physical Address</abbr>
<div class="street-address">8515 E Anderson</div>
<span class="locality">Scottsdale</span>, <span class="region">AZ</span>
<span class="postal-code">85255</span>
</div>
</pre>

RESOLUTION: The "type" parameter MUST be marked-up when content is available (like the above two examples). We are ditching the type-value-as-another class name pattern.

In addition since there are some potentical problems with the "type" parameter for TEL and EMAIL properties. Since there are no defined sub-properties (unlike ADR's post-code, locality, etc) the entire node-value of TEL is taken as the value. For example:
<pre>
<span class="tel">+1.123.456.7890 <abbr class="type" title="work">(work)</abbr></span>
</pre>
would be represented in vCard as:
<pre>
TEL;TYPE=work:+123.456.7890 (work)
</pre>

We are introducing another sub-property class="value" to enable excerpting of a the value of an element of for a property.

<pre>
<span class="tel"><span class="value">+1.123.456.7890</span> <abbr class="type" title="work">(work)</abbr></span>
</pre>

Then parsers would first need to look for class="value" and take the node value of that if it exists rather than class="tel".

If one or more child elements with the class name of "value" are present inside the element for a property, then concatenate the node values of those child elements (in the order found) and use that as the value of the property. This would be before using the node value of the element for a property itself.

== References ==

=== Normative References ===
* [[hcard|hCard]]
* vCard (RFC 2426)
* [http://w3.org/TR/XHTML1 XHTML 1.0 Recommendation]
* [http://w3.org/TR/html401 HTML 4.01 Recommendation]
* [http://gmpg.org/xmdp/ XMDP]

=== Informative References ===
* [http://w3.org/TR/REC-CSS1 CSS1 Recommendation]