Microformats Wiki - User contributions [en]

User:RobManson

2008-12-05T05:59:45Z

RobManson: Just an update to test editing bug is fixed

<div class="vcard">
<span class="fn n">
<span class="given-name">Rob</span>
<span class="family-name">Manson</span>
</span>
<div><span class="org">Mobile Online Business</span></div>
<div><span class="url">http://MobileOnlineBusiness.com.au</span></div>
<div><span class="url">http://SOAPjr.org</span></div>
<div><span class="url">http://paymentz.com.au</span></div>
<div>Address:<span class="adr"><span class="type">postal</span>:<div class="street-address addressField">P.O. Box 1174,</div><span class="locality addressField">Sydney</span><span class="region">NSW</span><span class="postal-code">1355,</span><div class="country-name addressField">Australia</div></span></div>
</div>

{{public-domain-release}}

old-json-serializations

2008-11-30T05:29:17Z

RobManson: /* References */ Added references to JSON-Schema and SOAPjr's DMD's

<div style="float:right;margin-left:1em">__TOC__</div>

= Standardised microformats representation in JSON - ufJSON =

==Introduction==

Although the microformat design process did not originally have the concept of an output format, there are times when this would be useful. As parsers mature, we need an easy way to support the interchange and integration of data. Not just for parsers, but also for the applications that use them. A standard output format should encourage a greater culture of reuse and sharing between developers and help collaborative projects such as the building of shared test suites and other tools. JSON is well placed to be the foundations of that common data format. It works equally as well within client-side applications and server-side development languages.

This specification should be considered a draft. Contents are subject to change. It is provided here for reference and as a basis for discussion on the mailing list. This work in some ways extends the efforts around jCard, which had some of the same aims but was only focussed on hCard.
'

==Authoring rules==

'''Follow the logical structure of the microformat'''
* The structure of the JSON should follow the logical structure of the microformat in regard to nesting elements.
<pre>// Correct
"fn" : "John Doe",
"n" : {
"given-name" : ["John"],
"family-name" : ["Doe"]
}

// Wrong - In hCard given-name is always a child of n
"fn" : "John Doe",
"given-name" : ["John"],
"family-name" : ["Doe"]
</pre>

'''Use the same property names as microformat equivalents'''
* All property names must be consistent with their equivalent microformat name. They should '''not''' be camel cased.
* All property names must be enclosed with double quotes to allow hyphenated properties.
** This is a JSON syntax rule anyway - do we need to restate it?

<pre>// Correct
"fn" : "John Doe",
"n" : {
"given-name" : ["John"],
"family-name" : ["Doe"]
}

// Wrong - givenName has been camel cased, it should be given-name
"fn" : "John Doe",
"n" : {
"givenName" : ["John"],
"familyName" : ["Doe"]
}
</pre>

'''Always use arrays for properties which can have multiple values'''
* Where the microformat specification allows a property to have multiple values always use an array even if only one value exists.

<pre>
// Correct
"nickname" : ["lostboy", "man with no name"],
url" : [ "http:\/\/www.joeblogs.com\/" ]

// Wrong - both nickname and url can have multiple values.
"nickname" : "lostboy",
"url" : "http:\/\/www.joeblogs.com\/"
</pre>

'''Properties that are not set must be omitted'''
<pre> // Wrong
"email" : [],
"bday" : ""
</pre>

'''Escape JSON where needed'''
* Escape JSON values where needed.
* This is a http://json.org syntax rule
** In JSON only the backslash, double quote and ASCII control characters need to be escaped. Forward slashes may be escaped as in the URL example below, but do not have to be.

<pre>
// Correct
"note" : [ "My current job title is \"Interactive Designer\"" ]

// Wrong
"note" : [ "My current job title is "Interactive Designer"" ]

// Optional
"url" : [ "http:\/\/www.joeblogs.com\/" ]
</pre>

==Authoring rules that need discussion==
There are a number of areas where there is no logical structure and naming convention to follow. This has caused the largest difference in data representation.

'''Representing XFN'''

XFN causes some major issues in terms of the differences in data representation. The Operator data structure would seem to be the most compact and less ambiguous.

<p><strong>Option for representation XFN</strong></p>
<pre>{ "xfn": [{
"friend": "true",
"met": "true",
"link": "http:\/\/hackdaylondon07.backnetwork.com\/people\/person.aspx?personid=684",
"text": "Andy Budd"
}]
</pre>

'''Representing rel-tag'''

There is a closer match between data structure to represent rel-tag. Because the value of a tag comes from the last fragment of the URL. It would be useful to include both a tag and text property in case they differ.

<p><strong>Option for representation rel-tag</strong></p>
<pre>{ "rel-tag": [{
"tag": "hackday",
"text": "hackday",
"link": "http:\/\/technorati.com\/tags\/hackday"
}]
</pre>

==Envelope structure==
When navigating data from different applications it is useful to make the path
of navigation consistent. The envelope structure provides a consistent start
point for navigating the microformat data as well as providing an area for
metadata. As a number of parsers and applications can process multiple formats
at once the envelope starts with an array called microformats. It then contains
individual arrays of each format request/supported.

There are two types of optional top level metadata. The first is parser-information,
it contains information about the parser used and the document parsed. The
second is an errors array, which when needed is populated with error messages.
Each individual microformat data set can also have an optionally attached array
of error messages where it is appropriate.

A new proposal that also addresses this area is [http://SOAPjr.org SOAPjr] - a hybrid of [http://en.wikipedia.org/wiki/SOAP_(protocol) SOAP] and [http://en.wikipedia.org/wiki/JSON-RPC JR (JSON-RPC)]. This adapts the SOAP/MIME Envelope/Head/Body separation into JSON.

<pre>
microformats
vcard
...
errors
xfn
...
errors
parser-information
name
version
page-http-status
page-title
page-url
time
errors
</pre>

===Envelope properties===

'''microformats'''<br/>
An array of request/supported formats. Each array item should contain a property. The name of the property should be the name of the microformat. If the microformat has a root class name that should be used i.e. "vcard" else use the name from community wiki i.e. "xfn".

'''parser-information'''<br/>
Is an array of optional properties about the parser used and the document parsed

'''name'''<br/>
The parser of the application used to create the JSON

'''version'''<br/>
A string that represents the application version number i.e. "version 2" or "2.0"

'''page-http-status'''<br/>
The HTTP status number from the request page that was parsed. i.e. "200" or "404"

'''page-title'''<br/>
The HTML page title from the request page that was parsed

''page-url'''<br/>
The full URL of the request page that was parsed

'''time'''<br/>
The time taken to parse the page. Uses the ISO 8601 millisecond time format i.e. T000000.0087 is 87 milliseconds

'''errors'''<br/>
Is an optional array of string error messages.

===Envelope examples===

'''Example JSON output ( single hCard )'''
<pre>{
"microformats": {
"vcard": [{
"fn": "John Doe",
"n": {
"given-name": "John",
"family-name": "Doe"
},
"url": ["http:\/\/www.johndoe.com\/"]
}]
},
"parser-information": {
"name": "UfXtract",
"version": "0.1",
"page-http-status": "200",
"page-title": "hcard1";
"page-url": "http:\/\/ufxtract.com\/testsuite\/hcard\/1.0\/hcard1.htm";
"time": "T000000.0098"
}
}
</pre>

'''Example JSON output ( minimal structure, more likely from a client-side parser )'''
<pre>{
"microformats": {
"vcard": [{
"fn": "John Doe",
"n": {
"given-name": "John",
"family-name": "Doe"
},
"url": ["http:\/\/www.johndoe.com\/"]
}]
},
"parser-information": {
"name": "UfXtract",
"version": "0.1",
"page-title": "hcard1"
}
}
</pre>

'''Example JSON output of microformat level error'''
<pre>{
"microformats": {
"vcard": [{
"n": {
"given-name": "John",
"family-name": "Doe"
},
"url": ["http:\/\/www.johndoe.com\/"],
"errors": [ "hCard does not contain the required fn property." ],
}]

},
"parser-information": {
"name": "UfXtract",
"version": "0.1",
"page-http-status": "200",
"page-title": "hcard1";
"page-url": "http:\/\/ufxtract.com\/testsuite\/hcard\/1.0\/nofilehere.htm";
"time": "T000001.0002"
}

}
</pre>

'''Example JSON output of a parser/page level error'''
<pre>{
"microformats": {
"vcard": []
},
"parser-information": {
"name": "UfXtract",
"version": "0.1",
"page-http-status": "404",
"page-title": "hcard1";
"page-url": "http:\/\/ufxtract.com\/testsuite\/hcard\/1.0\/nofilehere.htm";
"time": "T000001.0002"
},
"errors": [ "URL not found" ]
}
</pre>

==References==

*[http://www.json.org www.json.org]: the original specification, documentation, and list of implementations for many different programming languages.
*RFC 4627, current formal JSON specification.
*[http://en.wikipedia.org/wiki/JSON JSON on Wikipedia]
*[http://json-schema.org/ JSON-Schema Proposal]
*[http://soapjr.org/specs.html#dmd SOAPjr's Common DMD's (Data Model Definitions)]

old-json-serializations

2008-11-30T05:27:01Z

RobManson: /* Envelope structure */ Added reference to the SOAPjr - a hybrid of SOAP and JR (JSON-RPC)

governance-issues

2008-03-11T23:36:01Z

RobManson: /* Petition */

== Issue Summary 2007-02-28 ==
=== Editor ===
[http://www.opendarwin.org/~drernie/ Ernest Prabhakar]

=== Contributors ===
*[[User:AndyMabbett|Andy Mabbett]]
* Joe Andrieu
* Phae
* Ryan Cannon
* Colin Barrett
* ... Please add yourself.

== Preamble ==
Over the last year, a few people (AndyMabbett, JoeAndrieu, ErnestPrabhakar, JamesCraig, [[User:ManuSporny|ManuSporny]]) have raised issues about how the Microformats wiki, mailing list, and community are governed. This page is here to discuss ideas for documenting, formalizing, and/or improving our collective governance.

== Abstract ==
Governance has [http://www.phac-aspc.gc.ca/vs-sb/voluntarysector/glossary.html been defined] as "the traditions, institutions and processes that determine how power is exercised, how citizens are given a voice, and how decisions are made on issues of public concern." In the context of Microformats, it covers:
* Rules (both written and unwritten) expected of community members
* Formal process for change requests for known format problems (i.e. abbr-design-pattern) by voting, with leeway for admin vetoes.
* Who the various Admins are
* What powers Admins have
* Rules for how/when Admins can/should use those powers
* How to questioning/appealing a decision by an Admin
* How to become an Admin
* How to question/change any of these

While not all of these need to be explicitly spelled out, a healthy community our size requires a broad shared understanding of these facts -- as well as acceptance of them as "legitimate."

== Who Are Admins ==
* 2007-01-04 raised by [[User:DrErnie|DrErnie]] on [[microformats-issues]], before this page existed, and moved from there
*# ''As discussed in [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008011.html], there exist various concerns about the lack of clarity regarding governance of the list, wiki, and the specifications themselves. While agree that there does need to be some form of strong leadership to preserve the integrity of the community, I agree with [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008022.html Colin Barrett] when he said:''
:::"I think there should be bit more visible superstructure around just who is in this "cabal". It seems to me like the Editors/Authors of the various specs form the majority it of it, but perhaps that should be made a bit more apparent, and the "powers" of an editor (essentially, the ability to veto changes to the wiki, it seems) outlined a bit and some information about how to become an editor (AFIACT, make numerous, quality edits to the Wiki that the other editors approve of)."
:An entry has been added to the FAQ regarding [http://microformats.org/wiki/faq#Q:_Who_controls_microformats.3F Who controls microformats?].[[User:DrErnie|Dr. Ernie]] 08:48, 2 Feb 2007 (PST)

== Mailing List Unmoderation Discussion ==
Discussion from [[mailing-list-unmoderation]].

* I'm glad to see this issue getting traction. However, I'm curious why Ernie's standing in the community is relevant to the issue of unmoderating Andy. Tantek, could you explain why that has been presented as an integral part of this decision making process? Clearly, personal clout always shapes one's ability to influence the community; however, I doubt it should be officially incorporated in these "proceedings". Shouldn't every member of the community have an equal hearing under whatever governance procedures we use? [[User:JoeAndrieu|JoeAndrieu]] 09:38, 19 Mar 2007 (PDT)

:[http://microformats.org/discuss/mail/microformats-discuss/2007-March/009066.html Tantek also said]: "''Ernie, as someone who has made overwhelmingly positive contributions to the microformats community, IMHO the occasional OT post is reasonable'".
* I believe the statement was added to give context to the appealing member of the community. i.e. Ernie is a long standing, good contributor, as opposed to someone new who has no experience with this particular community or someone who has had little or no interaction with the community until now, and also negates it being a personal statement (rather he is interested in community as a whole, instead of being a friend of the Andy and having a personal goal, for example). Basically, he is a person with a certain amount of credibility and trustworthiness. [[User:Phae|Phae]] 10:25, 19 Mar 2007 (PDT)
* Agreed, Phae, Ernie is such a person and that is Tantek's point. But should one need to be a "friend of the court" to bring an action? That practice reinforces a culture of privilege that has historically proven antithetical to transparency and equality, both characteristics of good governance, IMO. It is great to see the powers-that-be responding to Ernie's request. It is also a bit frustrating that only those deemed meritorious by the peerage can call forth due process and that Andy's own efforts to speak on his behalf--referencing my previous request to do the same--were summarily dismissed by Tantek because they were "adversarial." Any robust governance should, IMO, work independent of privilege and be capable of addressing adversarial situations without arbitrary limits on the speech of those whose liberties are under challenge.--[[User:JoeAndrieu|JoeAndrieu]] 14:18, 19 Mar 2007 (PDT)
** Point taken and appreciated, but this is the first incident to come to this kind of a situation where someone else has felt the need to step in, and just happened to also involve someone that is felt to be a member of good standing. I'd like to hope that if another member of the community had felt a similar way and had chosen to bring it up, that it would also have been dealt with in this open manner (and I'm sure this incident will be brought up in the future). Hopefully this incident will be a good test case to better structure future interactions with administration. I can't personally comment on Andy's own appeals. [[User:Phae|Phae]] 14:45, 19 Mar 2007 (PDT)
**Agreed. The first efforts to work through a process like this are bound to be less than ideal. However, I'd like to get on the record two main points that appear problematic.
# [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008490.html my previous request to do the same] was not, in fact, dealt with in this open manner. Rather it decayed into a defensive debate about governance generally, leaving poor Andy stuck in moderated censure. Perhaps I'm not the most diplomatic sort, but the issue on the table is not about me. It is about Andy's continuing moderation.
# The [[mailing-list-unmoderation|unmoderation wiki page]] for Andy is effectively a public hearing on Andy's standing and privileges in the community, especially with [http://microformats.org/discuss/mail/microformats-discuss/2007-March/009066.html Tantek's request] that no replies be sent to the email list on the topic. I find it particularly disturbing that Andy's efforts to contribute to that hearing have been [http://microformats.org/wiki?title=mailing-list-unmoderation&diff=14419&oldid=14416 repeatedly] [http://microformats.org/wiki?title=mailing-list-unmoderation&diff=14456&oldid=14454 dismissed] by Tantek (see the [http://microformats.org/wiki?title=mailing-list-unmoderation&action=history history] for a complete list). While It probably wasn't the best form for Andy to edit my comment directly, he should, IMO, have a way to voice his opinion on the matter. He's been threatened with a ban if he does so on the mailing list. Is there another venue that is more appropriate than the wiki page taking input and votes on his unmoderation?--[[User:JoeAndrieu|JoeAndrieu]] 20:19, 19 Mar 2007 (PDT)
* Shouldn't this point be moot? According to the terms of the moderation, it will be lifted "if he successfully sends only topical / positive / improving email to the lists for one week." Once the week passed, this moderation ought to have been lifted automatically, and should not require a vote, right? --[[User:RCanine|Ryan Cannon]]
** At least one message was rejected during that first week, thus moderation was left as is, with the attention of the admins etc. focused on other higher priority matters. Given the higher quality of messages *with* moderation (as compared to before), some have made the statement that moderation is "working" and thus should be kept. [[User:Tantek|Tantek]] 08:58, 22 Mar 2007 (PDT)
* I dislike moderation because I find it causes me to be hesitant with my own contributions in some cases. Since I don't often know how long a message has been queued its hard for me to judge if my reply would be helpful, or if the moderated poster has already moved along with the rest of the discussion so I err on the side of moving onto something else. doesn't hurt me, but I feel sometimes it might not help with the overall discussions depth or conclusion. . Thus, I think the burden should be heavy to continue moderation for any length of time without a decision to unmoderate or outright ban. [[User:ChrisCasciano|ChrisCasciano]] 11:40, 23 Mar 2007 (ET)

== Examples ==
''Note: This is not to take a position on whether or not any of these decisions were appropriate or inappropriate. Rather, the existence of these events demonstrates the need to document why and how such decisions were -- or should be -- made and/or appealed.''

* Labelling microformats schema discussions as [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003551.html off-topic]
** Already covered by the [[microformats]] principles.
* Issue rejection [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008864.html governance]
* Negative, PoV and derogatory edit summary content such as "[http://microformats.org/wiki?title=hcard-authoring&diff=13621&oldid=12276#Add_To_Address_Book_Links smelled of excessive political correctness worrying]" and "[http://microformats.org/wiki?title=to-do&curid=1110&diff=13989&oldid=13988&rcid=23801 removed non-productive comment]".
** Removal of negative content from the wiki is not a negative. The Admins use their best judgment.
*[[rejected-formats#Pavatar|listing of items as "rejected"]] when [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008271.html requests for evidence of said rejection] reveal none.
** Not every email can be answered, nor should anyone expect them to be. In this case the rejection is in the mailing list archives.
* Despite an assurance that "all of the admins will be apropriately (sic) listed on the wiki page [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008526.html]", the [http://microformats.org/wiki/faq#Q:_Who_controls_microformats.3F list given in FAQ] is prefaced with the qualifier "including".
** Reference for assurance? No such assurance should ever have been given.
* Removal of disputed edits / removal of negative content from the wiki
**[http://microformats.org/wiki?title=mailing-list-unmoderation&diff=next&oldid=14416 mailing-list-unmoderation (16:12, 19 Mar 2007)]
**[http://microformats.org/wiki?title=governance&curid=3084&diff=0&oldid=14390&rcid=24255 governance (12:50, 19 Mar 2007)]
** [http://microformats.org/wiki?title=governance-issues&diff=14401&oldid=14396 governance-issues (14:55, 19 Mar 2007)]
**[http://microformats.org/wiki?title=mailing-lists&curid=1297&diff=14391&oldid=14389&rcid=24254 mailing-lists (12:42, 19 Mar 2007)]

== Proposal ==

# Create a publicly-visible ''microformats-admin'' mailing list, for easily identifying and contacting all admins
# Document a forum/mechanism/process where individuals concerned about admin actions can legitimately raise their concerns, to ensure substantive issues are addressed
# Maintain a [[governance]] page that captures and describes
## the identity of current Admins
## how to contact them
## the process for becoming an Admin
## the specific kinds of behavior warranting Admin intervention
## how/when suspended/moderated individuals can return to "good standing"
## how to appeal an Admin decision/action

== Petition ==

We acknowledge that the microformats list and wiki is not a democracy, and that one of the key goals of microformats is to have as little process and structure as possible. However, at the same time we believe that the "dictatorship" needs to not merely ''be'', but ''be seen as'' "benevolent." This includes some minimal level of transparency and due process to ensure that there are legitimate ways for ordinary members to speak out if they feel (rightly or wrongly) that a particular administrative action was unwise or unfair. Whether that is similar to the '''[[#Proposal]]''' above, or a counter-proposal by the ''admin'' team, we believe that something is necessary.
:''Please add your vote here''
*+1 Ernest Prabhakar
*+1 Joe Andrieu
*+1 James Craig
*+1 Steve Robillard
*+1 Chris Messina
*+1 [[User:ManuSporny|ManuSporny]] 08:59, 3 Aug 2007 (PDT)
*+1 Ben Buchanan
*+1 [[User:EatYourGreens|Jim O'Donnell]]
*+1 [[User:Csarven|Sarven Capadisli]]
*+1 [[User:TobyInk|TobyInk]]
*+1 [[User:JohnAllsopp|John Allsopp]]
*+1 [[User:TomMorris|Tom Morris]] - I do not think the current admins are doing a bad job, but would appreciate greater transparency by providing clear reasons for all administrative actions. I also think that unless group administration is transparent, Bad Things Can Happen.
*+1 [[User:JeffMcNeill|Jeff McNeill]]
*+1 [[User:RobManson|Rob Manson]]

== Resources ==

* [http://www.shirky.com/writings/group_enemy.html Clay Shirky] on a group as its own worst enemy
* [http://www.informationweek.com/news/showArticle.jhtml?articleID=199600005 Cory Doctorow] on Internet Jerks

semantic-html

2007-07-24T14:05:59Z

RobManson: Removed comment tag to focus this list on display-able things

<h1> Semantic (X)HTML </h1>

Semantic (X)HTML refers to:
# The semantic elements and attributes of (X)HTML (as opposed to the [[presentational-html|presentational HTML]] elements and attributes)
# (X)HTML documents that are written using semantic (X)HTML.
# The practice of writing semantic (X)HTML
# [[posh|plain old semantic HTML]]

__TOC__

== Contributors ==
* [http://tantek.com/ Tantek]
* [[User:AndyMabbett|Andy Mabbett]]
* [[User:RobManson|Rob Manson]]

== Semantic Elements ==

(This list is incomplete, please add!)

* a
* abbr
* acronym
* address
* blockquote
* button
* caption
* cite
* code
* del
* dfn
* dl
** dt
** dd
* em
* fieldset
** legend
* form
* h1,h2,h3,h4,h5,h6
* input
* ins
* img
** map
*** area
* kbd
* li
* link
* label
* legend
* ol
* p
* pre
* q
* samp
* select
** optgroup
** option
* strong
* sub
* sup
* table (when used for tabular data, not layout)
** tbody
** td
** tfoot
** th
** thead
** tr
* textarea
* tt
* ul
* var

== Semantic Attributes ==

(This list is incomplete, please add!)

* caption
* class
* data
* href
* hreflang
* id
* lang
* rel
* rev
* scope
* summary
* type

== Presentations ==
See [[posh#POSH_Presentations|POSH Presentations]].

== See also ==
* [[semantic-xhtml-design-principles]]
* [[semantic-class-names]]

== References ==
* [http://w3.org/TR/xhtml1 XHTML 1.0]
* [http://w3.org/TR/html401 HTML 4.01]

semantic-html

2007-07-24T13:26:55Z

RobManson: Added myself as a contributor

<h1> Semantic (X)HTML </h1>

Semantic (X)HTML refers to:
# The semantic elements and attributes of (X)HTML (as opposed to the [[presentational-html|presentational HTML]] elements and attributes)
# (X)HTML documents that are written using semantic (X)HTML.
# The practice of writing semantic (X)HTML
# [[posh|plain old semantic HTML]]

__TOC__

== Contributors ==
* [http://tantek.com/ Tantek]
* [[User:AndyMabbett|Andy Mabbett]]
* [[User:RobManson|Rob Manson]]

== Semantic Elements ==

(This list is incomplete, please add!)

*  (comment)
* a
* abbr
* acronym
* address
* blockquote
* button
* caption
* cite
* code
* del
* dfn
* dl
** dt
** dd
* em
* fieldset
** legend
* form
* h1,h2,h3,h4,h5,h6
* input
* ins
* img
** map
*** area
* kbd
* li
* link
* label
* legend
* ol
* p
* pre
* q
* samp
* select
** optgroup
** option
* strong
* sub
* sup
* table (when used for tabular data, not layout)
** tbody
** td
** tfoot
** th
** thead
** tr
* textarea
* tt
* ul
* var

== Semantic Attributes ==

(This list is incomplete, please add!)

* caption
* class
* data
* href
* hreflang
* id
* lang
* rel
* rev
* scope
* summary
* type

== Presentations ==
See [[posh#POSH_Presentations|POSH Presentations]].

== See also ==
* [[semantic-xhtml-design-principles]]
* [[semantic-class-names]]

== References ==
* [http://w3.org/TR/xhtml1 XHTML 1.0]
* [http://w3.org/TR/html401 HTML 4.01]

semantic-html

2007-07-24T13:26:02Z

RobManson: Added some missing elements

<h1> Semantic (X)HTML </h1>

Semantic (X)HTML refers to:
# The semantic elements and attributes of (X)HTML (as opposed to the [[presentational-html|presentational HTML]] elements and attributes)
# (X)HTML documents that are written using semantic (X)HTML.
# The practice of writing semantic (X)HTML
# [[posh|plain old semantic HTML]]

__TOC__

== Contributors ==
* [http://tantek.com/ Tantek]
* [[User:AndyMabbett|Andy Mabbett]]

== Semantic Elements ==

(This list is incomplete, please add!)

*  (comment)
* a
* abbr
* acronym
* address
* blockquote
* button
* caption
* cite
* code
* del
* dfn
* dl
** dt
** dd
* em
* fieldset
** legend
* form
* h1,h2,h3,h4,h5,h6
* input
* ins
* img
** map
*** area
* kbd
* li
* link
* label
* legend
* ol
* p
* pre
* q
* samp
* select
** optgroup
** option
* strong
* sub
* sup
* table (when used for tabular data, not layout)
** tbody
** td
** tfoot
** th
** thead
** tr
* textarea
* tt
* ul
* var

== Semantic Attributes ==

(This list is incomplete, please add!)

* caption
* class
* data
* href
* hreflang
* id
* lang
* rel
* rev
* scope
* summary
* type

== Presentations ==
See [[posh#POSH_Presentations|POSH Presentations]].

== See also ==
* [[semantic-xhtml-design-principles]]
* [[semantic-class-names]]

== References ==
* [http://w3.org/TR/xhtml1 XHTML 1.0]
* [http://w3.org/TR/html401 HTML 4.01]

receipt-examples

2007-07-24T02:23:38Z

RobManson: Added external link to example receipt provided by Leif

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bill / Invoice ===

Bills or Invoices are "yet to be paid" items.

Question: Perhaps these examples (yet to be provided) should be moved to a separate page as Bill/Invoice is quite different from Receipt.

: With [[hResume]], I've [[hresume-brainstorming|suggested]] that the subtle difference between actively seeking work and just presenting your resume be a case of including [[hlisting]] markup.
: With bills vs invoices, it may turn out that the content found within would be identical, and it might just be a case of putting in a class flag to indicate whether the presented document has been paid for or not.
: [[User:SignpostMarv|SignpostMarv]] 12:55, 21 Jul 2007 (PDT)

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/receipt/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

==== A1Books ====
[http://mobileonlinebusiness.com.au/uf/receipt/A1Books-Sales-Order-anon.htm Example]

==== Barnes&Noble ====
[http://mobileonlinebusiness.com.au/uf/receipt/BarnesAndNoble.com-receipt.anon.tidied.htm Example]

==== Facebook ====
[http://mobileonlinebusiness.com.au/uf/receipt/Facebook-gift-receipt.html Example]

==== Google Checkout ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Google-Checkout-e-mail-receipt.tidied.html Example email receipt]
*[http://mobileonlinebusiness.com.au/uf/receipt/Google-Checkout-Order-Receipt_DVD-Empire.tidied.htm Example web receipt]

==== iTunes ====
*[http://mobileonlinebusiness.com.au/uf/receipt/iTunes-receipt-e-mail.html iTunes e-mail receipt]

==== Longs/FujiFilm ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Longs-Fujifilm-photo-receipt.html Longs/Fujifilm e-mail receipt]

==== Mobivox/PayPal ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Mobivox-PayPal.htm Mobivox/PayPal receipt]
*[http://mobileonlinebusiness.com.au/uf/receipt/Mobivox-PayPal-printable.htm Mobivox/PayPal printable receipt]

==== Skype ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Skype-order-history.html Skype order history]

Note: Skype only provides receipts in PDF format, not HTML.

==== Symantec ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Symantec-reminder-e-mail.html Symantec e-mail reminder]

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

receipt-examples

2007-07-24T02:22:38Z

RobManson: Added external link to example receipt provided by Leif

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bill / Invoice ===

Bills or Invoices are "yet to be paid" items.

Question: Perhaps these examples (yet to be provided) should be moved to a separate page as Bill/Invoice is quite different from Receipt.

: With [[hResume]], I've [[hresume-brainstorming|suggested]] that the subtle difference between actively seeking work and just presenting your resume be a case of including [[hlisting]] markup.
: With bills vs invoices, it may turn out that the content found within would be identical, and it might just be a case of putting in a class flag to indicate whether the presented document has been paid for or not.
: [[User:SignpostMarv|SignpostMarv]] 12:55, 21 Jul 2007 (PDT)

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/receipt/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

==== A1Books ====
[http://mobileonlinebusiness.com.au/uf/receipt/A1Books-Sales-Order-anon.htm Example]

==== Barnes&Noble ====
[http://mobileonlinebusiness.com.au/uf/receipt/BarnesAndNoble.com-receipt.anon.tidied.htm Example]

==== Facebook ====
[http://mobileonlinebusiness.com.au/uf/receipt/Facebook-gift-receipt.html Example]

==== Google Checkout ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Google-Checkout-e-mail-receipt.tidied.html Example email receipt]
*[http://mobileonlinebusiness.com.au/uf/receipt/Google-Checkout-Order-Receipt_DVD-Empire.tidied.htm Example web receipt]

==== iTunes ====
*[http://mobileonlinebusiness.com.au/uf/receipt/iTunes-receipt-e-mail.html iTunes e-mail receipt]

==== Longs/FujiFilm ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Longs-Fujifilm-photo-receipt.html Longs/Fujifilm e-mail receipt]

==== Mobivox/PayPal ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Mobivox-PayPal.htm Mobivox/PayPal receipt]
*[http://mobileonlinebusiness.com.au/uf/receipt/Mobivox-PayPal-printable.htm Mobivox/PayPal printable receipt]

==== Skype ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Skype-order-history.html Skype order history]

Note: Skype only provides receipts in PDF format, not HTML.

==== Symantec ====
*[Symantec e-mail reminder] (awaiting upload)

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

receipt-examples

2007-07-24T02:21:20Z

RobManson: Added external link to example receipt provided by Leif

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bill / Invoice ===

Bills or Invoices are "yet to be paid" items.

Question: Perhaps these examples (yet to be provided) should be moved to a separate page as Bill/Invoice is quite different from Receipt.

: With [[hResume]], I've [[hresume-brainstorming|suggested]] that the subtle difference between actively seeking work and just presenting your resume be a case of including [[hlisting]] markup.
: With bills vs invoices, it may turn out that the content found within would be identical, and it might just be a case of putting in a class flag to indicate whether the presented document has been paid for or not.
: [[User:SignpostMarv|SignpostMarv]] 12:55, 21 Jul 2007 (PDT)

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/receipt/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

==== A1Books ====
[http://mobileonlinebusiness.com.au/uf/receipt/A1Books-Sales-Order-anon.htm Example]

==== Barnes&Noble ====
[http://mobileonlinebusiness.com.au/uf/receipt/BarnesAndNoble.com-receipt.anon.tidied.htm Example]

==== Facebook ====
[http://mobileonlinebusiness.com.au/uf/receipt/Facebook-gift-receipt.html Example]

==== Google Checkout ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Google-Checkout-e-mail-receipt.tidied.html Example email receipt]
*[http://mobileonlinebusiness.com.au/uf/receipt/Google-Checkout-Order-Receipt_DVD-Empire.tidied.htm Example web receipt]

==== iTunes ====
*[http://mobileonlinebusiness.com.au/uf/receipt/iTunes-receipt-e-mail.html iTunes e-mail receipt]

==== Longs/FujiFilm ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Longs-Fujifilm-photo-receipt.html Longs/Fujifilm e-mail receipt]

==== Mobivox/PayPal ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Mobivox-PayPal.htm Mobivox/PayPal receipt]
*[http://mobileonlinebusiness.com.au/uf/receipt/Mobivox-PayPal-printable.htm Mobivox/PayPal printable receipt]

==== Skype ====
*[Skype order history] (awaiting upload)

Note: Skype only provides receipts in PDF format, not HTML.

==== Symantec ====
*[Symantec e-mail reminder] (awaiting upload)

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

receipt-examples

2007-07-24T02:19:41Z

RobManson: Added external link to example receipt provided by Leif

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bill / Invoice ===

Bills or Invoices are "yet to be paid" items.

Question: Perhaps these examples (yet to be provided) should be moved to a separate page as Bill/Invoice is quite different from Receipt.

: With [[hResume]], I've [[hresume-brainstorming|suggested]] that the subtle difference between actively seeking work and just presenting your resume be a case of including [[hlisting]] markup.
: With bills vs invoices, it may turn out that the content found within would be identical, and it might just be a case of putting in a class flag to indicate whether the presented document has been paid for or not.
: [[User:SignpostMarv|SignpostMarv]] 12:55, 21 Jul 2007 (PDT)

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/receipt/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

==== A1Books ====
[http://mobileonlinebusiness.com.au/uf/receipt/A1Books-Sales-Order-anon.htm Example]

==== Barnes&Noble ====
[http://mobileonlinebusiness.com.au/uf/receipt/BarnesAndNoble.com-receipt.anon.tidied.htm Example]

==== Facebook ====
[http://mobileonlinebusiness.com.au/uf/receipt/Facebook-gift-receipt.html Example]

==== Google Checkout ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Google-Checkout-e-mail-receipt.tidied.html Example email receipt]
*[http://mobileonlinebusiness.com.au/uf/receipt/Google-Checkout-Order-Receipt_DVD-Empire.tidied.htm Example web receipt]

==== iTunes ====
*[http://mobileonlinebusiness.com.au/uf/receipt/iTunes-receipt-e-mail.html iTunes e-mail receipt]

==== Longs/FujiFilm ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Longs-Fujifilm-photo-receipt.html Longs/Fujifilm e-mail receipt]

==== Mobivox/PayPal ====
*[Mobivox/PayPal receipt] (awaiting upload)
*[Mobivox/PayPal printable receipt] (awaiting upload)

==== Skype ====
*[Skype order history] (awaiting upload)

Note: Skype only provides receipts in PDF format, not HTML.

==== Symantec ====
*[Symantec e-mail reminder] (awaiting upload)

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

receipt-examples

2007-07-24T02:17:49Z

RobManson: Added external link to example receipt provided by Leif

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bill / Invoice ===

Bills or Invoices are "yet to be paid" items.

Question: Perhaps these examples (yet to be provided) should be moved to a separate page as Bill/Invoice is quite different from Receipt.

: With [[hResume]], I've [[hresume-brainstorming|suggested]] that the subtle difference between actively seeking work and just presenting your resume be a case of including [[hlisting]] markup.
: With bills vs invoices, it may turn out that the content found within would be identical, and it might just be a case of putting in a class flag to indicate whether the presented document has been paid for or not.
: [[User:SignpostMarv|SignpostMarv]] 12:55, 21 Jul 2007 (PDT)

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/receipt/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

==== A1Books ====
[http://mobileonlinebusiness.com.au/uf/receipt/A1Books-Sales-Order-anon.htm Example]

==== Barnes&Noble ====
[http://mobileonlinebusiness.com.au/uf/receipt/BarnesAndNoble.com-receipt.anon.tidied.htm Example]

==== Facebook ====
[http://mobileonlinebusiness.com.au/uf/receipt/Facebook-gift-receipt.html Example]

==== Google Checkout ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Google-Checkout-e-mail-receipt.tidied.html Example email receipt]
*[http://mobileonlinebusiness.com.au/uf/receipt/Google-Checkout-Order-Receipt_DVD-Empire.tidied.htm Example web receipt]

==== iTunes ====
*[http://mobileonlinebusiness.com.au/uf/receipt/iTunes-receipt-e-mail.html iTunes e-mail receipt]

==== Longs/FujiFilm ====
*[Longs/Fujifilm e-mail receipt] (awaiting upload)

==== Mobivox/PayPal ====
*[Mobivox/PayPal receipt] (awaiting upload)
*[Mobivox/PayPal printable receipt] (awaiting upload)

==== Skype ====
*[Skype order history] (awaiting upload)

Note: Skype only provides receipts in PDF format, not HTML.

==== Symantec ====
*[Symantec e-mail reminder] (awaiting upload)

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

receipt-examples

2007-07-23T23:20:35Z

RobManson: Fixed up URL type

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bill / Invoice ===

Bills or Invoices are "yet to be paid" items.

Question: Perhaps these examples (yet to be provided) should be moved to a separate page as Bill/Invoice is quite different from Receipt.

: With [[hResume]], I've [[hresume-brainstorming|suggested]] that the subtle difference between actively seeking work and just presenting your resume be a case of including [[hlisting]] markup.
: With bills vs invoices, it may turn out that the content found within would be identical, and it might just be a case of putting in a class flag to indicate whether the presented document has been paid for or not.
: [[User:SignpostMarv|SignpostMarv]] 12:55, 21 Jul 2007 (PDT)

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/receipt/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

==== A1Books ====
[http://mobileonlinebusiness.com.au/uf/receipt/A1Books-Sales-Order-anon.htm Example]

==== Barnes&Noble ====
[http://mobileonlinebusiness.com.au/uf/receipt/BarnesAndNoble.com-receipt.anon.tidied.htm Example]

==== Facebook ====
[http://mobileonlinebusiness.com.au/uf/receipt/Facebook-gift-receipt.html Example]

==== Google Checkout ====
*[http://mobileonlinebusiness.com.au/uf/receipt/Google-Checkout-e-mail-receipt.tidied.html Example email receipt]
*[http://mobileonlinebusiness.com.au/uf/receipt/Google-Checkout-Order-Receipt_DVD-Empire.tidied.htm Example web receipt]

==== iTunes ====
*[iTunes e-mail receipt] (awaiting upload)

==== Longs/FujiFilm ====
*[Longs/Fujifilm e-mail receipt] (awaiting upload)

==== Mobivox/PayPal ====
*[Mobivox/PayPal receipt] (awaiting upload)
*[Mobivox/PayPal printable receipt] (awaiting upload)

==== Skype ====
*[Skype order history] (awaiting upload)

Note: Skype only provides receipts in PDF format, not HTML.

==== Symantec ====
*[Symantec e-mail reminder] (awaiting upload)

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

irc-people

2007-07-22T23:20:30Z

RobManson: Added myself to the irc list (nambor)

A list of [[irc|IRC]] regulars sorted by nick and their normal timezones (winter/summer).

* [[User:WebOrganics|weborganics]] (+0100)
* [[User:Adam Ballai|AdamBallai]] (-700/-700)
* [[User:Adam Craven|AdamCraven]] (+0000)
* [[User:Ajaswa|Andrew Jaswa]] (-0500)
* [[User:Alexander Graf|AlexanderGraf]] (+0100)
* [[User:AmanuelTewolde|Amanuel]] (-0500/-0400)
* [[User:Amette|amette]] (+1000)
* [[User:Amir Guindehi|AmirGuindehi]] (+1000)
* [[User:Ashley|Ashley]] (+1000)
* [[User:B.K._DeLong|bkdelong]] (-0500/-0400)
* [[User:Tyler Roehmholdt|Baristo]] (-0800/-0700)
* [[User:Ben Ward|BenWard]] (+0000)
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)
* [[User:HenriBergius|bergie]] (+0200/+0300)
* [[User:BenWest|bewest]] (-0800/-0700)
* [[User:BluesMoon|bluesmoon]] (+0530)
* [[User:BobChao|BobChao]] (+0800)
* [[User:Bob Jonkman|BobJonkman]] (-0500/-0400)
* [[User:Boneill|boneill]] (+0000)
* [[User:Brian|briansuda]] (+0000)
* [[User:Briski|Briski]] (+0000)
* [[User:BryanL|BryanL]] (-0500/-0400)
* [[User:BryanRieger|Bryan Rieger]] (+0000)
* [[User:Bug-E|Bug-E]] (+0200)
* [[User:Cgriego|cgriego]] (-0600/-0500)
* [[User:CharlesRoper|charles_r]] (0000/+0100)
* [[User:Charlvn|Charl]] (+0200/+0200)
* [[User:ChristopherStJohn|cks]] (-0600/-0500)
* [[User:Cloud|Cloud]] (+0000)
* [[User:Colin_Barrett|cbarrett]] (-1000)
* [[User:ColinDDevroe|cdevroe]] (-0500/-0600)
* [[User:Cruster|cruster]] (+0200)
* [[User:Csarven|csarven]] (-0500/-0400)
* [[User:ChrisBrentano|ctb]] (-0800/-0700)
* [[User:DanielBurka|DanielBurka]] (-0400)
* [[User:DavidMead|DavidMead]] (-0400)
* [[User:DerrickPallas|DerrickPallas]] (-0800/-0700)
* [[User:Dan Kubb|dkubb]] (-0800/-0700)
* [[User:DanC|DanC]] (-0600/-0500)
* [[User:DannyAyers|danja]] (+0100/+0200)
* [[User:Dave Cardwell|davecardwell]] (+0000)
* [[User:DenisDefreyne|ddfreyne]] (+0100/+0200)
* [[User:DeanEro|deanero]] (-0800/-0700)
* [[User:DiegoBudny|DiegoBudny]]
* [[User:DimitriGlazkov|dglazkov]] (-0600/-0500)
* [[User:DrewMcLellan|drewinthehead]] (+0000/+0100)
* [[User:DrewBell|droob]] (-0600/-0500)
* [[User:DimitriosZachariadis|dzach]] (+0200/+0300)
* [[User:Ed Summers|edsu]] (-0500/-0400)
* [[User:Enric|enric]] (-0800/-0700)
* [[User:Enric|Enric]] (-0800/-0700)
* [[User:Evan|evanpro]] (-0500)
* [[User:ChrisMessina|factoryjoe]] (-0800/-0700)
* [[User:Fil|Fil]] (+0200)
* [[User:MarkNormanFrancis|Mark Norman Francis]] (+0000/+0100)
* [[User:MarkoMrdjenovic|friedcell]] (+0100/+0200)
* [[User:Griffin|Griffin]] (-0600/-0500)
* [[User:Grantbow|Grantbow]] (-0800/-0700)
* [[User:Aubergine10|Guy Fraser]] (+0100/+0000)
* [[User:HenrichPoehls|HenrichP]] (+0100)
* [[User:Hlb|hlb]] (+0800-0700)
* [[User:IanHickson|Hixie]] (-0800/-0700)
* [[User:EdwardOConnor|hober]] (-0800/-0700)
* [[User:Ichigo|ichigo]] (+1000)
* [[User:Inkbase|inkbase]] (-0800/-0700)
* [[User:IwaiMasaharu|iwaim]] (+0900)
* [[User:Izo|IZO]]
* [[User:JamieKnight|JamieKnight]] (+1000/0000)
* [[User:WizardIsHungry|jcw9]] (-0500/-0400)
* [[User:Adactio|Jeremy Keith]] (+0000)
* [[User:JasonK|jkridner]] (-0600/-0500)
* [[User:JoeGregorio|jcgregorio]]
* [[User:Jonathan_Arkell|jonnay]] (-0700/0600)
* [[User:JulianStahnke|Julian Stahnke]] (+0000)
* [[User:Kapowaz|kapowaz]] (+0000/+0100)
* [[User:Keri Henare|kerihenare]] (+1200)
* [http://epeus.blogspot.com/ KevinMarks] (-0800/-0700)
* [[User:RyanKing|kingryan]] (-0800/-0700)
** [http://theryanking.com/blog/archives/2006/04/19/office-hours/ Office hours]: Wednesday, 21:00 UTC
* [[User:Lachlan Hunt|Lachy]] (+1000/+1100)
* [[User:Mark Mansour|Mark Mansour]] (+1100)
* [[User:MattisManzel|Mattis Manzel]] (+0100/+0200)
* [[User:CiaranMc|McNulty]] (+0000/+0100)
* [[mfbot]] - a bot which logs all edits to this wiki. It appends a number with a '+' or '-' sign, to indicate the number of characters added or removed as a result of the edit.
* [[User:Mike|Michael McCracken(mmc)]] (-0800/-0700)
* [[User:MikeKaply|mkaply]] (-0600/-0500)
* [[User:SteveIvy|monkinetic/redmonk]] (-0700)
* [[User:RobManson|nambor]] (+1000)
* [[User:neuro|neuro`]]
* [[User:Niekie|niekie]] (+0100/+0200)
* [[User:NTollervey|ntoll]] (+0000/+0100)
* [[User:Phae|Phae]] (+0000/+0100)
* [[User:PriitLaes|plaes]] (+0200/+0300)
* [[User:ChrisCasciano|pnhChris]] (-0500/-0400)
* [[User:PetarPopov|popov]] (-0800/-0700)
* [[User:DavidOsolkowski|qid]] (-0500)
* [[User:RCanine|RCanine]] (-0500/-0400)
* [[User:Remi|Remi]] (-0500/-0400)
* [[User:RobertBachmann|RobertBachmann]] (+0100/+0200)
** Office hours: <del>Wednesday, 18:00-20:00 UTC</del> (Currently no office hours)
* [[User:Ronnos|Ron Kok]] (+0000)
* [[User:SarahWorsham|sazbean]] (-0500/-0400)
* [[User:ScottNelle|snelle]] (-0500/-0400)
* [[User:Dana Benson|Snowden]] (-0800/-0700)
* [[User:Smackman|Steve Farrell]] (-0800/-0700)
* [[User:Steve Ganz|SteveGanz]] (-0800/-0700)
* [[User:SuperPhly|SuperPhly]] (-600/-500)
* [[User:DavidLehn|taaz]] (-0500/-0400)
* [[User:Tantek|Tantek]] (-0800/-0700)
* [[User:Trovster|trovster]] (-0800/-0700)
* [[User:Vadania|vadania]] (-0600/-0700)
* [[User:Vant|vant]] (+0900)
* [[User:Victor|victor]] (+0100/+0200)
* [[User:V-I-P|V-I-P]] (+0100/+0200)
* [[User:KrissWatt|VoodooChild]] (+0000/+0100)
* [[User:JacksonWilkinson|whafro]] (-0500/-0400)
* [[User:Richard Conyard|WhiskeyM]] (+0000)
* [[User:Veeliam|William Lawrence]] (-0800/-0700)
* [[User:Wojciech|wzajac]] (+0100/+0200)
* [[User:Ianloic|yakk]] (-0800/-0700)
* [[User:StevenWoods|woodss]] (+0000 GMT)
* [[User:Linmic|linmic]] (+0800-0700)
* [[User:Stii|Stii]] (+0200 GMT)

User:RobManson

2007-07-21T04:07:42Z

RobManson: Testing NewPage creation templates (stil requires Inputbox extension thought)

<div class="vcard">
<span class="fn n">
<span class="given-name">Rob</span>
<span class="family-name">Manson</span>
</span>
<div><span class="org">Mobile Online Business</span></div>
<div><span class="url">http://MobileOnlineBusiness.com.au</span></div>
<div><span class="url">http://paymentz.com.au</span></div>
<div>Address:<span class="adr"><span class="type">postal</span>:<div class="street-address addressField">P.O. Box 1174,</div><span class="locality addressField">Sydney</span><span class="region">NSW</span><span class="postal-code">1355,</span><div class="country-name addressField">Australia</div></span></div>
</div>

== New page based upon template test ==
<inputbox>
type=create
bgcolor=#eeeeff
width=40
default=NewPageName
preload=TestNewPageTemplate
buttonlabel=Create a new Extension (replace "MyExtension" with the correct name)
</inputbox>
[[Category:Info templates|{{PAGENAME}}]][[category:extension creation]]
</noinclude>

{{public-domain-release}}

hlisting-issues

2007-07-21T04:06:26Z

RobManson: Created -issues page and added first issue/question about rel-payment

<h1> hListing Issues </h1>

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

'''IMPORTANT''': Please read (or in this case create ;) ) the [[hlisting-faq|hListing FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well.

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

__TOC__

== Issues ==
*{{OpenIssue}} 2007-07-21 raised by [[User:RobManson]]
*# The only discussion I could find relating to payment method for hListing was in the tag section. Wouldn't [[rel-payment]] be a natural fit with hListing?

== Template ==

== Resolved Issues ==

== Closed Issues ==

== Related Pages ==

to-do

2007-07-21T03:58:43Z

RobManson: /* Wiki improvements */

<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]

__TOC__

== Lazyweb ==

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

=== for all microformats ===
* We have recently 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. [[use]] 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.
* Add [http://verselogic.net/projects/wordpress/wordpress-openid-plugin/ OpenID] to Microformats Blog.
* Submit definitions of "mcroformat", 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]

=== 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/
* 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])

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

=== 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)

== 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 tildas: <nowiki>~~~~</nowiki>.

=== Wiki improvements ===
* OpenID login, on behalf of a request a while ago from [[User:DanC]]. [[User:Tantek|Tantek]] 20:50, 20 Jul 2007 (PDT)
* 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)

== 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]], [[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.

=== help publishers ===
==== foldup cheatsheet ===
'''Next actions''': review all descriptions, property lists, examples in Erin's cheatsheet draft, give feedback back to Erin about her foldup cheatsheet, iterate, print, fold, distribute.

Help create a printable foldup cheatsheet of multiple microformats (ASAP, perhaps for [[events/2007-04-18-web-2-expo-dinner|Web 2.0 Expo Microformats dinner]]) that:
* prints onto both sides of a sheet of 8.5x11" paper (size chosen for US distribution, and because it folds nicely into 4ths sliced vertically, then 3rds sliced horizontally into a size approximating a business card, hoping to CC-by the whole thing so that others can do their own variants, perhaps for other paper sizes also)
* accordion folds first into 1/4 size along 3 vertical creases, then 1/3 size along 2 horizontal creases
* on each of the 8 vertical stripes (4 one side, 4 the other) of the sheet, info on each of the following microformats (it is assumed that [[hcard|hCard]] documentation will cover [[adr]], and [[geo]] also).
** people vs. other things
*** people-centric:
**** [[xfn|XFN]]
**** [[hcard|hCard]]([[adr]],[[geo]])
**** [[hcalendar|hCalendar]]
**** [[hresume|hResume]] + [[include-pattern]]
*** content-centric:
**** [[microformats]] list/overview
**** other common rels: [[rel-license]] [[rel-enclosure]] [[rel-tag]] [[rel-directory]]
**** [[hreview|hReview]] + [[xfolk|xFolk]]
**** [[hatom|hAtom]]
** original building blocks vs. newer
*** original:
**** [[microformats]] list/overview [[rel-license]] [[rel-tag]]
**** [[xfn|XFN]]
**** [[hcard|hCard]]([[adr]],[[geo]])
**** [[hcalendar|hCalendar]]
*** newer:
**** [[hreview|hReview]] + [[xfolk|xFolk]]
**** [[rel-directory]] [[rel-enclosure]]
**** [[hatom|hAtom]]
**** [[hresume|hResume]] + [[include-pattern]]
** other splits of 4 slices vs. 4 slices?
*** ...
*** ...
* each triple accordion fold section for a microformat should contain:
** property summary with required/optional singular/plural sub-properties (similar to current cheat sheet) + illustrative code sample with common properties
** list of properties, sub-properties with values and definitions of each
** URLs to spec, examples, implementations for more info.

Update: I made a folding cheat sheet to similar specifications. Not sure if it's 100% correct, it needs to be looked at for needed revisions. [http://erincaton.ca/media/cheatsheetHandout.pdf Cheat sheet PDF.] [[User:ErinCaton|ErinCaton]]

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)

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

* [[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 ===
==== [[hcard|hCard]] ====
* [[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

==== [[hcalendar|hCalendar]] ====
'''Next-actions''':
* itemize a list of properties 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.
* formalize [http://microformats.org/wiki/hcalendar- brainstorming#Tabular_event_calendars]
* flesh out [[hcalendar-examples]] and do a once over on markup/presentation of what RFC2445 examples would look like
* need spec details and then [[hcalendar-examples]] of multi-instance [[hcalendar|hCalendar]] events
* need spec details and then [[hcalendar-examples]] of repeating events
* add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.
* 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.

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

==== 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''':
* 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

==== 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 ===
* possibly move dead proposals off of homepage?

=== 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
* Add support for [http://verselogic.net/projects/wordpress/wordpress-openid-plugin/ OpenID] to the microformats blog.
* Read GTD (at least the first two chapters).

=== Campaigns ===

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

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

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

== 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]]
* translate red links on [[Main_Page-fr]]
* localize a french version of the official website and migrate contents
** ask authorization to the authors
** migration could be done on any collaborative CMS
** test a cocomment system (based on local-wiki)
** complete with original links
* find experts for peer-reviewing
* update [http://fr.wikipedia.org/wiki/Microformats French-wikipedia:Microformats] 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.
** create hCard, hCalendar... and all red link pages on french wikipedia
* find help and maintain http://www.communitywiki.org/MicroFormats
* localize [[species-fr]] and related pages
* clean all dead links pointing to elanceur.org

== 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 ===
<ul>
<li>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.</li>
<li>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.</li>
</ul>

== 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)

to-do

2007-07-21T03:55:29Z

RobManson: Fixing up edit conflict

<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]

__TOC__

== Lazyweb ==

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

=== for all microformats ===
* We have recently 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. [[use]] 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.
* Add [http://verselogic.net/projects/wordpress/wordpress-openid-plugin/ OpenID] to Microformats Blog.
* Submit definitions of "mcroformat", 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]

=== 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/
* 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])

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

=== 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)

== 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 tildas: <nowiki>~~~~</nowiki>.

=== Wiki improvements ===
* OpenID login, on behalf of a request a while ago from [[User:DanC]]. [[User:Tantek|Tantek]] 20:50, 20 Jul 2007 (PDT)
* ...

== 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]], [[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.

=== help publishers ===
==== foldup cheatsheet ===
'''Next actions''': review all descriptions, property lists, examples in Erin's cheatsheet draft, give feedback back to Erin about her foldup cheatsheet, iterate, print, fold, distribute.

Help create a printable foldup cheatsheet of multiple microformats (ASAP, perhaps for [[events/2007-04-18-web-2-expo-dinner|Web 2.0 Expo Microformats dinner]]) that:
* prints onto both sides of a sheet of 8.5x11" paper (size chosen for US distribution, and because it folds nicely into 4ths sliced vertically, then 3rds sliced horizontally into a size approximating a business card, hoping to CC-by the whole thing so that others can do their own variants, perhaps for other paper sizes also)
* accordion folds first into 1/4 size along 3 vertical creases, then 1/3 size along 2 horizontal creases
* on each of the 8 vertical stripes (4 one side, 4 the other) of the sheet, info on each of the following microformats (it is assumed that [[hcard|hCard]] documentation will cover [[adr]], and [[geo]] also).
** people vs. other things
*** people-centric:
**** [[xfn|XFN]]
**** [[hcard|hCard]]([[adr]],[[geo]])
**** [[hcalendar|hCalendar]]
**** [[hresume|hResume]] + [[include-pattern]]
*** content-centric:
**** [[microformats]] list/overview
**** other common rels: [[rel-license]] [[rel-enclosure]] [[rel-tag]] [[rel-directory]]
**** [[hreview|hReview]] + [[xfolk|xFolk]]
**** [[hatom|hAtom]]
** original building blocks vs. newer
*** original:
**** [[microformats]] list/overview [[rel-license]] [[rel-tag]]
**** [[xfn|XFN]]
**** [[hcard|hCard]]([[adr]],[[geo]])
**** [[hcalendar|hCalendar]]
*** newer:
**** [[hreview|hReview]] + [[xfolk|xFolk]]
**** [[rel-directory]] [[rel-enclosure]]
**** [[hatom|hAtom]]
**** [[hresume|hResume]] + [[include-pattern]]
** other splits of 4 slices vs. 4 slices?
*** ...
*** ...
* each triple accordion fold section for a microformat should contain:
** property summary with required/optional singular/plural sub-properties (similar to current cheat sheet) + illustrative code sample with common properties
** list of properties, sub-properties with values and definitions of each
** URLs to spec, examples, implementations for more info.

Update: I made a folding cheat sheet to similar specifications. Not sure if it's 100% correct, it needs to be looked at for needed revisions. [http://erincaton.ca/media/cheatsheetHandout.pdf Cheat sheet PDF.] [[User:ErinCaton|ErinCaton]]

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)

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

* [[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 ===
==== [[hcard|hCard]] ====
* [[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

==== [[hcalendar|hCalendar]] ====
'''Next-actions''':
* itemize a list of properties 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.
* formalize [http://microformats.org/wiki/hcalendar- brainstorming#Tabular_event_calendars]
* flesh out [[hcalendar-examples]] and do a once over on markup/presentation of what RFC2445 examples would look like
* need spec details and then [[hcalendar-examples]] of multi-instance [[hcalendar|hCalendar]] events
* need spec details and then [[hcalendar-examples]] of repeating events
* add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.
* 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.

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

==== 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''':
* 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

==== 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 ===
* possibly move dead proposals off of homepage?

=== 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
* Add support for [http://verselogic.net/projects/wordpress/wordpress-openid-plugin/ OpenID] to the microformats blog.
* Read GTD (at least the first two chapters).

=== Campaigns ===

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

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

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

== 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]]
* translate red links on [[Main_Page-fr]]
* localize a french version of the official website and migrate contents
** ask authorization to the authors
** migration could be done on any collaborative CMS
** test a cocomment system (based on local-wiki)
** complete with original links
* find experts for peer-reviewing
* update [http://fr.wikipedia.org/wiki/Microformats French-wikipedia:Microformats] 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.
** create hCard, hCalendar... and all red link pages on french wikipedia
* find help and maintain http://www.communitywiki.org/MicroFormats
* localize [[species-fr]] and related pages
* clean all dead links pointing to elanceur.org

== 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 ===
<ul>
<li>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.</li>
<li>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.</li>
</ul>

== 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)

to-do

2007-07-21T03:54:58Z

RobManson: Fixing up edit conflict

<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]

__TOC__

== Lazyweb ==

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

=== for all microformats ===
* We have recently 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. [[use]] 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.
* Add [http://verselogic.net/projects/wordpress/wordpress-openid-plugin/ OpenID] to Microformats Blog.
* Submit definitions of "mcroformat", 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]

=== 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/
* 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])

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

=== 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)

== 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 tildas: <nowiki>~~~~</nowiki>.

=== Wiki improvements ===
* OpenID login, on behalf of a request a while ago from [[User:DanC]]. [[User:Tantek|Tantek]] 20:50, 20 Jul 2007 (PDT)
* ...

== 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]], [[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.

=== help publishers ===
==== foldup cheatsheet ===
'''Next actions''': review all descriptions, property lists, examples in Erin's cheatsheet draft, give feedback back to Erin about her foldup cheatsheet, iterate, print, fold, distribute.

Help create a printable foldup cheatsheet of multiple microformats (ASAP, perhaps for [[events/2007-04-18-web-2-expo-dinner|Web 2.0 Expo Microformats dinner]]) that:
* prints onto both sides of a sheet of 8.5x11" paper (size chosen for US distribution, and because it folds nicely into 4ths sliced vertically, then 3rds sliced horizontally into a size approximating a business card, hoping to CC-by the whole thing so that others can do their own variants, perhaps for other paper sizes also)
* accordion folds first into 1/4 size along 3 vertical creases, then 1/3 size along 2 horizontal creases
* on each of the 8 vertical stripes (4 one side, 4 the other) of the sheet, info on each of the following microformats (it is assumed that [[hcard|hCard]] documentation will cover [[adr]], and [[geo]] also).
** people vs. other things
*** people-centric:
**** [[xfn|XFN]]
**** [[hcard|hCard]]([[adr]],[[geo]])
**** [[hcalendar|hCalendar]]
**** [[hresume|hResume]] + [[include-pattern]]
*** content-centric:
**** [[microformats]] list/overview
**** other common rels: [[rel-license]] [[rel-enclosure]] [[rel-tag]] [[rel-directory]]
**** [[hreview|hReview]] + [[xfolk|xFolk]]
**** [[hatom|hAtom]]
** original building blocks vs. newer
*** original:
**** [[microformats]] list/overview [[rel-license]] [[rel-tag]]
**** [[xfn|XFN]]
**** [[hcard|hCard]]([[adr]],[[geo]])
**** [[hcalendar|hCalendar]]
*** newer:
**** [[hreview|hReview]] + [[xfolk|xFolk]]
**** [[rel-directory]] [[rel-enclosure]]
**** [[hatom|hAtom]]
**** [[hresume|hResume]] + [[include-pattern]]
** other splits of 4 slices vs. 4 slices?
*** ...
*** ...
* each triple accordion fold section for a microformat should contain:
** property summary with required/optional singular/plural sub-properties (similar to current cheat sheet) + illustrative code sample with common properties
** list of properties, sub-properties with values and definitions of each
** URLs to spec, examples, implementations for more info.

Update: I made a folding cheat sheet to similar specifications. Not sure if it's 100% correct, it needs to be looked at for needed revisions. [http://erincaton.ca/media/cheatsheetHandout.pdf Cheat sheet PDF.] [[User:ErinCaton|ErinCaton]]

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)

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

* [[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 ===
==== [[hcard|hCard]] ====
* [[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

==== [[hcalendar|hCalendar]] ====
'''Next-actions''':
* itemize a list of properties 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.
* formalize [http://microformats.org/wiki/hcalendar- brainstorming#Tabular_event_calendars]
* flesh out [[hcalendar-examples]] and do a once over on markup/presentation of what RFC2445 examples would look like
* need spec details and then [[hcalendar-examples]] of multi-instance [[hcalendar|hCalendar]] events
* need spec details and then [[hcalendar-examples]] of repeating events
* add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.
* 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.

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

==== 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''':
* 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

==== 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 ===
* possibly move dead proposals off of homepage?

=== 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
* Add support for [http://verselogic.net/projects/wordpress/wordpress-openid-plugin/ OpenID] to the microformats blog.
* Read GTD (at least the first two chapters).

=== Campaigns ===

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

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

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

== 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]]
* translate red links on [[Main_Page-fr]]
* localize a french version of the official website and migrate contents
** ask authorization to the authors
** migration could be done on any collaborative CMS
** test a cocomment system (based on local-wiki)
** complete with original links
* find experts for peer-reviewing
* update [http://fr.wikipedia.org/wiki/Microformats French-wikipedia:Microformats] 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.
** create hCard, hCalendar... and all red link pages on french wikipedia
* find help and maintain http://www.communitywiki.org/MicroFormats
* localize [[species-fr]] and related pages
* clean all dead links pointing to elanceur.org

== 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 ===
<ul>
<li>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.</li>
<li>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.</li>
</ul>

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

to-do

2007-07-21T03:49:50Z

RobManson: Added to-do item to chase up admins ;)

<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]

__TOC__

== Lazyweb ==

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

=== for all microformats ===
* We have recently 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. [[use]] 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.
* Add [http://verselogic.net/projects/wordpress/wordpress-openid-plugin/ OpenID] to Microformats Blog.
* Submit definitions of "mcroformat", 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]

=== 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/
* 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])

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

=== 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)

== 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]], [[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.

=== help publishers ===
==== foldup cheatsheet ===
'''Next actions''': review all descriptions, property lists, examples in Erin's cheatsheet draft, give feedback back to Erin about her foldup cheatsheet, iterate, print, fold, distribute.

Help create a printable foldup cheatsheet of multiple microformats (ASAP, perhaps for [[events/2007-04-18-web-2-expo-dinner|Web 2.0 Expo Microformats dinner]]) that:
* prints onto both sides of a sheet of 8.5x11" paper (size chosen for US distribution, and because it folds nicely into 4ths sliced vertically, then 3rds sliced horizontally into a size approximating a business card, hoping to CC-by the whole thing so that others can do their own variants, perhaps for other paper sizes also)
* accordion folds first into 1/4 size along 3 vertical creases, then 1/3 size along 2 horizontal creases
* on each of the 8 vertical stripes (4 one side, 4 the other) of the sheet, info on each of the following microformats (it is assumed that [[hcard|hCard]] documentation will cover [[adr]], and [[geo]] also).
** people vs. other things
*** people-centric:
**** [[xfn|XFN]]
**** [[hcard|hCard]]([[adr]],[[geo]])
**** [[hcalendar|hCalendar]]
**** [[hresume|hResume]] + [[include-pattern]]
*** content-centric:
**** [[microformats]] list/overview
**** other common rels: [[rel-license]] [[rel-enclosure]] [[rel-tag]] [[rel-directory]]
**** [[hreview|hReview]] + [[xfolk|xFolk]]
**** [[hatom|hAtom]]
** original building blocks vs. newer
*** original:
**** [[microformats]] list/overview [[rel-license]] [[rel-tag]]
**** [[xfn|XFN]]
**** [[hcard|hCard]]([[adr]],[[geo]])
**** [[hcalendar|hCalendar]]
*** newer:
**** [[hreview|hReview]] + [[xfolk|xFolk]]
**** [[rel-directory]] [[rel-enclosure]]
**** [[hatom|hAtom]]
**** [[hresume|hResume]] + [[include-pattern]]
** other splits of 4 slices vs. 4 slices?
*** ...
*** ...
* each triple accordion fold section for a microformat should contain:
** property summary with required/optional singular/plural sub-properties (similar to current cheat sheet) + illustrative code sample with common properties
** list of properties, sub-properties with values and definitions of each
** URLs to spec, examples, implementations for more info.

Update: I made a folding cheat sheet to similar specifications. Not sure if it's 100% correct, it needs to be looked at for needed revisions. [http://erincaton.ca/media/cheatsheetHandout.pdf Cheat sheet PDF.] [[User:ErinCaton|ErinCaton]]

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)

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

* [[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 ===
==== [[hcard|hCard]] ====
* [[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

==== [[hcalendar|hCalendar]] ====
'''Next-actions''':
* itemize a list of properties 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.
* formalize [http://microformats.org/wiki/hcalendar- brainstorming#Tabular_event_calendars]
* flesh out [[hcalendar-examples]] and do a once over on markup/presentation of what RFC2445 examples would look like
* need spec details and then [[hcalendar-examples]] of multi-instance [[hcalendar|hCalendar]] events
* need spec details and then [[hcalendar-examples]] of repeating events
* add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.
* 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.

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

==== 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''':
* 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

==== 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 ===
* possibly move dead proposals off of homepage?

=== 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
* Add support for [http://verselogic.net/projects/wordpress/wordpress-openid-plugin/ OpenID] to the microformats blog.
* Read GTD (at least the first two chapters).

=== Campaigns ===

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

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

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

== 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]]
* translate red links on [[Main_Page-fr]]
* localize a french version of the official website and migrate contents
** ask authorization to the authors
** migration could be done on any collaborative CMS
** test a cocomment system (based on local-wiki)
** complete with original links
* find experts for peer-reviewing
* update [http://fr.wikipedia.org/wiki/Microformats French-wikipedia:Microformats] 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.
** create hCard, hCalendar... and all red link pages on french wikipedia
* find help and maintain http://www.communitywiki.org/MicroFormats
* localize [[species-fr]] and related pages
* clean all dead links pointing to elanceur.org

== 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 ===
<ul>
<li>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.</li>
<li>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.</li>
</ul>

== 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)

receipt-examples

2007-07-21T00:15:58Z

RobManson: Question regarding Bill/Invoice vs Receipt

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bill / Invoice ===

Bills or Invoices are "yet to be paid" items.

Question: Perhaps these examples (yet to be provided) should be moved to a separate page as Bill/Invoice is quite different from Receipt.

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/receipt/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

==== A1Books ====
[http://mobileonline.com.au/uf/receipt/A1Books-Sales-Order-anon.htm Example]

==== Barnes&Noble ====
[http://mobileonline.com.au/uf/receipt/BarnesAndNoble.com-receipt.anon.tidied.htm Example]

==== Facebook ====
[http://mobileonline.com.au/uf/receipt/Facebook-gift-receipt.html Example]

==== Google Checkout ====
[http://mobileonline.com.au/uf/receipt/Google-Checkout-e-mail-receipt.tidied.html Example email receipt]

[http://mobileonline.com.au/uf/receipt/Google-Checkout-Order-Receipt_DVD-Empire.tidied.htm Example web receipt]

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

receipt-examples

2007-07-21T00:11:18Z

RobManson: Google Checkout receipts provided by Leif

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bills ===

Bills are pre-purchase items.

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/receipt/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

==== A1Books ====
[http://mobileonline.com.au/uf/receipt/A1Books-Sales-Order-anon.htm Example]

==== Barnes&Noble ====
[http://mobileonline.com.au/uf/receipt/BarnesAndNoble.com-receipt.anon.tidied.htm Example]

==== Facebook ====
[http://mobileonline.com.au/uf/receipt/Facebook-gift-receipt.html Example]

==== Google Checkout ====
[http://mobileonline.com.au/uf/receipt/Google-Checkout-e-mail-receipt.tidied.html Example email receipt]

[http://mobileonline.com.au/uf/receipt/Google-Checkout-Order-Receipt_DVD-Empire.tidied.htm Example web receipt]

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

receipt-examples

2007-07-21T00:09:50Z

RobManson: Facebook receipt provided by Leif

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bills ===

Bills are pre-purchase items.

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/receipt/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

==== A1Books ====
[http://mobileonline.com.au/uf/receipt/A1Books-Sales-Order-anon.htm Example]

==== Barnes&Noble ====
[http://mobileonline.com.au/uf/receipt/BarnesAndNoble.com-receipt.anon.tidied.htm Example]

==== Facebook ====
[http://mobileonline.com.au/uf/receipt/Facebook-gift-receipt.html Example]

==== Google Checkout ====
[e-mail receipt pending upload]
[web receipt pending upload]

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

receipt-examples

2007-07-21T00:09:04Z

RobManson: Barnes&Noble example provided by Leif

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bills ===

Bills are pre-purchase items.

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/receipt/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

==== A1Books ====
[http://mobileonline.com.au/uf/receipt/A1Books-Sales-Order-anon.htm Example]

==== Barnes&Noble ====
[http://mobileonline.com.au/uf/receipt/BarnesAndNoble.com-receipt.anon.tidied.htm Example]

==== Facebook ====
[pending upload]

==== Google Checkout ====
[e-mail receipt pending upload]
[web receipt pending upload]

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

receipt-examples

2007-07-21T00:08:04Z

RobManson: A1 Books receipt provided by Leif

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bills ===

Bills are pre-purchase items.

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/receipt/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

==== A1Books ====
[http://mobileonline.com.au/uf/receipt/A1Books-Sales-Order-anon.htm Example]

==== Barnes&Noble ====
[pending upload]

==== Facebook ====
[pending upload]

==== Google Checkout ====
[e-mail receipt pending upload]
[web receipt pending upload]

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

receipt-examples

2007-07-21T00:06:36Z

RobManson: Updated URL

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bills ===

Bills are pre-purchase items.

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/receipt/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

==== A1Books ====
[pending upload]

==== Barnes&Noble ====
[pending upload]

==== Facebook ====
[pending upload]

==== Google Checkout ====
[e-mail receipt pending upload]
[web receipt pending upload]

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

receipt-examples

2007-07-19T19:57:34Z

RobManson: Added external link to example receipt

= Receipt =

Overview of Receipt exploratory discussion goes here...

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bills ===

Bills are pre-purchase items.

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [http://mobileonlinebusiness.com.au/uf/Amazon.com-Vieworder-anon.htm Example]
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* [[receipt]]
* http://en.wikipedia.org/wiki/Receipt

User:RobManson

2007-07-19T15:01:57Z

RobManson: Fixed adr issue with MediaWiki adding useless <p/>'s

User:RobManson

2007-07-19T14:48:47Z

RobManson: Added our product URL to my hCard

User:RobManson

2007-07-19T14:46:30Z

RobManson: Added a simple hCard for myself

commerce-examples

2007-07-19T08:56:54Z

RobManson: Created an initial draft of the commerce domain overview

= Commerce Documents/Artefacts =

== The Problem ==
The Commerce domain has a number of common documents that are used to record specific classes of interactions or value exchanges - see [http://en.wikipedia.org/wiki/Category:Accounting_source_documents wikipedia's accounting source documents].

The problem is that much of the accounting and business administration activities are based upon capturing, recording and managing these records - often by exporting and importing this data, or even worse by re-entering it into disparate systems. And these common artefacts are used with different names around the world and to meet different accounting requirements for each region, or even just in different industries or organisations.

This page aims to gather together at a high level a list of all the ''common'' artefacts found in the online commerce or e-commerce domain. This list should aim to identify which of these artefacts are currently covered (or can be covered) by existing microformats. The examples of the remaining artefacts may then help identify possible candidates for extensions to existing microformats or even potentially new microformats.

If nothing else this page aims to aid communication amongst people interested in microformats within the commerce domain.

== Contributors ==
* Rob Manson

== Common scenario to be explored ==
# Customer sees a product review online ([[hReview]])
# Customer follows a link to a product listing ([[hlisting-proposal|hListing]] containing [[product|hProduct]], [[currency]], [[measure]] and [[rel-payment]])
# Customer may add one or more products to a shopping cart to build a purchase order (offer)
# Customer may then commit to paying for this purchase order (acceptance)
# Merchant may then send the customer an invoice for an amount to be paid
# Or a Merchant may issue a receipt/bill for a payment that has been made
# If the payment is incorrect in some way then a credit note or memo may be issued to the Customer

== Real-World Example Pages ==
=== Product/Service review ===
See [[hReview]].

=== Product/Service listing ===
See [[hListing]].

=== Purchase order ===
Examples yet to be collected.

=== Invoice ===
Examples yet to be collected.

=== Receipt/Bill ===
See [[receipt-examples]].

=== Credit Memo/Note ===
Examples yet to be collected.

=== Analysis ===

==== Analysis of Type 1 ====

== Existing Practices ==

=== Summary of common patterns discovered ===

=== Other attempts to solve The Problem ===

== Proposal ==

== See Also ==
* http://en.wikipedia.org/wiki/Category:Accounting_source_documents

receipt-examples

2007-07-19T07:37:58Z

RobManson: Added link to wikipedia's Receipt page - some useful distinctions here

= Receipt =

Overview of Receipt exploratory discussion goes here...

== The Problem ==

The ability to securely purchase items through a web browser has created a large number of sites that contain the entire purchasing process online. It is common that a customer selects the items that they want to buy, a bill is displayed, a purchase occurs and finally a receipt is displayed to the customer. Currently, it is difficult for a computer to understand when a bill is displayed, when a receipt is displayed and what items are a part of that bill or receipt.

Typically, receipts are e-mailed to customers. It would be helpful if there was a better way to extract the receipt data from a website and process it using another piece of software. It would also be beneficial for other Microformats to be able to display a bill or receipt as part of their content. hListing, and hProduct, hAudio are a three examples of Microformats that could use a bill/receipt Microformat.

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bills ===

Bills are pre-purchase items.

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [[receipt-example-amazon | Example]] (an example will be uploaded by Leif soon)
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Skype ====

===== Skype Phone =====
[[receipt-example-skype-phone|example source code]]
* Name
* Shipping Address
* Order blurb "Confirmation of incoming order"
** date in dd/mm/yyyy format
* Order number in nnnn-nnnnnnn-nnn format
* Reference (was blank in example, presumed to appear on bank statement for this transaction)
* Order resume
* Notification of chosen payment method blurb: "Your payment method is: Credit card"
* Legal blurb

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==
* http://en.wikipedia.org/wiki/Receipt

receipt-examples

2007-07-19T06:17:01Z

RobManson: Added 6 real world example receipt descriptions from my records - says way too much about my spending habits :)

= Receipt =

Overview of Receipt exploratory discussion goes here...

== The Problem ==

The ability to securely purchase items through a web browser has created a large number of sites that contain the entire purchasing process online. It is common that a customer selects the items that they want to buy, a bill is displayed, a purchase occurs and finally a receipt is displayed to the customer. Currently, it is difficult for a computer to understand when a bill is displayed, when a receipt is displayed and what items are a part of that bill or receipt.

Typically, receipts are e-mailed to customers. It would be helpful if there was a better way to extract the receipt data from a website and process it using another piece of software. It would also be beneficial for other Microformats to be able to display a bill or receipt as part of their content. hListing, and hProduct, hAudio are a three examples of Microformats that could use a bill/receipt Microformat.

== Authors ==

=== Contributors ===
Rob Manson

== Real-World Examples ==

=== Bills ===

Bills are pre-purchase items.

=== Receipts ===

Receipts are post-purchase items.

==== Amazon ====
* [[receipt-example-amazon | Example]] (an example will be uploaded by Leif soon)
* contains:
**<del>email address</del> (could not find in examples)
**date of order
**order id
**shipments
***shipping estimate
***delivery estimate
***shipping address
***shipping speed
***shipping preference (item grouping)
***items
****quantity
****seller
****price
****item information
**payment
***card type
***last 5 digits
***expiration date
***billing address
***subtotal
***shipping and handling price
***total before tax
***tax
***grand total
**<del>discount price</del> (could not find in examples)
* Little semantic HTML of interest, except an anchor with id "payment-info"

==== Internet banking transaction receipts ====
===== Example 1 =====
<pre><nowiki>
receipt number
date
time
receipt type (e.g. TRANSFER BETWEEN MY ACCOUNTS)
transfer from
transfer to
amount
description
information/comment
</nowiki></pre>

==== Digital product purchase receipts ====
===== Example 1 : Software =====
<pre><nowiki>
receipt title/type
order/receipt number
seller's details
sold by (hCard candidate)
org
adr
tax number (VAT in this example)
tax id (Federal Tax ID)
buyer's details
buyer (hCard candidate)
name
org
street-address
locality
region
postal-code
country-name
tel
email
credit card number (PAN truncated - with type)
item list
product code
name
comments
price
delivery method
quantity
total in selected currency
total in sellers currency
total (sum of item list totals)
processing fee
grand total (final amount charged)
information (caveats and tax info)
permalink
</nowiki></pre>

===== Example 2 : SSL certificate =====
<pre><nowiki>
receipt title/type
seller (hCard candidate)
org
street-address
locality
region
postal-code
purchase information
order id
product name
domain name
validity period
number of licenses
card number (PAN truncated)
amount (with selected currency)
</nowiki></pre>

==== Physical product purchase receipts ====
===== Example 1 : Computer hardware =====
<pre><nowiki>
receipt title/type
seller's name (hCard candidate)
seller's URL (hCard candidate)
invoice id
org govt reference (ABN - Australian Business Number)
date
seller details (hCard candidate)
street-address
locality
region
postal-code
buyer (hCard candidate)
fn
billing address
street-address
locality
region
postal-code
delivery address
street-address
locality
region
postal-code
phone
item list
item
description
amount
quantity
product url
total
delivery cost
total excluding tax
tax (GST - Goods and Service Tax)
total including tax
</nowiki></pre>

==== Service purchase receipts ====
===== Example 1 : Online subscription =====
<pre><nowiki>
seller's details (hCard candidate)
org
street-address
locality
region
postal-code
country-name
buyer's details (hCard candidate)
fn
street-address
locality
region
postal-code
phone
date
receipt id
item list
product description
quantity
rate (per unit)
price
sub total
amount paid
balance due
information
transaction id
</nowiki></pre>

===== Example 2 : Co-location =====
<pre><nowiki>
receipt title/type
sellers details (hCard candidate)
org
url
phone
message
receipt number
date
amount
information
</nowiki></pre>

=== Analysis ===

==== Analysis of Bills ====

==== Analysis of Receipts ====

== Existing Practices ==

Listed below is an overview of existing patterns and practices found in the wild for bill and receipt data.

===Summary of common patterns discovered===

===Other attempts to solve The Problem===

== Proposal ==

== See Also ==

code-issues

2007-07-18T07:25:14Z

RobManson: How to contribute open source code to microformats.org?

== How does someone contribute to the code area ==
Based upon discussion in the irc channel I've been asked to create this wiki page.

Essentially this is just to track the issue of "how does someone contribut to the code area of the microformats.org site". Assuming this was created to host open source code for microformats - how does that work exactly?

e.g. the vCard to hCard creator [http://mobileonlinebusiness.com.au/uf/vCard_to_hCard_converter.html]

This was released under the GPL and was written in javascript (in response to an item in the wiki/to-do list) so it could be uploaded to a website (e.g. not dependent upon a specific server environment). The goal was to create a community resource like the hCard creator that would help people new to microformats understand the mapping from vCard to hCard, since there is already a wealth of vCards available today.

However it's not clear how someone actually contributes something like this to the code area. So the only option left was to host this on my own server. This makes it seem more like a url promotion activity and less of a community asset.

So basically I'm just looking for clarification on this point.

hcard-brainstorming

2007-07-18T02:42:29Z

RobManson: No complaints on mailing list so I updated this markup

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

__TOC__

== Authors ==
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/log/ Tantek Çelik], [http://technorati.com Technorati, Inc]

== Contributors ==
* [[User:Atamido|Atamido]]
* [[User:ChrisMessina|ChrisMessina]]
* [[User:DimitriGlazkov|DimitriGlazkov]]
* ...
* ... and many others

== Problems Being Solved ==

Some of the problems that [[hcard|hCard]] helps to solve:

* having to enter business cards that go out of date (subscribe to someone's syndicated [[hcard|hCard]] instead).
* annoying "update your contact info" email from various centralized contact info services

== FN Nickname semantic ==

There are many sites (e.g. [http://flickr.com Flickr], [http://consumating.com/ Consumating]) which permit the user to '''both''' have a multi-word login/handle/alias, '''and''' not show their ''real'' name (fn, n, given-name, family-name etc.).

For the people represented by the profile pages of these sites, the best we can do is mark-up their login/handle/alias as their "nickname". Originally, we had thought that such handles etc. were single words only, and thus we created the [[hcard#Implied_.22nickname.22_Optimization|Implied nickname optimization]] accordingly, where you can markup the handle as an "fn", and have it automatically set a "nickname" property value, and empty values for all the "n" sub-values.

In order to deal with multi-word handles, similar to the [[hcard#Organization_Contact_Info|hCard Organization contact info]] method, the following is proposed:

=== "fn" and "nickname" combination ===

Due to the use of potentially multi-word nicknames/handles/usernames in content published on the Web, (e.g. on sites like [http://flickr.com Flickr] and [http://consumating.com/ Consumating]), hCard has a mechanism for specifying a multi-word "fn" that is also a "nickname" without affecting any "n" sub-properties that are otherwise specified, and explicitly implying empty defaults for "n" sub-properties.

Similar to the [[hcard#Implied_.22nickname.22_Optimization|implied "nickname" optimization]], if the "fn" property and a "nickname" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn nickname"</code>), then

# The content of the "fn" is treated as a "nickname" property value.
# Parsers should handle the missing "n" property by implying empty values for all the "n" sub-properties.

== Examples ==

* See [[hcard-examples]], which provides several illustrative instructive examples, as well as 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

=== Using RFC2806 with hCard ===

[http://www.ietf.org/rfc/rfc2806.txt RFC 2806] defines the telephone scheme "tel:", "fax:" and "modem:" to handle phone communications with URIs in the same way, "mailto:" is defined for email. It's part of the list or registered schemes by IANA : [http://www.iana.org/assignments/uri-schemes Uniform Resource Identifier (URI) SCHEMES]

<pre><nowiki>
tel telephone [RFC2806]
fax fax [RFC2806]
modem modem [RFC2806]
</nowiki></pre>

It is practical to write your tel number like this.

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">+1-919-555-7878</a>
</nowiki></pre>

or even

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">Mr Smith's phone</a>
</nowiki></pre>

You can add support for "tel:" to your desktop and to your browser

* For Gnome, edit ~/.gnome/Gnome and add something to the URL Handlers section. (Dan Connolly uses this to get galeon to launch telnum from [http://dev.w3.org/cvsweb/2001/telagent/ telagent sources] for tel URIs)
* In Mozilla, [http://dizzy.mozdev.org/ Dizzy]
* In Internet Explorer, [http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp Asynchronous Pluggable Protocols]

On the CSS front… You could for example add automagically an icon. I have put the property !important for those who wants to add it to their own stylesheet in their browsers, so they know type of links when browsing.

<pre><nowiki>
a[href^="tel:"]:before {
content: '\260f ' !important;
padding-left: 20px !important; }

a[href^="mailto:"]:before {
content: '\2709 ' !important;
padding-left: 20px !important; }
</nowiki></pre>

== Encoding "modern" attributes ==

Since vCard was first established, various interactive communication technologies and addressing schemes have been widely adopted. Although there aren't specific properties for these technologies / addressing schemes, they can be captured as URLs or email addresses.

This has now been written up for the most part. See:

http://microformats.org/wiki/hcard-examples#New_Types_of_Contact_Info

Still to be addressed:

* iChat mac.com addresses, simply store "@mac.com" email addresses, e.g.
** <code><nowiki><a class="email" href="mailto:steve@mac.com">...</nowiki></code>
* MSN Instant Messenger, you can simple store "@hotmail.com" or "@msn.com" or "@passport.com" email addresses.
* Internet Relay Chat (IRC), use "irc:" URLs.

== Auto-Discovery ==

=== Representative hCard discovery ===
Ways to auto discover the representative hCard for a page, that is the hCard that means the person/owner of the page.

Applications for auto-discovery of the representative hCard for the page
* vCard auto extraction from the page
* profile icon discovery (e.g. what people use gravatar for and have proposed pavatar for).

The preferred option is to use only visible semantic HTML ([[POSH]]).

Here is a scenario that outlines the proposed auto-discovery process:

# I (as user) give the URL of my homepage or hCard or other profile URL, to a site that wants a profile icon
# That site goes and gets it (e.g. using hKit), and then:
## checks to see if there is an <nowiki><address></nowiki> hCard, and uses it if it finds it
## otherwise uses the first hCard it finds (which in cases of profile URLs which have a single hCard like on [http://flickr.com Flickr], [http://zooomr.com Zooomr], and [http://technorati.com/ Technorati], will work as expected).
# The site looks in the hCard for a "logo" property and uses the first one if it finds any.
# Otherwise it looks for a "photo" property and uses the first one if it finds any.
# Otherwise the site uses a default icon, but subscribes to the URL with the hCard and checks it for a "logo" or "photo", say, once a day.

=== vCard link rel auto-discovery ===

A similar possibility is an auto discovery link in the head of the document could point to a URL (perhaps with transform) to a vCard version of the representative hCard.

On the page with the hCard encoding, the best link would be as follows:
<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
this HTML page is an alternate view of the vCard.

The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”.

It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.

When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. Therefore rel="alternate" may not be appropriate. The problem of what rel value to use is bigger than links to vCards.

=== hCard to hCard relationships ===

There are several types of hCard to hCard relationships, that is, one hCard hyperlinking to another hCard which would beneift from the explicit rel values that described the specific relationship.

==== mini hCard to expanded hCard ====

Perhaps the most common type of hCard to hCard link is a mini hCard, e.g. from a personal home page or blog to the person's contact/about page, perhaps consisting of only a name and URL, that links to an expanded hCard. Examples in the wild:

In this instance, possible rel values might include:
* rel="expanded"
* rel="definitive" - the problem with this is that the expanded hCard is not necessarily a definitive version.
* rel="canonical" - similarly, the expanded hCard is not necessarily at a canonical URL. It may simply be *an* expanded version, not *the* expanded version.

The following rel values have been suggested, but are not really a good idea due to the fact that they imply a dependence to add a new rel value for any new microformat which might have a mini-version linking to a more expanded version:
* rel="author"
* rel='contact'
* rel="contactinfo"
* rel='hcard'
* rel='person'

Here are some more generic values that have been suggested which perhaps make even less sense:
* rel='microformat' - this doesn't make any sense when you imagine a world where nearly every web page contains microformats.
* rel='about' - what does "about" have to do with a person or even authorship?
* rel="profile" - should be reserved for meaning here is an [[xmdp|XMDP]] profile for the current page.
* rel='PIM' - not sure about how this makes any sense either.

==== mini hCard to remote site ====
Per the instructions in [[hcard-examples]] for [[hcard-examples#References_to_People_in_Blogrolls|marking up people in blogrolls]], you might have an hCard of your site for another person which then links to that other person's website. Should there be a rel value that indicates this "mini-hCard" to "person" relationship?

==== mini hCards and nearby expanded hCard links ====
Some authors include mini-hCards on their pages of themselves (e.g. in their blog posts), and yet those mini-hCards don't actually point to more expanded versions. However, sometimes they have a separate but nearby link on the same page like "about" or "contact" that does link to an expanded hCard.

E.g. on [http://factoryjoe.com/blog/ FactoryCity], blog posts have mini-hCards for "published by", e.g. (white space added for readability):
<pre><nowiki>
Published by
<span class="vcard author">
<a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
Chris Messina
</a>
</span>
</nowiki></pre>

On those same blog pages, there is a link labeled "Contact Information" that links to http://factoryjoe.com/blog/hcard/ which has an hCard with more information like phone number, birthday etc.

=== Auto-Discovery for XFN ===

An author will typically their XFN information on a specific page, rather than all pages. In particular, a specific page separate from the home page of their blog, and thus it would be useful to have an explicit rel value to assist in auto-discovery of XFN information.

This was suggested by Jens Alfke on 20050606 at the WWDC blogger's dinner.

== geo improvements ==
''See [[geo-brainstorming]]''

== Other use cases ==
*calculate and display the subject's age "as of today".
*calculate and display the subject's age at death (if a Date of Death is available)
*Generate an recurring iCal for a living subject's birthday
*Generate an recurring iCal for a dead subject's "anniversary of birth" (if a Date of Death is available)

== Issues with vCard Applications ==
See [[vcard-implementations]].

== Open Questions ==

Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile.

<pre><nowiki>
...
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a>
...
</nowiki></pre>

-- [http://suda.co.uk/ Brian Suda]

Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example:
<pre><nowiki>
<a href="http://mywebsite.com/" class="fn n">
<span class="given-name">John</span>
<span class="other-names">Q.</span>
<span class="family-name">Public</span>
</a>
</nowiki></pre>

When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN:
<pre><nowiki>
John Q. Public

John
Q.
Public
</nowiki></pre>

Either the white-space is preserved or it is not. Which should the transforming applications render?

-- [http://suda.co.uk/ Brian Suda]

A: The parsing application should follow the white space collapsing rules of the mime type it retrieves. I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.

-- [http://tantek.com/log/ Tantek]

Many of the Questions and Answers are relevant to both ["hCal"] and hCard.

Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>
<span class="agent">
<span class="vcard">
<span class="email">
<a class="internet" href="mailto:jfriday@host.com">
<dfn>
<span class="fn">Joe Friday</span>
</dfn>
</a>
</span>
<span class="tel">+1-919-555-7878</span>
<span class="title">Area Administrator, Assistant</span>
</span>
</span>
</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]
* If the answer to the above Q is "yes", why not use the following?
<pre><nowiki>
<dfn class="fn">Joe Friday</dfn>
</nowiki></pre>
or
<pre><nowiki>
<span class="agent">
<dfn class="vcard">
<span class="email">
<a class="internet" href="mailto:jfriday@host.com">
<span class="fn">Joe Friday</span>
</a>
</span>
<span class="tel">+1-919-555-7878</span>
<span class="title">Area Administrator, Assistant</span>
</dfn>
</span>
</nowiki></pre>
This would mark the entire hcard as the "defining instance".

[[User:Bob Jonkman|Bob Jonkman]] 10:07, 13 Jul 2007 (PDT)

== Applications ==
Applications that are hCard aware or can convert hCard to vCard formats.

=== Copy hCards favelet(s) ===
* I think a Favelet would work nicely here. When you find a page that is hCard friendly, you click the favlet and you get yourself a vCard. This is done! See X2V in the implementations section of the [[hcard|hCard]] spec.

=== Distributed Commentor Icons ===

* See [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hCards in your blog] for an example of hCards used for comment authors (commentors). The system used there, "Gravatars", is a centralized site that serves commentor icons that requires login etc.

What if we gave each commentor the option of hosting their own icon?

A distributed commentor icon implementation could work like this:

# Given the URL of a commentor, look for an <code><address></code> element with classname of "vcard" at the commentor's URL. The <code><address></code> element is supposed to be the contact information for the page (see [[hcard-faq|hCard FAQ]] for more info), so this makes sense.
# Next, look for the first element inside that hcard that has a classname of "logo".
# Hopefully that element is an <code><img></code>, and if so, use its src to get the commentor's icon.
# Presto. You've got distributed commentor icons!

== Spam prevention ==
hCard uses <code>mailto:</code> links, and therefore
it automatically "inherits" the disadvantage of <code>mailto:</code> links:
These links can be easily detected by emails spiders (used by spammers).

Email addresses are picked up like any other link crawled by a search engine and trustworthy crawlers may be deterred from adding emphasis while indexing these links by including rel="nofollow" (See [[rel-nofollow]]). However, email addresses used for spam are crawled by email spiders which will likely ignore this attribute.

There are ways to prevent email address detection by simple email spiders, while
still retaining full compatibility with (X)HTML applications.
One common way is to "encode" the the "m" of "mail" and "@" with character entities, yet it's unwise to follow a convention of only encoding specific characters because the email spiders can pick up on this too:

Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Example of the "encoded" link (with rel-nofollow added):
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>
</nowiki></pre>

Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.

''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)

=== Other prevention methods to consider ===
* Using server-side code to implement character entities randomly
* Displaying the address in a way thought to be only human readable (thus breaking the link):
** Using an image instead of text (could still be machine readable using OCR)
** Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
* Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
* Pointing to an email form or other URL instead of an email address

== Tutorials ==
* How to hCard encode entries in Popular blog software.
* Good reasons to publish your hCard
** as a business, get people to put you in their address book so they'll find you later
** as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.

== Parsing ==
See separate [[hcard-parsing|hCard parsing]] page for current hCard parsing rules.

Add thoughts/proposals to improve/add to hCard parsing here in this section in hCard brainstorming, and be sure to include URLs to examples of hCards in the wild which could benefit from parsing rule changes.

* Multiple Type parsing / Type Optimization: The spec allows for, and the [[hcard-authoring#Phone_Numbers|hcard-authoring]] demonstrate the use of multiple type designations for a single value of tel. The syntax used in the authoring examples where each seems like it could become cumbersome. As these type designations are all single 'word' strings it may be possible to implement additional parsing rules to allow for multiple types inside the same HTML element. Handling delimiters may be an issue [space, comma, etc?], and some in-the-wild usage of multiple types would need to be located and examined before considering additional parsing rules along these lines [ [[User:ChrisCasciano|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]
*Parsers could calculate the current age of hCard subjects, from the DoB. [[User:AndyMabbett|Andy Mabbett]] 07:47, 20 Apr 2007 (PDT)
*for hCards with DoB, parsers could generate and export a recurring hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:06, 20 Apr 2007 (PDT)
**If/ when date-of-death is added to hCard, parsers could instead generate a recurring "death-anniversary" hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:08, 20 Apr 2007 (PDT)
* ...

=== fax and modem hyperlink parsing ===
For the "tel" property in particular, when the element is:
* <code><a href="fax:..."></code> OR <code><area href="fax:..."></code> : parse the value of the 'href' attribute, omitting the "fax:" prefix and any "?" query suffix (if present), in the attribute. For details on the "fax:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "fax" in addition to any explicit subproperty type specified on the 'tel' property.
* <code><a href="modem:..."></code> OR <code><area href="modem:..."></code> : parse the value of the 'href' attribute, omitting the "modem:" prefix and any "?" query suffix (if present), in the attribute. For details on the "modem:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "modem" in addition to any explicit subproperty type specified on the 'tel' property.

== Post vCard additions ==

Keeping hCard properties and values as a 1:1 representation of vCard properties and values has numerous benefits such as simplicity, stability, interoperability with the vast number of existing vCard applications etc.

However some have found vCard to be limiting in terms of the data/properties/fields they want to express in contact information. Some implementations use vCard extensions to express such information [citation needed].

This section is for documentation of such suggested additions. Empirical evidence of actual *real world* examples on the Web of people publishing this information would be a good step towards considering any such additions/extensions.

* '''altitude'''. From [[hcard-issues]].
** Used by Wikipedia e.g. [http://en.wikipedia.org/wiki/Avers Avers]; [http://en.wikipedia.org/wiki/List_of_volcanoes_in_Argentina volcanoes in Argentina]
**Used (as "height") by PoI66 in GPS tracks, e.g [http://www.poi66.com/maps/show_earth.php?album=wip&lat=35.58756&lon=27.06803&extent=0.1&title=Beach%20van%20Lefkos%20]
**Used by Great Circle Mapper, e.g [http://gc.kls2.com/airport/BHX BHX]
**Used by UK Govt. Met Office (as "AMSL" = height Above Mean Sea Level) e.g. [http://www.metoffice.gov.uk/climate/uk/averages/19611990/sites/penkridge.html Penkridge Weather station]
**See also [[geo-elevation-examples]]
* '''vat-number''' : for VAT numbers of companies, which are used a lot in Europe and they need to be published on Belgian publications (including websites).
* '''gender'''
**most social network sites (see [[profile-examples]]) publish the gender of the individual
**Many pages publish implicit gender information, not easily machine parsable - using names (Andrew, Andrea), titles (Mr, Mrs, Miss), relationships (husband, brother), pronouns (he, she), etc. See also [[genealogy-brainstorming]]
* '''date-of-death'''
**Used by Wikipedia e.g. [http://en.wikipedia.org/wiki/John_Bonham John Bonham]
**Used in obituaries, e.g [http://www.westmidlandbirdclub.com/obituaries/norris.htm Tony Norris (WMBC)]; [http://www.guardian.co.uk/obituaries/story/0,,1725211,00.html Ivor Cutler (Guardian)]; [http://www.britarch.ac.uk/BA/ba8/ba8obit.html Grahame Clark (British Archaeology)]
**Used in grave indices e.g. [http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=676 Chico Marx]
**Used on war memorial pages [http://tinyurl.com/2ddlvq Captain Ronald Wilkinson]
**Used in biographies e.g. [http://www.oxforddnb.com/public/lotw/6.html Oxford National Dictionary of Biography]
Of course if vCard were extended itself, that may provide impetus to add such extensions to hCard in order to maintain the 1:1 representation of properties/values.

Thus see (and add to): [[vcard-suggestions]]

Another path to consider is the development of another microformat which includes an hCard and then extends it with additional properties for a particular domain. In many ways [[hresume|hResume]] has already done this. Other related efforts:
* [[genealogy]]
* [[profile]]

Using hCard as a stable building block for additional microformats may seem more desirable than incrementally growing hCard itself.

==Wikipedia's Persondata==
Wikipedia's [http://en.wikipedia.org/wiki/Wikipedia:Persondata Persondata] aligns very closely with hCard, but has additional date and place of birth & death fields. [[User:AndyMabbett|Andy Mabbett]] 13:02, 28 Jan 2007 (PST)

== TODO ==

* The [[hcard-profile]] needs verification and perhaps a URL for retrieving the actual XMDP, rather than as <pre> text on a wiki page.
* Complete translating the examples from the vCard spec into hCard, and place them on a separate hCard examples page.
* Create a "rich" but realistic hCard example, say for example for a salesperson, who wants to put a whole bunch of contact information on their website in order to be found/contacted easily.
* Provide examples of how to encode instant messaging (IM) accounts. Figure out what would the mailto: or aim: URL in hCard look like in vCard. And take a look at what vCard applications do today with IM addresses.

== CSS Styles ==
Not only can you create semantics with the hCard values, but you can add CSS styles to them as well. You are free to style the terms in any way you want, but here we can list a few ideas for how to style terms.

If you want to encode hCard data, but do NOT want to display it in the HTML code (WARNING: This is very much recommended AGAINST, and in general against the microformat principle of marking up visible data), then you can hide that tag in CSS with the following code:
<pre><nowiki>
<span style="display: none">Hidden Data</span>
</nowiki></pre>
Transforming applications will still find the data and use it when converting hCards to vCards.

== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF.

== Additional Parsing Improvements ==
=== Ambiguous name components ===

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

===ADR with no children===
Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect <code>adr</code> to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity.

Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:

*[http://en.wikipedia.org/wiki/Old_Street_station Old Street]
**"Place" ("locale" in the template) is a '''street'''
*[http://en.wikipedia.org/wiki/Hamstead_railway_station Hamstead]
**"Place" is a '''local district'''
*[http://en.wikipedia.org/wiki/Inverness_railway_station Inverness]
**"Place" is a '''city'''

Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:

*[http://en.wikipedia.org/wiki/Tesco Tesco]
*[http://en.wikipedia.org/wiki/BP BP]
*[http://en.wikipedia.org/wiki/Google Google]
*[http://en.wikipedia.org/wiki/Blue_Coat_Systems Blue Coat Systems]

I propose that, where <code>adr</code> has content, but no explicit sub-properties, there should be a default sub-property to which that content is allocated, in order that it is captured by user agents, and can later be manually tweaked (in, say, an address book programme) by users if so desired. This would satisfy the vCard requirement for child-of-adr, and adhere to the general principle to "[[be-strict|be strict in what you send but generous in what you receive]]".
*Note that there may be other reasons to consider this suggestion, such as "ease of authoring". Another way of looking at this suggestion is as a "adr/extended-address shorthand". [[User:Tantek|Tantek]] 08:28, 26 Mar 2007 (PDT)

* there is also a LABEL property which is NOT structured data, but purely a text string to be used when labeling. LABEL purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents. [[User:Brian|Brian]] 13:18, 30 Mar 2007 (UTC)
**On re-reading this, it seems that none of the adressess given in my examples meet the criteria of being "''formatted text corresponding to delivery address''". [[User:AndyMabbett|Andy Mabbett]] 03:35, 17 Apr 2007 (PDT)

Of the available sub-property options:

*street-address
*extended-address
*region
*locality

I suggest that "extended-address" is the most sensible sub-property to use, for this purpose. [[User:AndyMabbett|Andy Mabbett]] 03:57, 26 Mar 2007 (PDT)

=== INPUT element handling ===

In [[hcard-parsing]], I've defined special-case handling for several elements according to [[hcard-parsing#more_semantic_exceptions|more semantic exceptions]], e.g. textual properties on the IMG element use the 'alt' attribute.

One element I forgot at the time was the INPUT element, specifically, <nowiki><input type="text"></nowiki>.

The simple suggestion is to add the following to [[hcard-parsing]], specifically to the [[hcard-parsing#all_properties|all properties]] sub-section:

* <code><input type="text" value="..."></code>: use the value of the 'value' attribute. If there is no 'value' attribute then treat the value as empty.

[[User:Tantek|Tantek]]

==== Background discussion: ====

Key threads:
* http://microformats.org/discuss/mail/microformats-discuss/2006-September/005951.html
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006132.html
* http://microformats.org/discuss/mail/microformats-discuss/2007-January/008312.html

Somewhat related:
* http://microformats.org/wiki/rest/forms-brainstorming
* http://microformats.org/wiki/rest/forms-examples

One key summary:
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006172.html

The options discussed in a hypothetical hCard input system so far appear to be:

1) create a new root class other than vcard to indicate a form that's
fillable with hCard data.

Proposed markup:

<pre><nowiki>
<form class="vcard-input" ...>
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" />
<input type="text" class="family-name" name="last_name" />
</fieldset>
...
</form>
</nowiki></pre>

Benefits:
Doesn't overcomplicate hCard with new parsing rules,
doesn't require rewrite of existing parsers to ignore 'unparsable' data.
Drawbacks:
Requires completely new parsers to be written.
Existing parsers would ignore data even if a valid hCard could be extracted.

2) extend hCard's parsing rules to cover form elements and relying on
the FORM/INPUT semantics to indicate that stuff is inputtable.

Proposed markup:

<pre><nowiki>
<form ...>
<div class="vcard">
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" value="Rob" />
<input type="text" class="family-name" name="last_name" value="Manson" />
</fieldset>
...
</div>
<div class="vcard">
<fieldset class="fn">
<input type="text" class="given-name" name="first_name" value="Scott" />
<input type="text" class="family-name" name="last_name" value="Reynen" />
</fieldset>
...
</div>
</form>
</nowiki></pre>

Benefits:
Small addition to existing format rather than new one.
Semantics of an input form and the eventual display format are the same.
Drawbacks:
Existing parsers would/could parse forms as invalid hCards, would need re-writing.

Broader question:
* http://microformats.org/discuss/mail/microformats-discuss/2005-September/001059.html
Should this be extended beyond just hCard?

==== Key Issues/discussion points ====
* Extending parsing rules to extract value attributes from <input type="text|hidden"> fields
- ''Negative'' : this require re-coding the existing parsers
- ''Positive'' : this could help to enable uf based auto form filling
- ''Negative'' : this could help to enable uf based auto form filling (e.g. spam automation)
* Existing server side and client side scripts use non-hCard field names so class is the most seamless extension point
- ''Positive'' : this is in line with the current parsing model
* Many parsers (e.g. operator) parse the loaded html not the dynamic DOM
- ''Negative'' : parser doesn't pickup any updated form data after the page has loaded
- e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported
* Forms may contain more than one hCard so using <FORM class="vcard"> should not be required
- ''Positive'' : this minimises the changes to current parsing rules
* Empty values should be ignored when extracting hCards
* hCards with all empty values should be ignored when listing/extracting hCards
* Which form elements should be supported beyond input fields
- ''Examples''
- title select that lists mr/mrs/ms/dr/etc.
- checkboxes to choose which addresses to use
- ''Option'' : simplify extension to only support input fields and recommend that select's, radio buttons and checkboxes update related hidden input fields with simple javascript (e.g. onChange/Click="this.form.elements[this.className].value = this.value")
- ''Positive'' : this would simplify parsing and server side form processing as only single input fields for each value need to be used/validated
- ''Negative'' : hCard forms then require javascript if they use form elements other than basic <input type="text|hidden">
- ''Comment'' : either way any auto form filling will be more complex beyond simple <input type="text|hidden"> fields

[[User:RobManson|RobManson]]

== Accepted Suggestions ==

=== Encoding Company data as a Business Card (proposal) ===

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Implied "FN and N" Optimization (proposal) ===

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

BACKGROUND:

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== Rejected Suggestions ==

Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>
<span class="vcard">
...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...
</span>
</nowiki></pre>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

== References ==
=== Normative References ===
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC
* [http://gmpg.org/xmdp/ XMDP]
=== Informative References ===
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]
* [http://www.icao.int/mrtd/download/technical.cfm ICAO - Machine Readable Travel Documents format]

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

User:RobManson

2007-07-18T01:01:03Z

RobManson: Added public domain release to my profile

hcard-brainstorming

2007-07-13T14:13:47Z

RobManson: Summarised list of issues/options to discuss/resolve

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

__TOC__

== Authors ==
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/log/ Tantek Çelik], [http://technorati.com Technorati, Inc]

== Contributors ==
* [[User:Atamido|Atamido]]
* [[User:ChrisMessina|ChrisMessina]]
* [[User:DimitriGlazkov|DimitriGlazkov]]
* ...
* ... and many others

== Problems Being Solved ==

Some of the problems that [[hcard|hCard]] helps to solve:

* having to enter business cards that go out of date (subscribe to someone's syndicated [[hcard|hCard]] instead).
* annoying "update your contact info" email from various centralized contact info services

== FN Nickname semantic ==

There are many sites (e.g. [http://flickr.com Flickr], [http://consumating.com/ Consumating]) which permit the user to '''both''' have a multi-word login/handle/alias, '''and''' not show their ''real'' name (fn, n, given-name, family-name etc.).

For the people represented by the profile pages of these sites, the best we can do is mark-up their login/handle/alias as their "nickname". Originally, we had thought that such handles etc. were single words only, and thus we created the [[hcard#Implied_.22nickname.22_Optimization|Implied nickname optimization]] accordingly, where you can markup the handle as an "fn", and have it automatically set a "nickname" property value, and empty values for all the "n" sub-values.

In order to deal with multi-word handles, similar to the [[hcard#Organization_Contact_Info|hCard Organization contact info]] method, the following is proposed:

=== "fn" and "nickname" combination ===

Due to the use of potentially multi-word nicknames/handles/usernames in content published on the Web, (e.g. on sites like [http://flickr.com Flickr] and [http://consumating.com/ Consumating]), hCard has a mechanism for specifying a multi-word "fn" that is also a "nickname" without affecting any "n" sub-properties that are otherwise specified, and explicitly implying empty defaults for "n" sub-properties.

Similar to the [[hcard#Implied_.22nickname.22_Optimization|implied "nickname" optimization]], if the "fn" property and a "nickname" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn nickname"</code>), then

# The content of the "fn" is treated as a "nickname" property value.
# Parsers should handle the missing "n" property by implying empty values for all the "n" sub-properties.

== Examples ==

* See [[hcard-examples]], which provides several illustrative instructive examples, as well as 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

=== Using RFC2806 with hCard ===

[http://www.ietf.org/rfc/rfc2806.txt RFC 2806] defines the telephone scheme "tel:", "fax:" and "modem:" to handle phone communications with URIs in the same way, "mailto:" is defined for email. It's part of the list or registered schemes by IANA : [http://www.iana.org/assignments/uri-schemes Uniform Resource Identifier (URI) SCHEMES]

<pre><nowiki>
tel telephone [RFC2806]
fax fax [RFC2806]
modem modem [RFC2806]
</nowiki></pre>

It is practical to write your tel number like this.

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">+1-919-555-7878</a>
</nowiki></pre>

or even

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">Mr Smith's phone</a>
</nowiki></pre>

You can add support for "tel:" to your desktop and to your browser

* For Gnome, edit ~/.gnome/Gnome and add something to the URL Handlers section. (Dan Connolly uses this to get galeon to launch telnum from [http://dev.w3.org/cvsweb/2001/telagent/ telagent sources] for tel URIs)
* In Mozilla, [http://dizzy.mozdev.org/ Dizzy]
* In Internet Explorer, [http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp Asynchronous Pluggable Protocols]

On the CSS front… You could for example add automagically an icon. I have put the property !important for those who wants to add it to their own stylesheet in their browsers, so they know type of links when browsing.

<pre><nowiki>
a[href^="tel:"]:before {
content: '\260f ' !important;
padding-left: 20px !important; }

a[href^="mailto:"]:before {
content: '\2709 ' !important;
padding-left: 20px !important; }
</nowiki></pre>

== Encoding "modern" attributes ==

Since vCard was first established, various interactive communication technologies and addressing schemes have been widely adopted. Although there aren't specific properties for these technologies / addressing schemes, they can be captured as URLs or email addresses.

This has now been written up for the most part. See:

http://microformats.org/wiki/hcard-examples#New_Types_of_Contact_Info

Still to be addressed:

* iChat mac.com addresses, simply store "@mac.com" email addresses, e.g.
** <code><nowiki><a class="email" href="mailto:steve@mac.com">...</nowiki></code>
* MSN Instant Messenger, you can simple store "@hotmail.com" or "@msn.com" or "@passport.com" email addresses.
* Internet Relay Chat (IRC), use "irc:" URLs.

== Auto-Discovery ==

=== Representative hCard discovery ===
Ways to auto discover the representative hCard for a page, that is the hCard that means the person/owner of the page.

Applications for auto-discovery of the representative hCard for the page
* vCard auto extraction from the page
* profile icon discovery (e.g. what people use gravatar for and have proposed pavatar for).

The preferred option is to use only visible semantic HTML ([[POSH]]).

Here is a scenario that outlines the proposed auto-discovery process:

# I (as user) give the URL of my homepage or hCard or other profile URL, to a site that wants a profile icon
# That site goes and gets it (e.g. using hKit), and then:
## checks to see if there is an <nowiki><address></nowiki> hCard, and uses it if it finds it
## otherwise uses the first hCard it finds (which in cases of profile URLs which have a single hCard like on [http://flickr.com Flickr], [http://zooomr.com Zooomr], and [http://technorati.com/ Technorati], will work as expected).
# The site looks in the hCard for a "logo" property and uses the first one if it finds any.
# Otherwise it looks for a "photo" property and uses the first one if it finds any.
# Otherwise the site uses a default icon, but subscribes to the URL with the hCard and checks it for a "logo" or "photo", say, once a day.

=== vCard link rel auto-discovery ===

A similar possibility is an auto discovery link in the head of the document could point to a URL (perhaps with transform) to a vCard version of the representative hCard.

On the page with the hCard encoding, the best link would be as follows:
<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
this HTML page is an alternate view of the vCard.

The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”.

It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.

When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. Therefore rel="alternate" may not be appropriate. The problem of what rel value to use is bigger than links to vCards.

=== hCard to hCard relationships ===

There are several types of hCard to hCard relationships, that is, one hCard hyperlinking to another hCard which would beneift from the explicit rel values that described the specific relationship.

==== mini hCard to expanded hCard ====

Perhaps the most common type of hCard to hCard link is a mini hCard, e.g. from a personal home page or blog to the person's contact/about page, perhaps consisting of only a name and URL, that links to an expanded hCard. Examples in the wild:

In this instance, possible rel values might include:
* rel="expanded"
* rel="definitive" - the problem with this is that the expanded hCard is not necessarily a definitive version.
* rel="canonical" - similarly, the expanded hCard is not necessarily at a canonical URL. It may simply be *an* expanded version, not *the* expanded version.

The following rel values have been suggested, but are not really a good idea due to the fact that they imply a dependence to add a new rel value for any new microformat which might have a mini-version linking to a more expanded version:
* rel="author"
* rel='contact'
* rel="contactinfo"
* rel='hcard'
* rel='person'

Here are some more generic values that have been suggested which perhaps make even less sense:
* rel='microformat' - this doesn't make any sense when you imagine a world where nearly every web page contains microformats.
* rel='about' - what does "about" have to do with a person or even authorship?
* rel="profile" - should be reserved for meaning here is an [[xmdp|XMDP]] profile for the current page.
* rel='PIM' - not sure about how this makes any sense either.

==== mini hCard to remote site ====
Per the instructions in [[hcard-examples]] for [[hcard-examples#References_to_People_in_Blogrolls|marking up people in blogrolls]], you might have an hCard of your site for another person which then links to that other person's website. Should there be a rel value that indicates this "mini-hCard" to "person" relationship?

==== mini hCards and nearby expanded hCard links ====
Some authors include mini-hCards on their pages of themselves (e.g. in their blog posts), and yet those mini-hCards don't actually point to more expanded versions. However, sometimes they have a separate but nearby link on the same page like "about" or "contact" that does link to an expanded hCard.

E.g. on [http://factoryjoe.com/blog/ FactoryCity], blog posts have mini-hCards for "published by", e.g. (white space added for readability):
<pre><nowiki>
Published by
<span class="vcard author">
<a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
Chris Messina
</a>
</span>
</nowiki></pre>

On those same blog pages, there is a link labeled "Contact Information" that links to http://factoryjoe.com/blog/hcard/ which has an hCard with more information like phone number, birthday etc.

=== Auto-Discovery for XFN ===

An author will typically their XFN information on a specific page, rather than all pages. In particular, a specific page separate from the home page of their blog, and thus it would be useful to have an explicit rel value to assist in auto-discovery of XFN information.

This was suggested by Jens Alfke on 20050606 at the WWDC blogger's dinner.

== geo improvements ==
''See [[geo-brainstorming]]''

== Other use cases ==
*calculate and display the subject's age "as of today".
*calculate and display the subject's age at death (if a Date of Death is available)
*Generate an recurring iCal for a living subject's birthday
*Generate an recurring iCal for a dead subject's "anniversary of birth" (if a Date of Death is available)

== Issues with vCard Applications ==
See [[vcard-implementations]].

== Open Questions ==

Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile.

<pre><nowiki>
...
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a>
...
</nowiki></pre>

-- [http://suda.co.uk/ Brian Suda]

Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example:
<pre><nowiki>
<a href="http://mywebsite.com/" class="fn n">
<span class="given-name">John</span>
<span class="other-names">Q.</span>
<span class="family-name">Public</span>
</a>
</nowiki></pre>

When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN:
<pre><nowiki>
John Q. Public

John
Q.
Public
</nowiki></pre>

Either the white-space is preserved or it is not. Which should the transforming applications render?

-- [http://suda.co.uk/ Brian Suda]

A: The parsing application should follow the white space collapsing rules of the mime type it retrieves. I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.

-- [http://tantek.com/log/ Tantek]

Many of the Questions and Answers are relevant to both ["hCal"] and hCard.

Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>
<span class="agent">
<span class="vcard">
<span class="email">
<a class="internet" href="mailto:jfriday@host.com">
<dfn>
<span class="fn">Joe Friday</span>
</dfn>
</a>
</span>
<span class="tel">+1-919-555-7878</span>
<span class="title">Area Administrator, Assistant</span>
</span>
</span>
</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]

== Applications ==
Applications that are hCard aware or can convert hCard to vCard formats.

=== Copy hCards favelet(s) ===
* I think a Favelet would work nicely here. When you find a page that is hCard friendly, you click the favlet and you get yourself a vCard. This is done! See X2V in the implementations section of the [[hcard|hCard]] spec.

=== Distributed Commentor Icons ===

* See [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hCards in your blog] for an example of hCards used for comment authors (commentors). The system used there, "Gravatars", is a centralized site that serves commentor icons that requires login etc.

What if we gave each commentor the option of hosting their own icon?

A distributed commentor icon implementation could work like this:

# Given the URL of a commentor, look for an <code><address></code> element with classname of "vcard" at the commentor's URL. The <code><address></code> element is supposed to be the contact information for the page (see [[hcard-faq|hCard FAQ]] for more info), so this makes sense.
# Next, look for the first element inside that hcard that has a classname of "logo".
# Hopefully that element is an <code><img></code>, and if so, use its src to get the commentor's icon.
# Presto. You've got distributed commentor icons!

== Spam prevention ==
hCard uses <code>mailto:</code> links, and therefore
it automatically "inherits" the disadvantage of <code>mailto:</code> links:
These links can be easily detected by emails spiders (used by spammers).

Email addresses are picked up like any other link crawled by a search engine and trustworthy crawlers may be deterred from adding emphasis while indexing these links by including rel="nofollow" (See [[rel-nofollow]]). However, email addresses used for spam are crawled by email spiders which will likely ignore this attribute.

There are ways to prevent email address detection by simple email spiders, while
still retaining full compatibility with (X)HTML applications.
One common way is to "encode" the the "m" of "mail" and "@" with character entities, yet it's unwise to follow a convention of only encoding specific characters because the email spiders can pick up on this too:

Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Example of the "encoded" link (with rel-nofollow added):
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>
</nowiki></pre>

Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.

''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)

=== Other prevention methods to consider ===
* Using server-side code to implement character entities randomly
* Displaying the address in a way thought to be only human readable (thus breaking the link):
** Using an image instead of text (could still be machine readable using OCR)
** Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
* Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
* Pointing to an email form or other URL instead of an email address

== Tutorials ==
* How to hCard encode entries in Popular blog software.
* Good reasons to publish your hCard
** as a business, get people to put you in their address book so they'll find you later
** as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.

== Parsing ==
See separate [[hcard-parsing|hCard parsing]] page for current hCard parsing rules.

Add thoughts/proposals to improve/add to hCard parsing here in this section in hCard brainstorming, and be sure to include URLs to examples of hCards in the wild which could benefit from parsing rule changes.

* Multiple Type parsing / Type Optimization: The spec allows for, and the [[hcard-authoring#Phone_Numbers|hcard-authoring]] demonstrate the use of multiple type designations for a single value of tel. The syntax used in the authoring examples where each seems like it could become cumbersome. As these type designations are all single 'word' strings it may be possible to implement additional parsing rules to allow for multiple types inside the same HTML element. Handling delimiters may be an issue [space, comma, etc?], and some in-the-wild usage of multiple types would need to be located and examined before considering additional parsing rules along these lines [ [[User:ChrisCasciano|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]
*Parsers could calculate the current age of hCard subjects, from the DoB. [[User:AndyMabbett|Andy Mabbett]] 07:47, 20 Apr 2007 (PDT)
*for hCards with DoB, parsers could generate and export a recurring hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:06, 20 Apr 2007 (PDT)
**If/ when date-of-death is added to hCard, parsers could instead generate a recurring "death-anniversary" hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:08, 20 Apr 2007 (PDT)
* ...

=== fax and modem hyperlink parsing ===
For the "tel" property in particular, when the element is:
* <code><a href="fax:..."></code> OR <code><area href="fax:..."></code> : parse the value of the 'href' attribute, omitting the "fax:" prefix and any "?" query suffix (if present), in the attribute. For details on the "fax:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "fax" in addition to any explicit subproperty type specified on the 'tel' property.
* <code><a href="modem:..."></code> OR <code><area href="modem:..."></code> : parse the value of the 'href' attribute, omitting the "modem:" prefix and any "?" query suffix (if present), in the attribute. For details on the "modem:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "modem" in addition to any explicit subproperty type specified on the 'tel' property.

== Post vCard additions ==

Keeping hCard properties and values as a 1:1 representation of vCard properties and values has numerous benefits such as simplicity, stability, interoperability with the vast number of existing vCard applications etc.

However some have found vCard to be limiting in terms of the data/properties/fields they want to express in contact information. Some implementations use vCard extensions to express such information [citation needed].

This section is for documentation of such suggested additions. Empirical evidence of actual *real world* examples on the Web of people publishing this information would be a good step towards considering any such additions/extensions.

* '''altitude'''. From [[hcard-issues]].
** Used by Wikipedia e.g. [http://en.wikipedia.org/wiki/Avers Avers]; [http://en.wikipedia.org/wiki/List_of_volcanoes_in_Argentina volcanoes in Argentina]
**Used (as "height") by PoI66 in GPS tracks, e.g [http://www.poi66.com/maps/show_earth.php?album=wip&lat=35.58756&lon=27.06803&extent=0.1&title=Beach%20van%20Lefkos%20]
**Used by Great Circle Mapper, e.g [http://gc.kls2.com/airport/BHX BHX]
**Used by UK Govt. Met Office (as "AMSL" = height Above Mean Sea Level) e.g. [http://www.metoffice.gov.uk/climate/uk/averages/19611990/sites/penkridge.html Penkridge Weather station]
**See also [[geo-elevation-examples]]
* '''vat-number''' : for VAT numbers of companies, which are used a lot in Europe and they need to be published on Belgian publications (including websites).
* '''gender'''
**most social network sites (see [[profile-examples]]) publish the gender of the individual
**Many pages publish implicit gender information, not easily machine parsable - using names (Andrew, Andrea), titles (Mr, Mrs, Miss), relationships (husband, brother), pronouns (he, she), etc. See also [[genealogy-brainstorming]]
* '''date-of-death'''
**Used by Wikipedia e.g. [http://en.wikipedia.org/wiki/John_Bonham John Bonham]
**Used in obituaries, e.g [http://www.westmidlandbirdclub.com/obituaries/norris.htm Tony Norris (WMBC)]; [http://www.guardian.co.uk/obituaries/story/0,,1725211,00.html Ivor Cutler (Guardian)]; [http://www.britarch.ac.uk/BA/ba8/ba8obit.html Grahame Clark (British Archaeology)]
**Used in grave indices e.g. [http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=676 Chico Marx]
**Used on war memorial pages [http://tinyurl.com/2ddlvq Captain Ronald Wilkinson]
**Used in biographies e.g. [http://www.oxforddnb.com/public/lotw/6.html Oxford National Dictionary of Biography]
Of course if vCard were extended itself, that may provide impetus to add such extensions to hCard in order to maintain the 1:1 representation of properties/values.

Thus see (and add to): [[vcard-suggestions]]

Another path to consider is the development of another microformat which includes an hCard and then extends it with additional properties for a particular domain. In many ways [[hresume|hResume]] has already done this. Other related efforts:
* [[genealogy]]
* [[profile]]

Using hCard as a stable building block for additional microformats may seem more desirable than incrementally growing hCard itself.

==Wikipedia's Persondata==
Wikipedia's [http://en.wikipedia.org/wiki/Wikipedia:Persondata Persondata] aligns very closely with hCard, but has additional date and place of birth & death fields. [[User:AndyMabbett|Andy Mabbett]] 13:02, 28 Jan 2007 (PST)

== TODO ==

* The [[hcard-profile]] needs verification and perhaps a URL for retrieving the actual XMDP, rather than as <pre> text on a wiki page.
* Complete translating the examples from the vCard spec into hCard, and place them on a separate hCard examples page.
* Create a "rich" but realistic hCard example, say for example for a salesperson, who wants to put a whole bunch of contact information on their website in order to be found/contacted easily.
* Provide examples of how to encode instant messaging (IM) accounts. Figure out what would the mailto: or aim: URL in hCard look like in vCard. And take a look at what vCard applications do today with IM addresses.

== CSS Styles ==
Not only can you create semantics with the hCard values, but you can add CSS styles to them as well. You are free to style the terms in any way you want, but here we can list a few ideas for how to style terms.

If you want to encode hCard data, but do NOT want to display it in the HTML code (WARNING: This is very much recommended AGAINST, and in general against the microformat principle of marking up visible data), then you can hide that tag in CSS with the following code:
<pre><nowiki>
<span style="display: none">Hidden Data</span>
</nowiki></pre>
Transforming applications will still find the data and use it when converting hCards to vCards.

== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF.

== Additional Parsing Improvements ==
=== Ambiguous name components ===

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

===ADR with no children===
Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect <code>adr</code> to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity.

Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:

*[http://en.wikipedia.org/wiki/Old_Street_station Old Street]
**"Place" ("locale" in the template) is a '''street'''
*[http://en.wikipedia.org/wiki/Hamstead_railway_station Hamstead]
**"Place" is a '''local district'''
*[http://en.wikipedia.org/wiki/Inverness_railway_station Inverness]
**"Place" is a '''city'''

Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:

*[http://en.wikipedia.org/wiki/Tesco Tesco]
*[http://en.wikipedia.org/wiki/BP BP]
*[http://en.wikipedia.org/wiki/Google Google]
*[http://en.wikipedia.org/wiki/Blue_Coat_Systems Blue Coat Systems]

I propose that, where <code>adr</code> has content, but no explicit sub-properties, there should be a default sub-property to which that content is allocated, in order that it is captured by user agents, and can later be manually tweaked (in, say, an address book programme) by users if so desired. This would satisfy the vCard requirement for child-of-adr, and adhere to the general principle to "[[be-strict|be strict in what you send but generous in what you receive]]".
*Note that there may be other reasons to consider this suggestion, such as "ease of authoring". Another way of looking at this suggestion is as a "adr/extended-address shorthand". [[User:Tantek|Tantek]] 08:28, 26 Mar 2007 (PDT)

* there is also a LABEL property which is NOT structured data, but purely a text string to be used when labeling. LABEL purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents. [[User:Brian|Brian]] 13:18, 30 Mar 2007 (UTC)
**On re-reading this, it seems that none of the adressess given in my examples meet the criteria of being "''formatted text corresponding to delivery address''". [[User:AndyMabbett|Andy Mabbett]] 03:35, 17 Apr 2007 (PDT)

Of the available sub-property options:

*street-address
*extended-address
*region
*locality

I suggest that "extended-address" is the most sensible sub-property to use, for this purpose. [[User:AndyMabbett|Andy Mabbett]] 03:57, 26 Mar 2007 (PDT)

=== INPUT element handling ===

In [[hcard-parsing]], I've defined special-case handling for several elements according to [[hcard-parsing#more_semantic_exceptions|more semantic exceptions]], e.g. textual properties on the IMG element use the 'alt' attribute.

One element I forgot at the time was the INPUT element, specifically, <nowiki><input type="text"></nowiki>.

The simple suggestion is to add the following to [[hcard-parsing]], specifically to the [[hcard-parsing#all_properties|all properties]] sub-section:

* <code><input type="text" value="..."></code>: use the value of the 'value' attribute. If there is no 'value' attribute then treat the value as empty.

[[User:Tantek|Tantek]]

==== Background discussion: ====

Key threads:
* http://microformats.org/discuss/mail/microformats-discuss/2006-September/005951.html
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006132.html
* http://microformats.org/discuss/mail/microformats-discuss/2007-January/008312.html

Somewhat related:
* http://microformats.org/wiki/rest/forms-brainstorming
* http://microformats.org/wiki/rest/forms-examples

One key summary:
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006172.html
The options discussed in a hypothetical hCard input system so far appear to be:
1) create a new root class other than vcard to indicate a form that's
fillable with hCard data.

Benefits:
Doesn't overcomplicate hCard with new parsing rules,
doesn't require rewrite of existing parsers to ignore 'unparsable' data.
Drawbacks:
Requires completely new parsers to be written.
Existing parsers would ignore data even if a valid hCard could be extracted.

2) extend hCard's parsing rules to cover form elements and relying on
the FORM/INPUT semantics to indicate that stuff is inputtable.

Benefits:
Small addition to existing format rather than new one.
Semantics of an input form and the eventual display format are the same.
Drawbacks:
Existing parsers would/could parse forms as invalid hCards, would need re-writing.

Broader question:
* http://microformats.org/discuss/mail/microformats-discuss/2005-September/001059.html
Should this be extended beyond just hCard?

==== Key Issues/discussion points ====
* Extending parsing rules to extract value attributes from <input type="text|hidden"> fields
- ''Negative'' : this require re-coding the existing parsers
- ''Positive'' : this could help to enable uf based auto form filling
- ''Negative'' : this could help to enable uf based auto form filling (e.g. spam automation)
* Existing server side and client side scripts use non-hCard field names so class is the most seamless extension point
- ''Positive'' : this is in line with the current parsing model
* Many parsers (e.g. operator) parse the loaded html not the dynamic DOM
- ''Negative'' : parser doesn't pickup any updated form data after the page has loaded
- e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported
* Forms may contain more than one hCard so using <FORM class="vcard"> should not be required
- ''Positive'' : this minimises the changes to current parsing rules
* Empty values should be ignored when extracting hCards
* hCards with all empty values should be ignored when listing/extracting hCards
* Which form elements should be supported beyond input fields
- ''Examples''
- title select that lists mr/mrs/ms/dr/etc.
- checkboxes to choose which addresses to use
- ''Option'' : simplify extension to only support input fields and recommend that select's, radio buttons and checkboxes update related hidden input fields with simple javascript (e.g. onChange/Click="this.form.elements[this.className].value = this.value")
- ''Positive'' : this would simplify parsing and server side form processing as only single input fields for each value need to be used/validated
- ''Negative'' : hCard forms then require javascript if they use form elements other than basic <input type="text|hidden">
- ''Comment'' : either way any auto form filling will be more complex beyond simple <input type="text|hidden"> fields

[[User:RobManson|RobManson]]

== Accepted Suggestions ==

=== Encoding Company data as a Business Card (proposal) ===

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Implied "FN and N" Optimization (proposal) ===

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

BACKGROUND:

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== Rejected Suggestions ==

Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>
<span class="vcard">
...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...
</span>
</nowiki></pre>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

== References ==
=== Normative References ===
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC
* [http://gmpg.org/xmdp/ XMDP]
=== Informative References ===
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]
* [http://www.icao.int/mrtd/download/technical.cfm ICAO - Machine Readable Travel Documents format]

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

hcard-brainstorming

2007-07-13T13:25:55Z

RobManson: Added broader question from the mail list

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

__TOC__

== Authors ==
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/log/ Tantek Çelik], [http://technorati.com Technorati, Inc]

== Contributors ==
* [[User:Atamido|Atamido]]
* [[User:ChrisMessina|ChrisMessina]]
* [[User:DimitriGlazkov|DimitriGlazkov]]
* ...
* ... and many others

== Problems Being Solved ==

Some of the problems that [[hcard|hCard]] helps to solve:

* having to enter business cards that go out of date (subscribe to someone's syndicated [[hcard|hCard]] instead).
* annoying "update your contact info" email from various centralized contact info services

== FN Nickname semantic ==

There are many sites (e.g. [http://flickr.com Flickr], [http://consumating.com/ Consumating]) which permit the user to '''both''' have a multi-word login/handle/alias, '''and''' not show their ''real'' name (fn, n, given-name, family-name etc.).

For the people represented by the profile pages of these sites, the best we can do is mark-up their login/handle/alias as their "nickname". Originally, we had thought that such handles etc. were single words only, and thus we created the [[hcard#Implied_.22nickname.22_Optimization|Implied nickname optimization]] accordingly, where you can markup the handle as an "fn", and have it automatically set a "nickname" property value, and empty values for all the "n" sub-values.

In order to deal with multi-word handles, similar to the [[hcard#Organization_Contact_Info|hCard Organization contact info]] method, the following is proposed:

=== "fn" and "nickname" combination ===

Due to the use of potentially multi-word nicknames/handles/usernames in content published on the Web, (e.g. on sites like [http://flickr.com Flickr] and [http://consumating.com/ Consumating]), hCard has a mechanism for specifying a multi-word "fn" that is also a "nickname" without affecting any "n" sub-properties that are otherwise specified, and explicitly implying empty defaults for "n" sub-properties.

Similar to the [[hcard#Implied_.22nickname.22_Optimization|implied "nickname" optimization]], if the "fn" property and a "nickname" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn nickname"</code>), then

# The content of the "fn" is treated as a "nickname" property value.
# Parsers should handle the missing "n" property by implying empty values for all the "n" sub-properties.

== Examples ==

* See [[hcard-examples]], which provides several illustrative instructive examples, as well as 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

=== Using RFC2806 with hCard ===

[http://www.ietf.org/rfc/rfc2806.txt RFC 2806] defines the telephone scheme "tel:", "fax:" and "modem:" to handle phone communications with URIs in the same way, "mailto:" is defined for email. It's part of the list or registered schemes by IANA : [http://www.iana.org/assignments/uri-schemes Uniform Resource Identifier (URI) SCHEMES]

<pre><nowiki>
tel telephone [RFC2806]
fax fax [RFC2806]
modem modem [RFC2806]
</nowiki></pre>

It is practical to write your tel number like this.

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">+1-919-555-7878</a>
</nowiki></pre>

or even

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">Mr Smith's phone</a>
</nowiki></pre>

You can add support for "tel:" to your desktop and to your browser

* For Gnome, edit ~/.gnome/Gnome and add something to the URL Handlers section. (Dan Connolly uses this to get galeon to launch telnum from [http://dev.w3.org/cvsweb/2001/telagent/ telagent sources] for tel URIs)
* In Mozilla, [http://dizzy.mozdev.org/ Dizzy]
* In Internet Explorer, [http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp Asynchronous Pluggable Protocols]

On the CSS front… You could for example add automagically an icon. I have put the property !important for those who wants to add it to their own stylesheet in their browsers, so they know type of links when browsing.

<pre><nowiki>
a[href^="tel:"]:before {
content: '\260f ' !important;
padding-left: 20px !important; }

a[href^="mailto:"]:before {
content: '\2709 ' !important;
padding-left: 20px !important; }
</nowiki></pre>

== Encoding "modern" attributes ==

Since vCard was first established, various interactive communication technologies and addressing schemes have been widely adopted. Although there aren't specific properties for these technologies / addressing schemes, they can be captured as URLs or email addresses.

This has now been written up for the most part. See:

http://microformats.org/wiki/hcard-examples#New_Types_of_Contact_Info

Still to be addressed:

* iChat mac.com addresses, simply store "@mac.com" email addresses, e.g.
** <code><nowiki><a class="email" href="mailto:steve@mac.com">...</nowiki></code>
* MSN Instant Messenger, you can simple store "@hotmail.com" or "@msn.com" or "@passport.com" email addresses.
* Internet Relay Chat (IRC), use "irc:" URLs.

== Auto-Discovery ==

=== Representative hCard discovery ===
Ways to auto discover the representative hCard for a page, that is the hCard that means the person/owner of the page.

Applications for auto-discovery of the representative hCard for the page
* vCard auto extraction from the page
* profile icon discovery (e.g. what people use gravatar for and have proposed pavatar for).

The preferred option is to use only visible semantic HTML ([[POSH]]).

Here is a scenario that outlines the proposed auto-discovery process:

# I (as user) give the URL of my homepage or hCard or other profile URL, to a site that wants a profile icon
# That site goes and gets it (e.g. using hKit), and then:
## checks to see if there is an <nowiki><address></nowiki> hCard, and uses it if it finds it
## otherwise uses the first hCard it finds (which in cases of profile URLs which have a single hCard like on [http://flickr.com Flickr], [http://zooomr.com Zooomr], and [http://technorati.com/ Technorati], will work as expected).
# The site looks in the hCard for a "logo" property and uses the first one if it finds any.
# Otherwise it looks for a "photo" property and uses the first one if it finds any.
# Otherwise the site uses a default icon, but subscribes to the URL with the hCard and checks it for a "logo" or "photo", say, once a day.

=== vCard link rel auto-discovery ===

A similar possibility is an auto discovery link in the head of the document could point to a URL (perhaps with transform) to a vCard version of the representative hCard.

On the page with the hCard encoding, the best link would be as follows:
<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
this HTML page is an alternate view of the vCard.

The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”.

It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.

When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. Therefore rel="alternate" may not be appropriate. The problem of what rel value to use is bigger than links to vCards.

=== hCard to hCard relationships ===

There are several types of hCard to hCard relationships, that is, one hCard hyperlinking to another hCard which would beneift from the explicit rel values that described the specific relationship.

==== mini hCard to expanded hCard ====

Perhaps the most common type of hCard to hCard link is a mini hCard, e.g. from a personal home page or blog to the person's contact/about page, perhaps consisting of only a name and URL, that links to an expanded hCard. Examples in the wild:

In this instance, possible rel values might include:
* rel="expanded"
* rel="definitive" - the problem with this is that the expanded hCard is not necessarily a definitive version.
* rel="canonical" - similarly, the expanded hCard is not necessarily at a canonical URL. It may simply be *an* expanded version, not *the* expanded version.

The following rel values have been suggested, but are not really a good idea due to the fact that they imply a dependence to add a new rel value for any new microformat which might have a mini-version linking to a more expanded version:
* rel="author"
* rel='contact'
* rel="contactinfo"
* rel='hcard'
* rel='person'

Here are some more generic values that have been suggested which perhaps make even less sense:
* rel='microformat' - this doesn't make any sense when you imagine a world where nearly every web page contains microformats.
* rel='about' - what does "about" have to do with a person or even authorship?
* rel="profile" - should be reserved for meaning here is an [[xmdp|XMDP]] profile for the current page.
* rel='PIM' - not sure about how this makes any sense either.

==== mini hCard to remote site ====
Per the instructions in [[hcard-examples]] for [[hcard-examples#References_to_People_in_Blogrolls|marking up people in blogrolls]], you might have an hCard of your site for another person which then links to that other person's website. Should there be a rel value that indicates this "mini-hCard" to "person" relationship?

==== mini hCards and nearby expanded hCard links ====
Some authors include mini-hCards on their pages of themselves (e.g. in their blog posts), and yet those mini-hCards don't actually point to more expanded versions. However, sometimes they have a separate but nearby link on the same page like "about" or "contact" that does link to an expanded hCard.

E.g. on [http://factoryjoe.com/blog/ FactoryCity], blog posts have mini-hCards for "published by", e.g. (white space added for readability):
<pre><nowiki>
Published by
<span class="vcard author">
<a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
Chris Messina
</a>
</span>
</nowiki></pre>

On those same blog pages, there is a link labeled "Contact Information" that links to http://factoryjoe.com/blog/hcard/ which has an hCard with more information like phone number, birthday etc.

=== Auto-Discovery for XFN ===

An author will typically their XFN information on a specific page, rather than all pages. In particular, a specific page separate from the home page of their blog, and thus it would be useful to have an explicit rel value to assist in auto-discovery of XFN information.

This was suggested by Jens Alfke on 20050606 at the WWDC blogger's dinner.

== geo improvements ==
''See [[geo-brainstorming]]''

== Other use cases ==
*calculate and display the subject's age "as of today".
*calculate and display the subject's age at death (if a Date of Death is available)
*Generate an recurring iCal for a living subject's birthday
*Generate an recurring iCal for a dead subject's "anniversary of birth" (if a Date of Death is available)

== Issues with vCard Applications ==
See [[vcard-implementations]].

== Open Questions ==

Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile.

<pre><nowiki>
...
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a>
...
</nowiki></pre>

-- [http://suda.co.uk/ Brian Suda]

Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example:
<pre><nowiki>
<a href="http://mywebsite.com/" class="fn n">
<span class="given-name">John</span>
<span class="other-names">Q.</span>
<span class="family-name">Public</span>
</a>
</nowiki></pre>

When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN:
<pre><nowiki>
John Q. Public

John
Q.
Public
</nowiki></pre>

Either the white-space is preserved or it is not. Which should the transforming applications render?

-- [http://suda.co.uk/ Brian Suda]

A: The parsing application should follow the white space collapsing rules of the mime type it retrieves. I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.

-- [http://tantek.com/log/ Tantek]

Many of the Questions and Answers are relevant to both ["hCal"] and hCard.

Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>
<span class="agent">
<span class="vcard">
<span class="email">
<a class="internet" href="mailto:jfriday@host.com">
<dfn>
<span class="fn">Joe Friday</span>
</dfn>
</a>
</span>
<span class="tel">+1-919-555-7878</span>
<span class="title">Area Administrator, Assistant</span>
</span>
</span>
</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]

== Applications ==
Applications that are hCard aware or can convert hCard to vCard formats.

=== Copy hCards favelet(s) ===
* I think a Favelet would work nicely here. When you find a page that is hCard friendly, you click the favlet and you get yourself a vCard. This is done! See X2V in the implementations section of the [[hcard|hCard]] spec.

=== Distributed Commentor Icons ===

* See [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hCards in your blog] for an example of hCards used for comment authors (commentors). The system used there, "Gravatars", is a centralized site that serves commentor icons that requires login etc.

What if we gave each commentor the option of hosting their own icon?

A distributed commentor icon implementation could work like this:

# Given the URL of a commentor, look for an <code><address></code> element with classname of "vcard" at the commentor's URL. The <code><address></code> element is supposed to be the contact information for the page (see [[hcard-faq|hCard FAQ]] for more info), so this makes sense.
# Next, look for the first element inside that hcard that has a classname of "logo".
# Hopefully that element is an <code><img></code>, and if so, use its src to get the commentor's icon.
# Presto. You've got distributed commentor icons!

== Spam prevention ==
hCard uses <code>mailto:</code> links, and therefore
it automatically "inherits" the disadvantage of <code>mailto:</code> links:
These links can be easily detected by emails spiders (used by spammers).

Email addresses are picked up like any other link crawled by a search engine and trustworthy crawlers may be deterred from adding emphasis while indexing these links by including rel="nofollow" (See [[rel-nofollow]]). However, email addresses used for spam are crawled by email spiders which will likely ignore this attribute.

There are ways to prevent email address detection by simple email spiders, while
still retaining full compatibility with (X)HTML applications.
One common way is to "encode" the the "m" of "mail" and "@" with character entities, yet it's unwise to follow a convention of only encoding specific characters because the email spiders can pick up on this too:

Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Example of the "encoded" link (with rel-nofollow added):
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>
</nowiki></pre>

Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.

''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)

=== Other prevention methods to consider ===
* Using server-side code to implement character entities randomly
* Displaying the address in a way thought to be only human readable (thus breaking the link):
** Using an image instead of text (could still be machine readable using OCR)
** Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
* Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
* Pointing to an email form or other URL instead of an email address

== Tutorials ==
* How to hCard encode entries in Popular blog software.
* Good reasons to publish your hCard
** as a business, get people to put you in their address book so they'll find you later
** as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.

== Parsing ==
See separate [[hcard-parsing|hCard parsing]] page for current hCard parsing rules.

Add thoughts/proposals to improve/add to hCard parsing here in this section in hCard brainstorming, and be sure to include URLs to examples of hCards in the wild which could benefit from parsing rule changes.

* Multiple Type parsing / Type Optimization: The spec allows for, and the [[hcard-authoring#Phone_Numbers|hcard-authoring]] demonstrate the use of multiple type designations for a single value of tel. The syntax used in the authoring examples where each seems like it could become cumbersome. As these type designations are all single 'word' strings it may be possible to implement additional parsing rules to allow for multiple types inside the same HTML element. Handling delimiters may be an issue [space, comma, etc?], and some in-the-wild usage of multiple types would need to be located and examined before considering additional parsing rules along these lines [ [[User:ChrisCasciano|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]
*Parsers could calculate the current age of hCard subjects, from the DoB. [[User:AndyMabbett|Andy Mabbett]] 07:47, 20 Apr 2007 (PDT)
*for hCards with DoB, parsers could generate and export a recurring hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:06, 20 Apr 2007 (PDT)
**If/ when date-of-death is added to hCard, parsers could instead generate a recurring "death-anniversary" hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:08, 20 Apr 2007 (PDT)
* ...

=== fax and modem hyperlink parsing ===
For the "tel" property in particular, when the element is:
* <code><a href="fax:..."></code> OR <code><area href="fax:..."></code> : parse the value of the 'href' attribute, omitting the "fax:" prefix and any "?" query suffix (if present), in the attribute. For details on the "fax:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "fax" in addition to any explicit subproperty type specified on the 'tel' property.
* <code><a href="modem:..."></code> OR <code><area href="modem:..."></code> : parse the value of the 'href' attribute, omitting the "modem:" prefix and any "?" query suffix (if present), in the attribute. For details on the "modem:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "modem" in addition to any explicit subproperty type specified on the 'tel' property.

== Post vCard additions ==

Keeping hCard properties and values as a 1:1 representation of vCard properties and values has numerous benefits such as simplicity, stability, interoperability with the vast number of existing vCard applications etc.

However some have found vCard to be limiting in terms of the data/properties/fields they want to express in contact information. Some implementations use vCard extensions to express such information [citation needed].

This section is for documentation of such suggested additions. Empirical evidence of actual *real world* examples on the Web of people publishing this information would be a good step towards considering any such additions/extensions.

* '''altitude'''. From [[hcard-issues]].
** Used by Wikipedia e.g. [http://en.wikipedia.org/wiki/Avers Avers]; [http://en.wikipedia.org/wiki/List_of_volcanoes_in_Argentina volcanoes in Argentina]
**Used (as "height") by PoI66 in GPS tracks, e.g [http://www.poi66.com/maps/show_earth.php?album=wip&lat=35.58756&lon=27.06803&extent=0.1&title=Beach%20van%20Lefkos%20]
**Used by Great Circle Mapper, e.g [http://gc.kls2.com/airport/BHX BHX]
**Used by UK Govt. Met Office (as "AMSL" = height Above Mean Sea Level) e.g. [http://www.metoffice.gov.uk/climate/uk/averages/19611990/sites/penkridge.html Penkridge Weather station]
**See also [[geo-elevation-examples]]
* '''vat-number''' : for VAT numbers of companies, which are used a lot in Europe and they need to be published on Belgian publications (including websites).
* '''gender'''
**most social network sites (see [[profile-examples]]) publish the gender of the individual
**Many pages publish implicit gender information, not easily machine parsable - using names (Andrew, Andrea), titles (Mr, Mrs, Miss), relationships (husband, brother), pronouns (he, she), etc. See also [[genealogy-brainstorming]]
* '''date-of-death'''
**Used by Wikipedia e.g. [http://en.wikipedia.org/wiki/John_Bonham John Bonham]
**Used in obituaries, e.g [http://www.westmidlandbirdclub.com/obituaries/norris.htm Tony Norris (WMBC)]; [http://www.guardian.co.uk/obituaries/story/0,,1725211,00.html Ivor Cutler (Guardian)]; [http://www.britarch.ac.uk/BA/ba8/ba8obit.html Grahame Clark (British Archaeology)]
**Used in grave indices e.g. [http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=676 Chico Marx]
**Used on war memorial pages [http://tinyurl.com/2ddlvq Captain Ronald Wilkinson]
**Used in biographies e.g. [http://www.oxforddnb.com/public/lotw/6.html Oxford National Dictionary of Biography]
Of course if vCard were extended itself, that may provide impetus to add such extensions to hCard in order to maintain the 1:1 representation of properties/values.

Thus see (and add to): [[vcard-suggestions]]

Another path to consider is the development of another microformat which includes an hCard and then extends it with additional properties for a particular domain. In many ways [[hresume|hResume]] has already done this. Other related efforts:
* [[genealogy]]
* [[profile]]

Using hCard as a stable building block for additional microformats may seem more desirable than incrementally growing hCard itself.

==Wikipedia's Persondata==
Wikipedia's [http://en.wikipedia.org/wiki/Wikipedia:Persondata Persondata] aligns very closely with hCard, but has additional date and place of birth & death fields. [[User:AndyMabbett|Andy Mabbett]] 13:02, 28 Jan 2007 (PST)

== TODO ==

* The [[hcard-profile]] needs verification and perhaps a URL for retrieving the actual XMDP, rather than as <pre> text on a wiki page.
* Complete translating the examples from the vCard spec into hCard, and place them on a separate hCard examples page.
* Create a "rich" but realistic hCard example, say for example for a salesperson, who wants to put a whole bunch of contact information on their website in order to be found/contacted easily.
* Provide examples of how to encode instant messaging (IM) accounts. Figure out what would the mailto: or aim: URL in hCard look like in vCard. And take a look at what vCard applications do today with IM addresses.

== CSS Styles ==
Not only can you create semantics with the hCard values, but you can add CSS styles to them as well. You are free to style the terms in any way you want, but here we can list a few ideas for how to style terms.

If you want to encode hCard data, but do NOT want to display it in the HTML code (WARNING: This is very much recommended AGAINST, and in general against the microformat principle of marking up visible data), then you can hide that tag in CSS with the following code:
<pre><nowiki>
<span style="display: none">Hidden Data</span>
</nowiki></pre>
Transforming applications will still find the data and use it when converting hCards to vCards.

== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF.

== Additional Parsing Improvements ==
=== Ambiguous name components ===

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

===ADR with no children===
Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect <code>adr</code> to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity.

Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:

*[http://en.wikipedia.org/wiki/Old_Street_station Old Street]
**"Place" ("locale" in the template) is a '''street'''
*[http://en.wikipedia.org/wiki/Hamstead_railway_station Hamstead]
**"Place" is a '''local district'''
*[http://en.wikipedia.org/wiki/Inverness_railway_station Inverness]
**"Place" is a '''city'''

Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:

*[http://en.wikipedia.org/wiki/Tesco Tesco]
*[http://en.wikipedia.org/wiki/BP BP]
*[http://en.wikipedia.org/wiki/Google Google]
*[http://en.wikipedia.org/wiki/Blue_Coat_Systems Blue Coat Systems]

I propose that, where <code>adr</code> has content, but no explicit sub-properties, there should be a default sub-property to which that content is allocated, in order that it is captured by user agents, and can later be manually tweaked (in, say, an address book programme) by users if so desired. This would satisfy the vCard requirement for child-of-adr, and adhere to the general principle to "[[be-strict|be strict in what you send but generous in what you receive]]".
*Note that there may be other reasons to consider this suggestion, such as "ease of authoring". Another way of looking at this suggestion is as a "adr/extended-address shorthand". [[User:Tantek|Tantek]] 08:28, 26 Mar 2007 (PDT)

* there is also a LABEL property which is NOT structured data, but purely a text string to be used when labeling. LABEL purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents. [[User:Brian|Brian]] 13:18, 30 Mar 2007 (UTC)
**On re-reading this, it seems that none of the adressess given in my examples meet the criteria of being "''formatted text corresponding to delivery address''". [[User:AndyMabbett|Andy Mabbett]] 03:35, 17 Apr 2007 (PDT)

Of the available sub-property options:

*street-address
*extended-address
*region
*locality

I suggest that "extended-address" is the most sensible sub-property to use, for this purpose. [[User:AndyMabbett|Andy Mabbett]] 03:57, 26 Mar 2007 (PDT)

=== INPUT element handling ===

In [[hcard-parsing]], I've defined special-case handling for several elements according to [[hcard-parsing#more_semantic_exceptions|more semantic exceptions]], e.g. textual properties on the IMG element use the 'alt' attribute.

One element I forgot at the time was the INPUT element, specifically, <nowiki><input type="text"></nowiki>.

The simple suggestion is to add the following to [[hcard-parsing]], specifically to the [[hcard-parsing#all_properties|all properties]] sub-section:

* <code><input type="text" value="..."></code>: use the value of the 'value' attribute. If there is no 'value' attribute then treat the value as empty.

[[User:Tantek|Tantek]]

==== Background discussion: ====

Key threads:
* http://microformats.org/discuss/mail/microformats-discuss/2006-September/005951.html
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006132.html
* http://microformats.org/discuss/mail/microformats-discuss/2007-January/008312.html

Somewhat related:
* http://microformats.org/wiki/rest/forms-brainstorming
* http://microformats.org/wiki/rest/forms-examples

One key summary:
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006172.html
The options discussed in a hypothetical hCard input system so far appear to be:
1) create a new root class other than vcard to indicate a form that's
fillable with hCard data.

Benefits:
Doesn't overcomplicate hCard with new parsing rules,
doesn't require rewrite of existing parsers to ignore 'unparsable' data.
Drawbacks:
Requires completely new parsers to be written.
Existing parsers would ignore data even if a valid hCard could be extracted.

2) extend hCard's parsing rules to cover form elements and relying on
the FORM/INPUT semantics to indicate that stuff is inputtable.

Benefits:
Small addition to existing format rather than new one.
Semantics of an input form and the eventual display format are the same.
Drawbacks:
Existing parsers would/could parse forms as invalid hCards, would need re-writing.

Broader question:
* http://microformats.org/discuss/mail/microformats-discuss/2005-September/001059.html
Should this be extended beyond just hCard?

[[User:RobManson|RobManson]]

== Accepted Suggestions ==

=== Encoding Company data as a Business Card (proposal) ===

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Implied "FN and N" Optimization (proposal) ===

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

BACKGROUND:

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== Rejected Suggestions ==

Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>
<span class="vcard">
...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...
</span>
</nowiki></pre>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

== References ==
=== Normative References ===
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC
* [http://gmpg.org/xmdp/ XMDP]
=== Informative References ===
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]
* [http://www.icao.int/mrtd/download/technical.cfm ICAO - Machine Readable Travel Documents format]

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

hcard-brainstorming

2007-07-13T13:18:13Z

RobManson: Summary and links to background discussion from mail list etc.

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

__TOC__

== Authors ==
* [http://suda.co.uk/ Brian Suda]
* [http://tantek.com/log/ Tantek Çelik], [http://technorati.com Technorati, Inc]

== Contributors ==
* [[User:Atamido|Atamido]]
* [[User:ChrisMessina|ChrisMessina]]
* [[User:DimitriGlazkov|DimitriGlazkov]]
* ...
* ... and many others

== Problems Being Solved ==

Some of the problems that [[hcard|hCard]] helps to solve:

* having to enter business cards that go out of date (subscribe to someone's syndicated [[hcard|hCard]] instead).
* annoying "update your contact info" email from various centralized contact info services

== FN Nickname semantic ==

There are many sites (e.g. [http://flickr.com Flickr], [http://consumating.com/ Consumating]) which permit the user to '''both''' have a multi-word login/handle/alias, '''and''' not show their ''real'' name (fn, n, given-name, family-name etc.).

For the people represented by the profile pages of these sites, the best we can do is mark-up their login/handle/alias as their "nickname". Originally, we had thought that such handles etc. were single words only, and thus we created the [[hcard#Implied_.22nickname.22_Optimization|Implied nickname optimization]] accordingly, where you can markup the handle as an "fn", and have it automatically set a "nickname" property value, and empty values for all the "n" sub-values.

In order to deal with multi-word handles, similar to the [[hcard#Organization_Contact_Info|hCard Organization contact info]] method, the following is proposed:

=== "fn" and "nickname" combination ===

Due to the use of potentially multi-word nicknames/handles/usernames in content published on the Web, (e.g. on sites like [http://flickr.com Flickr] and [http://consumating.com/ Consumating]), hCard has a mechanism for specifying a multi-word "fn" that is also a "nickname" without affecting any "n" sub-properties that are otherwise specified, and explicitly implying empty defaults for "n" sub-properties.

Similar to the [[hcard#Implied_.22nickname.22_Optimization|implied "nickname" optimization]], if the "fn" property and a "nickname" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn nickname"</code>), then

# The content of the "fn" is treated as a "nickname" property value.
# Parsers should handle the missing "n" property by implying empty values for all the "n" sub-properties.

== Examples ==

* See [[hcard-examples]], which provides several illustrative instructive examples, as well as 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].

=== Using RFC2806 with hCard ===

[http://www.ietf.org/rfc/rfc2806.txt RFC 2806] defines the telephone scheme "tel:", "fax:" and "modem:" to handle phone communications with URIs in the same way, "mailto:" is defined for email. It's part of the list or registered schemes by IANA : [http://www.iana.org/assignments/uri-schemes Uniform Resource Identifier (URI) SCHEMES]

<pre><nowiki>
tel telephone [RFC2806]
fax fax [RFC2806]
modem modem [RFC2806]
</nowiki></pre>

It is practical to write your tel number like this.

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">+1-919-555-7878</a>
</nowiki></pre>

or even

<pre><nowiki>
<a class="tel" href="tel:+1-919-555-7878">Mr Smith's phone</a>
</nowiki></pre>

You can add support for "tel:" to your desktop and to your browser

* For Gnome, edit ~/.gnome/Gnome and add something to the URL Handlers section. (Dan Connolly uses this to get galeon to launch telnum from [http://dev.w3.org/cvsweb/2001/telagent/ telagent sources] for tel URIs)
* In Mozilla, [http://dizzy.mozdev.org/ Dizzy]
* In Internet Explorer, [http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp Asynchronous Pluggable Protocols]

On the CSS front… You could for example add automagically an icon. I have put the property !important for those who wants to add it to their own stylesheet in their browsers, so they know type of links when browsing.

<pre><nowiki>
a[href^="tel:"]:before {
content: '\260f ' !important;
padding-left: 20px !important; }

a[href^="mailto:"]:before {
content: '\2709 ' !important;
padding-left: 20px !important; }
</nowiki></pre>

== Encoding "modern" attributes ==

Since vCard was first established, various interactive communication technologies and addressing schemes have been widely adopted. Although there aren't specific properties for these technologies / addressing schemes, they can be captured as URLs or email addresses.

This has now been written up for the most part. See:

http://microformats.org/wiki/hcard-examples#New_Types_of_Contact_Info

Still to be addressed:

* iChat mac.com addresses, simply store "@mac.com" email addresses, e.g.
** <code><nowiki><a class="email" href="mailto:steve@mac.com">...</nowiki></code>
* MSN Instant Messenger, you can simple store "@hotmail.com" or "@msn.com" or "@passport.com" email addresses.
* Internet Relay Chat (IRC), use "irc:" URLs.

== Auto-Discovery ==

=== Representative hCard discovery ===
Ways to auto discover the representative hCard for a page, that is the hCard that means the person/owner of the page.

Applications for auto-discovery of the representative hCard for the page
* vCard auto extraction from the page
* profile icon discovery (e.g. what people use gravatar for and have proposed pavatar for).

The preferred option is to use only visible semantic HTML ([[POSH]]).

Here is a scenario that outlines the proposed auto-discovery process:

# I (as user) give the URL of my homepage or hCard or other profile URL, to a site that wants a profile icon
# That site goes and gets it (e.g. using hKit), and then:
## checks to see if there is an <nowiki><address></nowiki> hCard, and uses it if it finds it
## otherwise uses the first hCard it finds (which in cases of profile URLs which have a single hCard like on [http://flickr.com Flickr], [http://zooomr.com Zooomr], and [http://technorati.com/ Technorati], will work as expected).
# The site looks in the hCard for a "logo" property and uses the first one if it finds any.
# Otherwise it looks for a "photo" property and uses the first one if it finds any.
# Otherwise the site uses a default icon, but subscribes to the URL with the hCard and checks it for a "logo" or "photo", say, once a day.

=== vCard link rel auto-discovery ===

A similar possibility is an auto discovery link in the head of the document could point to a URL (perhaps with transform) to a vCard version of the representative hCard.

On the page with the hCard encoding, the best link would be as follows:
<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code>
this HTML page is an alternate view of the vCard.

The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”.

It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.

When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. Therefore rel="alternate" may not be appropriate. The problem of what rel value to use is bigger than links to vCards.

=== hCard to hCard relationships ===

There are several types of hCard to hCard relationships, that is, one hCard hyperlinking to another hCard which would beneift from the explicit rel values that described the specific relationship.

==== mini hCard to expanded hCard ====

Perhaps the most common type of hCard to hCard link is a mini hCard, e.g. from a personal home page or blog to the person's contact/about page, perhaps consisting of only a name and URL, that links to an expanded hCard. Examples in the wild:

In this instance, possible rel values might include:
* rel="expanded"
* rel="definitive" - the problem with this is that the expanded hCard is not necessarily a definitive version.
* rel="canonical" - similarly, the expanded hCard is not necessarily at a canonical URL. It may simply be *an* expanded version, not *the* expanded version.

The following rel values have been suggested, but are not really a good idea due to the fact that they imply a dependence to add a new rel value for any new microformat which might have a mini-version linking to a more expanded version:
* rel="author"
* rel='contact'
* rel="contactinfo"
* rel='hcard'
* rel='person'

Here are some more generic values that have been suggested which perhaps make even less sense:
* rel='microformat' - this doesn't make any sense when you imagine a world where nearly every web page contains microformats.
* rel='about' - what does "about" have to do with a person or even authorship?
* rel="profile" - should be reserved for meaning here is an [[xmdp|XMDP]] profile for the current page.
* rel='PIM' - not sure about how this makes any sense either.

==== mini hCard to remote site ====
Per the instructions in [[hcard-examples]] for [[hcard-examples#References_to_People_in_Blogrolls|marking up people in blogrolls]], you might have an hCard of your site for another person which then links to that other person's website. Should there be a rel value that indicates this "mini-hCard" to "person" relationship?

==== mini hCards and nearby expanded hCard links ====
Some authors include mini-hCards on their pages of themselves (e.g. in their blog posts), and yet those mini-hCards don't actually point to more expanded versions. However, sometimes they have a separate but nearby link on the same page like "about" or "contact" that does link to an expanded hCard.

E.g. on [http://factoryjoe.com/blog/ FactoryCity], blog posts have mini-hCards for "published by", e.g. (white space added for readability):
<pre><nowiki>
Published by
<span class="vcard author">
<a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn">
Chris Messina
</a>
</span>
</nowiki></pre>

On those same blog pages, there is a link labeled "Contact Information" that links to http://factoryjoe.com/blog/hcard/ which has an hCard with more information like phone number, birthday etc.

=== Auto-Discovery for XFN ===

An author will typically their XFN information on a specific page, rather than all pages. In particular, a specific page separate from the home page of their blog, and thus it would be useful to have an explicit rel value to assist in auto-discovery of XFN information.

This was suggested by Jens Alfke on 20050606 at the WWDC blogger's dinner.

== geo improvements ==
''See [[geo-brainstorming]]''

== Other use cases ==
*calculate and display the subject's age "as of today".
*calculate and display the subject's age at death (if a Date of Death is available)
*Generate an recurring iCal for a living subject's birthday
*Generate an recurring iCal for a dead subject's "anniversary of birth" (if a Date of Death is available)

== Issues with vCard Applications ==
See [[vcard-implementations]].

== Open Questions ==

Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile.

<pre><nowiki>
...
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a>
...
</nowiki></pre>

-- [http://suda.co.uk/ Brian Suda]

Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example:
<pre><nowiki>
<a href="http://mywebsite.com/" class="fn n">
<span class="given-name">John</span>
<span class="other-names">Q.</span>
<span class="family-name">Public</span>
</a>
</nowiki></pre>

When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN:
<pre><nowiki>
John Q. Public

John
Q.
Public
</nowiki></pre>

Either the white-space is preserved or it is not. Which should the transforming applications render?

-- [http://suda.co.uk/ Brian Suda]

A: The parsing application should follow the white space collapsing rules of the mime type it retrieves. I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.

-- [http://tantek.com/log/ Tantek]

Many of the Questions and Answers are relevant to both ["hCal"] and hCard.

Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.
<pre><nowiki>
<span class="agent">
<span class="vcard">
<span class="email">
<a class="internet" href="mailto:jfriday@host.com">
<dfn>
<span class="fn">Joe Friday</span>
</dfn>
</a>
</span>
<span class="tel">+1-919-555-7878</span>
<span class="title">Area Administrator, Assistant</span>
</span>
</span>
</nowiki></pre>
-- [http://www.ben-ward.co.uk/ Ben Ward]

== Applications ==
Applications that are hCard aware or can convert hCard to vCard formats.

=== Copy hCards favelet(s) ===
* I think a Favelet would work nicely here. When you find a page that is hCard friendly, you click the favlet and you get yourself a vCard. This is done! See X2V in the implementations section of the [[hcard|hCard]] spec.

=== Distributed Commentor Icons ===

* See [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hCards in your blog] for an example of hCards used for comment authors (commentors). The system used there, "Gravatars", is a centralized site that serves commentor icons that requires login etc.

What if we gave each commentor the option of hosting their own icon?

A distributed commentor icon implementation could work like this:

# Given the URL of a commentor, look for an <code><address></code> element with classname of "vcard" at the commentor's URL. The <code><address></code> element is supposed to be the contact information for the page (see [[hcard-faq|hCard FAQ]] for more info), so this makes sense.
# Next, look for the first element inside that hcard that has a classname of "logo".
# Hopefully that element is an <code><img></code>, and if so, use its src to get the commentor's icon.
# Presto. You've got distributed commentor icons!

== Spam prevention ==
hCard uses <code>mailto:</code> links, and therefore
it automatically "inherits" the disadvantage of <code>mailto:</code> links:
These links can be easily detected by emails spiders (used by spammers).

Email addresses are picked up like any other link crawled by a search engine and trustworthy crawlers may be deterred from adding emphasis while indexing these links by including rel="nofollow" (See [[rel-nofollow]]). However, email addresses used for spam are crawled by email spiders which will likely ignore this attribute.

There are ways to prevent email address detection by simple email spiders, while
still retaining full compatibility with (X)HTML applications.
One common way is to "encode" the the "m" of "mail" and "@" with character entities, yet it's unwise to follow a convention of only encoding specific characters because the email spiders can pick up on this too:

Example of the original link:
<pre><nowiki>
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a>
</nowiki></pre>

Example of the "encoded" link (with rel-nofollow added):
<pre><nowiki>
<a class="e&#109;ail" rel="nofollow" href="&#109;ailto:john.smith&#064;example.com">john.smith&#064;example.com</a>
</nowiki></pre>

Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.

''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)

=== Other prevention methods to consider ===
* Using server-side code to implement character entities randomly
* Displaying the address in a way thought to be only human readable (thus breaking the link):
** Using an image instead of text (could still be machine readable using OCR)
** Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)
* Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)
* Pointing to an email form or other URL instead of an email address

== Tutorials ==
* How to hCard encode entries in Popular blog software.
* Good reasons to publish your hCard
** as a business, get people to put you in their address book so they'll find you later
** as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.

== Parsing ==
See separate [[hcard-parsing|hCard parsing]] page for current hCard parsing rules.

Add thoughts/proposals to improve/add to hCard parsing here in this section in hCard brainstorming, and be sure to include URLs to examples of hCards in the wild which could benefit from parsing rule changes.

* Multiple Type parsing / Type Optimization: The spec allows for, and the [[hcard-authoring#Phone_Numbers|hcard-authoring]] demonstrate the use of multiple type designations for a single value of tel. The syntax used in the authoring examples where each seems like it could become cumbersome. As these type designations are all single 'word' strings it may be possible to implement additional parsing rules to allow for multiple types inside the same HTML element. Handling delimiters may be an issue [space, comma, etc?], and some in-the-wild usage of multiple types would need to be located and examined before considering additional parsing rules along these lines [ [[User:ChrisCasciano|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]
*Parsers could calculate the current age of hCard subjects, from the DoB. [[User:AndyMabbett|Andy Mabbett]] 07:47, 20 Apr 2007 (PDT)
*for hCards with DoB, parsers could generate and export a recurring hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:06, 20 Apr 2007 (PDT)
**If/ when date-of-death is added to hCard, parsers could instead generate a recurring "death-anniversary" hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:08, 20 Apr 2007 (PDT)
* ...

=== fax and modem hyperlink parsing ===
For the "tel" property in particular, when the element is:
* <code><a href="fax:..."></code> OR <code><area href="fax:..."></code> : parse the value of the 'href' attribute, omitting the "fax:" prefix and any "?" query suffix (if present), in the attribute. For details on the "fax:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "fax" in addition to any explicit subproperty type specified on the 'tel' property.
* <code><a href="modem:..."></code> OR <code><area href="modem:..."></code> : parse the value of the 'href' attribute, omitting the "modem:" prefix and any "?" query suffix (if present), in the attribute. For details on the "modem:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "modem" in addition to any explicit subproperty type specified on the 'tel' property.

== Post vCard additions ==

Keeping hCard properties and values as a 1:1 representation of vCard properties and values has numerous benefits such as simplicity, stability, interoperability with the vast number of existing vCard applications etc.

However some have found vCard to be limiting in terms of the data/properties/fields they want to express in contact information. Some implementations use vCard extensions to express such information [citation needed].

This section is for documentation of such suggested additions. Empirical evidence of actual *real world* examples on the Web of people publishing this information would be a good step towards considering any such additions/extensions.

* '''altitude'''. From [[hcard-issues]].
** Used by Wikipedia e.g. [http://en.wikipedia.org/wiki/Avers Avers]; [http://en.wikipedia.org/wiki/List_of_volcanoes_in_Argentina volcanoes in Argentina]
**Used (as "height") by PoI66 in GPS tracks, e.g [http://www.poi66.com/maps/show_earth.php?album=wip&lat=35.58756&lon=27.06803&extent=0.1&title=Beach%20van%20Lefkos%20]
**Used by Great Circle Mapper, e.g [http://gc.kls2.com/airport/BHX BHX]
**Used by UK Govt. Met Office (as "AMSL" = height Above Mean Sea Level) e.g. [http://www.metoffice.gov.uk/climate/uk/averages/19611990/sites/penkridge.html Penkridge Weather station]
**See also [[geo-elevation-examples]]
* '''vat-number''' : for VAT numbers of companies, which are used a lot in Europe and they need to be published on Belgian publications (including websites).
* '''gender'''
**most social network sites (see [[profile-examples]]) publish the gender of the individual
**Many pages publish implicit gender information, not easily machine parsable - using names (Andrew, Andrea), titles (Mr, Mrs, Miss), relationships (husband, brother), pronouns (he, she), etc. See also [[genealogy-brainstorming]]
* '''date-of-death'''
**Used by Wikipedia e.g. [http://en.wikipedia.org/wiki/John_Bonham John Bonham]
**Used in obituaries, e.g [http://www.westmidlandbirdclub.com/obituaries/norris.htm Tony Norris (WMBC)]; [http://www.guardian.co.uk/obituaries/story/0,,1725211,00.html Ivor Cutler (Guardian)]; [http://www.britarch.ac.uk/BA/ba8/ba8obit.html Grahame Clark (British Archaeology)]
**Used in grave indices e.g. [http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=676 Chico Marx]
**Used on war memorial pages [http://tinyurl.com/2ddlvq Captain Ronald Wilkinson]
**Used in biographies e.g. [http://www.oxforddnb.com/public/lotw/6.html Oxford National Dictionary of Biography]
Of course if vCard were extended itself, that may provide impetus to add such extensions to hCard in order to maintain the 1:1 representation of properties/values.

Thus see (and add to): [[vcard-suggestions]]

Another path to consider is the development of another microformat which includes an hCard and then extends it with additional properties for a particular domain. In many ways [[hresume|hResume]] has already done this. Other related efforts:
* [[genealogy]]
* [[profile]]

Using hCard as a stable building block for additional microformats may seem more desirable than incrementally growing hCard itself.

==Wikipedia's Persondata==
Wikipedia's [http://en.wikipedia.org/wiki/Wikipedia:Persondata Persondata] aligns very closely with hCard, but has additional date and place of birth & death fields. [[User:AndyMabbett|Andy Mabbett]] 13:02, 28 Jan 2007 (PST)

== TODO ==

* The [[hcard-profile]] needs verification and perhaps a URL for retrieving the actual XMDP, rather than as <pre> text on a wiki page.
* Complete translating the examples from the vCard spec into hCard, and place them on a separate hCard examples page.
* Create a "rich" but realistic hCard example, say for example for a salesperson, who wants to put a whole bunch of contact information on their website in order to be found/contacted easily.
* Provide examples of how to encode instant messaging (IM) accounts. Figure out what would the mailto: or aim: URL in hCard look like in vCard. And take a look at what vCard applications do today with IM addresses.

== CSS Styles ==
Not only can you create semantics with the hCard values, but you can add CSS styles to them as well. You are free to style the terms in any way you want, but here we can list a few ideas for how to style terms.

If you want to encode hCard data, but do NOT want to display it in the HTML code (WARNING: This is very much recommended AGAINST, and in general against the microformat principle of marking up visible data), then you can hide that tag in CSS with the following code:
<pre><nowiki>
<span style="display: none">Hidden Data</span>
</nowiki></pre>
Transforming applications will still find the data and use it when converting hCards to vCards.

== Other Implementations/Ideas ==
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML
* It would also be possible to convert XFN and hCard to FoaF.

== Additional Parsing Improvements ==
=== Ambiguous name components ===

When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.

There's currently no easy answer to this.

One implementation suggestion is a 'best-guess' algorithm, something along the lines of:

# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]
# For three or more words
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')
## Apply the grammar "given-name additional-name(s) family-name"

The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.

===ADR with no children===
Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect <code>adr</code> to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity.

Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:

*[http://en.wikipedia.org/wiki/Old_Street_station Old Street]
**"Place" ("locale" in the template) is a '''street'''
*[http://en.wikipedia.org/wiki/Hamstead_railway_station Hamstead]
**"Place" is a '''local district'''
*[http://en.wikipedia.org/wiki/Inverness_railway_station Inverness]
**"Place" is a '''city'''

Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair:

*[http://en.wikipedia.org/wiki/Tesco Tesco]
*[http://en.wikipedia.org/wiki/BP BP]
*[http://en.wikipedia.org/wiki/Google Google]
*[http://en.wikipedia.org/wiki/Blue_Coat_Systems Blue Coat Systems]

I propose that, where <code>adr</code> has content, but no explicit sub-properties, there should be a default sub-property to which that content is allocated, in order that it is captured by user agents, and can later be manually tweaked (in, say, an address book programme) by users if so desired. This would satisfy the vCard requirement for child-of-adr, and adhere to the general principle to "[[be-strict|be strict in what you send but generous in what you receive]]".
*Note that there may be other reasons to consider this suggestion, such as "ease of authoring". Another way of looking at this suggestion is as a "adr/extended-address shorthand". [[User:Tantek|Tantek]] 08:28, 26 Mar 2007 (PDT)

* there is also a LABEL property which is NOT structured data, but purely a text string to be used when labeling. LABEL purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents. [[User:Brian|Brian]] 13:18, 30 Mar 2007 (UTC)
**On re-reading this, it seems that none of the adressess given in my examples meet the criteria of being "''formatted text corresponding to delivery address''". [[User:AndyMabbett|Andy Mabbett]] 03:35, 17 Apr 2007 (PDT)

Of the available sub-property options:

*street-address
*extended-address
*region
*locality

I suggest that "extended-address" is the most sensible sub-property to use, for this purpose. [[User:AndyMabbett|Andy Mabbett]] 03:57, 26 Mar 2007 (PDT)

=== INPUT element handling ===

In [[hcard-parsing]], I've defined special-case handling for several elements according to [[hcard-parsing#more_semantic_exceptions|more semantic exceptions]], e.g. textual properties on the IMG element use the 'alt' attribute.

One element I forgot at the time was the INPUT element, specifically, <nowiki><input type="text"></nowiki>.

The simple suggestion is to add the following to [[hcard-parsing]], specifically to the [[hcard-parsing#all_properties|all properties]] sub-section:

* <code><input type="text" value="..."></code>: use the value of the 'value' attribute. If there is no 'value' attribute then treat the value as empty.

[[User:Tantek|Tantek]]

==== Background discussion: ====

Key threads:
* http://microformats.org/discuss/mail/microformats-discuss/2006-September/005951.html
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006132.html
* http://microformats.org/discuss/mail/microformats-discuss/2007-January/008312.html

Somewhat related:
* http://microformats.org/wiki/rest/forms-brainstorming
* http://microformats.org/wiki/rest/forms-examples

One key summary:
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006172.html
The options discussed in a hypothetical hCard input system so far appear to be:
1) create a new root class other than vcard to indicate a form that's
fillable with hCard data.

Benefits:
Doesn't overcomplicate hCard with new parsing rules,
doesn't require rewrite of existing parsers to ignore 'unparsable' data.
Drawbacks:
Requires completely new parsers to be written.
Existing parsers would ignore data even if a valid hCard could be extracted.

2) extend hCard's parsing rules to cover form elements and relying on
the FORM/INPUT semantics to indicate that stuff is inputtable.

Benefits:
Small addition to existing format rather than new one.
Semantics of an input form and the eventual display format are the same.
Drawbacks:
Existing parsers would/could parse forms as invalid hCards, would need re-writing.

[[User:RobManson|RobManson]]

== Accepted Suggestions ==

=== Encoding Company data as a Business Card (proposal) ===

( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )

In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.

Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.

Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].

See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.

=== Implied "FN and N" Optimization (proposal) ===

Right now a parser first looks for an "n" element.

And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.

BACKGROUND:

Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.

PROPOSAL:

We should consider adding one more implied optimization after the steps documented above and that is:

If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.

This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.
* +1 [[User:Atamido|Atamido]]
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]

== Rejected Suggestions ==

Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''

Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:
<pre><nowiki>
<span class="vcard">
...
<ul class="categories">
<li><a href="http://w3c.org">W3C</a></li>
</ul>
...
</span>
</nowiki></pre>

There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.

== References ==
=== Normative References ===
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC
* [http://gmpg.org/xmdp/ XMDP]
=== Informative References ===
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]
* [http://www.icao.int/mrtd/download/technical.cfm ICAO - Machine Readable Travel Documents format]

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

Template:hcard-related-pages

2007-07-12T23:55:44Z

RobManson: Added links to the vCard to hCard converter

* [[hcard|hCard]]
* [[hcard-cheatsheet|hCard cheatsheet]] - hCard properties
* [http://microformats.org/code/hcard/creator hCard creator] ([[hcard-creator-feedback|feedback]]) - create your own hCard.
* [http://mobileonlinebusiness.com.au/uf/vCard_to_hCard_converter.html] - create you own hCard from an existing vCard.
* [[hcard-authoring|hCard authoring]] - learn how to add hCard markup to your existing contact info.
* [[hcard-examples|hCard examples]] - example usage of various classes within hCard.
* [[hcard-examples-in-wild|hCard examples in the wild]] - an on-going list of websites which use hCards.
* [[hcard-faq|hCard FAQ]] - if you have any questions about hCard, check here.
* [[hcard-implementations|hCard implementations]] - websites or tools which either generate or parse hCards.
* [[hcard-implied]] - a proposal to create a alternative method of marking up a simple hCard
* [[hcard-parsing|hCard parsing]] - normative details of how to parse hCards.
* [[hcard-profile|hCard profile]] - the XMDP profile for hCard
*[[hcard-singular-properties|hCard singular properties]] - an explanation of the list of singular properties in hCard.
* [[hcard-tests|hCard tests]] - a wiki page with actual embedded hCards to try parsing.
* [[hcard-advocacy|hCard advocacy]] - encourage others to use hCard
* [[to-do#hCard|hCard "to do"]] - jobs to do

The hCard specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. These thoughts, issues, and questions are kept in separate pages.

* [[hcard-brainstorming|hCard brainstorming]] - brainstorms and other explorations relating to hCard.
**See also [[geo-brainstorming|Geo brainstorming]]
* [[hcard-feedback|hCard feedback]] - general feedback (as opposed to specific issues).
* [[hcard-issues|hCard issues]] - specific issues with the specification.
* [[vcard-errata|vCard errata]] - corrections to the vCard specification, which underlies hCard.
* [[vcard-suggestions|vCard suggestions]] - suggested improvements to the vCard specification.

hcard

2007-07-12T23:51:07Z

RobManson: Added links to the vCard to hCard converter

<h1>hCard</h1>

hCard is a simple, open, distributed format for representing people, companies, organizations, and places, using a 1:1 representation of vCard (RFC 2426) properties and values in [[semantic-xhtml|semantic XHTML]]. hCard is one of several open [[microformats|microformat]] standards suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML.

Want to get started with writing an [[hcard|hCard]]? Use the [http://microformats.org/code/hcard/creator hCard creator] to write up some contact information or paste your vCard into the [http://mobileonlinebusiness.com.au/uf/vCard_to_hCard_converter.html vCard to hCard converter] and publish it, or follow the [[hcard-authoring|hCard authoring tips]] to add hCard markup to your current contact page.

__TOC__

== Specification ==

; Editor: [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]
; Authors: [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc], [http://suda.co.uk/ Brian Suda]

; Acknowledgments: See [[hcard#Inspiration_and_Acknowledgements|acknowledgments]].

Microformats [[hcard#Copyright|copyright]] and [[hcard#Patents|patents]] statements apply.

== Introduction ==
The vCard standard (RFC 2426), has been broadly interoperably implemented (e.g. Apple's "Address Book" application built into MacOSX) - see the [http://mobileonlinebusiness.com.au/uf/vCard_to_hCard_converter.html vCard to hCard converter] to test this mapping.

In addition, many bloggers identify themselves by name and discuss their friends and family. With just a tad bit of structure, bloggers can discuss people in their blog(s) in such a way that spiders and other aggregators can retrieve this information, automatically convert them to vCards, and use them in any vCard application or service.

This specification introduces the '''hCard''' format, which uses a 1:1 representation of the properties and values of the aforementioned vCard standard, in semantic XHTML. Bloggers can both embed hCards directly in their web pages, and style them with CSS to make them appear as desired. In addition, hCard enables applications to retrieve information directly from web pages without having to reference a separate file.

Use the [http://microformats.org/code/hcard/creator hCard creator] or [http://mobileonlinebusiness.com.au/uf/vCard_to_hCard_converter.html vCard to hCard converter] and copy the HTML code it generates to your blog or website to publish your contact info.

== Format ==
=== In General ===
The vCard standard (RFC 2426) forms the basis of hCard.

The basic format of hCard is to use vCard object/property names in lower-case for class names, and to map the nesting of vCard objects directly into nested XHTML elements.

=== Root Class Name ===
The root class name for an hCard is "vcard". An element with a class name of "vcard" is itself called an ''hCard''.

=== Properties and Sub-properties ===
The properties of an hCard are represented by elements inside the hCard. Elements with class names of the listed properties represent the values of those properties. Some properties have sub-properties, and those are represented by elements inside the elements for properties.

=== Property List ===
hCard properties (sub-properties in parentheses like this)

'''Required:'''
* '''fn'''
* '''n'''* (family-name, given-name, additional-name, honorific-prefix, honorific-suffix)
Optional:
* nickname, sort-string
* url, email (type, value), tel** (type, value)
* adr (post-office-box, extended-address, street-address, locality, region, postal-code, country-name, type, value), label
* geo (latitude, longitude), tz
* photo, logo, sound, bday
* title, role, org (organization-name, organization-unit)
* category, note
* class, key, mailer, uid, rev

=== Property Notes ===
<nowiki>*</nowiki> The 'n' property is optional if any [[hcard#Implied_.22n.22_Optimization|implied 'n' optimization rules]] are in effect.<br />
<nowiki>**</nowiki> tel - Authors MAY want to follow the [http://en.wikipedia.org/wiki/E.123 E.123] standard for writing values of telephone numbers.

=== Singular vs. Plural Properties ===
Singular properties: 'fn', 'n', 'bday', 'tz', 'geo', 'sort-string', 'uid', 'class'. For properties which are singular, the first descendant element with that class should take effect, any others being ignored.

All other properties can be plural. Each class instance of such properties creates a new instance of that property.

=== Human vs. Machine readable ===
The human visible text contents of an element for a property represents the value of that property, with a few exceptions:

If an <code><abbr></code> element is used for a property, then the '<code>title</code>' attribute (if present) of the <code><abbr></code> element is the value of the property, instead of the contents of the element, which instead provide a more human presentable version of the value.

If an <code><a></code> element is used for one or more properties, it must be treated as follows:
# For the 'photo' property and any other property that takes a URL as its value, the <code>href="..."</code> attribute provides the property value.
# For other properties, the element's content is the value of the property.

If an <code><img></code> element is used for one or more properties, it must be treated as follows:
# For the 'photo' property and any other property that takes a URL as its value, the <code>src="..."</code> attribute provides the property value.
# For other properties, the <code><img></code> element's '<code>alt</code>' attribute is the value of the property.

If an <code><object></code> element is used for one or more properties, it must be treated as follows:
# For the 'photo' property and any other property that takes a URL as its value, the <code>data="..."</code> attribute provides the property value.
# For other properties, the element's content is the value of the property.

=== Value excerpting ===
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 "<code>value</code>" is introduced to excerpt out the subset of the element that is the value of the property. E.g. here is an hCard fragment for marking up a home phone number:<br />

vCard:
<pre><nowiki>
TEL;TYPE=HOME:+1.415.555.1212
</nowiki></pre>

hCard:
<pre><nowiki>
<span class="tel">
<span class="type">home</span>:
<span class="value">+1.415.555.1212</span>
</span>
</nowiki></pre>

This hCard fragment could be displayed as:

<div style="border: thin dashed black; width: 95%; padding: .5em 1em;">
<span class="tel">
<span class="type">home</span>:
<span class="value">+1.415.555.1212</span>
</span>
</div>



=== Property Exceptions ===
vCard has several properties which either do not make sense on, or are already implied within the context of a web page. This section explains what to (not) do with them.

# vCard's '''NAME''', '''PROFILE''', '''SOURCE''', '''PRODID''', '''VERSION''' properties are defined in Sections 2.1.2, 2.1.3, 2.1.4, 3.6.3, 3.6.9 of RFC 2426. Content publishers MUST NOT use these properties in their hCards, and as such, hCard consumers/parsers MUST IGNORE these properties if they are found within an hCard. Instead. hCard to vCard converters SHOULD use the title of the page where the hCard is found (e.g. the <code><title></code> element in (X)HTML documents) to construct the NAME property, MAY output a PROFILE value of "<code>VCARD</code>" per RFC 2426, SHOULD use the URL of the page where the hCard is found to construct the SOURCE property (e.g. perhaps as a parameter to a URL/service that converts hCards to vCards), for an output vCard stream (e.g. a .vcf file). Only services/applications that output actual vCards should write the PRODID property, with the product identifier for said service/application. Similarly only such services/applications should write the VERSION property, with the value "3.0" (without quotes) per RFC 2426 Section 3.6.9.

=== Organization Contact Info ===
If the "FN" and "ORG" properties have the exact same value (typically because they are set on the same element, e.g. class="fn org"), then the hCard represents contact information for a company, organization or place and should be treated as such. In this case the author MUST also NOT set the "N" property, or set it (and any sub-properties) explicitly to the empty string "". Thus parsers should handle the missing "N" property in this case by implying empty values for all the "N" sub-properties.

=== Implied "n" Optimization ===
Although vCard requires that the "N" property be present, the authors of the vCard specification (RFC 2426) themselves do not include "N" properties in their vCards near the end of the spec (p.38). This apparent contradiction can be resolved by simply allowing the "FN" property to imply "N" property values in typical cases provided in the spec. We do so explicitly in hCard.

If "FN" and "ORG" are not the same (see previous section), and the value of the "FN" property is exactly two words (separated by whitespace), and there is no explicit "N" property, then the "N" property is inferred from the "FN" property. For "FN"s with either one word see below, and for three or more, the author MUST explicitly markup the "N", except for the organization contact info case, [http://microformats.org/wiki/hcard#Organization_Contact_Info see above] for that.

# The content of "FN" is broken into two "words" separated by whitespace.
# The ''first'' word of the "FN" is interpreted as the "given-name" for the "N" property.
# The ''second/last'' word of the "FN" is interpreted as the "family-name" for the "N" property.
# Exception: If the first word ends in a "," comma OR if the second word is a single character (optionally followed by a period "."), then the first word (minus the comma at the end if any) is interpreted as the "family-name" and the second word is interpreted as the "given-name".

This allows simplification in the typical case of people stating:
* given-name (space) family-name
* family-name (comma) given-name
* family-name (comma) given-name-first-initial
* family-name (space) given-name-first-initial (optional period)

=== Implied "nickname" Optimization ===
Due to the prevalence of the use of nicknames/handles/usernames on the Web in actual content published on the Web (e.g. authors of [[hReview|reviews]]), hCard also has an implied "nickname" optimization to handle this.

Similar to the implied "n" optimization, if "FN" and "ORG" are not the same, and the value of the "FN" property is exactly one word, and there is no explicit "N" property, then:

# The content of the "FN" is treated as a "nickname" property value.
# Parsers should handle the missing "N" property by implying empty values for all the "N" sub-properties.

Note: the hCard may have additional explicit "nickname" property values in addition to the implied nickname.

=== Implied "organization-name" Optimization ===
The "ORG" property has two subproperties, organization-name and organization-unit. Very often authors only publish the organization-name. Thus if an "ORG" property has no "organization-name" inside it, then its entire contents MUST be treated as the "organization-name".

=== Tags as Categories ===
Categories in hCard can optionally be represented by tags with [[rel-tag]]. When a category property is a rel-tag, the tag (as defined by rel-tag) is used for that category.

=== type subproperty values ===
The 'type' subproperty in particular takes different values depending on which property it is a subproperty of. These 'type' subproperty values are case-INSENSITIVE, meaning "Home" is the same as "home", as well as multivalued, e.g. a tel can be home and preferred:

vCard:
<pre><nowiki>
TEL;TYPE=HOME,PREF:+1.415.555.1212
</nowiki></pre>

hCard:
<pre><nowiki>
<span class="tel"><span class="type">Home</span> (<span class="type">pref</span>erred):
<span class="value">+1.415.555.1212</span>
</span>
</nowiki></pre>

This could be displayed as:

<div style="border: thin dashed black; width: 95%; padding: .5em 1em; ">
<span class="tel"><span class="type">Home</span> (<span class="type">pref</span>erred):
<span class="value">+1.415.555.1212</span>
</span>
</div>

The following lists are ''informative''. See RFC 2426 sections 3.2.1 ADR, 3.3.1 TEL, and 3.3.2 EMAIL respectively for normative type values. They are repeated here for convenience. Default type subproperty value(s) is(are) first in each list and indicated in ALL CAPS. types may be multivalued.

* adr type: INTL, POSTAL, PARCEL, WORK, dom, home, pref
* tel type: VOICE, home, msg, work, pref, fax, cell, video, pager, bbs, modem, [http://flickr.com/photos/tags/carcellphone/ car], isdn, pcs
* email type: INTERNET, x400, pref, "other IANA registered address types"

=== XMDP Profile ===

See [[hcard-profile]] for the [http://gmpg.org/xmdp XMDP] profile of hCard which contains the above complete list of properties, with references to their RFC 2426 definitions.

=== Parsing Details ===

See [[hcard-parsing|hCard parsing]].

== Examples ==

This section is informative.

=== Sample vCard ===

Here is a sample vCard:

<pre><nowiki>
BEGIN:VCARD
VERSION:3.0
N:Çelik;Tantek
FN:Tantek Çelik
URL:http://tantek.com/
ORG:Technorati
END:VCARD
</nowiki></pre>

and an equivalent in hCard with various elements optimized appropriately. See [[hcard-example1-steps| hCard Example 1]] for the derivation.

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

This hCard might be displayed as:
<div style="border: thin dashed black; width: 95%; padding: .5em 1em;">
[http://tantek.com/ Tantek Çelik]<br />
Technorati
</div>

Note: The version information is unnecessary in hCard markup directly since the version will be defined by the profile of hCard that is used/referred to in the 'profile' attribute of the <head> element.

===Live example===

Here are the WikiMedia Foundation's contact details, as a live hCard which will be detected, on this page, by microformat parsing tools:

<div class="vcard">
<div class="fn org">'''Wikimedia Foundation Inc.'''</div>
<div class="adr">
<div class="street-address">'''200 2nd Ave. South #358'''</div>
<div> <span class="locality">'''St. Petersburg'''</span>, <span class="region">'''FL'''</span> <span class="postal-code">'''33701-4313'''</span></div>
<div class="country-name">'''USA'''</div>
</div>
<div>'''Phone:''' <span class="tel">'''+1-727-231-0101'''</span></div>
<div>'''Email:''' <span class="email">'''info@wikimedia.org'''</span></div>
<div><span class="tel"><span class="type">'''Fax'''</span>''':''' <span class="value">'''+1-727-258-0207'''</span></span></div>
</div>

The mark-up (wrapped, and emboldening omitted, for clarity) used is:

<pre><nowiki>
<div class="vcard">
<div class="fn org">Wikimedia Foundation Inc.</div>
<div class="adr">
<div class="street-address">200 2nd Ave. South #358</div>
<div>
<span class="locality">St. Petersburg</span>,
<abbr class="region" title="Florida">FL</abbr> <span class="postal-code">33701-4313</span>
</div>
<div class="country-name">USA</div>
</div>
<div>Phone: <span class="tel">+1-727-231-0101</span></div>
<div>Email: <span class="email">info@wikimedia.org</span></div>
<div>
<span class="tel"><span class="type">Fax</span>:
<span class="value">+1-727-258-0207</span></span>
</div>
</div>
</nowiki></pre>

=== More Examples ===
See [[hcard-examples|hCard examples]] for more examples, including all examples from vCard RFC 2426 converted into hCard.

==Buttons==
You can use these buttons on pages with hCards. See [[buttons#hCard]] for any recent additions.

* http://www.crowley.nl/images/hcard.png (mirror: http://www.davidjanes.com/images/mf_hcard.png)
* http://rbach.priv.at/2006/buttons/hcard.png
* http://www.boogdesign.com/images/buttons/microformat_hcard.png
* CSS-powered button, as evidenced at [http://re-run.com/about/microformat-badges microformat badges @ re-run]

== Examples in the wild ==
This section is '''informative'''. The number of hCard examples in the wild has expanded far beyond the capacity of being kept inline in this specification. They have been moved to a [[hcard-examples-in-wild|separate page]].

See [[hcard-examples-in-wild|hCard Examples in the wild]].

== Implementations ==
This section is '''informative'''. The number of hCard implementations has also expanded beyond the capacity of keeping them inline. They have been moved to a [[hcard-implementations|separate page]].

See [[hcard-implementations|hCard Implementations]].

== Copyright ==
{{MicroFormatCopyrightStatement2004}}

== Patents ==
{{MicroFormatPatentStatement}}

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426]
* [http://www.itu.int/rec/T-REC-E.123-200102-I/en ITU recommendation E.123] format of telephone numbers (chargeable document)

=== Informative References ===
* [[hcard-history|hCard history]]
** [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 2004-09-10]
** [http://tantek.com/log/2004/09.html#hcard hCard term introduced and defined on the Web, 2004-09-30]
** Contributed from http://developers.technorati.com/wiki/hCard 2005-06-20
* [http://www.dante.net/np/ds/osi/9594-6-X.520.A4.ps X.520 in Postscript] ([http://72.14.253.104/search?q=cache:FjqzsFu4h20J:www.dante.net/np/ds/osi/9594-6-X.520.A4.ps HTMLization courtesy of Google Cache]) - vCard refers to ROLE as being "based on the X.520 Business Category explanatory attribute".
* [http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426]
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]
* [http://en.wikipedia.org/wiki/E.123 Wikipedia summary of ITU-T Recommendation E.123] - for "TEL" values.
* [http://www.imc.org/pdi/ Internet Mail Consortium Personal Data Interchange vCard and vCalendar]

==== Specifications That Use hCard ====
* [[adr]]
* [[geo]]
* [[hcalendar|hCalendar]]
* [[hreview|hReview]]

==== Similar Work ====
* [http://www.intertwingly.net/wiki/pie/PaceBetterPersonElement Atom PaceBetterPersonElement]
* [http://www.jabber.org/jeps/jep-0054.html JEP-0054: vcard-temp]

== Inspiration and Acknowledgments ==
Thanks to: my good friend [http://vadim.com/ Vadim] who introduced me to vCard ''many'' years ago, and if I'd only paid more attention then, perhaps I could have helped a lot of people avoid wasting a lot of time reinventing various standards wheels.

== Notes on derivation from vCard ==
This section is ''informative''.

=== Semantic XHTML Design Principles ===
{{semantic-xhtml-design-principles}}

=== More Semantic Equivalents ===
For some properties there are HTML elements which better match and convey their semantics. The following properties SHOULD be encoded with the following (X)HTML:
* <code>URL</code> in vCard becomes <code><a class="url" href="...">...</a></code> inside the element with <code>class="vcard"</code> in hCard.
* Similarly, <code>EMAIL</code> in vCard becomes <code><nowiki><a class="email" href="mailto:...">...</a></nowiki></code>
* <code>PHOTO</code> in vCard becomes <code><img class="photo" src="..." alt="Photo of ..." /></code> or <code><object class="photo" data="..." type="...">Photo of ...</object></code>
* <code>UID</code> in vCard simply becomes another semantic applied to a specific URL (or EMAIL) for an hCard.

=== Singular and Plural derivations ===
The [[hcard#Singular_vs._Plural_Properties|lists of singular and plural properties]] have been derived by analyzing the semantics of the individual properties in vCard RFC2426 and determining logically that they MUST be singular per their semantics. See [[hcard-singular-properties]] for explanations.

==== Plural Properties Singularized ====
Since plural property names become their singular equivalents, even if the original plural property permitted only a single value with multiple components, those multiple components are represented each with their own singularly named property and the the property is effectively multivalued and subject to the above treatment of multivalued properties.

== Further Reading ==
* [http://www.digital-web.com/articles/microformats_primer/ Digital Web Magazine: Microformats Primer] by Garrett Dimon has a good intro to hCard
* [http://24ways.org/advent/practical-microformats-with-hcard Practical Microformats with hCard] by Drew McLellan
* [http://www.naturalsearchblog.com/archives/2006/09/28/tips-for-local-search-engine-optimization-for-your-site/ Local Search Engine Optimization using Microformats] by Chris Silver Smith
* [http://thedredge.org/ Andrew D. Hume] has written a blog post on [http://usabletype.com/articles/2005/usable-microformats/ usable microformats] which discusses hCard
* [http://www.thefutureoftheweb.com/blog/2006/1/hcard Jesse Skinner's introduction to hCard]
* [http://blog.usweb.com/ Shaun Shull's] great post on [http://blog.usweb.com/archives/how-microformats-affect-search-engine-optimization-seo How Microformats Affect SEO], including his [[hcard|hCard]] as an example.
* [http://24ways.org/2006/styling-hcards-with-css 24 Ways: Styling hCards with CSS] A 24 Ways article - John Allsopp on styling hCard using CSS
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page] and the [http://technorati.com/tags/hcard hCard tag]
* [http://www.rfc-editor.org/rfc/rfc4770.txt RFC 4770 - Extensions for Instant Messaging]

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