Microformats Wiki - User contributions [en]

events/2011-04-12-uk

2011-02-28T09:17:21Z

TobyInk: /* attendees */ add me

<entry-title>UK Meetup April 2011</entry-title>
__TOC__
One of several microformats [[events]].

== Idea ==
It has been a while since we had a microformats meet-up in the UK. The idea is for an event that is part social and part workshop to brainstorm the [[hcard-input-brainstorming|input micorformat]] ideas. As Tantek is in the UK between the 11-16 of April this would seem the best time to hold the event.

Please help us by adding your preferences to this page so we can organise the best time and place.

== what venue ==
These are venues we have used in the past, I am not sure if they still have the right layout or atmosphere for a meeting. Please add other venues that you think maybe good for the event. They need to be central and near good transport links?

<div class="discussion">
* London
** +1 If we hold the event in central London more people are likly to come along [[User:GlennJones|Glenn Jones]]
** +1 Possibly more venue choice, also. [[User:Phae|Phae]]
* Brighton
</div>

<div class="discussion">
* The Bricklayers Arms — 31 Gresse Street, London
* The Yorkshire Grey — 2 Theobald's Road, London
* Pitcher and Piano — 42 Kingsway, London
* Brew Wharf Yard — 2 Stoney Street, London
* The Princess — 76 Paul Street, London
* The Yorkshire Grey — 29-33 Grays Inn Road, London
** This is where we had the last vEvent (ages ago). They let us have the upstairs room for free. [[User:Phae|Phae]]
</div>

== what date ==
Which is the best date for the event?

<div class="discussion">
* Monday 11 April
* Tuesday 12 April
** +1 Held on a Tuesday night before [[User:GlennJones|Glenn Jones]]
** +1 London pubs are more easily bookable early in the week. [[User:Phae|Phae]]
* Wednesday 13 April
** -1 UX London is on this day
* Thursdays 14 April
** -1 Pub Standards is on this night [[User:GlennJones|Glenn Jones]]
** -1 UX London is on this day
* Friday 15 April
** -1 UX London is on this day
* Saturday 16 April
</div>

== attendees ==
Add yourself alphabetically sorted by family name if you plan on attending or attended.

* [[User:Phae|Frances Berriman]]
* [[User:Tantek|Tantek Çelik]]
* [[User:PaulDowney|Paul Downey (fn)]]
* [[User:SpikeUK|Chris Foote]]
* [[User:TobyInk|Toby Inkster]] (tentative)
* [[User:GlennJones|Glenn Jones (fn)]]
* ...

== photographs ==

* ...

== notes ==
Topics discussed, comments, and Q&A.

* …

== articles and blog posts ==
Articles and blog posts following up on the meetup. Add a link to your post in the list below. Newest first.

* ...

== related pages==
{{events-related-pages}}

value-class-pattern

2011-02-25T16:24:55Z

TobyInk: /* consuming and parsing tools */

<entry-title>Value Class Pattern</entry-title>

The value class pattern is derived from [[hCard#Value_excerpting|value-excerpting]] in hCard.

''The editors believe the value-class-pattern to be feature complete and ready for use in markup. Implementers are encouraged to update accordingly and provide [[value-class-pattern-feedback|feedback]]. '''Note''', the precise parsing behavior could change in response to implementer feedback, but the core methods are stable. You should watch this page for updates.''

See also, the [http://microformats.org/blog/2009/05/12/value-class-pattern/ blog announcement].

__TOC__
; Editors
: <span class="vcard"><span class="fn">[[User:BenWard|Ben Ward]]</span></span>
: <span class="vcard"><span class="fn">[[User:Tantek|Tantek Çelik]]</span></span>
; Short URL
: <kbd>http://tr.im/valueclass</kbd>

Sometimes, only a part of an element's content is to be used as the value of a microformat property. This may occur when a property has optional subproperties, such as <code>tel: type</code> and <code>tel: value</code> in [[hCard]]. Other times, the most appropriate structure for a property may include other content.

For these purposes, the special class name <code>value</code> is used to mark-up the relevant data excerpt from larger element content.

==Simple Examples==

Here is markup for a home phone number:

vCard fragment:

<source lang=text>TEL;TYPE=HOME:+1.415.555.1212</source>

hCard fragment:

<source lang=html4strict>
<span class="tel">
<span class="type">Home</span>:
<span class="value">+1.415.555.1212</span>
</span>
</source>

In this case, the <code>value</code> of <code>tel</code> is <code>+1.415.555.1212</code>, not <code>Home: +1.415.555.1212</code>.

Sometimes the value for a microformats property must be split into multiple pieces in the content of the element representing that property. Multiple elements with a class name of "value" (value elements) can be used to extract and concatenate these pieces into a single value for microformats properties which expect simple strings or tel values.

Another example, this time using a localized (British) telephone number:

<source lang=html4strict>
<span class="tel">
<span class="type">Home</span>:
<span class="value">+44</span> (0) <span class="value">1223 123 123</span>
</span>
</source>

In this case, the valid ''data'' for the telephone number is <samp>+441223123123</samp>, but the way in which phone number is presented in Britain will include the <samp>(0)</samp>, for local dialling. That is, from anywhere in the world you may dial <kbd>+441223123123</kbd>, or from within Britain you may dial <kbd>01223123123</kbd>. Common local publishing interferes with the data, since dialling <kbd>'''+440'''1223123123</kbd> is an invalid number.

In the mark-up, two <code>value</code> classes target the part of the telephone number string that makes an international, valid number, whilst allowing conventional presentation.

Another example, adding a place name to a [[geo]] co-ordinate:

<source lang=html4strict>
<p>I'm loitering outside The Bricklayer's Arms
<span class="geo">
51° 30' 48.45", -0° 8' 53.23"
(<span class="value">51.513458;-0.14812</span>)
</span>
</p>
</source>

Whilst the entire string is a geo point, it's only the decimal encoded co-ordinates which must be consumed by a microformats parser, so the <code>value</code> class isolates it from the degrees form, which the publisher includes for completeness.

==Basic Parsing==
# The value class pattern only applies to properties which are simple strings, enumerated values, telephone numbers, and datetimes. The value class pattern does not affect parsing of properties of type email, URL, URI, UID.
# Where an element with such a microformat property class name has a descendant with class name <code>value</code> (a "value" element), parsers should use the following portion of that element:
## if the value element is an <code>img</code> or <code>area</code> element, then use the element's <code>alt</code> attribute value.
## if the value element is an <code>abbr</code> element, then use the element's <code>title</code> attribute value.
## for any other element, use its inner-text.
# Where there are multiple descendants of a property with class name of <code>value</code> (multiple value elements)
## if the microformats property expects a simple string, enumerated value, or telephone number, then the values extracted from the value elements should be concatenated ''without'' inserting additional characters or white-space.
## if the microformats property expects a datetime value, see the [[#Date_and_time_parsing|Date Time Parsing]] section.
# Descendants with class of <code>value</code> must not be parsed deeper than one level. That is, where an element <code>foo</code> with class <code>value</code> has a <em>descendant</em> <code>bar</code> with class <code>value</code>, the content of <strong><code>foo</code></strong> is taken as the <code>value</code>. Nesting additional elements with class of <code>value</code> cannot be used to further isolate a property's value.

e.g.

<source lang=html4strict>
<p class="description">
<span class="value">
<em class="value">Puppies Rule!</em>
<strong>But kittens are better!</strong>
</span>
</p>
</source>

In this example, <code>description</code> has a child ‘<code>value</code>’, and that child has a ''grandchild'' ‘<code>value</code>’. However, the parsing of <code>value</code> classes stops at the first level, so the data for <code>description</code> is: <samp><code><em class="value">Puppies Rule!</em><strong>But kittens are better!</strong></code></samp>, not just <samp>Puppies Rule!</samp>.

== Date and time values ==
=== Summary ===
Some microformats properties expect an ISO8601 datetime value, e.g. [[hCalendar]] <code>dtstart</code> and <code>dtend</code> or [[hAtom]] <code>published</code>.

Authors may use the value class pattern to separately specify the date and the time, which are then combined to specify a single datetime value.

Example, this hCalendar 'dtstart' property with 'value' elements:

<source lang=html4strict>
<p>The weekly dinner will be on
<span class="dtstart">
<abbr class="value" title="2008-06-24">this Tuesday</abbr>
at <span class="value">18:30</span>
</span>
</p>
</source>

produces the following 'dtstart' value:

<source lang=text>
2008-06-24T18:30:00
</source>

and iCalendar converters produce the following DTSTART:

<source lang=text>
DTSTART:20080624T183000
</source>

The lack of a timezone indicates a "floating" datetime, that is a datetime independent of any particular timezone. Examples of floating datetimes could be an alarm clock you set to ring at 7am, or the common 9am-5pm workday.

=== Date and time parsing ===
For all date time properties (as defined in their respective microformats specifications), the following rules apply in addition to (and in some cases replacing) the above value class pattern parsing rules.

When a "value" element is found, parse a value from the element as follows:
* if the element is an <code>img</code> or <code>area</code> element, then use the element's <code>alt</code> attribute value.
* if the element is an <code>abbr</code> element, then use the element's <code>title</code> attribute value.
* for any other element, use its inner-text.
* if the value has both a specific ISO8601 date and a specific time, use those and stop looking for "value" elements.
* if the value has *only* a specific date, specifically, fits the following ISO8601 date patterns (i.e. as documented in the [http://en.wikipedia.org/wiki/ISO_8601 Wikipedia summary of ISO8601])
** YYYY-MM-DD
** YYYY-DDD
** then use that as the date value. For the purposes of the value class pattern, the hyphens "-" separating the year, month, day and/or ordinal day are required.
** ignore any further "value" elements that specify the date.
* if the value has *only* a specific time (with or without timezone), parse it for a time value that can match any of the following:
** HH:MM:SS-XX:YY
** HH:MM:SS+XX:YY
** HH:MM:SS-XXYY
** HH:MM:SS+XXYY
** HH:MM:SSZ
** HH:MM:SS
** HH:MM-XX:YY
** HH:MM+XX:YY
** HH:MM-XXYY
** HH:MM+XXYY
** HH:MMZ
** HH:MM
** HH is the 24 hour "hours" in the time, from 00 to 24, with optional leading 0 for values less than 10.
** MM are the minutes from 00 to 59
** SS are the optional seconds from 00 to 59 (60 for a leap second). If omitted, infer 00 seconds.
** XX is the time zone hours offset, from 00 to 12 with optional leading 0 for values less than 10.
** YY is the time zone minutes offset, from 00 to 59, though in practice only 00, 15, 30, 45 minute offsets are used in global timezones.
** Z is the literal 'Z' to indicate GMT.
** For the purposes of the value class pattern, the colons ":" separating the hour, minutes, seconds are required.
** However the colons ":" separating the hours and minutes of any timezone offset are ''optional'' and discouraged in order to make it less likely that a timezone offset will be confused for a time.
** Case insensitive { }"am"|{ }"a.m." suffix to treat an HH value of 12 as 00, or a case-insensitive { }"pm"|{ }"p.m." suffix to add 12 to HH value less than 12 - per [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia article on the 12 hour clock]. Note: [[X2V]] has implemented this.
*** HH:MM:SSam
*** HH:MM:SSpm
*** HH:MMam
*** HH:MMpm
*** HHam
*** HHpm
*** where "am" and "pm" mean "am or a.m." and "pm or p.m."
*** when MM is omitted, infer 00 minutes.
** ignore any further "value" elements that specify the time.
* if the value has *only* a specific timezone, parse it for a time zone value that can match any of the following:
** -XX:YY
** +XX:YY
** -XXYY
** +XXYY
** -XX
** +XX
** Z
** XX is the time zone hours offset, from 00 to 12 with optional leading 0 for values less than 10.
** YY is the time zone minutes offset, from 00 to 59, though in practice only 00, 15, 30, 45 minute offsets are used in global timezones.
** Z is the literal 'Z' to indicate GMT.
** ignore any further "value" elements that specify the timezone.

If by parsing the "value" element(s), at least a specific date has been found, then the "value" is overall valid, and the parser assembles the overall datetime value by concatenating the specific date, "T" and specific time (if time was specified, with 00 seconds implied if no seconds are provided), and specific timezone (if timezone and a specific time was specified).
* YYYY-MM-DD - no time specified
* YYYY-MM-DDTHH:MM:SS - time specified but no timezone. This is a floating time.
* YYYY-MM-DDTHH:MM:SS-XXYY or
* YYYY-MM-DDTHH:MM:SSZ or
* YYYY-MM-DDTHH:MM:SS+XXYY - both time and timezone were specified.

=== format specific details ===
The following are format specific details and <span id="format_specific_optimizations">optimizations</span> that make use of the value-class-pattern.

;<span style="font-size:smaller">short URL for this section</span>
:http://tr.im/vcpfso

==== hCalendar dtend implied date ====
Typically events that start and end the same day only display the date of the event once (makes sense per the DRY [[principle]]) (real world examples: [http://upcoming.yahoo.com/event/3010807/ Upcoming], ... more examples with URLs would help for thoroughness).

Thus it would be convenient if we could imply an [[hCalendar]] event "dtend" date from its "dtstart" date when only the time (and optionally timezone) was specified for its "dtend", e.g.:

<source lang=html4strict>
<span class="vevent">
The <span class="summary">party</span> will be on
<span class="dtstart">
<span class="value">2009-06-26</span>, from
<span class="value">19:00</span></span> to
<span class="dtend"><span class="value">22:00</span></span>.
</span>
</source>

To simplify this further for authors, hCalendar processors could treat the specifying of just the time per the value-class-pattern date and time value rules, and thus eliminate the need for the "value" span inside the "dtend" span:

<source lang=html4strict>
<span class="vevent">
The <span class="summary">party</span> will be on
<span class="dtstart">
<span class="value">2009-06-26</span>, from
<span class="value">19:00</span></span> to
<span class="dtend">22:00</span>.
</span>
</source>

hCalendar to iCalendar converters should produce the following iCalendar fragment (as part of a valid .ics file) from either of the above two examples:

<source lang=text>
BEGIN:VEVENT
SUMMARY:party
DTSTART:20090626T190000
DTEND:20090626T220000
END:VEVENT
</source>

Note: [[X2V]] has implemented dtend implied date from dtstart.

Examples "in the wild":
* http://microformats.org/wiki/events/2009-08-12-nyc-workshop (real world example, but on this wiki).

==== iCalendar generators ====
microformats implementations which consume [[hCalendar]] and generate iCalendar {{must}} in addition:
# remove any dash "-" separators in the date.
# remove any colon ":" separators in the time.
# add a whole day to any date-only (lacking a specified time) (date inclusive) hCalendar <code>dtend</code> property values in order to generate an (date exclusive) iCalendar <code>DTEND</code> property value with the same meaning, per the resolution to the [[dtend-issue]].
# perform datetime math on any +/- relative timezone value, and produce an effective UTC value ending with "Z".

==== hAtom updated implied date ====
Similarly, in blog posts that indicate both when they were "published" and "updated", the date is usually only displayed once, typically when "published" (real world examples with URLs would help for thoroughness).

Thus it would be convenient if we could imply an [[hAtom]] entry "updated" date from its "published" date when only the time (and optionally timezone) was specified for its "updated", e.g. for a blog post that was updated the same day:

<source lang=html4strict>
<span class="hentry">
<span class="entry-summary">short blog post example</span>
was published on <span class="published">
<span class="value">2009-08-01</span> at <span class="value">12:06</span></span>
and updated at <span class="updated"><span class="value">12:10</span></span>.
</span>
</source>

To simplify this further for authors, hAtom processors could treat the specifying of just the time per the value-class-pattern date and time value rules, and thus eliminate the need for the "value" span inside the "updated" span:

<source lang=html4strict>
<span class="hentry">
<span class="entry-summary">short blog post example</span>
was published on <span class="published">
<span class="value">2009-08-01</span> at <span class="value">12:06</span></span>
and updated at <span class="updated">12:10</span>.
</span>
</source>

==== Atom generators ====
microformats implementations which consume [[hAtom]] and generate
Atom {{must}} in addition:
* normalize all date and datetime values to [[RFC3339]].

=== derivation and tests ===
This section is <em>informative</em>.

The handling of date and time values in the value class pattern was originally [[value-excerption-pattern-brainstorming#date_and_time_separation|brainstormed on the value-excerption-pattern-brainstorming]] page and derived from that analysis and feedback. For the curious, historical details may be found there, along with additional thoughts for extension.

See [[value-class-date-time-tests]] for test cases.

==Parsing value from a <code>title</code> attribute==
The <code>value-title</code> class name allows the publisher to indicate the data value for a parent property is contained in the <code>title</code> attribute of an element, rather than the inner-text.

This can be used to provide a synonym within content, or used to quietly publish alternate forms of information for microformats parsing, without affecting the consumption of content.

For example, you can use casual localization with dates:

<source lang=html4strict>
<p>It was
<span class='dtstart'>
<span class='value-title' title='2008'>last year</span>
</span>
that I realised my addiction to cashew nuts would cost this country so dear.
</p>
</source>

Parsing rules for <code>value-title</code> are the same as for <code>value</code> above, with the following change:

* Where a microformats property has a child element with class name of <code>value-title</code>, the content of the <code>title</code> attribute of that element must be parsed, rather than the portion of the element that would be parsed for a class name of <code>value</code>.

===Using <code>value-title</code> to publish machine-data===

The initial usage of <code>value-title</code> is used to publish alternate, parsable forms of property values in a visible context without the use of the <code>abbr</code> element whose semantics already support interpretation of the 'title' attribute as an expanded, more precise form of the content.

Experience has found that there are some cases in microformats where a number of publishers want to include a precisely accurate and parsable value for a property but do not want it to be visible in their page, even as a tooltip.

For example, full [[ISO8601]] datetimes may be confusing to readers of the page (as a tooltip or when read aloud by a screen reader), and enumerated values such as the <code>type</code> subproperty of hCard's <code>tel</code> property use US-English terms, which are not part of pages in any other language.

Since both of those scenarios have shown to be obstacles for a number of publishers, for these cases, and these alone, there exists a further extension of value-excerption. This extension allows the parsable form of the property to be published ‘silently’ immediately adjacent with the respective local visible content.

Here is an example, with the required use of a first child element with class name <code>value-title</code>:

<source lang=html4strict>
<p class='tel' lang='en-gb'>
<span class='type'>
<span class='value-title' title='cell'> </span>
mobile
</span>
<span class='value'>+44 7773 000 000</span>
</p>
</source>

The <samp>cell</samp> value is parsed for the 'type' subproperty, but <samp>mobile</samp> is presented to the user.

In the case of dates:

<source lang=html4strict>
<p class='dtstart'>
<span class='value-title' title='2009-03-14T16:28-0600'> </span>
March 14th 2009, around half-past four
</p>
</source>

A microformats parser will read the ISO8601 format datetime <samp>2009-03-14T16:28-0600</samp>, but users will only see <samp>March 14th 2009, around half-past four</samp>. Testing has shown that the ISO8601 datetime above does not get exposed to any user at all.

===Parsing machine-data <code>value-title</code>===

Browsers collapse the <code>value-title</code> span down to a width of <code>0</code>, effectively providing no visual rendering, whilst keeping the element in the DOM. With no physical dimensions, there is no ‘hover’ state, so no tooltip is revealed. Furthermore, the empty element is not passed to assistive technology layers such as VoiceOver. Screen readers do not read the contents of the title attribute of an empty <code>span</code> element.

We conducted [[value-excerption-value-title-test|thorough testing]] of these parsing behaviors to ensure accessibility.

''Note: Whilst the <code>value-title</code> element is more gracefully written without whitespace inner-text (or as self-closing <code><foo /></code> element in XHTML), some tools such as WYSIWYG editors and HTML-Tidy will erroneously discard such elements, resulting in parsable data being thrown away by some tools. As such, <code><span class='value-title'> </span></code>, including a single whitespace character between the opening and closing tag, may also be used. In some situations, this whitespace may be rendered by the browser, and authors should test their output.''

Parsing this final <code>value-title</code> extension imposes some stricter restrictions on usage. These restrictions exist to reduce the impact of <abbr title="Don't Repeat Yourself">DRY</abbr> violations, reduce the opportunity for sites to spoof data, and encourage best practice for maintaining both forms of data accurately.

Where an element with class <code>value-title</code> is to be parsed as data for a property, and that element also contains no non-whitespace content (hereafter referred to as ‘empty’), the following rules apply:

* The ‘empty’ value-title element must be the '''first, non-whitespace child''' of the property element. That is, it should follow immediately after the property is declared, before the human-readable form, and without any additional nesting.
* The ‘empty’ value-title element can only be used for specific properties. Future microformat specifications (and updates to existing microformats) must explicitly state which properties may be used with this extension of the value-class-pattern. (Retroactive property support for existing microformats is documented below.)
* Where an ‘empty’ value-title element is to be used as the single property value, it must be the ''only'' such <code>value</code> content. That is, the first instance of a conforming <code>value-title</code> element overrides all other <code>value</code> and <code>value-title</code> siblings and/or cousins.
* Tools written to perform Conformance Testing and/or Validation of microformats ''should'' attempt to compare the machine-data and human-legible forms of the property data, and warn authors if the forms do not match.

=== limited use of value-title ===
Due to the fact that the value-title pattern hides some amount of data which tends to be a machine-specific duplicate of data that is provided in the human readable content, there are two microformats [[principles]] being compromised: '''visibility''' and '''<abbr title="Don't Repeat Yourself">DRY</abbr>'''. Thus the applicability of this pattern is deliberately restricted to properties that have demonstrated through experience a need for it, with no known better alternative.

In general authors should:

# First, try to directly specify microformats property values inline (the most visible, no duplication),
# Then consider using the value-class pattern
## Including multiple value elements for date and time properties
# and then only if those methods are insufficient, consider the value-title pattern.

This document post-dates other microformat specifications, such that they may not yet indicate which properties permit use of this pattern. In the interim, '''only''' the following types of properties should allow the value-title pattern.

* ISO8601 date, datetime, timezone, and duration values
* Enumerated values (such as the hCard tel/email/adr 'type' subproperties)
* Co-ordinates (such as the [[geo]] 'latitude' and 'longitude' properties)
* Telephone number properties (e.g. the hCard 'tel' property)

The [[machine-data]] page has documentation of some of the properties of some specs which experience has shown need a solution like the value-title pattern.

There are some simple reference examples and tests for this pattern on [[value-class-pattern-tests]].

In future use, ''specification authors'' may inherit use of <code>value-title</code> by use of ISO8601 date and time formats, or reuse of other microformats, but specifications should _avoid_ introducing new data structures that depend on or encourage this pattern. New specifications are themselves expected to adhere to the principals of visible data and <abbr>DRY</abbr>.

== Test cases ==
See [[value-class-pattern-tests]].

== <abbr title='Frequently Asked Questions'>FAQ</abbr>==
This section is '''informative'''.

Frequently asked questions about the value-class-pattern. Once this section grows too big, we'll make a separate wiki page (like [[value-class-faq]]).

<div class='discussion'>
* '''Is the value-class pattern supported by any of the microformats tools?'''
** '''A: Yes'''. See the [[value-class-pattern#Implementations|implementations]] section.
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** '''A: 'class' is for field names, not data.''' The class attribute is inappropriate for embedded data values, as per the HTML4 specification, which states <code>class</code> is for ‘general purposing processing’, which is defined as ‘e.g. for identifying fields when extracting data from HTML pages into a database, translating HTML documents into other formats, etc.’. ‘General purpose processing’ does not extend to data itself. Furthermore, this method avoids inventing a new string pattern for embedding data.
* '''Why use an 'empty' element? Why not make up a new attribute, like ‘data’?'''
** '''A: New attributes are invalid.''' Microformats exist and function in ''valid'' HTML. Those are the current standards for web development, and microformats exist for use ''now''. In the future, perhaps revisions of HTML will offer up another solution. For now, this method has been tested against browsers, and creates a consistent document structure (where machine-form and human-form data are siblings).
* '''Shouldn't the <code>title</code> attribute only be used for content?'''
** '''A: 'title' is used for content, machine readable content.''' The <code>title</code> attribute ''is'' used for content and is read by microformats parsers. This exists for cases where data cannot be parsed with sufficient precision from just the commonly published, visible information. This pattern allows both forms of content to be included, whilst keeping it invisible to human consumers.
</div>

You can also refer to the general [[faq|Microformats FAQ]] and [[principles]].

== Examples in the wild ==
This section is '''informative'''.

The following sites and pages have started marking up content with the value-class-pattern, and are thus good places to go for examples with real world content to test with implementations (i.e. parsers). If you use the value-class-pattern in your content, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-examples-in-wild]]).

* [http://visitmix.com/labs/oomph/2.0/tests/test.html Test Harness For Oomph] This pages uses a whole range of different patterns for both hCard and hCalendar, using both value and value-title, mostly derived from the specification above
* [http://georgebrock.com/ George Brocklehurst's activity stream] and [http://blog.georgebrock.com/ blog] use "value-title" for hAtom <code>published</code> property
* [http://ben-ward.co.uk/ Ben Ward's home page] uses:
** "value-title" for hCard <code>bday</code> property
** "value-title" for hAtom <code>updated</code> property
* [http://microformats.org/ microformats.org] uses:
** "value-title" for hAtom <code>updated</code> property in [[http://microformats.org/ microformats.org blog postss]]]
** date and time value separation for hCalendar <code>dtstart</code> property in [[events|microformats.org recent and upcoming events wiki page]]

''Add your site/page(s) that use the value-class-pattern here, along with a brief description of what value-class-pattern features you use, with which microformat(s) and which of its/their properties.''

== Implementations ==

This section is '''informative'''.

The following implementations have been developed which either generate or parse value-class-pattern property values. If you have an value-class-pattern implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page (like [[value-class-implementations]]).


=== consuming and parsing tools ===
* [[Google]] parses <code>value-title</code> as part of their [http://googlewebmastercentral.blogspot.com/2010/01/introducing-new-rich-snippets-format.html support for hCalendar rich snippets], as documented specifically in the [https://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=164506 microformats example for rich snippet events].
* [[Oomph]] Version 2 passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]] and is a thorough implementation of the value class pattern.
* [[X2V]] v0.9.3 and later:
** implements [[#Date_and_time_values|Date and time values parsing]], including am/pm time values
*** thus passes [[value-class-pattern-tests#Date_and_time_values|Date and time values test cases]].
** implements [[#hCalendar_dtend_implied_date|hCalendar implied dtend date]]
* [[Operator]] has *some* implementation of the value-class-pattern according to Michael Kaply, but precisely how much is implemented, for which properties (property types) and which microformats is not currently known.
* [[Optimus]] v0.8 and later implements <code>value-title</code> as [http://twitter.com/DmitryBaranovsk/status/1891253248 announced by Dmitry Baranovskiy].
* HTML::Microformats and its predecessors support <code>value</code> excerpting. HTML::Microformats (though not its predecessors) supports <code>value-title</code>.

=== publishing tools ===
* [http://getk2.com/ K2] (WordPress Theme) is using "value-title" for the hAtom published property. [http://code.google.com/p/kaytwo/issues/detail?id=832]

== Articles ==
Articles and <span id="Blog_Posts">blog posts</span> discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* <span class="hentry"><span class="published">2009-08-25</span> <span class="entry-summary">MIX Online: <span class="entry-title">[http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern]</span></span> by <span class="author vcard"><span class="fn">Jeremy Keith</span></span></span>
* [http://ablognotlimited.com/s/106 Getting Semantic With Microformats, Part 8: Value Class Pattern] -- A very thorough writeup by Emily Lewis on the value class pattern
* [http://adactio.com/journal/1579/ 2009-05-17 Adactio: Microformation]
* [http://forabeautifulweb.com/blog/about/value_class_pattern/ For A Beautiful Web: Value Class Pattern]
* <span class="hentry"><span class="published">2009-05-12</span> <span class="entry-title">notizblog.org: [http://notizblog.org/2009/05/12/microformats-value-class-pattern/ Microformats: Value Class Pattern]</span> by <span class="author vcard"><span class="fn">Matthias Pfefferle</span></span></span> (german)
* [http://microformats.org/blog/2009/05/12/value-class-pattern/ 2009-05-12 microformats.org: Value Class Pattern]

==Related Pages==
This section is '''informative'''.

* [[value-class-pattern-tests]]
* [[value-excerption-pattern-issues]]
* [[hcard#Value_excerpting|hCard: Value Excepting]]
* [[value-class-pattern-brainstorming]]
* [[value-excerption-pattern-brainstorming]]
* [[machine-data|Machine Data in Microformats]]

== References ==
This section is '''informative'''.
* [http://www.useit.com/alertbox/9608.html Jakob Nielsen: International Web Usability]

hcard-input-brainstorming

2011-02-15T15:04:10Z

TobyInk:

This page is for documenting previous efforts at formats for web forms that input contact information (people or organizations/venues) towards brainstorming the use of [[hcard-input|hCard for input]] into forms for enabling [[hcard-parsing-brainstorming#forms_auto-fill|hCard forms auto-fill]] and [[hCard]] copy + paste.

{{stub}}

== proposals ==
=== hCard properties on form elements ===
Use hCard properties as class names on form elements inside a container (such as a containing <code><fieldset></code> or the containing <code><form></code>) to indicate that those form elements accept values with the semantics of the respective hCard properties.

Example:
* how to markup a containing <code><form></code>, <code><fieldset></code>, or <code><div></code> element with the root class name <code>vcard</code>.
* how to markup <code><input type="text" ></code> elements with hCard property names

Details:
* how to markup <code><select></code> elements (e.g. for state/region and country name, many [[hcard-input-examples|examples]])
* how to markup compound input fields, e.g. City, State Zip all in one field (per [[hcard-input-examples#Yelp_add_business|Yelp add business example]])

=== Design goals for “input microformats” ===
Use the current microformat authoring conventions and schemas where possible. This goal should be understood in the light that most microformats are designed as hierarchical structures and whereas forms are not. Some breaking changes maybe required to deal with this fundamental difference, but these should be kept to a minimum.

Where possible any differences in authoring should be dealt with by creating a common superset of additional classes for auto-filling applications. This approach will limit the cognitive load on authors and allow the reuse of current parsers.

A primary design goal must be the consideration of i18n. This most effects dates and durations. The individual implementations may allow for language specific formatting, but it should not be part of this specification.

It should be reasonably easy for an author to add classes to a pre-existing form without having to change its data structure.

=== Auto-fill application vs generalist parsing documentation ===
Auto-filling a form and parsing its contents are two different operations, although they share the same conventions and schemeas. The discussion on how a microformat parser should extract values from form elements can be different to the needs of an application that can auto-fill a form using microformat data.

=== The <code>input</code> classname ===
To aid discovery and differentiate the use of microformats for the use of auto-fill applications we should use an <code>input</code> classname in conjunction with the root microformats classname. The current suggestion of appending the root classname with <code>input</code> ie <code>vcard-input</code> would break all current parsers. To add the demarcation we should use a new class <code>input</code>

Proposed markup:
<pre><nowiki>
<form class="vcard input">
<label for="name">title</label>
<input class="fn" id="name" type="text" />
<form>
</nowiki></pre>

This would allow authors and applications to determine the intended use case i.e. the microformat mark-up is for form auto-fill. It would also be a simple task to update the current generalist parsers to ignore the mark-up if they were looking for content only. By default, most of the current parsers would already ignore an empty form marked-up with microformats as the required properties such as fn in hCard would be blank.

=== Form fields should use the classname attribute ===
It is tempting to consider using the form field name attribute as an alternative to the classname attribute, but this would break the current authoring conventions and all current parsers. We should confine the definitions of microformat to classname and rel attributes.

Proposed markup:
<pre><nowiki>
<input class="fn" id="name" type="text" />
</nowiki></pre>

=== Text inputs and textareas ===
The mapping of content into text inputs and textareas is relatively straightforward, matches are made on the classname attribute and the whole value is used to fill in the form field.

Proposed markup:
<pre><nowiki>
<input class="fn" id="name" type="text" />
<textarea class="note" name="bio" cols="20" rows="2"></textarea>
</nowiki></pre>

=== Multiple form fields for plural microformat properties ===
Where a microformat property such as <code>street-address</code> in hCard can contain an array of values, these values will be added in order into the collection of form fields with the same classname.

Proposed markup:
<pre><nowiki>
<input class="street-address" name="address1" type="text" />
<input class="street-address" name="address2" type="text" />
<input class="street-address" name="address3" type="text" />
</nowiki></pre>

=== Selects ===
Values can be passed into selects where a match can be found against the content or value of an option. The example below shows how a select could be used to define the <code>type</code> of a <code>tel</code>. The auto-fill application should check the content of the option first then its value attribute. Where a property such as a tel type is plural and the select element has the <code>multiple</code> attribute an auto-fill application should set multiple values in the select.

Proposed markup:
<pre><nowiki>
<div class="tel">
<input class="value" name="telephone-number" type="text" />
<select class="type" name="telephone-type" multiple="multiple">
<option value="none">Select phone type</option>
<option value="home">Home</option>
<option value="work">Work</option>
<option value="pref">Pref</option>
<option value="fax">Fax</option>
<option value="cell">Mobile</option>
<option value="cell">Pager</option>
</select>
</div>
</nowiki></pre>

=== Checkbox inputs ===
Checkbox inputs can be used much like a multiple select. The values have to match the controlled vocabulary of the microfomat property being targeted.

Proposed markup:
<pre><nowiki>
<div class="tel">
<input class="value" type="text" />
<input class="type" name="type" value="home" type="checkbox" />Home
<input class="type" name="type" value="work" type="checkbox" />Work
etc…
</div>
</nowiki></pre>

=== Radio inputs ===
Radio inputs can be used to force a single selection from a controlled vocabulary. There are very few single value controlled vocabularies in the microformats schemas, but <code>rating</code> in hReview would be a good example.

Proposed markup:
<pre><nowiki>
<input class="rating" name="rating" value="5" type="radio" />5
<input class="rating" name="rating" value="4" type="radio" />4
<input class="rating" name="rating" value="3" type="radio" />3
etc…
</nowiki></pre>

=== Hidden input fields ===
In general, the use of hidden fields should be discouraged, but they are use useful for the post processing of language specific formatting. A good example of this would be hResumes use of <code>duration</code> to define how long someone has had a job. This is most often done with month/year drop down selects as on linkedin.com.

Proposed markup:
<pre><nowiki>
<select id="month-started">
<option value="1">January</option>
…
</select><br />
<input id="year-started" type="text" />
<input class="duration" type="hidden" onchange="someCustomFormatting()" />
</nowiki></pre>

In the example above the <code>duration</code> value is correctly passing into a hidden input which will be submitted with the form allowing the page author to build custom i18n formatting through JavaScript. The alternative would be to display an ISO duration such as “P3Y4M”. This type of interaction design could be achieved using JavaScript hijacking techniques to aid clients that do not support scripts.

=== HTML5 input types ===
Although HTML5 has new semantic input types such as <code>search</code> and <code>url</code> their primary purpose is to describe data types rather than the context of data use. We may know that the input in the example below is a date, but we only know that it is a start date of an event by the use of the classname attribute <code>dtstart</code>.

Proposed markup:
<pre><nowiki>
<div class="vevent">
<input class="dtstart" type="datetime" />
</nowiki></pre>

For clarity and consistency in authoring rules, an auto-fill application should not try and imply context from the input type. All the non date and number based input types <code>search</code>, <code>email</code>, <code>url</code> and <code>tel</code> should be treated as if they were a simple text input.

The <code>color</code> input is not supported as it is not yet used as a data type in the current or proposed schemas

=== DateTime, Number and Range input types ===
The new HTML5 DateTime input types still do not give the data context, but they do inform us of specific formatting requirements. Where possible the auto-fill application should format the DateTime value as per the <code>type</code>. If the passed data does not contain the DateTime fragment required for the specific format the input should be left blank.

Proposed markup:
<pre><nowiki>
<input class="dtstart" type="date" /> 1996-12-19
<input class="dtstart" type="month" /> 1996-12
<input class="dtstart" type="time" /> 17:39:57
<input class="dtstart" type="datetime" /> 1996-12-19T16:39:57-08:00
<input class="dtstart" type="datetime-local" /> 1996-12-19T16:39:57
</nowiki></pre>

The number and range inputs need to be type checked before data is past into the form fields. No invalid dates or numbers should be passed into the form fields.

Min and Max checking on form fields
If a <code>min</code> or <code>max</code> attribute exists for a number or datetime input the value being passed needs to be checked to make sure it is in range before the input is updated.

== <input type="vcard"> ==

Hey, that would be nice: if "vcard" were just an input type in forms. My browser could fill it in with my vCard, or with a vCard read from disk, or with data scraped from an hCard somewhere online. I wonder how doable this is using a JS shim?

== see also ==
* [[hcard-input]]
* [[hcard-input-examples]]
* [[hcard-input-formats]]

parsers

2011-02-07T12:24:20Z

TobyInk: /* HTML::Microformats */ add 0.102 release notice

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== .Net ==
[http://ufxtract.com/ UfXtract] is an open source .Net microformats parser. It can parse microformats from URLs or HTML strings. The extracted data can be used directly in .Net or converted into JSON, JSON-P or XML. Currently Supports 16 microformats and can easily be extended with new definitions.

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Microformat Shiv ===
* [http://microformatshiv.com/ Microformat Shiv] The microformat shiv provides a simple to use, light-weight, cross-browser microformat API. It even works with modern mobile browsers and is backward compatible with Internet Explore 6. Based on the microformat API for Mozilla's extensions. This is the same code base as the popular Operater plug-in.

=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
[http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
* input:
** rel: [[rel-enclosure]], [[rel-license]], [[rel-tag]], [[VoteLinks]], [[XFN]].
** class: [[adr]], [[figure]], [[geo]], [[hAtom]], [[hAudio]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hCard]], [[hListing]], [[hNews]], [[hProduct]], [[hRecipe]], [[hResume]], [[hReview]], [[hReview-aggregate]], [[xFolk]], [[XMDP]], [[XOXO]].
*** highly experimental: [[measure]], [[species]].
** poshformats: [http://ocoins.info/ OpenURL COinS].
* output:
** RDF: RDF/XML, Turtle, N-Triples, RDF/JSON, etc.
** JSON
** domain specific: vCard (3.0, 4.0 and XML), iCalendar, Atom, KML.
* By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2011-02-05 [http://microformats.org/discuss/mail/microformats-dev/2011-February/000667.html 0.102]
* 2010-12-22 0.101
* 2010-12-16 [http://microformats.org/discuss/mail/microformats-discuss/2010-December/013363.html 0.100]
* 2010-10-18 0.00_13
* 2010-06-25 0.00_12
* 2010-06-23 0.00_11
* 2010-05-13 0.00_10
* 2010-05-12 0.00_09
* 2010-04-29 0.00_08
* 2010-04-28 0.00_07
* 2010-04-16 [http://microformats.org/discuss/mail/microformats-dev/2010-April/000651.html 0.00_06]
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

==== XML::Atom::Microformats ====

[http://search.cpan.org/~tobyink/XML-Atom-Microformats/ XML::Atom::Microformats] provides the same functionality for Atom. It finds microformats in Atom entry content elements.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats Source [http://github.com/WebOrganics/TransFormr available from github] Live webservice available at [http://microform.at/ microform.at].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

parsers

2011-02-06T22:23:42Z

TobyInk: /* HTML::Microformats */ add output formats, v 0.101 and 0.102.

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== .Net ==
[http://ufxtract.com/ UfXtract] is an open source .Net microformats parser. It can parse microformats from URLs or HTML strings. The extracted data can be used directly in .Net or converted into JSON, JSON-P or XML. Currently Supports 16 microformats and can easily be extended with new definitions.

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Microformat Shiv ===
* [http://microformatshiv.com/ Microformat Shiv] The microformat shiv provides a simple to use, light-weight, cross-browser microformat API. It even works with modern mobile browsers and is backward compatible with Internet Explore 6. Based on the microformat API for Mozilla's extensions. This is the same code base as the popular Operater plug-in.

=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
[http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
* input:
** rel: [[rel-enclosure]], [[rel-license]], [[rel-tag]], [[VoteLinks]], [[XFN]].
** class: [[adr]], [[figure]], [[geo]], [[hAtom]], [[hAudio]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hCard]], [[hListing]], [[hNews]], [[hProduct]], [[hRecipe]], [[hResume]], [[hReview]], [[hReview-aggregate]], [[xFolk]], [[XMDP]], [[XOXO]].
*** highly experimental: [[measure]], [[species]].
** poshformats: [http://ocoins.info/ OpenURL COinS].
* output:
** RDF: RDF/XML, Turtle, N-Triples, RDF/JSON, etc.
** JSON
** domain specific: vCard (3.0, 4.0 and XML), iCalendar, Atom, KML.
* By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2011-02-05 0.102
* 2010-12-22 0.101
* 2010-12-16 [http://microformats.org/discuss/mail/microformats-discuss/2010-December/013363.html 0.100]
* 2010-10-18 0.00_13
* 2010-06-25 0.00_12
* 2010-06-23 0.00_11
* 2010-05-13 0.00_10
* 2010-05-12 0.00_09
* 2010-04-29 0.00_08
* 2010-04-28 0.00_07
* 2010-04-16 [http://microformats.org/discuss/mail/microformats-dev/2010-April/000651.html 0.00_06]
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

==== XML::Atom::Microformats ====

[http://search.cpan.org/~tobyink/XML-Atom-Microformats/ XML::Atom::Microformats] provides the same functionality for Atom. It finds microformats in Atom entry content elements.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats Source [http://github.com/WebOrganics/TransFormr available from github] Live webservice available at [http://microform.at/ microform.at].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

hBookmark

2011-01-17T00:05:28Z

TobyInk: issues

hBookmark is a microformat for bookmark management based on the [[hreview|hReview]] microformat.

Current Version is Draft 0.01

As usual, <pre> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.</pre>

== Schema ==
The hBookmark schema consists is based on the [[hreview|hReview]] microform format, and contains the following elements. They are summarized here, and explained in detail below. For technical meaning of capital 'REQUIRED'

Elements:
* hBookmark ('''<code>hBookmark</code>''')
** '''<code>uri</code>''' Standard URI. REQUIRED, Read/write support REQUIRED.
** '''<code>summary</code>''' text, 140 chars max. OPTIONAL, Read/write support REQUIRED.
** '''<code>description</code>'''text with optional valid HTML markup. ' OPTIONAL, Read/write support REQUIRED.
** '''<code>tag</code>''' text. One or more. OPTIONAL, Read/write support REQUIRED.
** '''<code>tri</code>'''Transitory Resource Identifier for bit.ly, etc. Date and service as optional attributes. .OPTIONAL, Read/write support OPTIONAL.
** '''<code>encoding</code>''' Type of content of uri. .OPTIONAL, Read/write support OPTIONAL.

== Issues ==
* This seems to be an unnecessary re-invention of [[xFolk]].

html5

2010-12-22T09:58:35Z

TobyInk: /* time element */ HTML::Microformats supports <time>.

<entry-title>Microformats in HTML5</entry-title>

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

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

==New features in HTML5==

=== time element ===
'''<code>time</code> element for representing date times'''. In HTML5, the machine form of datetimes can be represented natively. In some cases it may be possible to replace the date-time design pattern with native HTML5.
* <code>time</code> takes an optional <code>pubdate</code> attribute, to indicate the publication date of an <code>article</code>. Synonymous with [[hAtom]] <code>published</code>, may imply [[hAtom]] <code>updated</code>, may imply [[hReview]] <code>dtreviewed</code>, may imply [[hListing]] <code>dtlisted</code>

Note that there are documented [http://wiki.whatwg.org/wiki/Time limitations in the time element]. Please add additional opinions and use cases to that wiki page so that we can help improve the time element.

* Recommendation: Use the [[value-class-pattern]], in particular preferably <strong>date-time-separation</strong> for accessibly marking up dates and times while following the <abbr title="Don't Repeat Yourself">DRY</abbr> [[principle]] as much as possible.

* [[parsers#HTML::Microformats|HTML::Microformats]] and its predecessors have supported the <code>time</code> element since July 2008.

* Try http://dev.h2vx.com/ (the beta version of [[H2VX]]) as it now has preliminary support for <code><time datetime></code> as well as the new semantic HTML5 elements.

==== hCalendar with time element ====
Here is the [[hcalendar#Examples|hCalendar spec example]] updated to use section instead of div, and time instead of abbr.

<source lang=html4strict>
<section class="vevent">
<a class="url" href="http://conferences.oreillynet.com/pub/w/40/program.html">
http://conferences.oreillynet.com/pub/w/40/program.html
</a>
<span class="summary">Web 2.0 Conference</span>:
<time class="dtstart" datetime="2005-10-05">October 5</time>-
<time class="dtend" datetime="2005-10-07">7</time>,
at the <span class="location">Argent Hotel, San Francisco, CA</span>
</section>
</source>

=== article element ===
'''<code>article</code>''' element for major, independent compositions of content within a page. Perhaps synonymous with [[hAtom]] <code>hentry</code>. Could be parsed as <code>hentry</code> within explicit <code>hfeed</code> blocks?

=== data attributes ===
'''<code>data-</code> naming convention for tag attributes'''. the draft specification states that any attribute that starts with "data-" will be treated as a storage area for private data.
* Note that the data-* stuff is explicitly <em>not</em> for microformats. Those attributes are defined in such a way that browsers will never do anything special with them, ever. They are intended for script authors to have a space in which they can play without ever clashing with anything the browser does. There may be some cases of private [[poshformats]] that are never intended for interchange that may be used in data-* attributes.

=== new semantic elements ===
HTML5 has numerous new semantic elements.

Most microformats [[parsers]] probably won't recognize those elements and may ignore them - so avoid using microformats classes on new HTML5 semantic elements for anything in production.

HOWEVER, do try experimenting with microformats and new semantic HTML5,

AND try http://dev.h2vx.com/ (the beta version of [[H2VX]]) as it now has preliminary support for the new semantic HTML5 elements as well as <code><time datetime></code>.

== Additions beyond HTML5 ==
=== microdata ===
{{main|microdata}}
'''[[microdata]]''' is an extension to HTML5 that provides a set of attributes and associated DOM APIs for semantically marking up and extracting data from existing content in web pages, similar to microformats but with new attributes.

== Current microformat compatibility ==
There seems to be no issue with current implementation of the following microformats in HTML 5:
* [[hcard]]
* [[xfn]]

== Requests ==
* "how to use with HTML5" sections that include (a) microformats examples that use [[HTML5]], and (b) microformats parsing details that specify what to do (if anything special is required) with HTML5 elements (e.g. how to parse the <code>time</code> element for dates and times for microformats). See (and add to if necessary) :
** [[hcard-brainstorming#how_to_use_with_HTML5|hCard brainstorming - how to use with HTML5]]
** [[hcalendar-brainstorming#how_to_use_with_HTML5|hCalendar brainstorming - how to use with HTML5]] e.g. hCalendar with the <code>time</code> element
** [[citation-brainstorming#how_to_use_with_HTML5|citation brainstorming - how to use with HTML5]]
** if nothing special is required for HTML5, then after performing the analysis, that should be noted as well, for the purpose of clarity.

==Issues==
<div class='discussion issues'>
* '''The <code>rev</code> attribute has been removed'''. In HTML5, <code>rel</code> and <code>rev</code> are no-longer paired, and the <code>rel</code> attribute nolonger describes the direction of a relationship. Microformats which use <code>rev</code> will need to use <code>rel</code> instead.
** Or something like data-rev="vote-for"
*** As above, <code>data-</code> attributes are for application-context functionality, ''not'' shared vocabularies. Further, the HTML5 specification makes <code>rel</code> the correct attribute to use, regardless of direction, through the changed specification. --[[User:BenWard|BenWard]] 17:53, 12 May 2009 (UTC)
* '''The <code>profile</code> attribute has been removed'''. In HTML, the <code>profile</code> attribute from the <code>head</code> has been removed, with no direct replacement. This causes issues for GRDDL support. It's been suggested that profile URLs be represented in <code>link</code> elements instead, or even as a custom HTTP header. See [[grddl]] and [[profile-uris]]
** See [[rel-profile]] which is the replacement for the profile attribute. [[User:Tantek|Tantek]] 23:24, 5 November 2009 (UTC)
* '''Microdata <code>itemprop</code> duplicates <code>class</code> data'''. the new attribute itemprop is designed to hold some meaningful data about an element, but class already exists to hold this data. Unsure of reasons why itemprop required?
** This is because microdata is designed to be generically parsable, even when the parser does not understand the vocabulary. As such, property names have to be on an explicit attribute, not shared with other, non-data classnames. --[[User:BenWard|BenWard]] 21:12, 4 September 2009 (UTC)
* '''The [http://microformats.org/wiki/value-class-pattern#Date_and_time_parsing recommended removal of the colon in timezone] doesn’t validate''' The relevant uF wiki text is “However the colons ":" separating the hours and minutes of any timezone offset are optional and discouraged in order to make it less likely that a timezone offset will be confused for a time.” ref: [http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#global-dates-and-times HTML5 time microsyntax for <time>] --[[User:Oli|Oli]] 14:40, 14 February 2010 (+9)
</div>

== see also ==
* [[HTML3]]

wiki-feedback

2010-12-21T12:59:07Z

TobyInk: annoying CAPTCHA

== What is This? ==
We collect feedback on usability and organization of the wiki here.

== What can I do here? ==
* Complain about how hard the wiki is to use. (Make it a story, if possible.)
* Add suggestions regarding content, organization, and usability to [http://microformats.org/wiki/to-do#Information_Architecture the IA todo list]. (Add your own area if necessary).
* Concur that you also had a problem finding something on the wiki.
* Search through the [http://microformats.org/discuss/mail/microformats-discuss/ Mailing List Archives] for
** [http://www.google.com/search?&q=site%3Ahttp%3A%2F%2Fmicroformats.org%2Fdiscuss%2Fmail%2Fmicroformats-discuss%2F+confused confused]
** [http://www.google.com/search?&q=site%3Ahttp%3A%2F%2Fmicroformats.org%2Fdiscuss%2Fmail%2Fmicroformats-discuss%2F+trouble trouble]
** [http://www.google.com/search?&q=site%3Ahttp%3A%2F%2Fmicroformats.org%2Fdiscuss%2Fmail%2Fmicroformats-discuss%2F+confusion confusion]
** [http://www.google.com/search?&q=site%3Ahttp%3A%2F%2Fmicroformats.org%2Fdiscuss%2Fmail%2Fmicroformats-discuss%2F+help help]
and post your results here.

== Issues ==

<div id="Complaints:">
:'''Please add new issues to the end of this list. Thank you.'''

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-10-16</span> raised by <span class="fn">Roger </span></span>
<div class="description">
*# Roger was wondering how fn and org work together, and didn't see the relevant section in the [[hcard|hCard]] spec.
*#* See [[hcard#Organization_Contact_Info|Organization Contact Info]] in the spec, and [[hcard-authoring#The_Importance_of_Names|The Importance of Names]] in [[hcard-authoring]]. I recommend this be added to [[hcard-faq]]. [[User:Tantek|Tantek]] 17:54, 16 Oct 2006 (PDT)
*#* Once I pointed out the first reference, he wondered why he missed it. Nonetheless, missed it he did. How should we highlight recommendations/suggestions? [[User:BenWest|BenWest]] 21:44, 16 Oct 2006 (PDT)

</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-10-16</span> raised by <span class="fn">Justin </span></span>
<div class="description">
*# I didn't even see that there was a page on authoring within the pages and pages of specification. Even with it at the top of the page. I glanced right over it. It seems like most tutorials on hCard or [[hcalendar|hCalendar]] point people to the spec to get more information. Should we be encouraging people to point to the authoring page? I think a newbie would be very very very intimidated being pointed right to the spec.
*#* I agree with this. Perhaps a more friendly intro page could be constructed to introduce hCard and link to the various resources. [[User:Ashley|Ashley]] 14:31, 16 Oct 2006 (PDT)
</div>
</div>

<div class="vevent">
* <span class="summary vcard"><span class="dtstart">2006-10-16</span> raised by <span class="fn">[[User:Ashley|Ashley]]</span></span>
<div class="description">
*# can't find any useful information about marking up a key in the wiki. Perhaps someone could include some examples?
*#* Ashley, what do you mean by a "key"? [[User:Tantek|Tantek]] 17:54, 16 Oct 2006 (PDT)
*#** Er, hCard "[[hcard-examples#3.7.2_KEY_Type_Definition|key]]". I just found it though. I'm becoming increasingly proficient at opening my mouth before I know what I'm talking about around here, sorry.
</div>
</div>

<div class="vevent">
* <span class="summary vcard"><span class="dtstart">2006-10-16</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# I have a co-worker who "was baffled by [[hCalendar]]; not least because, though the page had an irrelevant and misleading treatise on 'Semantic XHTML Design Principles', it didn't list the hCalendar fields, let alone say which are mandatory and which are optional!" I started such a list, but the edit was soon reverted. [[User:BenWest|BenWest]] 15:11, 16 Oct 2006 (PDT)
*#* Agreed that hCalendar needs to list the properties/sub-properties. Added to my [[to-do]] list. [[User:Tantek|Tantek]] 17:54, 16 Oct 2006 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-10-16</span> raised by <span class="fn">[[User:BenWest|BenWest]]</span></span>
<div class="description">
*# This suggestion http://microformats.org/discuss/mail/microformats-discuss/2006-October/006101.html and many other proposals like it aren't being captured on the wiki. This means we are doomed to discuss rejected microformats again and again. Maybe we can have a gallery of ideas and their status (both ongoing and dead)... [[User:BenWest|BenWest]] 15:11, 16 Oct 2006 (PDT)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2006-10-16</span> raised by <span class="fn">Mike Schinkel</span></span>
<div class="description">
*# Mike says in a recent email to the list: -- (Nothing I could find on Microformats.org is explicit in defining "goals") -- (If would be good if there were a consensus, or at least if we were all aware.)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2007-03-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# Poor Internationalisation: We should not [http://microformats.org/wiki?title=hcard-authoring&diff=13621&oldid=12275 assume that all publishing is done in English].
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-02-06</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span></span>
<div class="description">
*# The use of <code><nowiki><h1></nowiki></code> and other such headings, instead of wiki-format headings ("="), breaks the section-edit buttons. The last section on such pages is not editable without editing the whole (sometimes large) page; and the change from the default behavior is also confusing to people used to editing other MediaWiki installations.
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2010-12-21</span> raised by <span class="fn">[[User:TobyInk|TobyInk]]</span></span>
<div class="description">
*# The wiki has a CAPTCHA activated when adding external links. It treats links to the mailing list archive as external. This is very annoying.
</div>
</div>

</div>

===Template===
{{issues-format}}

== How Does This Work? ==
List issues, above. After they are addressed and confirmed, we can strike through them, and after some time when it is clear they have been addressed we can archive them. Perhaps if there is a suggestion it should be emphasised and we should take care to make sure it gets moved to the [[to-do]] list.

==See also==
*[[issues]]

parsers

2010-12-21T12:44:54Z

TobyInk: /* HTML::Microformats */ add link to release announcement

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== .Net ==
[http://ufxtract.com/ UfXtract] is an open source .Net microformats parser. It can parse microformats from URLs or HTML strings. The extracted data can be used directly in .Net or converted into JSON, JSON-P or XML. Currently Supports 16 microformats and can easily be extended with new definitions.

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Microformat Shiv ===
* [http://microformatshiv.com/ Microformat Shiv] The microformat shiv provides a simple to use, light-weight, cross-browser microformat API. It even works with modern mobile browsers and is backward compatible with Internet Explore 6. Based on the microformat API for Mozilla's extensions. This is the same code base as the popular Operater plug-in.

=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[rel-enclosure]], [[rel-license]], [[rel-tag]], [[VoteLinks]], [[XFN]].
** class: [[adr]], [[figure]], [[geo]], [[hAtom]], [[hAudio]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hCard]], [[hListing]], [[hNews]], [[hProduct]], [[hRecipe]], [[hResume]], [[hReview]], [[hReview-aggregate]], [[xFolk]], [[XMDP]], [[XOXO]].
*** highly experimental: [[measure]], [[species]].
** poshformats: [http://ocoins.info/ OpenURL COinS].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-12-16 [http://microformats.org/discuss/mail/microformats-discuss/2010-December/013363.html 0.100]
* 2010-10-18 0.00_13
* 2010-06-25 0.00_12
* 2010-06-23 0.00_11
* 2010-05-13 0.00_10
* 2010-05-12 0.00_09
* 2010-04-29 0.00_08
* 2010-04-28 0.00_07
* 2010-04-16 [http://microformats.org/discuss/mail/microformats-dev/2010-April/000651.html 0.00_06]
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

==== XML::Atom::Microformats ====

[http://search.cpan.org/~tobyink/XML-Atom-Microformats/ XML::Atom::Microformats] provides the same functionality for Atom. It finds microformats in Atom entry content elements.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats Source [http://github.com/WebOrganics/TransFormr available from github] Live webservice available at [http://microform.at/ microform.at].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

parsers

2010-12-21T10:47:06Z

TobyInk: /* HTML::Microformats */ update version listing; VoteLinks is a rel-based uf.

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== .Net ==
[http://ufxtract.com/ UfXtract] is an open source .Net microformats parser. It can parse microformats from URLs or HTML strings. The extracted data can be used directly in .Net or converted into JSON, JSON-P or XML. Currently Supports 16 microformats and can easily be extended with new definitions.

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Microformat Shiv ===
* [http://microformatshiv.com/ Microformat Shiv] The microformat shiv provides a simple to use, light-weight, cross-browser microformat API. It even works with modern mobile browsers and is backward compatible with Internet Explore 6. Based on the microformat API for Mozilla's extensions. This is the same code base as the popular Operater plug-in.

=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[rel-enclosure]], [[rel-license]], [[rel-tag]], [[VoteLinks]], [[XFN]].
** class: [[adr]], [[figure]], [[geo]], [[hAtom]], [[hAudio]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hCard]], [[hListing]], [[hNews]], [[hProduct]], [[hRecipe]], [[hResume]], [[hReview]], [[hReview-aggregate]], [[xFolk]], [[XMDP]], [[XOXO]].
*** highly experimental: [[measure]], [[species]].
** poshformats: [http://ocoins.info/ OpenURL COinS].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-12-16 0.100
* 2010-10-18 0.00_13
* 2010-06-25 0.00_12
* 2010-06-23 0.00_11
* 2010-05-13 0.00_10
* 2010-05-12 0.00_09
* 2010-04-29 0.00_08
* 2010-04-28 0.00_07
* 2010-04-16 [http://microformats.org/discuss/mail/microformats-dev/2010-April/000651.html 0.00_06]
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

==== XML::Atom::Microformats ====

[http://search.cpan.org/~tobyink/XML-Atom-Microformats/ XML::Atom::Microformats] provides the same functionality for Atom. It finds microformats in Atom entry content elements.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats Source [http://github.com/WebOrganics/TransFormr available from github] Live webservice available at [http://microform.at/ microform.at].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

hnews-issues

2010-11-30T10:34:42Z

TobyInk: /* Open Issues */ request for someone to clarify the spec

<h1> hNews issues </h1>

__TOC__

These are externally raised issues about [[hnews|hNews]] 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 draft.

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

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

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

See related [[hatom-issues]] and [[hcard-issues]].

== Template ==

{{issues-format}}

== Issues ==
=== Open Issues ===

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"> <span class="published">2010-11-14</span> raised by <span class="fn">[[User:TobyInk|TobyInk]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Meaning of rel=principles</strong>. It's currently defined as "represents the statement of principles and ethics used by the news organization that produced the news story" - but are those the principles the ones used by the organisation at the time the article was written, or are they the principles that are being used by the organisation currently? If the latter, this property might be better as an extension to hCard. Either way, I think it should be clarified.
** An interesting distinction, and not one I think that was discussed at any point, as far as I can see in my notes. I agree, clarification is needed. I have a feeling that the second option (the principles that are being used by the organization currently) is much simpler, and so more likely to be used. I also agree in part with your point about extending hCard in that case, as the principles apply to the [http://microformats.org/wiki/hnews#Additional_Fields source-org], rather than to the article itself. However, what about those cases where the source organization applies different principles for different types of content? For instance, an opinion piece? [[User:JonathanMalek begin_of_the_skype_highlighting end_of_the_skype_highlighting|JonathanMalek]] 04:45, 15 November 2010 (UTC)
** Good question Toby. The underlying basis of rel-principles has always been 'the principles that apply to this article'. Therefore if the article was written and published under certain principles then it should link to those principles even if the principles of the organisation subsequently change. The purpose of this is so that the reader can always tell under what principles a particular item of news was produced. Therefore rel-principles has to remain flexible by article rather than by author. For this reason I think it is better that it remain part of hNews rather than as an extension to hCard [[User:Martinjemoore|Martin Moore]] 16 November 2010
*** This was the interpretation I'd always assumed, and hoped was the case as it seems most useful. Could somebody update the [[hnews]] page on the wiki to clarify the definition? [[User:TobyInk|TobyInk]] 10:34, 30 November 2010 (UTC)
</div>
</div>
<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2010-03-29</span> raised by <span class="fn">[[User:Trondhuso|Trond Husø]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Add lead class/tag</strong>. An article consists of a title, lead and the body content. I would very much like to see the lead attribute/tag being added. I see two possible usages: 1) In a world of AJAX you could show the content related to the lead-part + Click here for more. When you click the link the rest of the article becomes visible. Or it can be used in parts where you load to a title/lead carousel. 2) In RSS/Atom the Lead-part is what you would like to see in the description part of the feed.
** Trond, I really like the idea. I suggest taking a look at using [http://microformats.org/wiki/hAtom#Entry_Summary hAtom entry-summary] for this purpose. I feel the lead paragraph of the typical upside-pyramid-style news story is an ideal value for the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.summary atom:summary] element. And, by re-using the hAtom conventions in this way, your news item will be semantically available to software focusing on both hAtom and hNews. The Associated Press interpreted Atom in this way, as illustrated by one of [http://hosted.ap.org/lineups/TOPHEADS-atom_0.3.xml?SITE=CAANG&SECTION=HOME AP's public Atom feeds]. [[User:gut1975|Guthrie Collin]] 14:25, 01 April 2010 (UTC)
</div>
</div>

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-11-16</span> raised by <span class="fn">[[User:gut1975|Guthrie Collin]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Allowable number of item-licenses?</strong>. In the news world, different news companies sometimes share the copyright on specific works, and this arrangement results in two copyright statements appearing for one piece of content. Modeling this relationship in the hNews world would result in two or more "item-license" elements, with each item-license element potentially linking to a separate license for each news company. Hence, I think the hNews format should explicitly allow more than one item-license for each "hnews hentry" container. Thoughts?
** If as you say "In the news world, different news companies sometimes share the copyright on specific works, and this arrangement results in two copyright statements appearing for one piece of content" then please provide URLs to real world examples that demonstrate as such. Absent any such examples, we must not change hNews for an otherwise assumed to be theoretical example, per microformats [[process]] and [[principles]]. [[User:Tantek|Tantek]] 23:51, 16 November 2009 (UTC)
** Some examples are:<blockquote><p>[http://sports.yahoo.com/nhl/preview?gid=2006122911 Capitals-Devils Preview on Yahoo!] which was created under a joint arrangement between AP and STATS, Inc (scroll to page bottom).</p><p>[http://www.kcbd.com/global/story.asp?s=11520396 Colo. medical pot & taxes on KCBD 11 in Lubbock, TX] which was an AP story but since AP and some of its customers have special copyright arrangements, KCBD and its parent company also share copyright on the content (see bottom of page).</p></blockquote>As you can see, it's somewhat inefficient to have the license separate from the content in this way, and I think the hNews schema should permit multiple item-license elements for these situations. [[User:gut1975|Guthrie Collin]] 16:21, 17 November 2009 (UTC)
</div>
</div>

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-20</span> raised by <span class="fn">[[User:MilesD|Miles De Feyter]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">News, Commentary, and Opinion pieces as they relate to hNews</strong>. An interesting comment came up today when looking at how to use hNews on other AOL properties outside of our main news site, and that is, some of our sites are both news and commentary. Let's take our sports site for example http://www.fanhouse.com/

This site reports on sports news with article headlines such as:
[http://www.fanhouse.com/news/nfl/big-ben-tops-pass-rankings/723353 Big Ben tops pass rankings]

But fanhouse.com also has some obvious opinion pieces such as:
[http://kevin-blackistone.fanhouse.com/2009/10/19/ail-to-the-redskins-worst-run-franchise-on-the-planet/ Fail to the Redskins: Worst-Run Franchise on the Planet]

Currently we have one publishing system for all of our content within Fanhouse whether it be feed driven, in house publisher, news content, or commentary. So at the moment if one thing gets hNews it all does.

Have you given this situation thought? My initial thinking is that perhaps this is where a principles statement specific to Fanhouse could account for the different types of content being labeled hNews.
** Very glad you brought this up. We've given this alot of thought. I think your initial thinking is right. Right now the place to distinguish differences such as these (e.g. reporting from opinion) is within the principles statement. But this is something I think would benefit significantly from further development (i.e. the development of additional hNews criteria) [[User:Martinjemoore|Martin Moore]]
** I believe that hNews is applicable to many types of news, ranging from reporting facts, to analysis pieces, opinion and columns. It is not unusual for a given piece of news to be a mix of two or three "types". Really, the purpose of hNews is allow for the common structural components of news to be more clearly marked up. The exact content is less important than the form. However, I also see that there is also value for a publisher of hNews to be able to self-classify the "type" of content. One way to do this would be to use rel-tag to indicate how the publisher would like to describe the hNews-encoded content (as commentary, opinion, analysis, interview, satire or whatever). [[User:Smyles|Stuart Myles]]
</div>
</div>

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-14</span> raised by <span class="fn">[[User:MarkNg|MarkNg]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">adr for dateline</strong>. From [http://twitter.com/pigsonthewing/status/4831500605 Andy Mabbett on Twitter] : hNews microformat spec "dateline. optional. Using text or hCard" should read "dateline. optional. Using text, adr or hCard".
** Seems like a useful extra to me, any objections ? [[User:MarkNg|MarkNg]]
** Agreed, makes sense. --[[User:JonathanMalek|JonathanMalek]] 00:57, 15 October 2009 (UTC)
** +1 to addition of optional "adr" markup of "dateline", but should also allow "geo" markup of "dateline" as well. i.e. change: <blockquote><p>* a dateline element MAY be encoded in an hCard.</p></blockquote> to <blockquote><p>* a dateline element MAY be encoded with an [[adr]], [[geo]], or [[hCard]] on the same element.</p></blockquote> [[User:Tantek|Tantek]] 19:57, 15 October 2009 (UTC)
</div>
</div>

=== Resolved Issues ===

<div class="hentry">
{{ResolvedIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-15</span> raised by <span class="fn">[[User:TobyInk|TobyInk]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">XMDP defines 'principles' incorrectly.</strong> The XMDP for hNews defines 'principles' as a class, whereas the rest of the draft refers to it as a link type (i.e. 'rel' value).
** ACCEPTED SPEC UPDATE. FIXED: thanks for pointing that out. I believe the updated profile reflects that correctly now. --[[User:JonathanMalek|JonathanMalek]] 15:37, 15 October 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ResolvedIssue}} <span class="entry-summary author vcard"><span class="published">2009-11-13</span> raised by <span class="fn">[[User:gut1975|Guthrie Collin]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">The item-license element is incorrectly described as a class</strong>. The XMDP profile and element description for item-license in hNews describes the element as a class attribute value, however, the [http://microformats.org/wiki/licensing-brainstorming#item_as_container Licensing Brainstorming] proposal describes this field as a link type. In addition, the hNews examples purport item-license as a link type. Which item-license description is correct?
** ACCEPTED SPEC UPDATE. FIXED: the correct description is as a link (rel). The profile has been updated to reflect that correctly. --[[User:JonathanMalek|JonathanMalek]] 18:44, 13 November 2009 (UTC)
</div>
</div>

=== Closed Issues ===
<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-09</span> raised by <span class="fn">Miles De Feyter</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Implementation of item-license as it relates to hNews</strong>. Reading through the item-license brainstorm it seems to indicate that "item-license" would need to be nested within something with the class of "item". So as this relates to hNews is the suggestion to then have an articles containing div have the three class names of "hnews hentry item"?
** At this point, Miles, that is correct (following the [[licensing-brainstorming#item_as_container|licensing-brainstorming]] concept and guidance). I expect we'll see changes around item-license (it's still just brainstorming), but for the time being, the third class name "item" is needed. --[[User:JonathanMalek|JonathanMalek]] 16:25, 12 October 2009 (UTC)
** Added to [[hnews-faq]] --[[User:JonathanMalek|JonathanMalek]] 02:19, 14 October 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">2009-09-28</span> raised by <span class="fn">[[User:MilesD|Miles De Feyter]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Principles as a requirement</strong>. Working for a publishing company that owns and operates a large number of different organizations I'd love to incorporate hNews within our publishing system. The hNews requirement for a principles statement could pose a problem though or at least make rolling out hNews a more involved process then it would be otherwise. The issue is, I would now have to go to each product owner and ask then to provide this principles statement to link to. So my concern is now rather then just making a change to the publishing system to support hNews there is this requirement for some supporting content. And due to the nature of the content I can only assume our legal dep. would need to sign off as well, further complicating the adoption of hNews.
** +1 I agree that the "principles" property (and probably all other others) should be optional. [[User:Tantek|Tantek]] 18:29, 29 September 2009 (UTC)
*** I think it's important to explain why principles is a requirement. hnews is essentially a specialization of hAtom. Its purpose is to distinguish news on the web. Hence the description of source organisation, license and principles. Of these, principles is the only one which consistently distinguishes news on the web from other content (eg. commercial, government). In the future it should be distinguished further by making the principles themselves machine readable (but that is for a later date). Most professional news organisations adhere to a Statement of Principles (e.g. see http://en.wikipedia.org/wiki/Journalism_ethics_and_standards and http://www.journalism.org/resources/ethics_codes). If a site wants to mark up its content but does not want to distinguish it as news, then wouldn't it be easiest to use hAtom? [[User:martinjemoore|Martin Moore]] 9:00, 20 September 2009 (UTC)
*** Having discussed this issue at length outside this brainstorming, we understand some of the concerns of the microformat community regarding 'must', but are still convinced of the criticality of principles to hNews - therefore recommend downgrading from 'must' to 'should'. [[User:martinjemoore|Martin Moore]] 14:00, 7 October 2009 (UTC)
**** Accepted and implemented in 0.1. In keeping with the general direction here, we've changed <code>item-license</code> as well, and would consider adopting the same with <code>source-org</code> as well, if it proves to present the same problems. --[[User:JonathanMalek|JonathanMalek]] 00:53, 15 October 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">18:32, 24 August 2009 (UTC)</span> raised by <span class="fn">[[User:Kevin Marks|Kevin Marks]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">hCalendar instead of dateline?</strong> Would an [[hCalendar]] event (which can contain an hCard location) make sense for a dateline, or is the 'date' part more often omitted?
** Confusingly, the journalistic term "dateline" isn't anything to do with a date or time. It is the location from which a report is filed and is generally the main location associated with a story. Generally, a dateline consists of a city (e.g. "Rome") but could be the name of a ship at sea or even a space station. [[User:Stuart Myles|Stuart Myles]] 21:12, 24 August 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">18:32, 24 August 2009 (UTC)</span> raised by <span class="fn">[[User:Kevin Marks|Kevin Marks]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">hCard instead of geo?</strong> Is geo really in use here, or would using an hCard (that can contain geo) be a better way of representing locations referred to in the story, as more human readable?
** The reason for geo being highlighted (as an optional field) is to promote at least one location identifier in the story--preferably the most appropriate single location on a map for that particular story. Geo does not have to be related to dateline, but in some [http://labs.ap.org/wiki/hNews examples] we've worked on, we show the two collapsed into a single field. --[[User:JonathanMalek|JonathanMalek]] 23:53, 24 August 2009 (UTC)
** For locations referred to in the story, I agree--publishers should be using [[hCard]] with the contained geo to markup the locations themselves. One of the concepts I've struggled with is drawing an admittedly arbitrary line between the metadata ''about'' a story from the metadata ''within'' a story. For the former, we've focused on simplicity and minimalism, primarily as a means to encourage adoption. That has meant preferring [[rel-tag]] over in-line entity extraction and markup using compound microformats. For the latter, we feel that the field is open: use whatever microformat fits your purpose, however you can--the more, the better. This lets publishers with minimal technology capabilities at least get started by tweaking a few templates in their CMS, while those more technically inclined aren't limited by the simplicity of the format to a paucity of data. --[[User:JonathanMalek|JonathanMalek]] 23:53, 24 August 2009 (UTC)
** Also, dateline can be text or [[hCard]], as noted in the [[news-brainstorming#Common_News_Fields|Common News Fields]] section. --[[User:JonathanMalek|JonathanMalek]] 18:17, 24 September 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">18:32, 24 August 2009 (UTC)</span> raised by <span class="fn">[[User:Kevin Marks|Kevin Marks]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">What is item-license?</strong> Using [[rel-license]] presumably?
** We're working off the [[licensing-brainstorming#item_as_container|licensing-brainstorming]] discussions for this. Our concern with [[rel-license]] was its definition as applying to an entire page, rather than an item within a page. The current discussions around licensing definitely address that. --[[User:JonathanMalek|JonathanMalek]] 00:02, 25 August 2009 (UTC)
*** +1 using item-license for news-brainstorming makes sense. [[User:Tantek|Tantek]] 22:32, 27 August 2009 (UTC)
</div>
</div>

hnews-issues

2010-11-14T11:58:37Z

TobyInk: /* Open Issues */ meaning of rel=principles

<h1> hNews issues </h1>

__TOC__

These are externally raised issues about [[hnews|hNews]] 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 draft.

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

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

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

See related [[hatom-issues]] and [[hcard-issues]].

== Template ==

{{issues-format}}

== Issues ==
=== Open Issues ===

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"> <span class="published">2010-11-14</span> raised by <span class="fn">[[User:TobyInk|TobyInk]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Meaning of rel=principles</strong>. It's currently defined as "represents the statement of principles and ethics used by the news organization that produced the news story" - but are those the principles the ones used by the organisation at the time the article was written, or are they the principles that are being used by the organisation currently? If the latter, this property might be better as an extension to hCard. Either way, I think it should be clarified.</dd>
</div>
</div>
<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2010-03-29</span> raised by <span class="fn">[[User:Trondhuso|Trond Husø]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Add lead class/tag</strong>. An article consists of a title, lead and the body content. I would very much like to see the lead attribute/tag being added. I see two possible usages: 1) In a world of AJAX you could show the content related to the lead-part + Click here for more. When you click the link the rest of the article becomes visible. Or it can be used in parts where you load to a title/lead carousel. 2) In RSS/Atom the Lead-part is what you would like to see in the description part of the feed.
** Trond, I really like the idea. I suggest taking a look at using [http://microformats.org/wiki/hAtom#Entry_Summary hAtom entry-summary] for this purpose. I feel the lead paragraph of the typical upside-pyramid-style news story is an ideal value for the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.summary atom:summary] element. And, by re-using the hAtom conventions in this way, your news item will be semantically available to software focusing on both hAtom and hNews. The Associated Press interpreted Atom in this way, as illustrated by one of [http://hosted.ap.org/lineups/TOPHEADS-atom_0.3.xml?SITE=CAANG&SECTION=HOME AP's public Atom feeds]. [[User:gut1975|Guthrie Collin]] 14:25, 01 April 2010 (UTC)
** Follow-up comment #2
</div>
</div>

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-11-16</span> raised by <span class="fn">[[User:gut1975|Guthrie Collin]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Allowable number of item-licenses?</strong>. In the news world, different news companies sometimes share the copyright on specific works, and this arrangement results in two copyright statements appearing for one piece of content. Modeling this relationship in the hNews world would result in two or more "item-license" elements, with each item-license element potentially linking to a separate license for each news company. Hence, I think the hNews format should explicitly allow more than one item-license for each "hnews hentry" container. Thoughts?
** If as you say "In the news world, different news companies sometimes share the copyright on specific works, and this arrangement results in two copyright statements appearing for one piece of content" then please provide URLs to real world examples that demonstrate as such. Absent any such examples, we must not change hNews for an otherwise assumed to be theoretical example, per microformats [[process]] and [[principles]]. [[User:Tantek|Tantek]] 23:51, 16 November 2009 (UTC)
** Some examples are:<blockquote><p>[http://sports.yahoo.com/nhl/preview?gid=2006122911 Capitals-Devils Preview on Yahoo!] which was created under a joint arrangement between AP and STATS, Inc (scroll to page bottom).</p><p>[http://www.kcbd.com/global/story.asp?s=11520396 Colo. medical pot & taxes on KCBD 11 in Lubbock, TX] which was an AP story but since AP and some of its customers have special copyright arrangements, KCBD and its parent company also share copyright on the content (see bottom of page).</p></blockquote>As you can see, it's somewhat inefficient to have the license separate from the content in this way, and I think the hNews schema should permit multiple item-license elements for these situations. [[User:gut1975|Guthrie Collin]] 16:21, 17 November 2009 (UTC)
</div>
</div>

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-20</span> raised by <span class="fn">[[User:MilesD|Miles De Feyter]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">News, Commentary, and Opinion pieces as they relate to hNews</strong>. An interesting comment came up today when looking at how to use hNews on other AOL properties outside of our main news site, and that is, some of our sites are both news and commentary. Let's take our sports site for example http://www.fanhouse.com/

This site reports on sports news with article headlines such as:
[http://www.fanhouse.com/news/nfl/big-ben-tops-pass-rankings/723353 Big Ben tops pass rankings]

But fanhouse.com also has some obvious opinion pieces such as:
[http://kevin-blackistone.fanhouse.com/2009/10/19/ail-to-the-redskins-worst-run-franchise-on-the-planet/ Fail to the Redskins: Worst-Run Franchise on the Planet]

Currently we have one publishing system for all of our content within Fanhouse whether it be feed driven, in house publisher, news content, or commentary. So at the moment if one thing gets hNews it all does.

Have you given this situation thought? My initial thinking is that perhaps this is where a principles statement specific to Fanhouse could account for the different types of content being labeled hNews.
** Very glad you brought this up. We've given this alot of thought. I think your initial thinking is right. Right now the place to distinguish differences such as these (e.g. reporting from opinion) is within the principles statement. But this is something I think would benefit significantly from further development (i.e. the development of additional hNews criteria) [[User:Martinjemoore|Martin Moore]]
** I believe that hNews is applicable to many types of news, ranging from reporting facts, to analysis pieces, opinion and columns. It is not unusual for a given piece of news to be a mix of two or three "types". Really, the purpose of hNews is allow for the common structural components of news to be more clearly marked up. The exact content is less important than the form. However, I also see that there is also value for a publisher of hNews to be able to self-classify the "type" of content. One way to do this would be to use rel-tag to indicate how the publisher would like to describe the hNews-encoded content (as commentary, opinion, analysis, interview, satire or whatever). [[User:Smyles|Stuart Myles]]
</div>
</div>

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-14</span> raised by <span class="fn">[[User:MarkNg|MarkNg]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">adr for dateline</strong>. From [http://twitter.com/pigsonthewing/status/4831500605 Andy Mabbett on Twitter] : hNews microformat spec "dateline. optional. Using text or hCard" should read "dateline. optional. Using text, adr or hCard".
** Seems like a useful extra to me, any objections ? [[User:MarkNg|MarkNg]]
** Agreed, makes sense. --[[User:JonathanMalek|JonathanMalek]] 00:57, 15 October 2009 (UTC)
** +1 to addition of optional "adr" markup of "dateline", but should also allow "geo" markup of "dateline" as well. i.e. change: <blockquote><p>* a dateline element MAY be encoded in an hCard.</p></blockquote> to <blockquote><p>* a dateline element MAY be encoded with an [[adr]], [[geo]], or [[hCard]] on the same element.</p></blockquote> [[User:Tantek|Tantek]] 19:57, 15 October 2009 (UTC)
</div>
</div>

=== Resolved Issues ===

<div class="hentry">
{{ResolvedIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-15</span> raised by <span class="fn">[[User:TobyInk|TobyInk]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">XMDP defines 'principles' incorrectly.</strong> The XMDP for hNews defines 'principles' as a class, whereas the rest of the draft refers to it as a link type (i.e. 'rel' value).
** ACCEPTED SPEC UPDATE. FIXED: thanks for pointing that out. I believe the updated profile reflects that correctly now. --[[User:JonathanMalek|JonathanMalek]] 15:37, 15 October 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ResolvedIssue}} <span class="entry-summary author vcard"><span class="published">2009-11-13</span> raised by <span class="fn">[[User:gut1975|Guthrie Collin]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">The item-license element is incorrectly described as a class</strong>. The XMDP profile and element description for item-license in hNews describes the element as a class attribute value, however, the [http://microformats.org/wiki/licensing-brainstorming#item_as_container Licensing Brainstorming] proposal describes this field as a link type. In addition, the hNews examples purport item-license as a link type. Which item-license description is correct?
** ACCEPTED SPEC UPDATE. FIXED: the correct description is as a link (rel). The profile has been updated to reflect that correctly. --[[User:JonathanMalek|JonathanMalek]] 18:44, 13 November 2009 (UTC)
</div>
</div>

=== Closed Issues ===
<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-09</span> raised by <span class="fn">Miles De Feyter</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Implementation of item-license as it relates to hNews</strong>. Reading through the item-license brainstorm it seems to indicate that "item-license" would need to be nested within something with the class of "item". So as this relates to hNews is the suggestion to then have an articles containing div have the three class names of "hnews hentry item"?
** At this point, Miles, that is correct (following the [[licensing-brainstorming#item_as_container|licensing-brainstorming]] concept and guidance). I expect we'll see changes around item-license (it's still just brainstorming), but for the time being, the third class name "item" is needed. --[[User:JonathanMalek|JonathanMalek]] 16:25, 12 October 2009 (UTC)
** Added to [[hnews-faq]] --[[User:JonathanMalek|JonathanMalek]] 02:19, 14 October 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">2009-09-28</span> raised by <span class="fn">[[User:MilesD|Miles De Feyter]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Principles as a requirement</strong>. Working for a publishing company that owns and operates a large number of different organizations I'd love to incorporate hNews within our publishing system. The hNews requirement for a principles statement could pose a problem though or at least make rolling out hNews a more involved process then it would be otherwise. The issue is, I would now have to go to each product owner and ask then to provide this principles statement to link to. So my concern is now rather then just making a change to the publishing system to support hNews there is this requirement for some supporting content. And due to the nature of the content I can only assume our legal dep. would need to sign off as well, further complicating the adoption of hNews.
** +1 I agree that the "principles" property (and probably all other others) should be optional. [[User:Tantek|Tantek]] 18:29, 29 September 2009 (UTC)
*** I think it's important to explain why principles is a requirement. hnews is essentially a specialization of hAtom. Its purpose is to distinguish news on the web. Hence the description of source organisation, license and principles. Of these, principles is the only one which consistently distinguishes news on the web from other content (eg. commercial, government). In the future it should be distinguished further by making the principles themselves machine readable (but that is for a later date). Most professional news organisations adhere to a Statement of Principles (e.g. see http://en.wikipedia.org/wiki/Journalism_ethics_and_standards and http://www.journalism.org/resources/ethics_codes). If a site wants to mark up its content but does not want to distinguish it as news, then wouldn't it be easiest to use hAtom? [[User:martinjemoore|Martin Moore]] 9:00, 20 September 2009 (UTC)
*** Having discussed this issue at length outside this brainstorming, we understand some of the concerns of the microformat community regarding 'must', but are still convinced of the criticality of principles to hNews - therefore recommend downgrading from 'must' to 'should'. [[User:martinjemoore|Martin Moore]] 14:00, 7 October 2009 (UTC)
**** Accepted and implemented in 0.1. In keeping with the general direction here, we've changed <code>item-license</code> as well, and would consider adopting the same with <code>source-org</code> as well, if it proves to present the same problems. --[[User:JonathanMalek|JonathanMalek]] 00:53, 15 October 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">18:32, 24 August 2009 (UTC)</span> raised by <span class="fn">[[User:Kevin Marks|Kevin Marks]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">hCalendar instead of dateline?</strong> Would an [[hCalendar]] event (which can contain an hCard location) make sense for a dateline, or is the 'date' part more often omitted?
** Confusingly, the journalistic term "dateline" isn't anything to do with a date or time. It is the location from which a report is filed and is generally the main location associated with a story. Generally, a dateline consists of a city (e.g. "Rome") but could be the name of a ship at sea or even a space station. [[User:Stuart Myles|Stuart Myles]] 21:12, 24 August 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">18:32, 24 August 2009 (UTC)</span> raised by <span class="fn">[[User:Kevin Marks|Kevin Marks]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">hCard instead of geo?</strong> Is geo really in use here, or would using an hCard (that can contain geo) be a better way of representing locations referred to in the story, as more human readable?
** The reason for geo being highlighted (as an optional field) is to promote at least one location identifier in the story--preferably the most appropriate single location on a map for that particular story. Geo does not have to be related to dateline, but in some [http://labs.ap.org/wiki/hNews examples] we've worked on, we show the two collapsed into a single field. --[[User:JonathanMalek|JonathanMalek]] 23:53, 24 August 2009 (UTC)
** For locations referred to in the story, I agree--publishers should be using [[hCard]] with the contained geo to markup the locations themselves. One of the concepts I've struggled with is drawing an admittedly arbitrary line between the metadata ''about'' a story from the metadata ''within'' a story. For the former, we've focused on simplicity and minimalism, primarily as a means to encourage adoption. That has meant preferring [[rel-tag]] over in-line entity extraction and markup using compound microformats. For the latter, we feel that the field is open: use whatever microformat fits your purpose, however you can--the more, the better. This lets publishers with minimal technology capabilities at least get started by tweaking a few templates in their CMS, while those more technically inclined aren't limited by the simplicity of the format to a paucity of data. --[[User:JonathanMalek|JonathanMalek]] 23:53, 24 August 2009 (UTC)
** Also, dateline can be text or [[hCard]], as noted in the [[news-brainstorming#Common_News_Fields|Common News Fields]] section. --[[User:JonathanMalek|JonathanMalek]] 18:17, 24 September 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">18:32, 24 August 2009 (UTC)</span> raised by <span class="fn">[[User:Kevin Marks|Kevin Marks]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">What is item-license?</strong> Using [[rel-license]] presumably?
** We're working off the [[licensing-brainstorming#item_as_container|licensing-brainstorming]] discussions for this. Our concern with [[rel-license]] was its definition as applying to an entire page, rather than an item within a page. The current discussions around licensing definitely address that. --[[User:JonathanMalek|JonathanMalek]] 00:02, 25 August 2009 (UTC)
*** +1 using item-license for news-brainstorming makes sense. [[User:Tantek|Tantek]] 22:32, 27 August 2009 (UTC)
</div>
</div>

page

2010-07-17T08:06:34Z

TobyInk: /* brainstorming */ difficulty in cmses

{{stub}}

<entry-title>page</entry-title>

One particularly interesting use case that seems to keep popping up is that of understanding what a page represents.

This page is for collecting research, ideas, and brainstorms about using microformats to represent what a page is (or is about).

[[microformats]] do a good job of allowing authors to easily markup various semantics in pages such as people, events, reviews etc., however, there are only a few examples ([[XFN]], [[rel-me]], [[representative-hcard]]) of using microformats to designate what a whole page means or represents.

== examples ==
Perhaps move this to [[page-examples]] once it grows a bit.

Examples on the web of pages which represent particular types of objects.

=== Wikipedia ===
Wikipedia has pages that represent or are about numerous types of objects. Typically they use specific "infobox" templates to distinguish them.
* ... (links to specific Wikipedia pages that represent specific types of objects)

== formats ==
Perhaps move this to [[page-formats]] once it grows a bit.
=== existing microformats usage ===
==== person ====
* [[XFN]] - use of XFN on a page implies that the page itself is or represents a person.
** [[rel-me]] - rel="me" hyperlinks in particular assert that the current page represents a person, and the destination of the hyperlink also represents the same person.
** There are numerous sites/profiles which support
*** [[hcard-xfn-supporting-friends-lists#Services_with_XFN_supporting_friends_lists|XFN friends lists]]
*** [[hcard-xfn-supporting-friends-lists#Services_with_XFN_rel.3D.22me.22_to_one_external_site|XFN rel-me to connect your profiles]]
* [[representative-hcard]] - representative hCard is a way to publish (and parse for) the fact that particular hCard represents the person that the page is or is about.
** many (most?) of the [[hcard-supporting-user-profiles|numerous sites supporting hCard profiles]] also support representative hCards.

=== Facebook Open Graph Protocol ===
[http://developers.facebook.com/docs/opengraph Facebook's Open Graph Protocol] introduces a meta-tag based format for expressing that a page is or is about a particular type of thing. The following [http://developers.facebook.com/docs/opengraph#types types of objects] are represented:

Activities
* activity
* sport

Businesses
* bar
* company
* cafe
* hotel
* restaurant

Groups
* cause
* sports_league
* sports_team

Organizations
* band
* government
* non_profit
* school
* university

People
* actor
* athlete
* author
* director
* musician
* politician
* public_figure

Places
* city
* country
* landmark
* state_province

Products and Entertainment
* album
* book
* drink
* food
* game
* product
* song
* movie
* tv_show

Websites
* blog
* website
* article

== brainstorming ==
Perhaps move this to [[page-brainstorming]] once it grows a bit.

=== microformat root class on html or body ===
One simple technique that could work for all microformats is to put the root class name of the microformat on the <code><html></code> (permitted in [[HTML5]]), or if not, then the <code><body></code> element.

A page that represents an event:
<source lang=html4strict>
<!DOCTYPE html>
<html class="vevent">
...
</html>
</source>

A page that represents a review:
<source lang=html4strict>
<body class="hreview">
...
</body>
</source>

This is a simple/easy rule to remember for publishers.

* ... but a lot of publishing platforms (i.e. blog engines, CMSes) would make this pretty difficult in practice. [[User:TobyInk|TobyInk]] 08:06, 17 July 2010 (UTC)

For processors/parsers, the rule is simple as well:

* check the <code><html></code> for microformats root class names, if found, treat the page as that type (or types?) of object
* else check the <code><body></code> for microformats root class names, if found, treat the page as that type (or types?) of object
* else perform any format-specific detection
** [[representative-hcard-parsing]]
** [[XFN]]

== see also ==
* [[exploratory-discussions]]

parsers

2010-06-23T20:43:55Z

TobyInk: /* HTML::Microformats */ supports votelinks, xmdp.

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[rel-enclosure]], [[rel-license]], [[rel-tag]], [[XFN]].
** class: [[adr]], [[figure]], [[geo]], [[hAtom]], [[hAudio]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hCard]], [[hListing]], [[hNews]], [[hProduct]], [[hRecipe]], [[hResume]], [[hReview]], [[hReview-aggregate]], [[VoteLinks]], [[xFolk]], [[XMDP]], [[XOXO]].
*** highly experimental: [[measure]], [[species]].
** poshformats: [http://ocoins.info/ OpenURL COinS].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-06-23 0.00_11
* 2010-05-13 0.00_10
* 2010-05-12 0.00_09
* 2010-04-29 0.00_08
* 2010-04-28 0.00_07
* 2010-04-16 [http://microformats.org/discuss/mail/microformats-dev/2010-April/000651.html 0.00_06]
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

==== XML::Atom::Microformats ====

[http://search.cpan.org/~tobyink/XML-Atom-Microformats/ XML::Atom::Microformats] provides the same functionality for Atom. It finds microformats in Atom entry content elements.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats [http://github.com/WebOrganics/TransFormr available from github].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

parsers

2010-06-23T20:38:09Z

TobyInk: /* HTML::Microformats */ released 0.00_11

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[rel-enclosure]], [[rel-license]], [[rel-tag]], [[XFN]].
** class: [[adr]], [[figure]], [[geo]], [[hAtom]], [[hAudio]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hCard]], [[hListing]], [[hNews]], [[hProduct]], [[hRecipe]], [[hResume]], [[hReview]], [[hReview-aggregate]], [[xFolk]], [[XOXO]].
*** highly experimental: [[measure]], [[species]].
** poshformats: [http://ocoins.info/ OpenURL COinS].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-06-23 0.00_11
* 2010-05-13 0.00_10
* 2010-05-12 0.00_09
* 2010-04-29 0.00_08
* 2010-04-28 0.00_07
* 2010-04-16 [http://microformats.org/discuss/mail/microformats-dev/2010-April/000651.html 0.00_06]
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

==== XML::Atom::Microformats ====

[http://search.cpan.org/~tobyink/XML-Atom-Microformats/ XML::Atom::Microformats] provides the same functionality for Atom. It finds microformats in Atom entry content elements.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats [http://github.com/WebOrganics/TransFormr available from github].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

parsers

2010-05-12T20:39:37Z

TobyInk: /* HTML::Microformats */ update for 0.00_09

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[XFN]], [[rel-license]], [[rel-enclosure]], [[rel-tag]].
** class: [[hCard]], [[adr]], [[geo]], [[hAtom]], [[hNews]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hReview]], [[hReview-aggregate]], [[hListing]], [[hProduct]], [[hResume]], [[xFolk]], [[hAudio]], [[hRecipe]], [[XOXO]], [[figure]].
*** highly experimental: [[species]], [[measure]].
** poshformats: [http://ocoins.info/ OpenURL COinS].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-05-12 0.00_09
* 2010-04-29 0.00_08
* 2010-04-28 0.00_07
* 2010-04-16 [http://microformats.org/discuss/mail/microformats-dev/2010-April/000651.html 0.00_06]
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

==== XML::Atom::Microformats ====

[http://search.cpan.org/~tobyink/XML-Atom-Microformats/ XML::Atom::Microformats] provides the same functionality for Atom. It finds microformats in Atom entry content elements.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats [http://github.com/WebOrganics/TransFormr available from github].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

parsers

2010-04-29T22:39:03Z

TobyInk: /* HTML::Microformats */ two new releases, and XML::Atom::Microformats

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[XFN]], [[rel-license]], [[rel-enclosure]], [[rel-tag]].
** class: [[hCard]], [[adr]], [[geo]], [[hAtom]], [[hNews]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hReview]], [[hReview-aggregate]], [[hListing]], [[hProduct]], [[hResume]], [[xFolk]], [[hAudio]].
*** highly experimental: [[species]], [[measure]].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-04-29 0.00_08
* 2010-04-28 0.00_07
* 2010-04-16 [http://microformats.org/discuss/mail/microformats-dev/2010-April/000651.html 0.00_06]
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

==== XML::Atom::Microformats ====

[http://search.cpan.org/~tobyink/XML-Atom-Microformats/ XML::Atom::Microformats] provides the same functionality for Atom. It finds microformats in Atom entry content elements.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats [http://github.com/WebOrganics/TransFormr available from github].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

profile-uris

2010-04-28T09:51:38Z

TobyInk: Atom advice, page cleanups

=== Individual Microformats ===
;[[adr]]
;[[geo]]
;[[hCard]]
:http://microformats.org/profile/hcard
:http://ufs.cc/x/hcard
;[[hAtom]]
:http://microformats.org/profile/hatom
:http://ufs.cc/x/hatom
;[[hCalendar]]
:http://microformats.org/profile/hcalendar
:http://ufs.cc/x/hcalendar
;[[hResume]]
:http://microformats.org/profile/hresume
:http://ufs.cc/x/hresume
;[[hReview]]
:http://microformats.org/profile/hreview
:http://ufs.cc/x/hreview
;[[rel-license]]
:http://microformats.org/profile/rel-license
:http://ufs.cc/x/rel-license
;[[rel-nofollow]]
:http://microformats.org/profile/rel-nofollow
:http://ufs.cc/x/rel-nofollow
;[[rel-tag]]
:http://microformats.org/profile/rel-tag
:http://ufs.cc/x/rel-tag
;[[vote-links]]
:http://microformats.org/profile/vote-links
:http://ufs.cc/x/vote-links
;[[XFN]]
:http://gmpg.org/xfn/11
;[[xFolk]]
:http://microformats.org/profile/xfolk
:http://ufs.cc/x/xfolk
;[[XMDP]]
:http://gmpg.org/xmdp/1
;[[XOXO]]
:http://microformats.org/profile/xoxo
:http://ufs.cc/x/xoxo

== How to link to a profile URI ==
=== HTML 4.x / XHTML 1.x ===
<source lang=html4strict>
<head profile="http://gmpg.org/xfn/11 http://microformats.org/profile/hcard">
</source>

=== (X)HTML 5 / XHTML 2 ===
An alternative method is provided for people using markup languages which do not support <code><nowiki><head profile></nowiki></code>. Add <code>rel="profile"</code> to either a visible link (<code><nowiki><a></nowiki></code>) or hidden link (<code><nowiki><link></nowiki></code>).

Example:
<source lang=html4strict><p>This page uses
<a rel="profile" href="http://gmpg.org/xfn/11">XFN 1.1</a>!</p>
</source>

=== Atom 1.0 ===

(This is a draft idea being implemented in the XML::Atom::Microformats Perl parsing module.)

To indicate that an Atom <code><content></code> element contains a Microformat, give the entry a <code><link rel="profile"></code> link to the relevant profile URI. You can indicate that ''all'' entries within a feed contain a particular microformat by including <code><link rel="profile"></code> on the root Atom <code><feed></code> element.

Example:
<source lang=xml>
<feed>
<title>Example Feed</title>
<link rel="profile" href="http://ufs.cc/x/hcard" />
<entry>
<title>Example Entry Containing hCard</title>
<content type="text/html">...</content>
</entry>
<entry>
<title>Example Entry Containing hCard and hCalendar</title>
<content type="text/html">...</content>
<link rel="profile" href="http://ufs.cc/x/hcalendar" />
</entry>
</feed>
</source>

=== Content Management Systems ===
For [[cms]]'s there is:
* [http://www.mediawiki.org/wiki/Extension:HTML_Profiles MediaWiki extension for profile URIs]

==Implementations==
=== GRDDL ===
Tools that support [http://www.w3.org/2001/sw/grddl-wg/ GRDDL] use profiles to parse microformats.

=== Cognition===
In "strict mode", [http://buzzword.org.uk/swignition/ Swignition] (formerly called Cognition) refuses to parse any microformats where the profile URI has not been explicitly declared on the page. (It will however, still parse microformats for which there exists no profile URI!)

=== HTML::Microformats ===

[http://microformats.org/wiki/parsers#HTML::Microformats HTML::Microformats] uses profile URIs to toggle support for individual microformats.

== Issues ==
When this section gets too big, move it to [[profile-uris-issues]]
Some issues include:
<div class="discussion">
* what domain to use? Candidates include:
** microformats.org
** www.w3.org
** gmpg.org
** One proposal is: use www.w3.org, following [http://www.w3.org/1999/10/nsuri W3C namespace policy].
** Use [http://microformats.org/profile microformats.org] and [http://gmpg.org GMPG] profile URIs - [[User:Tantek|Tantek]] 10:17, 6 August 2009 (UTC)
* what about versioning? How to keep in sync with the wiki and test materials?
** As to versioning, change the profile whenever the underlying spec changes significantly (within some reasonable latency, say, a couple weeks or a month). For example: [http://www.w3.org/2006/03/hcard an hCard Profile at w3.org], and discussion: [http://microformats.org/discuss/mail/microformats-dev/2006-March/000068.html an hCard profile that seems to work with GRDDL].
* what profile URI to use for combinations, such as [[hcard]] and [[hcalendar]]?
** note [http://www.w3.org/TR/html401/struct/global.html#adef-profile HTML4.01] states "that one or more meta data profiles, [are] separated by white space"; though it's simpler for authors if they can just use one profile URI.
** e.g. use <code><head profile="http://microformats.org/profile/hcard http://microformats.org/profile/hcalendar"></code>
* More profiles are needed.
** Like which ones??
</div>

=== Validator warning ===
Due to [http://sourceforge.net/tracker/index.php?func=detail&aid=1264455&group_id=27659&atid=390963 inconsistent wording of the HTML specs], HTMLTidy (and other tools?) give "[http://sourceforge.net/mailarchive/forum.php?thread_name=oytAFzxaKxiFFwpx%40pigsonthewing.org.uk&forum_name=htmlvalidator-help Warning: <head> escaping malformed URI reference]"
when more than one profile is used, e.g.

<source lang=html4strict>
<head profile="http://microformats.org/profile/hcard http://microformats.org/profile/hcalendar">
</source>

W3C HTML validator has very poor validation of attributes and is technically unable to check this case. The HTML DTD however defines <code>profile</code> attribute as <code>%URI</code> (it's an alias for <code>CDATA</code>), same as <code><a href></code> attribute.

== Experimental URIs ==
The following includes URIs to external experimental XMDPs, and should only be used for testing purposes.

=== Experimental Combined Profile ===
The following URL covers all non-draft Microformats as of March 2008, except XMDP. You can mix and match it with other XMDP profiles for new/draft microformats.

http://purl.org/uF/2008/03/

=== Experimental Individual Microformats ===

<dl>
<dt>adr
<dd>(Use an hCard profile.)
<dd>(Or use the combined profile.)
<dt>figure
<dd>http://purl.org/uF/figure/draft
<dt>geo
<dd>http://purl.org/uF/geo/0.9/
<dd>(Or use an hCard profile.)
<dd>(Or use the combined profile.)
<dt>hAtom
<dd>http://purl.org/uF/hAtom/0.1/
<dt>hAudio
<dd>http://purl.org/NET/haudio &dagger;
<dd>http://purl.org/uF/hAudio/0.9/ &dagger;
<dt>hCalendar
<dd>http://purl.org/uF/hCalendar/1.0/ &dagger;
<dd>http://www.w3.org/2002/12/cal/hcal ¶&dagger;
<dd>http://dannyayers.com/microformats/hcalendar-profile &dagger;
<dd>(Or use the combined profile.)
<dt>hCard
<dd>http://purl.org/uF/hCard/1.0/ &dagger;
<dd>http://www.w3.org/2006/03/hcard &dagger;
<dd>(Or use the combined profile.)
<dt>hResume
<dd>http://microformats.org/wiki/hresume-profile
<dt>hReview
<dd>http://www.purl.org/stuff/rev# &dagger;
<dt>rel-license
<dd>http://purl.org/uF/rel-license/1.0/ &dagger;
<dd>(Or use the combined profile.)
<dt>rel-nofollow
<dd>http://purl.org/uF/rel-nofollow/1.0/
<dd>(Or use the combined profile.)
<dt>rel-tag
<dd>http://purl.org/uF/rel-tag/1.0/
<dd>(Or use the combined profile.)
<dt>VoteLinks
<dd>http://purl.org/uF/VoteLinks/1.0/ &dagger;
<dd>http://tommorris.org/profiles/votelinks ¶&dagger;
<dd>(Or use the combined profile.)
<dt>XFN
<dd>http://gmpg.org/xfn/11
<dd>http://gmpg.org/xfn/1 (older version)
<dd>(Or use the combined profile.)
<dt>xFolk
<dd>http://microformats.org/wiki/xfolk-profile
<dt>XOXO
<dd>(Use the combined profile.)
</dl>

&dagger; = GRDDL-enabled.<br/>
¶ = non-XMDP profile.

=== Other Interesting Profile URIs ===
* [http://purl.org/uF/pattern-data-class/1 Experimental data-* class pattern]
* [http://purl.org/stuff/hdoap/profile hDOAP (posh format)] ¶&dagger;

==See also==
* [[hcard-profile]]
* [[hcalendar-profile]]
* [[profile-uri-examples-in-wild|Profile URI examples, in the wild]]
* [[faqs-for-rdf]] for discussion of connecting microformats to URIs.

parsers

2010-04-16T22:42:52Z

TobyInk: /* HTML::Microformats */ fix link

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[XFN]], [[rel-license]], [[rel-enclosure]], [[rel-tag]].
** class: [[hCard]], [[adr]], [[geo]], [[hAtom]], [[hNews]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hReview]], [[hReview-aggregate]], [[hListing]], [[hProduct]], [[hResume]], [[xFolk]], [[hAudio]].
*** highly experimental: [[species]], [[measure]].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-04-16 [http://microformats.org/discuss/mail/microformats-dev/2010-April/000651.html 0.00_06]
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats [http://github.com/WebOrganics/TransFormr available from github].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

parsers

2010-04-16T22:40:53Z

TobyInk: /* HTML::Microformats */ 0.00_06

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[XFN]], [[rel-license]], [[rel-enclosure]], [[rel-tag]].
** class: [[hCard]], [[adr]], [[geo]], [[hAtom]], [[hNews]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hReview]], [[hReview-aggregate]], [[hListing]], [[hProduct]], [[hResume]], [[xFolk]], [[hAudio]].
*** highly experimental: [[species]], [[measure]].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-04-16 [http://microformats.org/discuss/mail/microformats-discuss/2010-April/013244.html 0.00_06]
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats [http://github.com/WebOrganics/TransFormr available from github].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

parsers

2010-04-16T22:18:00Z

TobyInk: /* HTML::Microformats */ supports haudio

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[XFN]], [[rel-license]], [[rel-enclosure]], [[rel-tag]].
** class: [[hCard]], [[adr]], [[geo]], [[hAtom]], [[hNews]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hReview]], [[hReview-aggregate]], [[hListing]], [[hProduct]], [[hResume]], [[xFolk]], [[hAudio]].
*** highly experimental: [[species]], [[measure]].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats [http://github.com/WebOrganics/TransFormr available from github].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

parsers

2010-04-16T22:03:18Z

TobyInk: /* HTML::Microformats */ 0.00_05

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[XFN]], [[rel-license]], [[rel-enclosure]], [[rel-tag]].
** class: [[hCard]], [[adr]], [[geo]], [[hAtom]], [[hNews]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hReview]], [[hReview-aggregate]], [[hListing]], [[hProduct]], [[hResume]], [[xFolk]].
*** highly experimental: [[species]], [[measure]].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-04-16 0.00_05
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats [http://github.com/WebOrganics/TransFormr available from github].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

hrecipe-issues

2010-03-25T15:44:21Z

TobyInk: /* hrecipe. Proposal for Draft 0.2 */ value and type are used strangely

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

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2009-01-22</span> raised by <span class="fn">[[User:ThomasLoertsch|ThomasLoertsch]]</span></span>
<div class="description">
* '''"num" and "unit"'''. I only recently discovered the properties "type" and "value" from 'hCard'. I'll replace "num" and "unit" from the unfinished 'measure' with them.
** The decision to replace "num", "unit", and "item" with "type" and "value" needs further explanation. Was it due to the fact that measure is unfinished? If so I think leaving "ingredient" and "nutrition" as text strings until measure is finished would be a better idea. The transition from "type"/"value" to measure will be difficult at a later point and I believe measure is more appropriate than re-using hCard. [[User:Yde|Yde]] 11:46, 23 January 2009 (UTC)
*** The proposal to replace "num", "unit", and "item" with "type" and "value" has several reasons: first, i only recently thoroughly and systematically investgated other formats and that's when i found "type" and "value". They have a semantic advantage in that they may be more suitable for cases like value:"2"/type:"eggs" or value:"1/2"/type:"spoonfull" which are rather informal ways of putting measures, at least do not lend themselves easily to formal specification. Another reason is that these terms come from a comparably very stable vocabulary, while measure has not even draft status. It would be perfectly okay for measure to change attribute names, semantics or even the whole structure of the vocabulary. Although it doesn't look like that measure will (have to) do that I'd prefer to stay on the safe side, especially since we might even gain semantic advantage. [[User:ThomasLoertsch|ThomasLoertsch]] 19:43, 23 January 2009 (UTC)
**** I'm still not sure this is the right decision. 1) I don't think the semantic meaning of hCard's "type"/"value" is exactly equivalent to measure's "num"/"unit"/"item". From the [[hcard-profile]]: "Value: This class name is used to distinguish the actual *value* of a property from any other cruft that may be in the element representing the property." So what is the actual value of an ingredient? Is it the name of the ingredient or is the quantity? 2) This is ''exactly'' what [[measure]] is for. The advantage of being able to convert measures would IMO be one of the gratest advantages of hRecipe. I don't see why value:"2"/type:"eggs" is better than num:"2"/item:"eggs"? I agree that cases like value:"1/2"/type:"spoonfull" is problematic, but that's a [[measure]] issue. 3) Many [[recipe-formats]] use quantity/unit/item.
***** Measurements are rather informal in recipes and therefor the type/value pair seems quite appropriate to me. Automatic translation is out of scope. Anyway for a good enough machine translation of a recipe the markup of the ingredients won't be the main hurdle. Standardizing the informal quantities would be a requirement for such an effort. I made some suggestions for a vocabulary of most used "units" like cups, teespoonfulls etc a few months ago but no one reacted. So I dropped it.
***** But we're moving in circles. You are making valid points too. One reason I decided this way is that it's more inline with other decisions like reusing "fn". Since not all the shortcomings of microformats can be solved within hRecipe and since there has been no interest in discussing them here I decided to go the way of least resistance and stick with the customs of compactness, reuse and rather lax interpretation of semantic constraints. IMO hRecipe is now consistent with the genereal microformats approach and neither necessitates nor hinders a general redesign of microformats (which I think would be a good thing). --[[User:ThomasLoertsch|ThomasLoertsch]] 11:21, 18 February 2009 (UTC)
**** Proposed resolution: keep "ingredient" as a text string like "yield" - which would also benefit from a measure format - until such a format is ready. [[User:Yde|Yde]] 10:23, 15 February 2009 (UTC)
***** I opened this issue again and marked the subproperty 'value' and 'type' of ingredient as ''experimental''. This should leave enough room to discuss this issue further. --[[User:ThomasLoertsch|ThomasLoertsch]] 11:21, 18 February 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-12-27</span> raised by <span class="fn">[[User:Tantek|Tantek Çelik]]</span></span>
<div class="description discussion issues">
# '''Too many properties.''' From reviewing the [[recipe-examples]], it does not appear that the schema implied by the examples justify the number of properties in hRecipe, especially for a first draft. microformats should start as small as possible (even smaller), and in this regard I believe several improvements could be made. There is one obvious example of recipe-title vs recipe-summary, but it looks like there may be more. Would appreciate feedback from folks who add hRecipe to the recipes on the web regarding which properties they ended up not using.
#* It is not necessarily helpful to constrain a vocabulary by all means. hCard and hCalender are examples for too large vocabularies (which mostly stems from the approach taken of converting an existing vocab 1:1) which are not as easily usable as one would wish. But to be useful a vocabluary should encompass 80:20 of the usecases, otherwise it may well not be worth the burden of implementation. We better try to hit that sweet spot right from the start - since otherwise, how should hRecipe get traction in the wild. All of the proposed properties are used on big recipe sites (many 'user generated content' sites among them) on the web. Please provide more arguments which properties you specifically think are superfluous. The only concrete example you give is to replace title by summary (which I think is a bad idea). [[User:ThomasLoertsch|ThomasLoertsch]]
#* Version 0.2 (and a little more so 0.21) has marked all but the most essential properties as ''experimental''. There use is not at all discouraged but implementors are warned that these properties may be removed from later version if they aren't used in real world applications. This uptake by implementors should be observed and studied before a final descision is made. A proposed timeframe would be at least a few months, maybe even a year or two, depending on how many implemetations surface in the meantime. --[[User:ThomasLoertsch|ThomasLoertsch]] 11:21, 18 February 2009 (UTC)
#* I checked the usage of the hRecipe format today and was delighted to see that Yahoo! searchmonkey lists 56.000 of them (search Yahoo for "searchmonkey:com.yahoo.page.uf.recipe"). The site I work for is responsible for about 12.000 of them but when i checked the first 70 results none of them was from our site :-) In fact they almost all came from personal sites, blogs and the like and this is really great! It was also very interesting to see that a lot of them came from WordPress Blogs which shows that the WordPress Plugin for hRecipe is very useful. But back to the issue: I checked the first 60 or so results and about 2/3 of them where really using hRecipe. 17 of them were from different sites(*) (**).

It's never bad to gather some empirical data to make an informed decision, so I took the burden to count element use. Actually this didn't take much more then an hour, so if somebody wants to check the results from 61 to ... feel free! Well, now, without futher ado, the results:
<pre>
16 fn
17 ingredient (3 value, 3 type)
3 yield
15 instructions
3 duration
4 photo
9 summary
4 author
3 published
1 nutrition (0 value, 0 type)
2 tag
</pre>
Of course this is not representative, but it gives a fairly good impression. If you add our site (or 20% of all published hRecipes ;) you can add +1 to all elements since we use everything...

Evaluation:

"fn", "ingredient" and "instructions" are no-brainers. Also "summary" is surprisingly strong and the intuition, that it's a strong part of how people communicate on recipes, seems to be right.

"author" and "published" probably didn't get so much used because on a blog they are provided anyway and most of the sites investigated were blogs. OTOH they aren't important for the functionality of a recipe and can be added by other means. So maybe they should be removed for the sake of terseness.

"photo" was definitely less used than there were photos added to recipes. And I know a lot of people who, when showed 2 recipes, one with and one without photo, almost certainly choose the one with photo. So IMHO it should stay.

"yield" was used surprisingly seldomly. Isn't it an essential addition to the ingredients list? Maybe the yield is often self-explanatory, maybe this reflects the fact, that also the value and type of ingredients wasn't marked up most of the time. 'Smallishness' would certainly suggest to omit all the three: "value", "type" and yield". People seem to feel that the "ingredient" field naturally holds information not only about the name of the ingredient but about type and value too and don't bother to mark these up explicitely. Again for big sites which generate their content from databases the cost-benefit ratio is totally different...

"duration" would be a candidate for removal as well. But still, remeber that this list only reflects usage of the elements. An information of duration was part of the recipe more often than it was marked up as such.

"tag" obviously didn't get used much and is maybe strong enough on it's own. People add tags no matter if they are part of a vocabulary, and the rel-tag pattern is certainly easy enough to grasp and straightforward to implement.
But the WordPress plugin added a tagging vocabulary on it's own (how dare they... ;-) which did get used most of the time. So tagging principally is strong. Well, I still don't have a clue on this one.

"nutrition" is definitely a candidate for removal, maybe into it's own vocabulary. OTOH, big commercially backed sites very often provide nutritional information and when provided it is a much more integral part of the information context than say the author. So maybe it should stay?
The full result-set, including URLs:
<pre>
fn ingredient v t yield instructions duration photo summary author published nutrition v t tag
http://nissasham.blog.com/
x x x x x x
http://reciperiot.blog.com/
x x x
http://www.greenworld365.com/twice-baked-buttermilk-potatoes/
x x
http://peachquilting.com/2009/04/beef-with-garlic-potatoes/ (wordpress plugin)
x x x x
http://fivepennynicole.com/blog/2008/10/29/world-series-caramel-corn/ (wordpress plugin)
x x x x x x x
http://www.theslowcook.com/2009/04/23/shrimp-stir-fry/ (wordpress plugin)
x x x
http://bitten.blogs.nytimes.com/2009/01/29/addictive-mac-and-cheese/ well ... very freestyle
x x x x
http://au.food.yahoo.com/recipes/recipe/-/5346170/baked-chicken-ravioli/
x x x x
http://humblegourmand.com/recipes/grovestand-lemon-cupcakes/
x x x x x x x
http://www.f00die.com/
x x x x
http://www.thebarkersworld.com/ (wordpress plugin)
x x x x
http://www.murraywilliams.com/cooking/souffle.html
x x x x
http://cookingwithbooze.org/beer/beer-brats/
x x x x
http://itsripe.com/recipes/11-kale-smoothie
x x x x x x x x x x
http://xavierroy.com/blog/chicken-legs-in-lemon-basil-mustard-sauce
x x x x x x x x x
http://www.f00die.com/2008/06/17/hobo-potatoes-w-arugula/
x x x x x
http://www.todayonpei.com/?p=5420
x x x
</pre>

(*) well, more of them, I skipped some WordPress Blogs since they all came from the same Plugin. But as the feature set of the Plugin continues to grow it doesn't make much sense to investigate them too thoroughly now unless you want to take into account which version of the plugin was used exactly etc etc - an undertaking I'm not really up to ;-)

(**) I felt quite bad when I saw that a lot of them used the pre-0.2 version with "title", "method" etc but I really don't know what I could do about it now (or then, too). I guess these decisions are made and the pain will diminish over time (cough).
--[[User:ThomasLoertsch|ThomasLoertsch]] 17:36, 17 June 2009 (UTC)
</div>
</div>

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-07-01</span> raised by <span class="fn">[[User:BenWard|BenWard]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Reconsidering semantic of <code>published</code> over ‘<code>created</code>’</strong>. I think the reuse of <code>published</code> from [[hAtom]] may be incorrect. Given its use in hAtom, <code>published</code> represents the date and time that the content was originally published to the page. In the case of a recipe, it seems that you would instead want to represent the date that the recipe was authored/created, which is subtly different. The publication of a recipe on a web page is something that should be done with hAtom itself (publishing an <code>hEntry</code> that contains the recipe), but the recipe itself would contain the date that ''the recipe itself'' was created. e.g. <samp>I came up with this recipe for mashed potato in <span class='created'><span class='value-title' title='2008-08'>last summer</span></span></samp>. I'm totally open to ideas about this, but my feeling is that it's unnecessary to represent the publication date since that should be represented by a complete hAtom entry. Do we think that <code>created</code> as described here falls inside the 80:20?
** I agree with your interpretation of "published" versus "created". "published" is not used very often on it's own (see above) and I'm sure "created" would be used much less so - because it often is very difficult to determine when a recipe was created, when it was modified enough to count as newly created, from where (and when) it originated etc. IMO "published" MAY be out of the 80:20, but "created" certainly IS. You raise a point though that I'm thinking heavily about right now. I'm pondering if it would be wise to move most of the properties that are currently marked as "experimental" out of the draft and refer to them only (but explicitly) as possibly useful additions to a hRecipe. I would then add hReview as well and, from the 'experimental' properties, only leave "Nutrition" within the property set of hRecipe. But I need to think about that a little more. Anyway: I think your point is valid but should be part of a broader approach. --[[User:ThomasLoertsch|ThomasLoertsch]] 15:09, 2 July 2009 (UTC)
</div>
</div>

== resolved issues ==
<div class="vevent">
* {{ResolvedIssue}} <span class="summary vcard"><span class="dtstart">2008-12-27</span> raised by <span class="fn">[[User:Tantek|Tantek Çelik]]</span></span>
<div class="description">
*# '''author is re-used from hAtom not hCard'''. minor issue. the "author" property is actually re-used from [[hAtom]] rather than hCard - hCard has no such property.
*#* Yikes! Corrected... [[User:ThomasLoertsch|ThomasLoertsch]] 17:52, 6 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}}<span class="summary vcard"><span class="dtstart">2008-01-17</span> raised by <span class="fn">[[User:Yde|Yde]]</span></span>
<div class="description">
* '''method'''. Would it make sense to [[reuse]] [[hreview|hReview's]] "description" instead of hRecipe's "method" or is this stretching the semantics too far?
** I just discovered that hCalender uses "method", and with totally different semantics. So I guess we MUST change it. I'm not very happy with "description" though - that's a very unspecific term. Maybe "instructions", or "steps", or "preparation" , or "procedure"? They are all 'available'. I like "instructions" most, but since I'm not a native speaker I'm hesitant. Maybe the semantics are too different? Maybe "preparation" is better since we already almost have it (or had it - see the discussion about "preparation-time" -> "duration" above)? [[User:ThomasLoertsch|ThomasLoertsch]] 12:24, 21 January 2009 (UTC)
** Since no further comments surfaced I'll change the property name to "instructions". I think it's a fairly unambiguous name which also can easily be reused in other formats. [[User:ThomasLoertsch|ThomasLoertsch]] 14:30, 2 Febuary 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} <span class="summary vcard"><span class="dtstart">2008-12-27</span> raised by <span class="fn">[[User:Tantek|Tantek Çelik]]</span></span>
<div class="description discussion issues">
# '''Unnecessary recipe prefixing of summary property.''' Note: this is a re-opening of an issue from [[recipe-issues]]. The usage of summary in recipes appears to be very similar to that used for events. Rephrased, insufficient (if any?) evidence has been provided that summary means anything "special" enough (distinguishing it from the generic term "summary" as used in microformats) in the context of recipes to merit prefixing and thus a new property.
#* proposed resolution: Re-use generic "summary" property rather than introducing a recipe microformat scoped "recipe-summary" property.
#* I agree principally but there are different "summary"s around: The [[hReview]]-Draft specifies a summary as "This optional field serves as a title for the review itself" while the [[hCalendar]] Draft refers to RFC 2445 which defines summary as "This property defines a short summary or subject for the calendar component". I certainly agree more with the semantics from RFC 2445 but referring to either of the two doesn't make much sense right now. Since you are editor of both hReview and hCalendar maybe you can clarify the subject? If hReview would be aligned with RFC 2445 then I would promote dropping the prefix.[[User:ThomasLoertsch|ThomasLoertsch]] 17:52, 6 January 2009 (UTC)
#** Agreed, the definitions of "summary" across hCalendar and hReview could be better converged. Please add this as an issue to both [[hcalendar-issues]] and [[hreview-issues]] and I'll follow-up there accordingly. Given that is the path forward, let's fix this immediately in hRecipe now that the issue (and resolution) has been captured. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#*** Will change "recipe-summary" to "summary" as defined in hCalender/RFC2445. [[User:ThomasLoertsch|ThomasLoertsch]] 15:00, 16 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} <span class="summary vcard"><span class="dtstart">2008-12-27</span> raised by <span class="fn">[[User:Tantek|Tantek Çelik]]</span></span>
<div class="description discussion issues">
# '''preparation-time could re-use duration instead''' - it appears that the "preparation-time" semantic basically means the "duration" of the recipe, and thus could re-use that property from [[hCalendar]] rather than introducing a new property name.
#* proposed resolution: change "preparation-time" to "duration" and note re-use from [[hCalendar]] - or at least document how preparation-time is a different enough semantic from "duration" to justify the introduction of a new term.
#* One difference is that hCalendar ''duration'' is a singular property whereas hRecipe's ''preparation-time'' is plural. Also, ''preparation-time'' will often (typically) use value+note subproperties, while ''duration'' will usually be an ISO 8601 duration. [[User:TobyInk|TobyInk]] 20:32, 29 December 2008 (UTC)
#** Plurality is a contextual aspect and does not alter the semantic of the underlying property, thus is insufficient justification for introducing a new term. We do not duplicates of each property in a singular and plural form. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#** Syntax differences (value+note vs ISO 8601) are also insufficient to justify the introduction of a new property for the same semantic. Rather, it is better to expand the syntax of the existing property, e.g. perhaps using the [[value-excerption-pattern]] and to note that explicitly. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#*** Semantically the reuse of "duration" is okay. RFC 2445 permits multiple duration values "if the property permits" so that should be fine too. If the syntactic differences can be worked out the way Tantek suggests above than it's okay with me to re-use "duration". I'm just not sure if it helps usability to overload properties in such a way but that ay be another discussion on it's own. [[User:ThomasLoertsch|ThomasLoertsch]] 15:00, 16 January 2009 (UTC)
#** The observation that preparation-time uses a nested "note" subproperty may actually reveal a problem with that approach itself, that is, perhaps instead of "preparation-time" with "value" and "note" subproperties, it may be better to refactor it as a "preparation" (an act thereof) with "duration" and "note" subproperties. [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#*** Removed the sub-property "note" from the v_0.2 draft format since I now agree that it looks a little overengineered. [[User:ThomasLoertsch|ThomasLoertsch]] 12:47, 22 January 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} '''issues too long''' <span class="summary vcard"><span class="dtstart">2009-01-22</span> raised by <span class="fn">[[User:ThomasLoertsch|ThomasLoertsch]]</span></span>
<div class="description">
As threatened 2 weeks ago I heavily re-edited this page because discussions had become a little frayed (and heated at soem points). Have a look at the [http://microformats.org/wiki/index.php?title=hrecipe-issues&oldid=37788 previous version] for the full debate and feel free to re-edit this page if you find that I axed it too much. [[User:ThomasLoertsch|ThomasLoertsch]] 14:47, 2 February 2009 (UTC)
</div>
</div>

<div class="vevent">
* {{ResolvedIssue}} '''new draft'''<span class="summary vcard"><span class="dtstart">2009-01-22</span> raised by <span class="fn">[[User:ThomasLoertsch|ThomasLoertsch]]</span></span>
<div class="description">
* The following is a proposal for draft 0.2, reflecting the issues discussed so far. "recipe-title" is replaced with "fn" from hCard (although I'm not convinced that this is a good idea), "recipe-summary" with "summary", "num" and "unit" from the unfinished 'measure' with "type" and "value" from 'hCard' (i only recently discovered them...), "method" (wihch is already used by [[hCalendar]] with "instructions", "preparation-time" with "duration". Two "note"s are deleted for brevity. "summary", "nutrition", "author", "published" and "photo" are marked as 'experimental', meaning that they may be removed from future drafts or the final specification, depending on experience and feedback from implementations :
</div>

=== '''hrecipe'''. Proposal for Draft 0.2 ===

* '''fn'''. the name of the recipe. required. text. re-used from [[hCard]]
* '''ingredient''' required. 1 or more. text with optional valid (x)HTML markup.
** '''value''' and '''type'''. optional. re-used from [[hCard]].
* '''yield'''. optional. text.
* '''instructions'''. optional. text with optional valid (x)HTML markup.
* '''duration'''. optional. 1 or more. text (see [[ISO-31-1]] duration brainstorming). re-used from [[hCalendar]].
* '''''summary'''''. optional. text. re-used from [[hCalendar]]. [ ''experimental'' ]
* '''''nutrition'''''. optional. 1 or more. [ ''experimental'' ].
** '''''value''''' and '''''type'''''. optional. re-used from [[hCard]]. [ ''experimental'' ].
* '''''author'''''. optional. 1 or more. re-used from [[hAtom]] using [[hCard]]. [ ''experimental'' ].
* '''''published'''''. optional. re-used from [[hAtom]]. [ ''experimental'' ].
* '''''photo'''''. optional. 1 or more. using any element containing a URL, such as IMG. re-used from [[hCard]]. [ ''experimental'' ].
* '''''tag'''''. optional. 1 or more. [ ''experimental'' ].
--[[User:ThomasLoertsch|ThomasLoertsch]] 11:01, 10 February 2009 (UTC)

** <strong id="issue-20100325">The above seems to use ''value'' very differently to other microformats</strong>. In other microformats it's used for [[value-class-pattern|value excerpting]] in most properties (i.e. the ''value'' class is used to indicate which text should be parsed with the rest being ignored); and in a handful of particular properties (e.g. hCard tel, email, adr, label) it's used in the ''value''+''type'' combination to indicate the main text that should be parsed while ''type'' refines the meaning of the property. In a recipe ingredient, the main idea to get across would be the ingredient itself (e.g. eggs, whisky, cardamom), so if ''value'' were to be used, you'd expect it to be more like this: <code><li class="ingredient">2 <span class="value">eggs</span>, lightly whisked</li></code>. Wrapping <code>class=value</code> around the '2' is fairly at odds with how that class is used in other microformats. [[User:TobyInk|TobyInk]] 15:44, 25 March 2010 (UTC)
*** Suggestion: remove these subproperties from the ingredient and nutrition properties. [[User:TobyInk|TobyInk]] 15:44, 25 March 2010 (UTC)
</div>

== closed issues ==

<div class="vevent">
* {{ClosedIssue}} <span class="summary vcard"><span class="dtstart">2008-12-27</span> raised by <span class="fn">[[User:Tantek|Tantek Çelik]]</span> in the context of issue '''Too many properties'''</span>
<div class="description discussion issues">
# '''Drop "recipe-title".''' In reviewing the examples, few (if any?) include *both* a title and a summary, and in practice the semantics of usage in the context of recipes appears to be virtually indistinguishable. Therefore we don't need both, and following in the pattern provided by [[hCalendar]] (which got it from [[RFC2445]]), we should keep the more generic concept of a "summary" and drop the concept of "title" from hRecipe.
#* I tend to agree. There are definitely use cases for both "recipe-title/title/fn" and "recipe-summary/summary" - e.g. "[http://www.simonwheatley.co.uk/2006/03/26/a-moroccan-ish-casserole/ A Moroccan-ish Casserole]" sounds more like a summary while "[http://blog.bumblepuppy.org.uk/2006/10/05/spaghetti-primavera/ Spaghetti primavera]" is the full name or the title of the recipe. But the problem is, they would serve the same purpose. [[User:Yde|Yde]] 10:07, 17 January 2009 (UTC)
#** Title and summary are different things and they are used differently in the real world. The examples you give are both names/titles/labels/headings, although more or less descriptive. They are short, memorable and make the thing adressable by humans. A summary can be (and mostly is) much longer and serves a different purpose: it describes essential properties of the object at hand, eg: "this is easy and fast to prepare, but still looks impressive", "easy, tasty, fast, vegan, good on cold days" or "the kids loved this last summer, but the ingredients can be hard to get" or "whenever i cook this i start to dream of ..." [[User:ThomasLoertsch|ThomasLoertsch]] 14:25, 20 January 2009 (UTC)
#*** Right, on second thought, I believe "title/name" and "summary" are different things. [[User:Yde|Yde]] 11:22, 23 January 2009 (UTC)
#* The term "title" has been so horribly overloaded across formats, vocabularies that it is nearly meaningless and for that reason should be avoided in any/all format efforts, preferring instead something more semantically specific such as "fn" (meaning full/formatted name of an item) or "summary" (when items are labeled more often with a short description/explanation rather than a name). [[User:Tantek|Tantek]] 20:54, 15 January 2009 (UTC)
#** Synonyms and homonyms are part of the real world - we have to cope with them. Also the word "title" is not horribly overloaded, you're exaggerating here. It just happened that hCard were the first to use it, and in a way that's empirically much less important then the use of "title" as the heading of a resource. Still the real problem is that Microformats have only one namespace and no resolution mechanism for conflicts like this, beside "first come first served". [[User:ThomasLoertsch|ThomasLoertsch]] 15:00, 16 January 2009 (UTC)
#** Maybe it would be better to make a clear cut with some of the sins of the past and deprecate some terms in hCard / hCalendar[[User:ThomasLoertsch|ThomasLoertsch]] 15:30, 3 February 2009 (UTC)
#* "fn" is [[existing-classes|defined]] as "the name of the object" which is pretty much what "recipe-title" means right now. So, whether we chose to keep this property, summary, or both, renaming "recipe-title" to "fn" would make sense. [[User:Yde|Yde]] 23:03, 16 January 2009 (UTC)
#** the definition of "fn" in [[existing-classes|existing classes]] is maybe a little too short. "fn" is defined in hCard which is a reformulation of RFC 2462, which says: "Type name:FN - Type purpose: To specify the formatted text corresponding to the name of the object the vCard represents. -Type special notes: This type is based on the semantics of the X.520 Common Name attribute. The property MUST be present in the vCard object. - Type example: 'FN:Mr. John Q. Public\, Esq.'" (http://www.ietf.org/rfc/rfc2426.txt, on page 8). That clearly means a name of a person or an institution. Institution equals a juristical person, so "fn" semantically boils down to 'name of a person'. I wouldn't use that for every object. [[User:ThomasLoertsch|ThomasLoertsch]] 14:03, 20 January 2009 (UTC)
#*** Thanks for the clarification. "fn" is definitely not a good idea. [[User:Yde|Yde]] 10:00, 23 January 2009 (UTC)
#*** <code>fn</code> is already reused more generically in hAudio, hReview and hListing (for items). The definition of use within microformats has already been adapted from the strict vcard interpretation in prior work. --[[User:BenWard|BenWard]] 23:04, 27 January 2009 (UTC)
#**** I see. I can't help but thinking: what a mess... What's the family name of a recipe, audio-recording or list-entry? What's the point of re-using a semantically totally void two-letter-acronym, when it doesn't even fit very well? What's the point of reusing an element when I have to lookup the meaning of it every time anyway? [[User:ThomasLoertsch|ThomasLoertsch]] 00:48, 28 January 2009 (UTC)
#***** <code>fn</code> is ''formatted''-name, not ‘family’. ‘Name as presented’, ‘display name’. I agree that <code>fn</code> takes a double glance when you're learning, but it's there and the reuse in other specs is consistent; there's a much stronger author benefit in building on common equivalent-semantic vocabulary than introducing synonyms, which I think will cause more confusion. Better to have a strong spec with common vocabulary than introduce duplication. I'll keep in mind that we should better emphasise the expansion of <code>fn</code> in all specs for benefit of new authors. I can see how ‘family name’ is a muddle too easily made in hCard. --[[User:BenWard|BenWard]] 07:01, 28 January 2009 (UTC)
#****** I was referring to the fact that a name of a natural or juridical person is semantically quite different to the name of an object. Other things like the opacity of the two-letter-code "fn" are indeed problematic too but not my main issue here. That vCard-legacy seems to be lurking around every corner. Why not make a clear cut and deprecate the problematic parts like "title" and "fn"? The approach to rather overload the semantics (and the property-constraints) just to keep element-count low only takes that far. In the end it hinders usability instead of improving it. I think [[reuse]] and [[naming-principles]] don't strike the right balance in that respect. [[User:ThomasLoertsch|ThomasLoertsch]] 11:45, 28 January 2009 (UTC)
#* why not define a property "name"?! From my understanding of the english language (I'm not a native speaker) "name" is semantically generic enough to serve as a substitute for "title". Defining it rather broadly as "designation or title or denominator or heading of an item" would make it easily reusable. Plus we would have to explicitely discourage it's use for naming real or juristical persons and point to "fn" instead. [[User:ThomasLoertsch|ThomasLoertsch]] 12:21, 21 January 2009 (UTC)
#** Hmmm. I would really like to get feedback on this... Again my argumentation:
#*** <code>title</code> would be the best solution but is already "taken". Depercating some of hCalenders sins would be the best solution but seems out of reach so far.
#*** <code>heading</code> would be a possible solution either but seems more suited for prose
#*** <code>name</code> gets the semantics quite well, especially in the case of recipes which are more a "thing" or abstract conceptualization than a work of literature/science/prose
#*** <code>fn</code> with it's subproperties is geared towards natural and juristical persons, which are quite different from things and concepts. Also semantics of the term "fn" are rather opaque, even misleading, which hinder it's usability.
#** Therefor I'd love "title", could live very well with "name", could live still well with "heading" and would sleep bad (but sleep) with "fn". [[User:ThomasLoertsch|ThomasLoertsch]] 16:30, 2 Febuary 2009 (UTC)
#** Okay, since there's no response I bow my head to "fn". But it speaks for itself that it's the only tag that has to be explained in the schema. [[User:ThomasLoertsch|ThomasLoertsch]] 11:15, 10 February 2009 (UTC)
</div>
</div>

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

==related pages==
* [[hRecipe]]
* [[hrecipe-feedback|hRecipe feedback]] - general feedback regarding hRecipe

Per the microformats [[process]], the [[recipe]] effort developed
* [[recipe-examples]]
* [[recipe-formats]]
* [[recipe-brainstorming]] (see also [[recipe-brainstorming-archive]])
* [[recipe-issues]]
towards the development of this draft.

xfolk-brainstorming

2010-03-24T13:32:43Z

TobyInk: /* xFolk Brainstorming */ deprecate in favour of hreview

= xFolk Brainstorming =

[[xfolk|xFolk]] is a bare bones microformat for describing and tagging things represented by a URL. This definition, although simple, is pretty broad. xFolk brainstorming is a set of fairly free-flowing ideas about the future directions of xFolk. Are there functional issues you feel xFolk should address? Other issues or ideas? Do you have implementation ideas you would like to discuss? Put them here.

__TOC__

== Authors ==
[http://thecommunityengine.com/home Bud Gibson]

Add your name to the end of the list if you contribute an idea.

== Functional Extensions ==

* We will be adding the ability to tag any visible element that has an href attribute. This includes <img> and <object> elements. It is likely that there will be more specialized, domain-specific microformats for some of these items in the future.

== Attribute Value Naming ==

* Should we change the name of taggedlink, used to represent the item to be tagged to a more neutral name such as tagged or taggedresource?

The editor's current thinking is that taggedlink represents well the fact that people are identifying things represented by a URL. However, as some discussants have pointed out, the name may be too narrow. The editor is waiting to collect further data and use cases.

Here is one use case recently presented by Eran on the discussion list:

<blockquote>
For simplicity let's assume I'm using xFolk for my photo tagging service. Following the microformat philosophy, I would like to present the information in a way that's meaningful both to people and machines. For a machine, a URL is enough to identify a a resource so something like the following is enough:

<pre><span class="xfolkentry">
<a class="taggedlink" href="http://example.com/image.png">my image</a>
<a rel="tag" href="http://example.com/tag/foo">foo</a>
</span></pre>
But to a human browing this page this makes little sense. The following alternative representation might work better:

<pre><span class="xfolkentry">
<img class="taggedresource" src="http://example.com/image.png" alt="my
image">
<a rel="tag" href="http://example.com/tag/foo">foo</a>
</span></pre>

Using class="taggedlink" on an IMG element doesn't seem right. Of course, we can combine the two:

<pre><span class="xfolkentry">
<a class="taggedlink" href="http://example.com/image.png">
<img src="http://example.com/image.png" alt="my image">
</a>
<a rel="tag" href="http://example.com/tag/foo">foo</a>
</span></pre>

Which works very well for images but might not work so well for other media types (video, text snippets, etc.)
<p><cite>Eran</cite></p>
</blockquote>

----

<pre>
<span class="xfolkentry">
<span class="taggedresource">This is my note</span>
<a rel="tag" href="http://example.com/tag/foo">foo</a>
</span>
</pre>

Here's an option. I gave it the class "taggedlink" and the class "inline". Style inline not to show as a link and not to change the cursor if you want.

<pre>
<span class="package">
<span class="xfolkentry">
<span><a href="URLofSomeSort" class="taggedlink inline">This is my note</a></span>
<a rel="tag" href="http://example.com/tag/foo">foo</a>
</span>
</pre>

more complete usecase:
<pre>
<ul class="aPackage">
<ul>
<li class="xfolkentry">
<a class="taggedresource" href="someurl">url's title</a>
<a rel="tag" href="http://example.com/tag/foo">foo</a>
<span class="comment">this is a comment about my link</span>
</li>

<li class="xfolkentry">
<span class="taggedresource">This is my note</span>
<a rel="tag" href="http://example.com/tag/footoo">footoo</a>
<span class="comment">this is a comment about my note</span>
</li

<li class="xfolkentry">
<img class="taggedresource" src="someurl.jpeg">
<a rel="tag" href="http://example.com/tag/foobar">foobar</a>
</li>
</ul>
</pre>

== Deprecate xFolk ==

We should deprecate [[xFolk]] in favour of [[hReview]]. Having two such similar microformats seems pointless. xFolk emerged more or less as a fully formed idea from a single contributor over a two day wiki-editing spree; hReview has more evidence of having followed a sensible, iterative design process with multiple contributors. Any xFolk entry can be re-expressed in hReview pretty trivially:

<pre>
<div class="xfolkentry">
<h2><a class="taggedlink" href="http://example.com/">Example</a></h2>
<p class="description">This is an example page for use in documentation.</p>
tagged: <a rel="tag" href="http://en.wiktionary.org/wiki/example">example</a>
</div>
</pre>

becomes, in hReview:

<pre>
<div class="hreview">
<h2 class="item"><a class="fn url" href="http://example.com/">Example</a></h2>
<p class="description">This is an example page for use in documentation.</p>
tagged: <a rel="tag" href="http://en.wiktionary.org/wiki/example">example</a>
</div>
</pre>

== Implementation Ideas ==

==See also==
*[[xfolk-delirious]]

==Related pages==
{{template:xfolk-related-pages}}

hatom-issues

2010-03-21T23:00:29Z

TobyInk: /* No defined parsing rule for updated timestamps in inselements */ swignition and html::microformats supports some of this

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

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

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

== closed issues ==
See: [[hatom-issues-closed]]

== resolved issues ==
See: [[hatom-issues-resolved]]

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

===2010===
==== No defined parsing rule for <code>updated</code> timestamps in <code>ins</code>elements ====
* {{OpenIssue}} 2010-01-20 raised by [[User:BenWard|BenWard]]
*# hAtom includes the <code>updated</code> property for the last modification/revision date of an entry. HTML already has an <code>ins</code> element for marking up inserted changes to text, and that element has a <code>datetime</code> attribute, to document the date and time of the change. Currently, hAtom and microformats have no model for parsing the data from that <code>datetime</code> attribute, but the document semantics suggest it would be an appropriate source for the <code>updated</code> property. Example: <http://blog.benward.me/post/250674456>
*#* Proposed resolution. Document a parsing rule for the <code>ins</code> element, stating that for an <code>ins</code> (or <code>del</code>) element with class of <code>updated</code>, the value of the <code>datetime</code> attribute should be used as the value.
*#** +1 This sounds like a good idea and something worthy of being incorporated into [[hcard-parsing#more_semantic_exceptions]] (which is where the core of generic microformat parsing is currently documented) for special handling for all datetime properties. [[User:Tantek|Tantek]] 17:43, 21 January 2010 (UTC)
*#* This has been supported by Swignition for well over a year, and is supported by HTML::Microformats. [[User:TobyInk|TobyInk]] 23:00, 21 March 2010 (UTC)
*#* Proposed extended resolution: As well as the above explicit parsing rule, an implication parsing rule stating that where <code>update</code> is not explicitly marked up, the parser may aggregate all <code>ins</code> and <code>del</code> elements in the <code>hentry</code>, and use the most recent <code>datetime</code> attribute content as the <code>updated</code> value.
*#** +1 Brilliant. Indeed right now 'updated', if missing, is implied from the 'published' property. Suggested change to that rule (incorporating your proposal) : if 'updated' is missing, use the latest in time value of: the 'published' property value, and the 'datetime' attributes of all ins and del elements inside the hentry. [[User:Tantek|Tantek]] 17:43, 21 January 2010 (UTC)

<div class="hentry">
{{OpenIssue}}
<span class="entry-summary author vcard">
<span class="published">2010-03-20</span>
raised by <span class="fn">[[User:Singpolyma|Singpolyma]]</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Should we talk about parsing of <time> element?</strong>. I use this element to mark up published on my blog. It is not supported by any implementation that I know of. Should implementors be encouraged to add this? Should the spec talk about it as an alternative to datetime-design-pattern? That page currently says to check the hcal issues, but there is nothing there about it.
** Swignition has supported this for well over a year. It's also been supported in HTML::Microformats since version 0.00_00. [[User:TobyInk|TobyInk]] 23:00, 21 March 2010 (UTC)
</div>
</div>

===2009===
==== too many required hentry properties ====
* {{OpenIssue}} 2009-05-26 raised by [[User:Tantek|Tantek]]
*# hAtom 0.1 requires numerous properties for an hentry (often based directly on required elements from the Atom standard). Given the broad variety of situations that hAtom is used in content, many (or even most) of these properties are not already specified in such content, and thus it is poor methodology to require them because there is a good chance (experience has shown) either (a) the content author will ignore the requirement, or (b) will make something up to satisfy the requirement. A few similar/overlapping/sub-issues are noted below (e.g. [[#Author|author is required]], and not always available).
*#* Proposed resolution. Make nearly all hentry properties "optional" in hAtom 0.2. Consider keeping at most only one required property, perhaps "updated" - that is, if there is no date of update/publication in the content you are trying to mark up, then perhaps it doesn't make sense to mark up that content with hAtom, since hAtom is for episodic, time-based/stamped content.
*#** consider pattern abstraction: all microformats should minimize "required" properties for the same reason, and perhaps ''only'' require at most a single property which is indicative of what that microformat is for, that is, if the author does not publish that one required property, then perhaps they should not be using the microformat that requires that one property.
*#* I have the same problem. I'm collecting various feeds to analyse them. The sources are often RSS 0.9, but I want to put the results into an Atom feed. --[[User:Simon Brodtmann|Simon Brodtmann]] 00:51, 1 July 2009 (UTC)
*#** entry:author should be optional and could be either a hCard or a string
*#** entry lacks a [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.category category] and it shuld either use rel-tag or just be a string
* 2009-07-18 [[User:DavidJanes]] I would like to break this into a separate issue for each currently required element, as we're likely to have to define defaulting rules
* 2009-07-21 [[User:TobyInk|TobyInk]]: Why not have three levels of property: ''required'', ''recommended'' and ''optional''. There would be as few as possible ''required'' properties. Any properties which are needed to create a conformant application/atom+xml feed would be ''recommended''. Everything else would be ''optional''.'
** 2009-07-02 [[User:DavidJanes]] why not then use the RFC MUST, SHOULD and MAY terminology? I think this is a good idea though.
** 2009-09-03 [[User:Chris Cressman|Chris Cressman]] +1 to the idea of property "levels" and reusing RFC terminology.

==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** +1 [[User:WebOrganics|Martin McEvoy]] but not recommended.
*** ... your vote here ...
** if this element is not in the [[hatom#In_General|physical model]], the logical model value should be
*** the empty string
**** +1 [[User:DavidJanes]]
**** -1 [[User:WebOrganics|Martin McEvoy]]
*** the value should not be blank.
**** +1 [[User:WebOrganics|Martin McEvoy]] see: [http://www.atomenabled.org/developers/syndication/#requiredEntryElements Required Entry Elements] from Atom Enabled.
**** [[User:DavidJanes]] what should it be then, if physically representing it is optional? Since Atom makes this a SHOULD and not a MUST (I'm not shouting, just following RFC convention), and we're assuming there's a good reason for the entry-title not to be present in the first place, why not an empty string?
***** [[User:WebOrganics|Martin McEvoy]] entry:title is a required attribute of atom at both feed and entry level, in both instances it says "Contains a human readable title" (a requirement) an empty string is not anything human readable (personal oppinion), maybe hAtom 0.2 should only recommend that the value of entry-title "should" not be an empty string.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== updated optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]] ... the demand for optionality of the issue is high (cf the microsoft web clips) and if it remains required we're just going to reinvent hAtom without this element
*** +1 [[User:Chris Cressman|Chris Cressman]] Agree there is demand for optionality. This requirement has previously deterred me from using hAtom.
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
**** +1 [[User:Chris Cressman|Chris Cressman]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:Chris Cressman|Chris Cressman]]

==== author optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]] for the same reason 'updated' should be optional: we'll just reinvent hAtom slightly differently otherwise
*** +1 [[User:Chris Cressman|Chris Cressman]] Same reason as 'updated' above.
*** ... your vote here ...
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** "anonymous" (somewhat like [[hreview]]), except not explicit
**** +0.5 [[User:DavidJanes]]
**** 0 [[User:Chris Cressman|Chris Cressman]] Using a blog post as an example, I can determine the author from surrounding context. 'Anonymous' doesn't seem like an acceptable solution. However, I don't have the technical expertise to create a better solution and would be willing to accept 'anonymous'.
*** make this implementation defined
*** something constructed from the page's URL & other information
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:Chris Cressman|Chris Cressman]]

=== 2008 ===
==== add url property to hentry ====
* {{OpenIssue}} 2008-09-10 raised by [[User:Tantek|Tantek]]
*# hAtom 0.1 uses [[rel-bookmark]] for permalinks. Permalinks may not always be hyperlinks or hyperlinkable. Thus I propose we re-use the <code>url</code> property (from [[hCard]], [[hCalendar]], [[hReview]], etc.) as a sub-property of the <code>hentry</code> property/container/root.
*#* Proposed resolution. Add "url" sub-property to "hentry" in hAtom 0.2.
*# {{ToDo}} can anyone provide examples where this would be used? [[User:DavidJanes]]

==== misuse of address element ====
* {{OpenIssue}} 2008-06-07 raised by [[User:Tantek|Tantek]]
*# hAtom 0.1 says "an Entry Author element SHOULD be encoded in an <code><address></code> element" and "find the Nearest In Parent <code><address></code> element(s) with class name author and that is/are a valid hCard" - this is a misuse of the address element. The address element means the ''contact'' for the page or major portion thereof (see [[hcard-faq#Should_I_use_ADDRESS_for_hCards|hCard FAQ: Should I use ADDRESS for hCards]]), which ''may'' also be the ''author'' but is not necessarily. See [[hcards-and-pages]] for more details on this semantic distinction.
*#* Proposed resolution: Eliminate all requirements and recommended use of the <code><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*#** +1 [[User:Chris Cressman|Chris Cressman]] Prefer microformat solutions that don't dictate specific elements.
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:Chris Cressman|Chris Cressman]]

=== 2007 ===
==== marking up comments ====
* {{OpenIssue}} 2007-11-25 raised by [http://www.wirewd.com/ Ken Wronkiewicz].
*# There's no currently defined way to exactly handle threaded discussions. I think this is quite useful to have.
*#* The prior art is RFC [http://tools.ietf.org/html/rfc4685 4864]. The microformat solution should map fairly cleanly to this.
* include in hAtom 0.2
** -1 [[User:DavidJanes]] I think hAtom Comments should be a separate spec
*** +1 to David's -1. [[User:TobyInk|TobyInk]] They're in a separate RFC, so should be separate to hAtom too. That said, it would be nice if hAtom had a clear, documented mechanism for creating extensions.
** +1 [[User:Singpolyma|Singpolyma]] Comments are the important "next step" for hAtom. The proposal I've seen that I most liked was embedding an hfeed in an hentry.
*** [[User:DavidJanes]] would you look to explicitly write out that proposal here (or in a new section); this is my preferred solution too, but there's another proposal on the table for doing this too

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''[[rel-tag#Tag_Spaces|rel-tag tagspaces]] should map to atom:category schemes''
*#* hAtom already defines how to map term and label. It seems that the tagspace can easily map to scheme
*# {{ToDo}} can we get a real-world example mapping of this? [[User:DavidJanes]]

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element
** +1 [[User:DavidJanes]] - this is just making explicit a particular composition. is it not? Also: if there's a geo in a hfeed (outside of hentry), should it be considered to apply to all entries?
** +1 [[User:Chris Cressman|Chris Cressman]]
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:Chris Cressman|Chris Cressman]]

==== Relationship of rel-bookmark to url+uid ====
The concept of permalink is available in hCard and hCalendar as the classes url and uid. This combination matches the permalink semantics by indicating that the url should be derefenced to find a more dynamic or up-to-date version of the content, and that that url is a stable unique id that can be used to identify the content.

hAtom 0.1 uses rel-bookmark for the permalink concept. The current state of [[uid-brainstorming]] indicates that the [[hCard]] and [[hCalendar]] permalink concept is likely to be used in subsequent microformats. It may be important to reconcile hAtom with that trajectory. Possible reconcilliations include:

1) To leave things as they are. The two permalink concepts are to be kept separate.

2) Treat the two concepts as equivalent. Allow both in hAtom, and consider allowing both in other formats. eg <a rel="bookmark" href="http://example.com/"> would fill out uid and url values if they are not supplied explicitly.

3) Choose one over the other for hAtom and perhaps for future microformats also. "url uid" allows for some greater freedom (uid can be pointed at a non-url uid), but it is unclear at this stage whether that freedom is warranted or advisable to permit.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)
** -1 [[User:Singpolyma|Singpolyma]]

==== Datetime format (atom:<i>updated</i> and atom:<i>published</i>) ====
* 2006-05-23 raised by [[User:RobertBachmann|Robert Bachmann]]
** Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.
*** ACCEPTED FAQ - hAtom references datetime-design-pattern, which discusses which date format to use
** 2009-07-20 [[User:DavidJanes]] {{ToDo}} is this moot? can we move this to resolved?

==== Feed <i>id</i> (atom:<i>id</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# atom:<i>id</i> is required for atom:feed. Thus it should be available in hAtom to.

It is suggested the Feed permalink should be used as the feed ID, however a piece by Mark Pilgrim (http://diveintomark.org/archives/2004/05/28/howto-atom-id) makes arguments against using permalinks and in favour of Tag URIs.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed <i>permalink</i> (atom:<i>permalink</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>
** I'm proposing the following rules:
**# a Feed Permalink element is identified by [[rel-bookmark]] at the feed level (inside a Feed element but not inside an Entry element)
**# a Feed <del>SHOULD</del><ins>MAY</ins> have a Feed Permalink
**# a Feed Permalink element represents the concept of an Atom link in a feed.
**# if the Feed Permalink is missing, use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI
** 2006-04-03 [[User:ChrisCasciano|ChrisCasciano]] - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.
** 2006-04-03 [[User:RobertBachmann|Robert Bachmann]]: I've replaced "SHOULD" with "MAY".
** 2006-04-24 [[User:RobertBachmann|Robert Bachmann]]: Maybe we could simplify my proposal to:
*** "''Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI''"
*** IMO this would be good enough for at least 80% of the cases.
** 2006-04-12 [[User:DavidJanes]]: {{ToDo}} can we find an example of this in the wild and if so we should add it to the -examples page.
** [[User:Singpolyma|singpolyma]] 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't [[rel-home]] make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed <i>updated</i> (atom:<i>updated</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>updated</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# The Feed Updated element is identified by the class name <code>updated</code> at the feed level (inside a Feed element but not inside an Entry element)
**# If no element with the class name <code>updated</code> is present, use the youngest <code>updated</code> from the feed's entries.
** 2006-04-12 [[User:DavidJanes]] I like this. And the definition of "feed level"
** 2007-06-20 [[User:MikeKaply]] The "youngest" thing is a really bad idea. If a page has 100 hAtom entries, a parser would have to go through all 100 looking for a low date. That's crazy.
*** 2008-03-20 [[User:TobyInk]] Not crazy at all. I've just implemented an hAtom to Atom converter and I do precisely this. Most (useful) hAtom parsers will "go through all 100 entries" anyway, won't they? So why not look for the youngest updated date as part of that loop. The only slight annoyance is that in RFC 4287, the <atom:updated> element must occur before the first <atom:entry> element -- this is easily solved by inserting a placeholder <atom:updated> element, looping through the entries and then going back and filling in the date. This is really, really, '''not''' a difficult thing to implement.

* include in hAtom 0.2
** +0.5 [[User:DavidJanes]]

==== Feed <i>title</i> (atom:<i>title</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>title</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# a Feed Title element is identified by the class name <code><del>entry</del><ins>feed</ins>-title</code>
**# a Feed SHOULD have an Feed Title
**# a Feed Title element represents the concept of an Atom feed title
**# if the Feed Title is missing, use
**#* <del>the first <code><h#></code> element in the Feed, or</del>
**#* the <code><title></code> of the page, or
**#* assume it is the empty string
** 2006-04-01 [[User:ChrisCasciano|ChrisCasciano]] - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using <code><title></code> before h# would be prefered if not the most common desire of the page author.
** 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><h#></code> to encode the date for a group of postings
** 2006-04-12 [[User:DavidJanes]]: why <code>entry-title</code> for the feed title. Why not <code>fn</code> or <code>feed-title</code>?
** 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.
** 2007-02-26 [[User:MikeKaply|Mike Kaply]]: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.

==== Feed <i>author</i> and Entry author (atom:<i>author</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules for Feed author:
**# a Feed Author element is represented by class name <code>author</code> at the feed level (inside a Feed element but not inside an Entry element)
**# a Feed Author element represents the concept of a Atom author
**# a Feed Author element MUST be encoded in a [[hcard|hCard]]
**# a Feed Author element SHOULD be encoded in a <code><address></code> element
**# a Feed MAY have more than one Feed Author elements
**# if the Feed Author is missing
**#* find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
**#* otherwise <del>the Feed is invalid hAtom</del> <ins>there is no Feed Author</ins>
** I'm proposing the following rules for entry author:
**# an Entry Author element is represented by class name <code>author</code>
**# an Entry Author element represents the concept of an Atom author
**# an Entry Author element MUST be encoded in an [[hcard|hCard]]
**# an Entry Author element SHOULD be encoded in an <code><address></code> element
**#<del> If a Feed has no Feed author each Entry MUST have at least one Entry Author element</del>
**# <ins>If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
**#* find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
**#* otherwise the Entry is invalid hAtom</ins>
**# an Entry MAY have more than one Entry Author elements
** [[User:Singpolyma|singpolyma]] 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author. Also, one or more entries may be missing an author IF feed-level has an author.
** 2006-04-17 [[User:RobertBachmann|Robert Bachmann]]: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

==== Entry <i>id</i> (atom:<i>id</i>) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>id</i> is required for atom:entry. Thus it should be available in hAtom to. The Entry permalink should be used as the entry id.
** --[[User:Federico|Federico]] 19:52, 25 Apr 2006 (PDT): I would add "Only if the id attribute is not defined for the element that contains the entry". The id attribute can be a tag uri. If you use always use the Entry permalink as the entry id and the Atom feed uses tag uris, you would end with two different ids for the same entry.
** 2006-12-31 response by [[User:ComputerKid|Emanla Eraton]] No, it shouldn't be a permalink. It should be a "tag:" id for entries.
** 2007-06-06 [[RyanKing]] - the syntax of tag URIs and html id attributes are incompatible. HTML disallows forward-slash (/) in ids [http://www.w3.org/TR/html401/types.html#type-name], while tag URIs require them [http://www.faqs.org/rfcs/rfc4151.html].

==== Author ====
===== author as an hcard is too much to require =====
The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]

* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a <div class="author"> element.
** [[Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"
** [[User:Fil|Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.

* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"
** [[Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec
***[[User:Phae|Frances]] - Just thought I'd mention a scenario I have where the author of an entry does make a pretty useless vCard - the author in each case is an entire team ("creative team", "technical department") etc., rather than a specific, identifiable, person. Some use may be regained when URL to specific team/information is included, in this circumstance.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki><span class="author"><span class="vcard"><span class="fn">My Name</span></span></span></nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki><span class="author vcard"><span class="fn">My Name</span></span></nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry <i>source</i> (atom:<i>source</i>) ====
* raised by [[User:Kevin Marks|Kevin Marks]]
** When defining hAtom 0.1, atom:source was omitted. We should consider adding this back in as a useful element for providing citations of composite feeds.
*** 2009-07-20 [[User:DavidJanes]] {{ToDo}} we need an example of how this would look in the real world

== Other Questions and Issues ==
General comments, modeling issues, algorithm issues, should have issues, etc. go here.

=== Entry Updated Required? -- Blogger Issue ===
moved to [[hatom-brainstorming]]

=== 'MAY have multiple Feed elements' -- details and viability of multiple feeds ===
moved to [[hatom-brainstorming]]

== pre 0.1 issues ==
'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''

See: [[hatom-issues-pre-0.1]]

== Template ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

parsers

2010-03-21T10:06:35Z

TobyInk: /* Swignition */ refer to HTML::Microformats

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[XFN]], [[rel-license]], [[rel-enclosure]], [[rel-tag]].
** class: [[hCard]], [[adr]], [[geo]], [[hAtom]], [[hNews]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hReview]], [[hResume]], [[xFolk]].
*** highly experimental: [[species]], [[measure]].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster
** Active development has moved to HTML::Microformats (see above).

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats [http://github.com/WebOrganics/TransFormr available from github].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

parsers

2010-03-21T10:04:45Z

TobyInk: /* PHP */ add ARC2

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[XFN]], [[rel-license]], [[rel-enclosure]], [[rel-tag]].
** class: [[hCard]], [[adr]], [[geo]], [[hAtom]], [[hNews]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hReview]], [[hResume]], [[xFolk]].
*** highly experimental: [[species]], [[measure]].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats [http://github.com/WebOrganics/TransFormr available from github].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

=== ARC2 ===
[http://arc.semsol.org/ ARC2] is a semantic web toolkit which includes support for hCard, adr, geo, XFN, hCalendar, hAtom, hResume, hReview, xFolk, rel-license and rel-tag. It's tri-licensed under the GPL 2 and 3, and the W3C Software licence.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

parsers

2010-03-21T09:54:01Z

TobyInk: /* HTML::Microformats */ expand list of supported formats, add links to release notes for other versions

<entry-title>Microformats Parsers</entry-title>
;shortlinks
:http://ufs.cc/w/parsers (preferred)
:http://tr.im/ufprs
This page lists libraries that consume, transform or convert microformats. This is only a partial list. If you know of other such tools for microformats, please add them and list what specific microformats they support.

Alphabetical listing by programming language:

== Java ==
* [http://code.google.com/p/any23/ Any23 (Anything to Triples)] parses microformats into RDF triples
* [http://zwitserloot.com/org.microformats.hCard/ org.microformats.hCard] by Reinier Zwitserloot

== Javascript ==
=== Sumo ===
* [http://www.danwebb.net/2007/2/9/sumo-a-generic-microformats-parser-for-javascript Sumo! A Generic Microformats Parser For JavaScript]

== Perl ==
=== Data::Microformat ===
* [http://search.cpan.org/~ussjoin/Data-Microformat-0.01/lib/Data/Microformat/hCard.pm Data::Microformat] is a CPAN module to parse and create hCard, adr, and geo.
** By Brendan O'Connor / Six Apart

=== HTML::Microformats ===
Perhaps we can capture and update this info on a page like [[perl-html-microformats-parser]].
* [http://search.cpan.org/~tobyink/HTML-Microformats/ HTML::Microformats] is a CPAN module that has support for:
** rel: [[XFN]], [[rel-license]], [[rel-enclosure]], [[rel-tag]].
** class: [[hCard]], [[adr]], [[geo]], [[hAtom]], [[hNews]], [[User:TobyInk/hcalendar-1.1|hCalendar]], [[hReview]], [[hResume]], [[xFolk]].
*** highly experimental: [[species]], [[measure]].
** By [[User:TobyInk|Toby Inkster]].

Versions and releases notes:
* 2010-03-20 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000647.html 0.00_04]
* 2010-03-09 [http://microformats.org/discuss/mail/microformats-dev/2010-March/000642.html 0.00_03]
* 2010-02-28 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000641.html 0.00_02]
* 2010-02-24 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000640.html 0.00_01]
* 2010-02-20 [http://microformats.org/discuss/mail/microformats-dev/2010-February/000639.html 0.00_00]
* see also the "Changes" file included in the CPAN distribution.

===Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a parser for both “upper case Semantic Web” (RDF, RDFa) and “lower case semantic web” (microformats) technologies. It includes modules for exporting parsed data in a variety of formats, including RDF, vCard, iCalendar, Atom and KML.
** By Toby Inkster

=== Text::Microformat ===
* Text::Microformat is a microformats parser hosted on [http://code.google.com/p/ufperl/ Google Code] that supports:
** [[hCard]], [[hCalendar]], [[rel-tag]]

== PHP ==
=== XMFP ===
<span id="xmfp">[http://code.google.com/p/xmfp/ XMFP]</span> (eXtensible MicroFormats Parser for PHP 5) by [http://www.metonymie.com Emiliano Martínez Luque] is a set of PHP 5 classes providing a simple API for extracting Microformated Content either from a URI or a String representing HTML/XML. It can return the results as a PHP associative array, a JSON definition or an XML representation of the data. It supports most of the currently accepted microformats and can be easily extended to add new ones, it also has full support of the include pattern and provides basic validation of microformated data.

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

===PHP Microformats parser===
[http://www.phpclasses.org/browse/package/3597.html Microformats parser] is a PHP package for extracting the microformats data embedded into HTML. The gathered data is stored as an xArray of objects - one for each microformat type container found. [http://malatestapunk-stuff.blogspot.com/2007/01/php-microformats-parser.html Announcement]. The parser supports most of the hCard (missing SOUND), hCalendar, hReview (missing item info; spec really needs some clarification) and rel elements, according to their respective specification on microformats Wiki.

===Transformr===
A Simple set of XSLT and PHP tools for Transforming Microformats [http://github.com/WebOrganics/TransFormr available from github].

=== hCard Validator ===
[http://code.google.com/p/hcardvalidator/ Source code] of the [http://hcard.geekhood.net/ hCard Validator] contains XSLT and PHP code for hCard and include microformats.

== Python ==
===AUMP===
* [http://aump.googlecode.com AUMP] is a parser written by David Janes. It supports hCard, hCalendar, hAtom, hReview and hListing.
** Uses Python's [http://docs.python.org/library/xml.dom.minidom.html xml.dom.minidom] after cleaning input through [http://www.w3.org/People/Raggett/tidy/ HTML Tidy].

===Microtron===
* [[Microtron]] is intended to be a general-purpose microformat parser/transformer.

It can operate on the definition file included in [[Optimus]], making it a close replacement for certain tasks, and can easily be extended with new formats without modifying the source. The primary advantages are speed (> 100x faster that [[Optimus]] for some operations), simplicity (single file) and small code size (currently < 150 lines).

== Ruby ==
===Prism ===
* [[Prism]]
** by [[implementors#Mark_Wunsch|Mark Wunsch]]
** Library and command line tool for parsing POSH/Microformats
** Uses the [http://nokogiri.org/ Nokogiri] HTML, XML, SAX, and Reader parser

=== mofo ruby microformats parser===
* [http://mofo.rubyforge.org/ mofo], [http://groups.google.com/group/mofo-rb mofo Google Group], [http://github.com/defunkt/mofo/tree/master GitHub repository]
** by [[implementors#Chris Wanstrath|Chris Wanstrath]]
** Uses the [http://wiki.github.com/why/hpricot Hpricot] HTML/XML parser

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

=== uformats ===
* [http://rubyforge.org/projects/uformats uformats]

=== scrAPI ===
* [http://rubyforge.org/projects/scrapi scrAPI]

== XSLT ==
===Optimus===
* [[Optimus]] is open source XSLT that parses microformats, converts them into JSON or XML, and validates them too.

===X2V===
* [[X2V]] is [http://hg.microformats.org/ open source XSLT for extracting microformats].
** by Brian Suda

== editing this page ==
For now, this page ''copies'' (rather than ''moves'') information from the existing [[implementations | Implementations]] page.

== see also ==
* [[implementations]]
* [[implementors]]
* [[user-interface]]
* [[open-source]]

implementations

2010-03-21T09:38:52Z

TobyInk: /* Swignition */ no longer actively developed

<entry-title>Microformats Implementations</entry-title>
{{TOC-right}}
This page lists the applications, plugins, sample code, services, tools that produce or consume microformats.

== help improve this page ==
This is only a partial list. If you know other services or tools for or supporting microformats, please add them to this page, link to their [[implementors]], and list what specific microformats they support.

When you find an implementation:
# Make sure that it is an implementation, rather an publishing example (e.g. [[hcard-examples-in-wild|hCard examples in the wild]], [[hcalendar-examples-in-wild|hCalendar examples]], et.c).
# Note the name of the ''tool or service'' and the name of the ''developer(s)'' who built it.
# Add a third level heading with the name of the tool/service to the Applications / Plugins / Services / Tools section below, sorted alphabetically by name of tool/service. e.g. <p><kbd><nowiki>=== Name of Tool ===</nowiki></kbd></p>
# Add a top level list item just below the heading with an external link to the tool/service, along with a link to evidence of their support for microformats, and mention (and locally link) each microformat that is supported. E.g. <p><kbd>* Link to tool/service, link to their blog post announcing support for e.g. <nowiki>[[hCard]] and [[hReview]]</nowiki></kbd></p>
# Add a nested list item and local to wiki hyperlink the Name of Developer to a fragment identifier in the [[implementors]] page, e.g. Apple Computer would be linked like this: <p><kbd><nowiki>** by [[implementors#Apple_Computer|Apple Computer]]</nowiki></kbd></p>
# Check to see if there is an entry for the developer in the [[implementors|list of implementors]], if not add them there. Add a link to the developer's home page followed by "has implemented microformats in:".
# In the entry for the developer, add a list item and local to wiki hyperlink the Name of Tool to a fragment identifier in this page, e.g. X2V would be linked like this: <p><kbd><nowiki>* [[implementations#X2V|X2V]]</nowiki></kbd></p>
# Save the page and make sure that each fragment ID local hyperlink when clicked scrolls you to the right spot (for the developer, and for the tool). Make any fix-up edits as necessary. That's it!

=== Implementation Details ===
If there are implementation details worth noting, add them them as nested list items under the item for the implementation itself. If the details subsection grows too big for a specific implementation, feel free to move the details to their own page and leave a link in place on the implementations page.

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

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

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

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

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

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

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

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

Alphabetically:

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

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

=== Backnetwork ===
* [http://backnetwork.com/ Backnetwork] is a community networking tool for events that supports [[hCard]], [[hCalendar]], and [[XFN]].
** by [[implementors#Glenn_Jones|Glenn Jones]] of [[implementors#Madgex|Madgex]].

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

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

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

=== Bugzilla ===

* [http://www.bugzilla.org/ Bugzilla] [http://www.bugzilla.org/status/2007-08-23.html 3.1.1] includes some microformats on show_bug.cgi and a few other places.

=== cmSiteNavigation ===
* [http://www.christophm.de/software/firefox/cmSiteNavigation/ cmSiteNavigation] extension for Firefox make use of links marked with a [[existing-rel-values|"rel" value]], and parses additional link types also.
** This seems to use rel values defined in the HTML 4 spec, not microformats. This is more of a [[posh|POSH]] implementation than a [[microformats]] implementation.

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

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

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

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

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

=== Digg ===
* [http://digg.com/ Digg] supports [[hcard|hCards]] for profiles and rel-me for identity consolidation (though they currently mix rel-nofollow with rel-me, negating these links).

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

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

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

=== Facebook ===
* [http://facebook.com/ Facebook] supports [[hcard|hCard]] for some public profiles '''(example needed)'''.
* There is also an [http://www.facebook.com/apps/application.php?id=2400943827&ref=s hCard application] (a plug-in) for Facebook users.
* Note also the [http://www.facebook.com/group.php?gid=2374732285 microformats group], which Facebook users who support microformats can join.

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

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

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

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

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

=== Google Chrome ===
* See [[chrome-extensions|Chrome Extensions]]

=== Google Search ===
* Consumes microformats via rich snippets: [[search engines | wiki page]], [http://www.google.com/support/webmasters/bin/answer.py?answer=99170 rich snippets docs]
* supports [[rel-nofollow]]
** by [[implementors#Google|Google]]

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

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

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

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

=== Greasemonkey ===
* [http://greasemonkey.makedatamakesense.com/google_hcalendar/ Google hCalendar] - Adds hCalendar data to Google Calendar.
* [http://www.nickpeters.net/?p=35 Social xFolk] - Adds xFolk links to social bookmarking sites del.icio.us and ma.gnolia.
* [http://monkeyformats.org/ Monkeyformats] - a collection of GreaseMonkey scripts that add actual hCard and hCalendar microformat markup to several international phone directories.

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

=== hCard to Gmail Service ===
* [http://jkg3.com/Journal/81/bookmarklet hCard to gmail] is a bookmarklet / service which will convert hCard formatted data to the .CSV file for importing to gmail.
** by [[implementors#Jamie_Knight|Jamie Knight]]

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

=== Helios Calendar ===
* [http://www.helioscalendar.com/ Helios Calendar] is a commercial PHP script for event publishing that [http://www.helioscalendar.com/index.php?com=features&d=1 supports hCalendar and hCard].
** by [[implementors#Refresh Web Development|Refresh Web Development]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== Mash Maker ===
* [http://mashmaker.intel.com/ Intel Mash Maker] supports microformats as of 2007-11-15 (see [http://softwareblogs.intel.com/2007/11/15/bookmarks-microformats-and-bug-fixes/ announcing blog post])
** by [[implementors#Intel|Intel]]

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

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

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

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

=== Movable Type ===
* [http://movabletype.org Movable Type] (MT) open source blogging software supports:
** [[XFN]] [[rel-me]] "other profiles" UI, and [[hAtom]] activity streams (as of MT v4.1 - see [http://www.sixapart.com/about/news/2008/01/time_for_action.html announcement] and [http://www.movabletype.org/2008/01/building_action_streams.html technical details].)
** by [[implementors#Six Apart|Six Apart]]
See also [[movable-type]].

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

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

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

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

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

=== Netscape Navigator ===
* Version 9.0+ supports [[Firefox extensions]], e.g. [[Operator]]:
** [http://notizblog.org/2007/10/21/operator-unter-navigator-90/ Operator unter Navigator 9.0]

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

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

=== Open-Xchange ===
* The [http://www.open-xchange.com Open-Xchange] collaboration appliance supports publishing and subscribing of contacts in hCard format (in addition to exporting vcard) officially since v6.16. The format is extended by additional fields (like "date of marriage") in the OXMF microformat.

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

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

=== Portable Social Network Profile Parser ===
* [http://lab.backnetwork.com/ufXtract-psn/ Portable Social Network Profile Parser] implements parsing of [[hCard]], [[XFN]], and in particular [[rel-me]] for [[identity-consolidation]] for [[social-network-portability]].
** by [[implementors#Glenn_Jones|Glenn Jones]] of [[implementors#Madgex|Madgex]].

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

=== Pownce ===
*[http://pownce/ Optimus]. Output formats: XML, JSON, JSON-P.

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

=== Realcom HAKONE for Notes ===
* [http://www.realcom.co.jp/en/hakone2.html HAKONE for Notes] - supports [[hCard|hCard]]
** by [[implementors#Realcom|Realcom]]

=== Realcom KnowledgeMarket ===
* [http://www.realcom.co.jp/en/enterprisesuite2.html KnowledgeMarket] - supports [[hCard|hCard]]
** by [[implementors#Realcom|Realcom]]

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

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

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

=== Safari Microformats plugin ===
<blockquote>
The Safari Microformats plugin notifies you when the author of the website has published Microformats and allows you to easily import hCards and hCalendars in Address Book and iCal. This plugin was inspired by the idea and mockup of Jon Hicks.
</blockquote>
[http://www.zappatic.net/safarimicroformats/ Safari Microformats Plugin]
* Note - the latest version, 3.1, currently only works w/Mac OS 10.5 (Leopard)

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

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

<div id="cognition">
=== Swignition ===
* [http://buzzword.org.uk/swignition/ Swignition] is a Perl framework and script (usable online via CGI, and downloadable for local use) that supports:
** [[hatom|hAtom]]
** [[haudio|hAudio]]
** [[User:TobyInk/hcalendar-1.1|hCalendar]]
** [[hcard|hCard]], [[adr]], [[geo]], [[jCard]], [[xfn|XFN]] (1.0 and 1.1) and [http://xen.adactio.com XEN]
** [[hresume|hResume]]
** [[hreview|hReview]]
** [[rel-tag]], [[rel-enclosure]] and [[rel-license]]
** [[figure]]
** [[measure]]
** [[species]]
** [[xfolk|xFolk]]
** [[xoxo|XOXO]]
** several non-microformat semantic HTML techniques, including GRDDL, RDFa, eRDF and COinS.
** by [[implementors#Toby_Inkster|Toby Inkster]]
** no longer actively developed, see [[parsers#HTML::Microformats|HTML::Microformats]] for its replacement.
</div>

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

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

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

=== Technorati Search ===
* [http://technorati.com/ Technorati] [http://technorati.com/search Search] supports and handles both [[vote-links]] and [[rel-nofollow]] for indicating whether a link should have any/positive/negative weighting towards the destination.
** by [http://technorati.com/about/staff.html Technorati Staff]

=== Technorati Tags ===
* [http://technorati.com/tags/ Technorati Tags] pages aggregate blog posts tagged with the [[rel-tag]] open tagging standard, in addition to recent tagged photos and links.

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

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

=== Transformr ===
* [http://code.google.com/p/transformr/ Transformr] Is a microformats transformation toolkit. Transformr is also available as a [http://transformr.co.uk/ webservice]
** by [[implementors#Martin_McEvoy|Martin McEvoy]]

=== TYPO3 ===
* [http://www.typo3.com TYPO3]
==== Getting Started ====
* [http://typo3.org TYPO3 Developer Ressource]
* [http://www.acqal.com/a/article/getting-help-with-typo3-98.html Getting Help With TYPO3]
==== tt_address extension====
* [http://typo3.org/extensions/repository/view/tt_address/2.0.1/ tt_address] - hCard support with the tt_address extension version 2.0.0
** by [[implementors#Ingo_Renner|Ingo Renner]]
==== TIMTAB extension====
* [http://typo3.org/extensions/repository/view/timtab/0.5.11/ TIMTAB] - XFN support for blogrolls with the TIMTAB weblog extension for TYPO3
** by [[implementors#Ingo_Renner|Ingo Renner]]

=== Tweeterboard ===
* Tweeterboard supports [hcard|hCard]], and [http://gmpg.org/xfn XFN] on profile pages ([http://tweeterboard.com/user/missrogue example]).

=== Twitter ===

* [http://twitter.com Twitter] [http://twitter.com/al3x/statuses/53982402 supports] [[hatom|hAtom]], [[hcard|hCard]], and [http://gmpg.org/xfn XFN].
** hCards for groups are marked up with "fn" not "fn org". See, for example, [http://twitter.com/microformats microformats on Twitter]
** Improper address mark-up (no child properties; though this may be all that can be achieved, if the user enters a value like "Birmingham, England")
** Uses <code>class="label"</code> for non-hCard purpose.

=== ufXtract ===
* [http://lab.backnetwork.com/ufXtract/ ufXtract] implements [[parsing]] of microformats such as [[hCard]] and [[XFN]].
** by [[implementors#Glenn_Jones|Glenn Jones]] of [[implementors#Madgex|Madgex]]. See [http://www.glennjones.net/Post/831/ufXtractmicroformatsparser.htm blog post announcement].

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

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

=== VIREL Microformats Search Engine===
* [http://www.virel.de/ microformats search engine] - website friendly crawler. searches for public informations embedded as microformats in web pages.

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

=== WordPress ===
*See [[wordpress|WordPress]].

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

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

=== xfn-spider ===

* [http://sphinx.net.ru/hg/xfn-spider xfn-spider] — simple crawler extracting microformats with XSLT ([http://sphinx.net.ru/blog/entry/simple-microformat-xslt-extraction/ Original article in Russian] circa summer 2007) and exporting information to OPML feedlist, tag cloud etc.

* See [http://services.alphaworks.ibm.com/manyeyes/view/SNnqRHsOtha6i5-m6iGTH2- XFN visualization] example at IBM's Many Eyes made using data extracted with xfn-spider

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

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

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

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

=== Yalwa - Local directory ===
* [http://www.yalwa.com/ Yalwa - Local Directory] supports [[hreview|hReview]].
Example: [http://wiesbaden.yalwa.de/ID_102318221/Yalwa-GmbH.html Yalwa Listing]

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

== Validators ==

See [[debugging-tools]].

==Search engines==
See [[search-engines]]

== Companies / Developers / Organizations ==
See [[implementors]]

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

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

hresume-issues

2010-03-18T09:12:56Z

TobyInk: /* Issues */ add id attribute for linking

<h1> hResume issues </h1>

These are externally raised issues about [[hresume|hResume]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/log/ Tantek]

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

__TOC__

== Issues ==

* <span id="issue-20100317">{{OpenIssue}} 2010-03-17 raised by [[User:TobyInk|TobyInk]]</span>
*# ''Embedding hCard for job title leads to ambiguities.''
*#* It's tempting to assume that any <code>class="vcard"</code> within the <code>class="experience"</code> must be an hCard representing the contact while they were at the organisation (e.g. <code>class="title"</code> represents their job title, <code>class="role"</code> their role, etc). But there's no guarantee of that. e.g. <code><span class="experience vevent">...<span class="location vcard"><i class="fn">Employer's Name</i></span>...</span></code>.
*#** Suggested solution: provide a class name for indicating that a particular hCard represents the contact while they were at the organisation. e.g. <code>class="vcard me"</code>.

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

* {{OpenIssue}} 2007-06-21 raised by [[User:Steve_Ganz|Steve Ganz]].
*# ''rel-tag can be difficult to implement for "skill" ''
*#* In Draft, version 0.1 it is required that each "skill" be marked up with rel-tag. While this is a good idea, and easy to do for individuals, it poses some challenges in the real world for large publishers of user generated resume data. If rel-tag was optional for "skills", it would be easier to implement.
*#* +1, expecting a resume author to link out to a hypothetical tagspace is an unnecessary barrier to entry. In reality authors end up linking to places like WikiPedia, which is not a real tagspace as defined in rel-tag. We should look at a more complex skill format for both this and the issue below opened by NTollervey. --[[User:CiaranMc|Ciaran McNulty]]
*#* +1, I have tried very hard to think of ways to make rel-tag work for skills description. In the end I had to drop marking up skills altogether in hResume because I am unwilling to add meaningless hyperlinks. As Ciaran mentioned we need a more complex structure that actual models to real world use. I have documented some alternative ideas [[hresume-skill-brainstorm|skill brainstorm]] [[User:GlennJones|Glenn Jones]]

* {{OpenIssue}} 2007-01-04 raised by [[User:NTollervey|ntoll]].
*# ''With regard to the "skill" attributes in a resume:''
*#* Often skills have an indication of the level of attainment - be it as a descriptive "tag" or a duration denoting the length of experience of the referenced skill. In fact, abstracting out a "skill" microformat might be useful for re-use in the job-listing (Vacancy?) microformat. That way, job requirements can be married to CVs. Although not a job-site, I like Sourceforge.net's skill inventory feature (that captures both a level and length of experience) although I think its implementation is horrendous.
*#* +1, There are enough people using either skill ratings or denote duration for us to consider extending the skills. We already have two patterns in other microformats rating and ISO duration that could be used extend the structure [[hresume-skill-brainstorm|skill brainstorm]] [[User:GlennJones|Glenn Jones]]

* {{OpenIssue}} 2006-10-19 raised by [[RyanKing]].
*# ''There's currently no way to say 'present' in hCalendar''
*#* Many job experience listings will include jobs that the person is presently working at. Ciaran McNulty [http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html correctly pointed out] that a blank DTEND does not indicate that the event is still ongoing. We need to find an easy way to make this work in hResume.
*#* Any solution should also be a valid hCalendar, which makes things even more difficult. One possible solution would be to use an event without a DTEND for the current period of employment but have some extra class that indicates that within the semantics of hResume it's an ongoing event and let the hCalendar version just indicate the start of the employment. --[[User:CiaranMc|Ciaran McNulty]]
*#* Although not the best solution, for the time being, a date far ahead in the future (e.g., 2049-12-31) may have practical use (Note: Google Calendar can handle up to but not including year 2050) -- --[[User:Csarven|Sarven Capadisli]] 21:34, 18 November 2008 (UTC)
*#* I tend to just use the current date for dtend: anything else seems semantically wrong as an abbr of "present". [[User:GeoffreySneddon|GeoffreySneddon]] 21:46, 19 November 2008 (UTC)

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

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2009-02-21</span> raised by <span class="fn">[http://microformats.org/wiki/User:mfreeman mfreeman]</span></span>
<div class="description">
*The draft should describe a way to handle a series of assignments at various employers within the context of one job working for a contracting, consulting, or temporary firm/agency.
*For example, a person is employed by ABC Corp. as a Staff Consultant from 1/1/2000 to 12/31/2008. During that time, ABC Corp. placed the person at:
**XYZ Inc. as a Business Analyst from 1/1/2000 to 12/31/2005
**DEF LLC as a Technical Writer from 1/1/2006 to 6/1/2006
**"on the bench" with no assignment from 6/2/2006 to 8/14/2006
**OMG Inc. as a Database Designer from 8/15/2006 to 12/31/2008
*The draft may already address this, but it is not obvious.
</div>
</div>

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

hresume-issues

2010-03-17T17:09:39Z

TobyInk: experience hCard issue.

<h1> hResume issues </h1>

These are externally raised issues about [[hresume|hResume]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/log/ Tantek]

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

__TOC__

== Issues ==

* {{OpenIssue}} 2010-03-17 raised by [[User:TobyInk|TobyInk]]
*# ''Embedding hCard for job title leads to ambiguities.''
*#* It's tempting to assume that any <code>class="vcard"</code> within the <code>class="experience"</code> must be an hCard representing the contact while they were at the organisation (e.g. <code>class="title"</code> represents their job title, <code>class="role"</code> their role, etc). But there's no guarantee of that. e.g. <code><span class="experience vevent">...<span class="location vcard"><i class="fn">Employer's Name</i></span>...</span></code>.
*#** Suggested solution: provide a class name for indicating that a particular hCard represents the contact while they were at the organisation. e.g. <code>class="vcard me"</code>.

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

* {{OpenIssue}} 2007-06-21 raised by [[User:Steve_Ganz|Steve Ganz]].
*# ''rel-tag can be difficult to implement for "skill" ''
*#* In Draft, version 0.1 it is required that each "skill" be marked up with rel-tag. While this is a good idea, and easy to do for individuals, it poses some challenges in the real world for large publishers of user generated resume data. If rel-tag was optional for "skills", it would be easier to implement.
*#* +1, expecting a resume author to link out to a hypothetical tagspace is an unnecessary barrier to entry. In reality authors end up linking to places like WikiPedia, which is not a real tagspace as defined in rel-tag. We should look at a more complex skill format for both this and the issue below opened by NTollervey. --[[User:CiaranMc|Ciaran McNulty]]
*#* +1, I have tried very hard to think of ways to make rel-tag work for skills description. In the end I had to drop marking up skills altogether in hResume because I am unwilling to add meaningless hyperlinks. As Ciaran mentioned we need a more complex structure that actual models to real world use. I have documented some alternative ideas [[hresume-skill-brainstorm|skill brainstorm]] [[User:GlennJones|Glenn Jones]]

* {{OpenIssue}} 2007-01-04 raised by [[User:NTollervey|ntoll]].
*# ''With regard to the "skill" attributes in a resume:''
*#* Often skills have an indication of the level of attainment - be it as a descriptive "tag" or a duration denoting the length of experience of the referenced skill. In fact, abstracting out a "skill" microformat might be useful for re-use in the job-listing (Vacancy?) microformat. That way, job requirements can be married to CVs. Although not a job-site, I like Sourceforge.net's skill inventory feature (that captures both a level and length of experience) although I think its implementation is horrendous.
*#* +1, There are enough people using either skill ratings or denote duration for us to consider extending the skills. We already have two patterns in other microformats rating and ISO duration that could be used extend the structure [[hresume-skill-brainstorm|skill brainstorm]] [[User:GlennJones|Glenn Jones]]

* {{OpenIssue}} 2006-10-19 raised by [[RyanKing]].
*# ''There's currently no way to say 'present' in hCalendar''
*#* Many job experience listings will include jobs that the person is presently working at. Ciaran McNulty [http://microformats.org/discuss/mail/microformats-discuss/2006-October/006477.html correctly pointed out] that a blank DTEND does not indicate that the event is still ongoing. We need to find an easy way to make this work in hResume.
*#* Any solution should also be a valid hCalendar, which makes things even more difficult. One possible solution would be to use an event without a DTEND for the current period of employment but have some extra class that indicates that within the semantics of hResume it's an ongoing event and let the hCalendar version just indicate the start of the employment. --[[User:CiaranMc|Ciaran McNulty]]
*#* Although not the best solution, for the time being, a date far ahead in the future (e.g., 2049-12-31) may have practical use (Note: Google Calendar can handle up to but not including year 2050) -- --[[User:Csarven|Sarven Capadisli]] 21:34, 18 November 2008 (UTC)
*#* I tend to just use the current date for dtend: anything else seems semantically wrong as an abbr of "present". [[User:GeoffreySneddon|GeoffreySneddon]] 21:46, 19 November 2008 (UTC)

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

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2009-02-21</span> raised by <span class="fn">[http://microformats.org/wiki/User:mfreeman mfreeman]</span></span>
<div class="description">
*The draft should describe a way to handle a series of assignments at various employers within the context of one job working for a contracting, consulting, or temporary firm/agency.
*For example, a person is employed by ABC Corp. as a Staff Consultant from 1/1/2000 to 12/31/2008. During that time, ABC Corp. placed the person at:
**XYZ Inc. as a Business Analyst from 1/1/2000 to 12/31/2005
**DEF LLC as a Technical Writer from 1/1/2006 to 6/1/2006
**"on the bench" with no assignment from 6/2/2006 to 8/14/2006
**OMG Inc. as a Database Designer from 8/15/2006 to 12/31/2008
*The draft may already address this, but it is not obvious.
</div>
</div>

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

User:TobyInk/hcalendar-1.1

2010-03-08T22:00:45Z

TobyInk: /* Related-To Links */ clarify linking to UIDs

<entry-title>hCalendar 1.1</entry-title>

http://www.boogdesign.com/images/buttons/microformat_hcalendar.png

'''This is a DRAFT version of an update to the [[hCalendar]] spec.'''

(I am aware of the existence of [[hcalendar-brainstorming]] and [[htask]]. This is intended to be more of a formal-style document, representing a draft replacement for the current [[hcalendar]] spec, mostly aimed at filling in areas where the current spec is incomplete or ambiguous, rather than adding newly requested functionality.)

hCalendar is a simple, open, distributed calendaring and events format, based on the iCalendar standard ([http://www.ietf.org/rfc/rfc2445.txt RFC2445]), suitable for embedding in HTML or XHTML, Atom, RSS, and arbitrary XML. hCalendar is one of several open [[microformats|microformat]] standards.

Want to get started with writing an [[hcalendar|hCalendar]] event? Use the [http://microformats.org/code/hcalendar/creator hCalendar creator] to write up an event and publish it, or follow the [[hcalendar-authoring|hCalendar authoring tips]] to add hCalendar mark-up to your page of upcoming events or events you mention in blog posts, wikis, etc.

__TOC__

== Specification ==

; Editor : [http://tobyinkster.co.uk Toby Inkster]
; Authors : [http://tantek.com/ Tantek Çelik] ([http://technorati.com Technorati, Inc])
: [http://suda.co.uk/ Brian Suda]
: [http://tobyinkster.co.uk Toby Inkster]

=== Copyright ===
Per the public domain release on the authors' user pages ([[User:Tantek|Tantek Çelik]], [[User:Brian|Brian Suda]]) this specification is released into the public domain.

{{MicroFormatPublicDomainContributionStatement}}

=== Patents ===
{{MicroFormatPatentStatement}}

=== Inspiration and Acknowledgments ===
Thanks to:
* Adam Bosworth for leading the [http://wiki.oreillynet.com/foocamp04/index.cgi?HTMLForCalendars FOO Camp 2004 HTML For Calendars presentation] which brought together a critical mass of interested parties.

== Introduction ==
The iCalendar standard ([http://www.ietf.org/rfc/rfc2445.txt RFC2445]), has been broadly interoperably implemented (e.g. Apple's "iCal" application built into MacOSX).

In addition, bloggers often discuss events on their blogs -- upcoming events, write-ups of past events, etc. With just a tad bit of structure, bloggers can discuss events in their blog(s) in such a way that spiders and other aggregators can retrieve such events, automatically convert them to iCalendar, and use them in any iCalendar application or service.

This specification introduces the '''hCalendar''' format, which is a representation of a subset of the aforementioned iCalendar standard, in semantic HTML. Bloggers can both embed hCalendar events and todo items directly in their web pages, and style them with CSS to make them appear as desired. In addition, hCalendar enables applications to retrieve information about such events directly from web pages without having to reference a separate file.

{{rfc-2119-intro}}

== Semantic XHTML Design Principles ==

{{semantic-xhtml-design-principles}}

For practical implementations, note that Internet Explorer's support for styling <code><nowiki><abbr></nowiki></code> elements is poor, and might require wrapper elements.

== Format ==
=== In General ===
The iCalendar standard ([http://www.ietf.org/rfc/rfc2445.txt RFC2445]) forms the basis of hCalendar.

The basic format of hCalendar is to use iCalendar object/property names in lower-case for class names, and to map the nesting of iCalendar objects directly into nested XHTML elements.

The VJOURNAL and VTIMEZONE components of iCalendar are explicitly not supported as part of hCalendar. hCalendar authors {{should-not}} use classes "vjournal" or "vtimezone" within an hCalendar context; parsers {{must-not}} attempt to interpret them if conforming to this version of the specification. [[hAtom]] {{may}} be used as an alternative to VJOURNAL for those authors wishing to publish journal information. VTIMEZONE has no suggested direct replacement: authors {{should}} restrict themselves to publishing dates in [http://www.w3.org/TR/NOTE-datetime W3CDTF format] using only well-known timezones.

=== Root Class Name ===
The root class name for hCalendar is "vcalendar". An element with a class name of "vcalendar" is itself called an ''hCalendar''.

The root class name for events is "vevent". An element with a class name of "vevent" is itself called an ''hCalendar event''. The root class name for todo items is "vtodo". An element with a class name of "vtodo" is itself called an ''hCalendar todo''. The root class name for alarm items is "valarm". An element with a class name of "valarm" is itself called an ''hCalendar alarm''. The root class name for freebusy items is "vfreebusy". An element with a class name of "vfreebusy" is itself called an ''hCalendar freebusy''.

For authoring convenience, "vevent", "vtodo" and "vfreebusy" are treated as root class names for parsing purposes. If a document contains elements with class names "vevent", "vtodo" or "vfreebusy", but not "vcalendar", the entire document has an implied "vcalendar" context.

An element with a class name of "valarm" is itself called an ''hCalendar alarm''. This is not a root class name.

=== Properties and Sub-properties ===
The properties of an hCalendar are represented by elements inside the hCalendar. 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 for hCalendars ====

* vcalendar ?
** ''vevent'' (hCalendar event)*
** ''vtodo'' (hCalendar todo)*
** ''vfreebusy'' (hCalendar freebusy)*
** calscale ? [String representing calendar system being used. Default is "GREGORIAN" if not specified.]
** method ? [Method taken from [http://www.ietf.org/rfc/rfc2446.txt RFC 2446]. Default is "PUBLISH".]

Although each component of an hCalendar is optional and {{may}} occur more than once, an hCalendar {{should}} contain at least one of <code>vevent</code>, <code>vtodo</code> or <code>vfreebusy</code>.

===== Key =====
Based on Perl's [http://www.perl.com/doc/manual/html/pod/perlre.html standard quantifiers]:
{| border="1" cellpadding="2"
| '''bold''' {1} || {{must}} be present exactly once
|-
| ''italic''<nowiki>*</nowiki> || {{optional}}, and {{may}} occur more than once
|-
| + || {{must}} be present, and {{may}} occur more than once
|-
| ? || {{optional}}, but {{must-not}} occur more than once
|-
| [square brackets] || list of common values
|-
| (parentheses) || data format
|-
| <nowiki>A | B</nowiki> || A or B (not both)
|-
| # || comment
|-
| ! || awaiting documentation
|}

==== Property List for hCalendar Events ====

hCalendar event properties

* '''vevent''' {1}
** '''dtstart''' ([[iso-8601|ISO date]]) {1}
** '''summary''' {1}
** class ? ["PUBLIC", "PRIVATE", "CONFIDENTIAL"]
** created (ISO date) ?
** description ?
** dtend (ISO date) | duration (ISO date duration) ?
** dtstamp (ISO date) ?
** geo ([[geo]]) ?
** last-modified (ISO date) ?
** location (text | [[geo]] | [[adr]] | [[hCard]]) ?
** organizer ([[#Nested_hCards|see section below]]) ?
** priority ? ["LOW", "MEDIUM", "HIGH" or integer from 0 to 9]
** recurrence-id (link) ?
** sequence (integer) ?
** status ? ["TENTATIVE", "CONFIRMED", "CANCELLED"]
** transp ? ["OPAQUE", "TRANSPARENT"]
** uid (link) ?
** url (link) ?
** ''attach'' (link) *
** ''attendee'' ([[#Nested_hCards|see section below]]) *
** ''categories'' *
** ''contact'' ([[#Nested_hCards|see section below]]) *
** ''comment'' *
** ''exdate'' (ISO date) *
** ''exrule'' (see the section on Recurrence below) *
*** '''freq''' {1} ["SECONDLY", "MINUTELY", "HOURLY", "DAILY", "WEEKLY", "MONTHLY", "YEARLY"]
*** until (ISO date) | count (integer) ?
*** interval ?
*** ''bysecond'' *
*** ''byminute'' *
*** ''byhour'' *
*** ''byday'' *
*** ''bymonthday'' *
*** ''byyearday'' *
*** ''byweekno'' *
*** ''bymonth'' *
*** ''bysetpos'' *
*** wkst ?
** ''rdate'' (ISO date) *
** ''related-to'' (link) *
** ''resources'' *
** ''rrule'' (see the section on Recurrence below) *
*** (as per "exrule")
** ''valarm'' (hCalendar alarm) *

Additionally an hCalendar event {{may}} contain zero or more links marked up as [[rel-tag]] corresponding to additional values for the CATEGORIES property from iCalendar; and zero or more links marked up as [[rel-enclosure]] corresponding to additional values for the ATTACH property.

==== Mapping of hAtom to hCalendar ====

The VJOURNAL component {{must not}} be used in hCalendar. hAtom entries {{may}} be used instead. Below is an informative mapping of iCalendar to hAtom.

{| border="1"
|-
! iCalendar
! hAtom
|-
| BEGIN:VJOURNAL
| hentry
|-
| ATTACH
| [[rel-enclosure]]
|-
| CATEGORIES
| [[rel-tag]]
|-
| COMMENT
| entry-summary
|-
| DESCRIPTION
| entry-content
|-
| SUMMARY
| entry-title
|-
| ORGANIZER
| author
|-
| UID
| [[rel-bookmark]]
|-
| CREATED
| published
|-
| LAST-MODIFIED
| updated
|-
| DTSTAMP
| updated
|}

==== Property List for hCalendar Todos ====

hCalendar todo items have the same properties as hCalendar events, except that they {{should-not}} contain "transp" or "dtend" properties. The "dtstart" property is optional. The following additional properties are defined:

* '''vtodo''' {1}
** due (ISO date) ?
** percent-complete ?
** completed (ISO date) ?

Allowed values for the "status" property are instead: "NEEDS-ACTION", "COMPLETED", "IN-PROCESS", "CANCELLED".

As per hCalendar events, [[rel-tag]] and [[rel-enclosure]] links {{may}} be used.

==== Property List for hCalendar Alarms ====

* '''valarm''' {1}
** '''summary''' {1}
** '''trigger''' (ISO date duration) {1}
** action ? ["AUDIO", "DISPLAY", "EMAIL", "PROCEDURE"]
** description ?
** duration (ISO date duration) ?
** repeat (integer) ?
** ''attach'' (link) *
** ''attendee'' (text | [[hCard]]) *

[[rel-enclosure]] links {{may}} be used, but [[rel-tag]] {{should-not}}.

The "ACTION" property is required in RFC 2445, but in hCalendar defaults to "DISPLAY".

{{OpenIssue}} This is an over-simplistic representation of [http://www.kanzaki.com/docs/ical/trigger.html TRIGGER].

==== Property List for hCalendar Freebusys ====

* '''vfreebusy''' {1}
** '''summary''' {1}
** '''freebusy''' +
*** '''fbtype''' {1}
*** ''value'' * (ISO date then slash then ISO-date-or-ISO-duration)
** comment ?
** dtend (ISO date) ?
** dtstamp (ISO date) ?
** dtstart (ISO date) ?
** duration (ISO date duration) ?
** organizer (text | [[hCard]]) ?
** uid (link) ?
** url (link) ?
** ''attendee'' (text | [[hCard]]) *
** ''contact'' (text | [[hCard]]) *

[[rel-tag]] and [[rel-enclosure]] links {{should-not}} be included.

=== Case-Sensitivity of Pre-Defined Values ===

Certain properties have a list of possible values, defined in the iCalendar specification in ALL-CAPS. For example, the "transp" property has a value of either "OPAQUE" or "TRANSPARENT". hCalendar authors {{may}} use lower or mixed case for these values. hCalendar parsers {{must}} convert these to upper case if exporting as iCalendar.

=== Dates and Times ===

Dates and times {{must}} be expressed in the [http://www.w3.org/TR/NOTE-datetime W3C datetime format]. Authors {{may}} take advantage of the [[abbr-design-pattern|ABBR design pattern]], but {{should}} take into account [[accessibility-issues#abbr-design-pattern|accessibility issues]].

==== Durations ====

Durations {{must}} be expressed as ISO 8601 durations of time, as per RFC 2445. Some examples:

<pre>The <span class="summary">management meeting</span> with last approximately
<abbr class="duration" title="PT2H30M">two and a half hours</abbr>.</pre>

<pre>This <abbr title="2008-06-23" class="dtstart">summer</abbr>, we begin our
<abbr class="duration" title="P13W">season</abbr> of light entertainment.</pre>

=== Links ===

When a class is found indicating a property of type "link", then it {{should}} be parsed as follows:

# If the element is an <a> element, the "href" attribute is used as the value;
# Otherwise, if the element is an <img> element, the "src" attribute is used as the value;
# Otherwise, if the element is an <object> element, the "data" attribute is used as the value;
# If all else fails, the element is interpreted as if it were a non-link element, with the textual content of the element being treated as the value. If authors rely on this behavior, absolute URLs {{should}} be specified.

==== UID ====

As a special case, the UID property is parsed as follows:

# If the element with class "uid" has a fragment identifier (that is, if it has an "id" attribute or is <a name>), then the value of the UID property {{must}} be set to the absolute URL of that fragment;
# Otherwise the element with class "uid" is parsed using the procedure described in the previous section on links in general.
# If there is no element with class "uid", then the element bearing the root class name (e.g. "vevent" or "vtodo") is checked. If that element has a fragment identifier (that is, if it has an "id" attribute or is <a name>), then the value of the UID property {{must}} be set to the absolute URL of that fragment.
# If all else fails, an hCalendar parser {{may}} choose to generate its own UID for the item. Reasonable care {{must}} be taken to ensure the uniqueness of this UID. Authors {{should not}} rely on this behavior.
# Otherwise, the item has no UID value.

==== Related-To Links ====

The value of the related-to property {{must}} be a link, and {{should}} be the UID of another hCalendar event or todo item (not necessarily on the same page). If the element with the "related-to" class is <a> or <area>, then it {{may}} take a rel attribute with any of the following values:

* vcalendar-parent
* vcalendar-child
* vcalendar-sibling

These correspond to the PARENT, CHILD and SIBLING values of the RELTYPE sub-property.

=== Recurrence ===

In RFC 2445, recurrence (RDATE) and exclusion dates (EXDATE) may be a comma-separated list of ISO dates. In hCalendar, each "rdate" and "exdate" class {{must}} each be a single date. Each of these can occur zero or more times within todo items and events.

Recurrence rules (RRULE) and exclusion rules (EXRULE) are complex. hCalendar parsers are not required to support them, and {{may}} choose to ignore the entire contents of "rrule" and "exrule" properties. But if "rrule" and "exrule" are supported, then they {{must}} be parsed according to the guidelines in this section of the specification.

That is, parsers {{must}} aim to implement "rrule" and "exrule" entirely, or not at all.

==== A Worked Example ====

The following example iCalendar recurrence rule is given in RFC 2445:

<pre>
DTSTART;TZID=US-Eastern:19970105T083000
RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;
BYMINUTE=30
</pre>

This represents an event which occurs every Sunday in January at 08:30 and 09:30, starting on 5 January 1997 and only occurring on odd-numbered years. Here is an example of how that might be translated into HTML:

<pre>
<p>Our organisation has been offering a series of summer lectures since
<abbr class="dtstart" title="19970105T083000">January 1997</abbr>. They
are
<span class="rrule">
held <span class="freq">yearly</span>,
every <span class="interval">2</span>nd year (1999, 2001, etc),
every <span class="byday">Sunday</span>
in January <abbr class="bymonth" title="1" style="display:none"></abbr>
at <span class="byhour">8</span>:<span class="byminute">30</span> and
repeated at <span class="byhour">9</span>:30.
</span>
</p>
</pre>

This might be rendered as:
<div style="margin:1em 4em 1.5em;padding:0.5em;border:1px solid silver;background:#f8f8f8;font-size:120%">
<p>Our organisation has been offering a series of summer lectures since
<abbr class="dtstart" title="19970105T083000">January 1997</abbr>. They
are
<span class="rrule">
held <span class="freq">yearly</span>,
every <span class="interval">2</span>nd year (1999, 2001, etc),
every <span class="byday">Sunday</span>
in January <abbr class="bymonth" title="1" style="display:none"></abbr>
at <span class="byhour">8</span>:<span class="byminute">30</span> and
repeated at <span class="byhour">9</span>:30.
</span>
</p>
</div>

==== Notes ====

# The examples above show only the DTSTART and RRULE properties and do not represent an entire VEVENT (which would require an element with class "vevent", and one with class "summary").
# For further information and allowed values, see section 4.3.10 of RFC 2445.
# Although iCalendar doesn't allow the "BY*" properties to be repeated (BYHOUR=8;BYHOUR=9) it does allow a single "BY*" property to contain a comma-separated list of numbers (BYHOUR=8,9). When an hCalendar recurrence rule specifies a repeated "BY*" property, parsers {{must}} interpret this as being equivalent to a comma-separated list in iCalendar.
# RFC 2445 section 4.3.10 defines the tokens "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" / "WEEKLY" / "MONTHLY" / "YEARLY" as possible values for FREQ. hCalendar allows these to be specified in a case-insensitive manner. Parsers {{should}} convert them to upper-case if exporting as an iCalendar file.
# hCalendar recurrence rules {{may}} use tokens longer than two characters to identify the day. Parsers {{must}} trim the token down to its first two non-whitespace characters and upper-case them if wishing to convert them to iCalendar BYDAY tokens.
# hCalendar recurrence rules {{should-not}} include multiple occurrences of "until" or "count" sub-properties, and {{should-not}} specify both an "until" and a "count" sub-property for the same rule. If a rule violates this requirement, parsers {{must}} use only the first "until" or "count" sub-property and {{must}} ignore subsequent uses of "until" or "count".

==== Simplified Notation ====

In the notation above, an element with class "freq" is a required child element of "rrule" and "exrule". When a parser encounters a recurrence rule with no "freq" specified, then the entire contents of the "rrule" or "exrule" element {{must}} be treated as a literal iCalendar RRULE or EXRULE. For example:

<pre><p>Our organisation has been offering a series of summer lectures since
<abbr class="dtstart" title="19970105T083000">January 1997</abbr>. They
are held every second year (1999, 2001, etc), every Sunday in January at
8:30 and repeated at 9:30.
<abbr title="FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;BYMINUTE=30"
class="rrule" style="display:none"></abbr>
</p></pre>

This allows authors to express complicated rules in more natural language without having to worry about how to map their language onto the various recurrance rule sub-properties.

=== Nested Events and Todos ===

As with [[hcard-parsing#nested_hCards|hCard]], events and todos {{may}} be nested:

<pre><nowiki>
<div class="vevent">
<h1 class="summary">Technology Conference</h1>
<p class="dtstart">2008-03-01</p>

<h2>Workshops</h2>
<ul>
<li class="vevent">
<b class="summary">Microformats</b>
<abbr class="dtstart" title="2008-03-01T10:30:00Z">10:30am</abbr>
</li>
<li class="vevent">
<b class="summary">RDFa</b>
<abbr class="dtstart" title="2008-03-01T11:30:00Z">11:30am</abbr>
</li>
<li class="vtodo">
<b class="summary">Lunch</b>
<abbr class="dtstart" title="2008-03-01T12:45:00Z">12:45pm</abbr>
</li>
</ul>
</div>
</nowiki></pre>

The events and todos are to be parsed as independent items, with properties from the children not being applied to the parent, nor vice versa. The only thing a parser {{may}} infer from the nesting is the RELATED-TO property. However, if the items explicitly specify a "related-to" class, the explicit relation {{must}} override any implied relation.

<div id="Nested_hCards"></div>

=== People embedded in hCalendar items ===

The "attendee", "contact" and "organizer" properties each describe a person. These elements may be treated as [[hcard|hCards]] even when no class "vcard" is found on the element.

<pre>
YES: <div class="attendee vcard"><span class="fn">...</span></div>
YES: <div class="attendee"><span class="fn">...</span></div>
NO: <div class="attendee"><p class="vcard"><span class="fn">...</span></p></div>
</pre>

If the hCards do not contain an "fn" property (formatted name), then:

* The entire contents of the element are taken to be the person's formatted name.
* If the element is a link with href beginning with "mailto:" then the e-mail address linked to is taken to be the person's e-mail address.
* If the element is a link with href not beginning with "mailto:" then the link is taken to be the person's URL.

Some parameters may then be mapped from the hCard to various parameters used in iCalendar.

==== Attendees ====

* hCard "fn" maps to the iCalendar "CN" parameter
* hCard "role" maps to the iCalendar "ROLE" parameter
* the first hCard "email" of the first hCard "agent" maps to the iCalendar "DELEGATED-TO" parameter
* the first hCard "email" maps to the iCalendar "ATTENDEE" property itself
* Additional class names within the hCard {{may}} which be parsed (or ignored, as they are not part of hCard):
** class name "kind" (terminology from vCard 4.0), implied contact type (individual or organisation) or "cutype" (term: iCalendar) maps to the iCalendar "CUTYPE" parameter
** class name "rsvp" maps to the iCalendar "RSVP" parameter
** class name "partstat" maps to the iCalendar "PARTSTAT" parameter
** class name "member" (e-mail address) maps to the iCalendar "MEMBER" parameter
** class name "delegated-from" (e-mail address) maps to the iCalendar "DELEGATED-FROM" parameter

For example, the following:

<pre><nowiki>
<p class="attendee">Alice Smith</p>
<p class="attendee">
<a class="fn email" href="mailto:bob@example.net">Bob Jones</a>,
<span class="role">Req-Participant</span>
(RSVP <span class="rsvp">true</span>)
<span class="agent vcard">
<a href="fn email" href="mailto:dave@example.net">Dave Wong</a>
</span>
</p>
<p><a class="attendee" href="mailto:eve@example.net">Eve Ville</a></p>
<p class="attendee">
<a class="fn org" href="mailto:corp@example.net">Example Corp</a>
</p></nowiki></pre>

is equivalent to this in iCalendar:

<pre>ATTENDEE;VALUE=TEXT:Alice Smith
ATTENDEE;CN=Bob Jones;ROLE=REQ-PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVIDUAL
DELEGATED-TO:"MAILTO:dave@example.net":MAILTO:bob@example.net
ATTENDEE;CN=Eve Ville;CUTYPE=INDIVIDUAL:MAILTO:eve@example.net
ATTENDEE;CN=Example Corp;CUTYPE=GROUP:MAILTO:corp@example.net</pre>

==== Contacts ====

The CONTACT is essentially a free-form string in iCalendar. Parsers should generate this string from the "fn" property and other properties if desired. For example:

<pre><nowiki>
<p class="contact">Alice Smith</p>
<p class="contact">
<a class="fn email" href="mailto:bob@example.net">Bob Jones</a>,
<span class="role">Req-Participant</span>
(RSVP <span class="rsvp">true</span>)
<span class="agent vcard">
<a href="fn email" href="mailto:dave@example.net">Dave Wong</a>
</span>
<span class="tel">01234 567 890</span>
</p></nowiki></pre>

<pre>CONTACT:Alice Smith
CONTACT:Bob Jones\, Tel: 01234 567 890</pre>

==== Organizer ====

* hCard "fn" maps to the iCalendar "CN" parameter
* the first hCard "email" of the first hCard "agent" maps to the iCalendar "SENT-BY" parameter
* the first hCard "email" maps to the iCalendar "ORGANIZER" property itself

=== Categories and Attachments ===

RFC 2445 specifies that a VEVENT or VTODO {{may}} have a single CATEGORIES property, which takes a comma-separated list of categories applicable to the item. For example:
<pre><nowiki>CATEGORIES:BUSINESS,HUMAN RESOURCES</nowiki></pre>

This specification allows the "categories" property to occur multiple times, and also allows categories to be specified using [[rel-tag]]. An hCalendar-to-iCalendar converter {{must}} coalesce multiple hCalendar categories into a single iCalendar CATEGORIES string. It {{may}} convert these to upper-case. As an example, the following hCalendar and iCalendar events are considered equivalent:
<pre><nowiki>
<div class="vevent">
<span class="dtstart">2008-04-01</span> <span class="summary">April Fools' Day</span>
<span class="categories">Days, Foolishness,</span>
<a rel="tag" href="http://en.wikipedia.org/wiki/April">April (on Wikipedia)</a>
<span class="categories">Practical Jokes</span>
</div>
</nowiki></pre>
<pre><nowiki>
BEGIN:VEVENT
DTSTART:2008-04-01
SUMMARY:April Fools' Day
CATEGORIES:DAYS,FOOLISHNESS,APRIL,PRACTICAL JOKES
END:VEVENT
</nowiki></pre>

hCalendar components (except freebusy) {{may}} include one or more attachments -- documents related to the component. For example, an hCalendar event describing a meeting might have the agenda attached. In RFC 2445, binary attachments are allowed; in hCalendar, all attachments must be given as URLs (though they may be "data:" URLs). This specification allows two equivalent syntaxes for attaching files to a component:

# An HTML class of "attach" may be set on an element, in which case it should be parsed according to the general rules for links.
# If the element is <a> or <area>, then [[rel-enclosure]] may be used.

The following five examples should be considered equivalent in hCalendar:

<pre><nowiki>
<img class="attach" src="map.jpeg" alt="Map to meeting location.">
<a class="attach" href="map.jpeg">Map to meeting location.</a>
<a rel="enclosure" href="map.jpeg">Map to meeting location.</a>
<a class="attach" rel="enclosure" href="map.jpeg">Map to meeting location.</a>
<span class="attach">http://example.org/map.jpeg</span> 
</nowiki></pre>

=== Include Pattern ===

The [[include-pattern|include pattern]] {{may}} be used within hCalendar mark-up to reference material elsewhere on the page.

=== ABBR Pattern ===

The [[abbr-design-pattern|ABBR design pattern]] {{may}} be used within hCalendar, but authors {{should}} take into account potential accessibility issues.

=== VTODO List XOXO Minimization ===

The following minimization is defined for VTODO when used with [[xoxo]]:

<pre><ol class="vtodo-list xoxo">
<li>Eat breakfast <span class="status">COMPLETED</span></li>
<li>
Go to work
<ol>
<li>Walk to station</li>
<li>Buy ticket</li>
<li>Board train</li>
</ol>
</li>
<li>Attend <span class="summary">meeting</span></li>
</ol></pre>

When class "vtodo-list" is found on an element with class "xoxo", then each list item corresponds to a todo item. For each item, if no summary is found in, then the entire contents of the item (less any nested lists) are taken to be the summary. Nested lists correspond to the RELATED property of VTODO with RELTYPE of PARENT/CHILD. An example iCalendar translation of the above XOXO list might be:

<pre>BEGIN:VTODO
UID:f4bc9c52b4a13dd53-01
SUMMARY:Eat breakfast COMPLETED
STATUS:COMPLETED
END:VTODO
BEGIN:VTODO
UID:f4bc9c52b4a13dd53-02
SUMMARY:Go to work
RELATED;RELTYPE=CHILD:f4bc9c52b4a13dd53-02-01
RELATED;RELTYPE=CHILD:f4bc9c52b4a13dd53-02-02
RELATED;RELTYPE=CHILD:f4bc9c52b4a13dd53-02-03
END:VTODO
BEGIN:VTODO
UID:f4bc9c52b4a13dd53-02-01
SUMMARY:Walk to station
RELATED;RELTYPE=PARENT:f4bc9c52b4a13dd53-02
END:VTODO
BEGIN:VTODO
UID:f4bc9c52b4a13dd53-02-02
SUMMARY:Buy ticket
RELATED;RELTYPE=PARENT:f4bc9c52b4a13dd53-02
END:VTODO
BEGIN:VTODO
UID:f4bc9c52b4a13dd53-02-03
SUMMARY:Board train
RELATED;RELTYPE=PARENT:f4bc9c52b4a13dd53-02
END:VTODO
BEGIN:VTODO
UID:f4bc9c52b4a13dd53-03
SUMMARY:meeting
END:VTODO</pre>

== Examples ==

=== Simple hCalendar Event ===

Here is a sample event in an iCalendar:
<pre><nowiki>
BEGIN:VCALENDAR
PRODID:-//XYZproduct//EN
VERSION:2.0
BEGIN:VEVENT
URL:http://www.web2con.com/
DTSTART:20071005
DTEND:20071020
SUMMARY:Web 2.0 Conference
LOCATION:Argent Hotel\, San Francisco\, CA
END:VEVENT
END:VCALENDAR
</nowiki></pre>

and an equivalent event in hCalendar format with various elements optimized appropriately. See [[hcalendar-example1-steps]] for the derivation.

<pre><nowiki>
<div class="vevent">
<a class="url" href="http://www.web2con.com/">http://www.web2con.com/</a>
<span class="summary">Web 2.0 Conference</span>:
<abbr class="dtstart" title="2007-10-05">October 5</abbr>-
<abbr class="dtend" title="2007-10-20">19</abbr>,
at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div>
</nowiki></pre>

which could be displayed as:

<div class="vevent" style="margin:1em 4em 1.5em;padding:0.5em;border:1px solid silver;background:#f8f8f8;font-size:120%">
<span class="url">http://www.web2con.com/</span> 
<span class="summary">Web 2.0 Conference</span>:
<abbr class="dtstart" title="2007-10-05">October 5</abbr>-
<abbr class="dtend" title="2007-10-20">19</abbr>,
at the <span class="location">Argent Hotel, San Francisco, CA</span>
</div>

Note that this is a '''live''' hCalendar microformat, which will be found on this page by parsers.

=== Full hCalendar Example ===

The following hCalendar example includes three events and a todo item. It makes use of nested hCalendar components, embedded hCards and recurrences.

<pre><nowiki>
<div class="vcalendar">

<div class="vevent">
<h1 class="uid" id="xmas">
<span class="summary">Christmas</span> Schedule
</h1>
<abbr class="dtstart" title="0001-12-25" style="display:none"></abbr>
<p class="comment rrule"><span class="freq">Yearly</span>
period of festive merriment.</p>
<div class="attendee vcard">
<b class="role">
<abbr title="REQ-PARTICIPANT">Required for merriment:</abbr>
</b><br>
<span class="fn">
<span class="honorific-prefix nickname">Santa</span>
<span class="given-name">Claus</span>
</span>
(<span class="adr><span class="region">North Pole</span></span>)
</div>

<div class="vtodo">
<h2 class="uid" id="shopping">Shopping</h2>
<abbr class="dtstart" title="2008-12-01">In December</abbr>, don't forget
to <span class="summary">buy everyone their presents</span> before the
shops shut on <abbr class="due" title="2008-12-24T16:00:00">Christmas
Eve</abbr>!
</div>

<div class="vevent">
<h2 id="jones" class="uid summary">Jones' Christmas Lunch</h2>
<p class="comment">The Joneses have been having a wonderful lunch
<abbr class="rrule" title="FREQ=YEARLY">every year</abbr> at
<abbr class="dtstart" title="2003-12-25T13:00:00Z">1pm for the last
few years</abbr>.</p>
<p><span class="attendee">Everyone</span>'s invited.</p>
</div>
</div>

<div class="vevent">
<h2 class="summary">Boxing Day</h2>
<p class="comment">
<abbr class="rrule" title="FREQ=YEARLY">Every year</abbr>
<abbr class="dtstart" title="0001-12-26">the day after</abbr>
<a class="related-to" href="#xmas" rel="vcalendar-sibling">Christmas</a>
is Boxing Day. Nobody knows quite why this day is called that.
</p>
</div>

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

This might be transformed to iCalendar as:

<pre><nowiki>
BEGIN:VCALENDAR
BEGIN:VEVENT
UID:<http://example.org/hcalendar#xmas>
SUMMARY:Christmas
DTSTART:0001-12-25
RRULE:FREQ=YEARLY
COMMENT:Yearly period of festive merriment.
ATTENDEE;ROLE=REQ-PARTICIPANT;VALUE=TEXT:Santa Claus
RELATED-TO;REL-TYPE=CHILD:<http://example.org/hcalendar#shopping>
RELATED-TO;REL-TYPE=CHILD:<http://example.org/hcalendar#jones>
END:VEVENT
BEGIN:VTODO
UID:<http://example.org/hcalendar#shopping>
SUMMARY:buy everyone their presents
DTSTART:2008-12-01
DUE:2008-12-24T16:00:00
RELATED-TO;REL-TYPE=PARENT:<http://example.org/hcalendar#xmas>
END:VTODO
BEGIN:VEVENT
UID:<http://example.org/hcalendar#jones>
SUMMARY:Jones' Christmas Lunch
DTSTART:2003-12-25T13:00:00Z
RRULE:FREQ=YEARLY
COMMENT:The Joneses have been having a wonderful lunch every year at
1pm for the last few years.
ATTENDEE:Everyone
RELATED-TO;REL-TYPE=PARENT:<http://example.org/hcalendar#xmas>
END:VEVENT
BEGIN:VEVENT
SUMMARY:Boxing Day
DTSTART:0001-12-26
RRULE:FREQ=YEARLY
COMMENT:Every year the day after Christmas is Boxing Day. Nobody knows quite
why this day is called that.
RELATED-TO;REL-TYPE=SIBLING:<http://example.org/hcalendar#xmas>
END:VEVENT
END:VCALENDAR
</nowiki></pre>

The following vCard can also be extracted from it:

<pre><nowiki>
BEGIN:VCARD
FN:Santa Claus
N:;Claus;;Santa;
NICKNAME:Santa
ROLE:REQ-PARTICIPANT
ADR:;;;;North Pole;;
END:VCARD
</nowiki></pre>

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [[hcard|hCard]]
* [http://www.ietf.org/rfc/rfc2445.txt iCalendar RFC2445]
* [[rfc-2119| RFC 2119]]
* [[iso-8601|ISO8601]]

=== Informative References ===
* [http://w3.org/TR/REC-CSS1 CSS1]
* [http://tantek.com/log/2004/09.html#hcalendar hCalendar term introduced and defined on the Web, 20040930]
* [http://wiki.oreillynet.com/foocamp04/index.cgi?HTMLForCalendars FOO Camp 2004 HTML For Calendars presentation, 20040911]
* [http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats FOO Camp 2004 Simple Semantic Formats presentation, 20040910]
* [http://ietfreport.isoc.org/idref/draft-royer-ical-basic/ iCal-Basic (latest)] [http://www.faqs.org/ftp/pub/pub/internet-drafts/draft-royer-ical-basic-04.txt (draft 04)]
* [http://www.w3.org/TR/NOTE-datetime W3C Note on Date and Time Formats]
* [http://www.imc.org/pdi/ Internet Mail Consortium Personal Data Interchange vCard and vCalendar]
* Contributed from http://developers.technorati.com/wiki/hCalendar

==== Specifications That Use hCalendar ====
* [[hreview|hReview]]

==== Related Work ====
* [http://lists.osafoundation.org/pipermail/ietf-calsify/ IETF-calsify archives]
* [http://www.softwarestudio.org/iCal/2445Issues.html RFC2445 Issues List]
* [http://ietf.webdav.org/calsify/ CALSIFY WG Links And Resources]

=== Further Reading ===
* [http://www.livejournal.com/users/jwz/444651.html jwz - Hula] (required reading)
* [http://www.jwz.org/doc/groupware.html Groupware Bad by Jamie Zawinski] crystallizes the reason for hCalendar ('''emphasis''' added):
<blockquote>Right now people can do that by publishing .ics files, but it's not trivial to do so, and it's work on the part of other people to look at them. '''If it's not HTML hanging off our friend's home page that can be viewed in any browser on a public terminal in a library, the bar to entry is too high and it's useless.'''</blockquote>

* [http://muddybranch.thejkgroup.com/ Jason Klemow's blog]
* [http://weblog.infoworld.com/udell/2006/01/11.html#a1368 Moving forward with microformats] by [http://weblog.infoworld.com/udell Jon Udell] provides an hCalendar example and some discussion.
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page] and the [http://technorati.com/tags/hcalendar hCalendar tag]
* [http://en.wikipedia.org/wiki/HCalendar Wikipedia article on hCalendar] (requires expansion)

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

hmedia

2010-02-24T15:31:12Z

TobyInk: /* XMDP Profile */ enclosure is a rel value, not a class

<entry-title>hMedia</entry-title>
{{Template:DraftSpecification}}
{{TOC-right}}

'''[[hmedia|hMedia]]''' is a simple and open format for publishing Images Video and Audio. hMedia may be embedded in HTML or XHTML, Atom, RSS, and arbitrary XML. hMedia is one of several open [[microformats|microformat]] standards.

== hMedia Draft Specification 2009-01-04 ==

=== Editor/Author ===

* <span class="author">[[User:WebOrganics| Martin McEvoy]]</span>

=== Contributors ===

In historical order of contribution

* [http://tantek.com/log/ Tantek Çelik]
* [[User:Kevin_Marks|Kevin Marks]]
* [http://napsterization.org/stories/ Mary Hodder]
* [[User:RodBegbie | Rod Begbie]]
* [http://joshkinberg.com/blog/ Joshua Kinberg]
* [[User:ChrisMessina | ChrisMessina]]
* [http://onlisareinsradar.com/ Lisa Rein]
* [[User:ChrisNewell | Chris Newell]]
* [[User:ManuSporny | Manu Sporny]]
* [[User:MikeJohnson | Mike Johnson]]
* [[User:WebOrganics| Martin McEvoy]]

=== Inspiration and Acknowledgements ===

Many thanks to [http://tantek.com/log/ Tantek Çelik], [[User:Kevin_Marks|Kevin Marks]], [http://napsterization.org/stories/ Mary Hodder], [[User:ChrisNewell|Chris Newell]], [[User:ChrisMessina | Chris Messina]], [http://changelog.ca/ Charles Iliya Krempeaux] and [http://blog.digitalbazaar.com Manu Sporny] for their valuable contributions to Media Info and Media Metadata in general.

=== Patents ===

{{MicroFormatPatentStatement}}

=== Semantic XHTML Design Principles ===

{{semantic-xhtml-design-principles}}

== Scope ==

Images, Video and Audio regularly share several common fields. hMedia has been based on a minimal common subset based on the analysis of 225 media related web pages. All fields discovered during analysis occur more than 80% of the time or more across each of the target domains listed on the [[media-info-examples|Media Info Examples]] page. hMedia was developed using the [[process|Microformats Process]] and [[principles|Design Principles]].

== Introduction ==

<cite>[http://napsterization.org/stories/ Mary Hodder] - 22 Jan 2006</cite>
<blockquote>There are many ways to publish media by users, but as people try to access those remixing and aggregation become more and more prevalent, having consistent records becomes important. Audio, photos and video show up in each other's publishing spaces, even though they are unique media objects. A photo might be next to the link for an audio piece, as it's visual artwork. A video can be comprised of quotes of other videos, photos and audio. Still photos can be made from videos. All three types of objects can contain subsets of media that is tagged and described.</blockquote>

== Format ==

=== Abstract ===

hMedia is a single media publishing format that relates to Images, Video and Audio with an Emphasis on Practical, Simple, and Minimal. Wherever possible field names have been chosen from those defined by the [[hcard|hCard]] standard.

=== Schema ===

See [[hmedia#Key|key]].

* hMedia '''hmedia'''{1}.
** '''fn'''. {1}.
** ''contributor'' *. Using text or [[hcard]].
** photo ?. Using the HTML IMG element.
** player ?. Using use any appropriate html element such as OBJECT.
** ''enclosure'' *. A <abbr title="Uniform Resource Locator">URL</abbr> using the [[rel-design-pattern]]

{{cheatsheet-key}}

=== Schema Definition ===

{{rfc-2119-intro}}

==== hmedia ====

hMedia is used to describe information associated with Images, Videos and Audio.

====fn====

The name of a media.

* The element is identified by the class name <code>fn</code>.
* hMedia {{must}} include one <code>fn</code> element.

==== contributor ====

A Contributor is any person or organization that takes part in the creation or distribution of the Media

* The element is identified by the class name <code>contributor</code>.
* hMedia {{may}} include one or more contributors.
* The contents of the element {{may}} include a valid [[hcard|hCard]].

==== photo ====

An embedded Image or Photograph of the Media

* The element is identified by the class name <code>photo</code>.
* hMedia {{may}} include one <code>photo</code> element.
* The element {{should}} use an <img> element.
* The <img> element attributes <code>height</code> and <code>width</code> {{may}} be used to determine the dimensions of a <code>photo</code>

==== player ====

The contents are an embedded video or movie of the Media such as a Flash Movie.

* The element is identified by the class name <code>player</code>.
* hMedia {{may}} include one <code>player</code> element.
* The element {{may}} use any appropriate html element such as <object>.
* The <object> element attributes <code>height</code> and <code>width</code> {{may}} be used to determine the dimensions of a <code>player</code>

==== enclosure ====

Indicates that the referred <abbr title="uniform resource locator">url</abbr> is a download of the Media.

* The element is identified by a <abbr title="Uniform Resource Locator">URL</abbr> using the [[rel-design-pattern]], the rel attribute {{should}} contain the value of <code>enclosure</code>..
* hMedia {{may}} include one or more <code>enclosure</code>'s.
* The media type of the enclosure {{should}} be specified by using a <code>type</code> specifier for a <abbr title="uniform resource locator">url</abbr>, the contents {{may}} be any [http://www.iana.org/assignments/media-types/ iana assigned media type] .
* Multiple enclosure elements {{should}} be used for different representations of the same Audio, video or Image.

=== XMDP Profile ===

<pre>
<dl class="profile">
<dt>class</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
HTML4 definition of the 'class' attribute.</a>
This meta data profile defines some 'class' attribute values (class names)
and their meanings as suggested by a
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile">
draft of "Hypertext Links in HTML"</a>.</p>
<dl>
<dt>hmedia</dt>
<dd>
Used to describe semantic information associated with Images, Videos and Audio.
</dd>
<dt>fn</dt>
<dd>
The name of a media
</dd>
<dt>contributor</dt>
<dd>
A Contributor is any person or organization that takes part in the creation or distribution of the Media
</dd>
<dt>photo</dt>
<dd>
An embedded Image or Photograph of the Media.
</dd>
<dt>player</dt>
<dd>
An embedded video or movie of the Media.
</dd>
</dl>
</dd>
<dt>rel</dt>
<dd>
<dl>
<dt>enclosure</dt>
<dd>
Indicates that the referred url is a download of the Media.
</dd>
</dl>
</dd>
</dl>
</pre>

Note (informative). See also an [http://purl.org/microformat/hmedia/ RDF Schema for the hMedia vocabulary].

== Modularity ==

Although media items are sometimes presented on their own they are often found in data structures that are supported by existing microformats. It should therefore be possible to use the hMedia microformat as a child (or in some cases a parent) of these microformats.

=== Media Distribution and Syndication ===

* [[hatom|hAtom]]

Podcast and <abbr title="Video Podcast">Vidcast</abbr> feeds reference a sequence of media items. hMedia can therefore be used as a child element of hAtom.

Please see: [[hmedia#hAtom_and_hMedia|hAtom+hMedia example]].

=== Media Events ===

* [[hcalendar|hCalendar]]

hMedia may used to describe a continuous media stream for example a TV channel. An event or a schedule of events on the channel can be signaled using [[hcalendar#Root_Class_Name|vevent]] as child elements. A combination of hMedia and hCalendar may provide what is necessary to capture a specific event, the media stream information and the timing information.

Please see: [[hmedia#hCalendar_and_hMedia|hCalendar and hMedia]].

=== Media Reviews ===

* [[hreview|hReview]]

A Review about Audio, Video or Images often occurs in media publishing, hMedia reviews can often be published using hReview, capturing the reviewer, the reviewed item, a rating, a description, and the Date of a media review. hMedia may therefore be published as a child element of a [[hreview#Schema|hReview item]]

Please see: [[hmedia#hReview_and_hMedia|hReview and hMedia]].

== Examples ==

Using Real world Examples found on the [[media-info-examples]] page

=== Images ===

<pre>
<div class="hmedia">
<a rel="enclosure" type="image/jpeg" href="http://www.treeswing.net/index.php?showimage=355">
<img class="photo" alt="Saturday Nights alright for fighting, by treeswing"
src="http://cache1.photoblogs.org/thumbnail/?hash=9bece0678c5610bd4b631d9037286df7&size=450"/>
</a>
<span class="fn">Saturday Night's Alright For Fighting</span>,
<em>by <span class="contributor vcard">
<a class="url fn" href="http://www.treeswing.net/">Treeswing</a>
(<a class="url" href="http://www.photoblogs.org/profile/treeswing.net/">profile</a>)
</span></em>
</div>
</pre>

=== Video ===

<pre>
<div class="hmedia">
<span class="fn">Introduction to the Open Media Web</span>
<object class="player" type="application/x-shockwave-flash" data="http://www.viddler.com/player/1d6265f3/">
<param name="movie" value="http://www.viddler.com/player/1d6265f3/"/>
<param name="allowScriptAccess" value="always"/>
<param name="allowFullScreen" value="true"/>
</object>
<ul>
<li><a rel="enclosure" type="video/mp4" title="Download the original source file for this movie"
href="/explore/factoryjoe/videos/2.m4v">Original</a></li>
</ul>
</div>
</pre>

=== Audio ===

<pre>
<span class="hmedia">
<a rel="enclosure" type="audio/mpeg" href="http://homepage.mac.com/mr.gilbert/.Music/earle_waydownhole.mp3">
<span class="contributor vcard">
<span class="fn">Steve Earle</span>
</span> -
<span class="fn">"Way Down in the Hole" (Tom Waits cover)</span>
</a>
</span>
</pre>

=== Combined ===

==== hAtom and hMedia ====
<pre><div id="example" class="hentry hmedia">
<h2 class="entry-title"><a class="fn" href="#example" rel="bookmark">Introduction to the Open Media Web</a></h2>
<p>by <cite class="author vcard"><span class="fn">Author</span></cite> on:
<abbr class="updated" title="2008-12-14T11:08:00+01:00">14th Dec, 2008</abbr></p>
<div class="entry-content"><p>The introductory video describing the Open Media Web project and where it's -- roughly -- going!</p></div>
<object class="player" width="545" height="451" type="application/x-shockwave-flash" data="http://www.viddler.com/player/1d6265f3/">
<param name="movie" value="http://www.viddler.com/player/1d6265f3/"/>
<param name="allowScriptAccess" value="always"/>
<param name="allowFullScreen" value="true"/>
</object>
<p>Download: <a rel="enclosure" type="video/mp4;length=18454938" href="http://www.viddler.com/explore/factoryjoe/videos/2.m4v">
Original</a>
</p>
</div></pre>

==== hCalendar and hMedia ====
<pre><div class="hmedia">
<div id="bip-play-emp">
<object class="player" height="395" width="640"
data="http://www.bbc.co.uk/emp/9player.swf?revision=7276&embedPageUrl=
http://www.bbc.co.uk/iplayer/episode/b00gd1mr/Doctor_Who_The_Next_Doctor/#anchor-info-dialog&domId=bip-play-emp
&config=http://www.bbc.co.uk/emp/iplayer/config.xml
&playlist=http://www.bbc.co.uk/iplayer/playlist/b00gd1mr
&guidance=unset"
name="bbc_emp_embed_bip-play-emp"
id="bbc_emp_embed_bip-play-emp"
type="application/x-shockwave-flash">
<param name="movie" value="http://www.bbc.co.uk/emp/9player.swf?revision=7276&embedPageUrl=
http://www.bbc.co.uk/iplayer/episode/b00gd1mr/Doctor_Who_The_Next_Doctor/#anchor-info-dialog
&domId=bip-play-emp&config=http://www.bbc.co.uk/emp/iplayer/config.xml
&playlist=http://www.bbc.co.uk/iplayer/playlist/b00gd1mr
&guidance=unset"/>
<param name="allowScriptAccess" value="always"/>
<param name="allowFullScreen" value="true"/>
<param name="wmode" value="default"/>
<param name="quality" value="high"/>
</object>
</div>
<div class="vevent">
<span class="summary">
<a class="url fn" href="http://www.bbc.co.uk/iplayer/episode/b00gd1mr/Doctor_Who_The_Next_Doctor">
Doctor Who: The Next Doctor
</a>
</span>,
Broadcast on: <span class="location">BBC One</span>,
<abbr class="dtstart" title="2008-12-25T18:10:00+01:00">6:00pm Thursday 25th December</abbr>,
Duration:
<abbr class="duration" title="PT60M">60</abbr> minutes,
Available until:
<abbr class="dtend" title="2009-01-08T15:49:00+01:00">3:49pm Thursday 8th January</abbr>
</div>
</div></pre>

==== hReview and hMedia ====
<pre><div class="hreview">
Reviewed by: <span class="reviewer vcard">
<span class="fn">anonymous</span>,
</span>
On: <abbr class="dtreviewed" title="2009-01-03">January 3rd, 2009</abbr>.
<div class="item hmedia">
<p><a class="url fn" rel="enclosure" href="http://mediaweb.musicradio.com/mp3/Mis-takes.mp3" type="audio/mpeg">Mis-takes</a>
by: <span class="contributor vcard">
<span class="fn">The Charlatans</span>
</span></p>
</div>
<div>Rating: <abbr class="rating" title="4">****</abbr> out of 5 stars</div>
<div class="description">
<p>This is a great track from The Charlatans latest album You Cross My Path, well worth a listen.</p>
</div>
</div></pre>

==Examples in the wild==
This section is '''informative'''.

The following sites have implemented [[hMedia]], and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc. If your site is marked up with hMedia, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page like [[hmedia-examples-in-wild]].

* [http://www.norfolkblackhistorymonth.org.uk/events/2009/film.html Norfolk Black Film Festival] marks up movie information with hMedia. Example: the movie [http://www.norfolkblackhistorymonth.org.uk/events/2009/blacula.html Blacula].
* [http://rhizohm.net/music/ Rhizohm: some experiments / compositions] - music
* [http://thunderkick.us/index_hMedia.html Thunderkick] - photos
* The [http://weborganics.co.uk/hCast/ Hypermedia Podcast] uses [[hmedia|hMedia]] + [[hatom|hAtom]] to generate a [http://search.yahoo.com/mrss MediaRSS] feed ([[hmedia#hAtom_and_hMedia|as demonstrated above]]) with the Transformr web-service hMedia implementation (documented below)
* An example of [http://weborganics.co.uk/dataset/dataset-article.html hMedia and html 5] using the <code><audio></code> and <code><video></code> tags.
* ...

== Implementations ==
This section is '''informative'''.

The following implementations have been developed which either generate or parse [[hMedia]] content. If you have an hMedia implementation, feel free to add it to the '''top''' of this list. Once the list grows too big, we'll make a separate wiki page like [[hmedia-implementations]].

* [[Oomph]] supports parsing hMedia on pages and displaying a friendly media player interface to easily browse music, movies, and pictures on the page.
* [http://transformr.co.uk Transformr] is a web-service that parses [[hmedia|hMedia]] + [[hatom|hAtom]] and produces [http://search.yahoo.com/mrss MediaRSS]
* ...

== Articles ==
This section is '''informative'''.

The following articles have been written which discuss [[hMedia]]. If you have an hMedia article or blog post, feel free to add it to the '''top''' of this list using [[hAtom]] markup. Once the list grows too big, we'll make a separate wiki page like [[hmedia-articles]].

* 2009-08-11 The [http://visitmix.com/Opinions/I-3-hMedia I <3 hMedia] article by <span class="vcard"><span class="fn">Tim Aidlin</span></span> on Mix Online discusses viewing two examples with hMedia with [[oomph|Oomph]], music on [http://rhizohm.net/music Rhizohm] and photos on [http://thunderkick.us/index_hMedia.html Thunderkick].

== History ==
* Dougal Campbell first talks about [http://microformats.org/discuss/mail/microformats-discuss/2005-July/000229.html microformats for various types of media?] on Jul 13th 2005

* Thu Sep 1st 2005, a discussion about a Playlist Microformat by Lucas Gonze, [http://microformats.org/discuss/mail/microformats-discuss/2005-September/000835.html hPlaylist]

* Tantek Çelik starts Initial exploration about a [http://microformats.org/discuss/mail/microformats-discuss/2005-September/000843.html media-info microformat] on Sep 3rd 2005

* Joshua Kinberg discusses a [http://microformats.org/discuss/mail/microformats-discuss/2005-September/000992.html media/enclosure microformat] on Sep 20th 2005

* On November 2nd 2005 Chris Messina discusses [http://microformats.org/discuss/mail/microformats-discuss/2005-November/001833.html a microformat for audio track metadata].

* On December 6th 2005 Charles Iliya Krempeaux discusses a [http://microformats.org/discuss/mail/microformats-discuss/2005-December/002292.html TV show microformat].

* On Jan 1st 2006 Tantek Çelik calls for a simple media microformat which describes the 80/20 of information about a particular piece of media and nothing more. see: [http://microformats.org/discuss/mail/microformats-discuss/2006-January/002551.html]

* March 24th 2006 Rod Begbie [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003383.html Proposed a Music microformat].

* Enric discusses a [http://microformats.org/discuss/mail/microformats-discuss/2006-June/004419.html media file example of hAtom] on Jun 13th 2006

* Steve Williams (Digg) discusses [http://microformats.org/discuss/mail/microformats-discuss/2006-August/005139.html Media Metadata, Specifically Video Thumbnails] on Aug 16th 2006

* First [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008626.html hMedia microformat] Propsal by Chris Newell on Feb 8th 2007

* More interest in a [http://microformats.org/discuss/mail/microformats-discuss/2007-February/008848.html music/media-info microformat] by Marian Steinbach on Feb 26th 2007 and later on [http://microformats.org/discuss/mail/microformats-new/2007-March/000028.html Microformats New]

* Martin McEvoy Renews interest in a [http://microformats.org/discuss/mail/microformats-new/2008-November/001861.html Media Microformat] on Nov 9th 2008

* hMedia 0.1 Draft Specification 2009-01-04

== References ==

=== Normative References ===

* [[hcard]]
* [[rel-design-pattern]]
* [[rel-enclosure]]

=== Informative References ===

* [http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.2 HTML4 Image element]
* [http://www.w3.org/TR/REC-html40/struct/objects.html#h-13.3 HTML4 Object element]
* [http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel HTML4 rel Definition]
* [http://www.alistapart.com/articles/byebyeembed/ Article on why you should not use embed] from A List Apart.

== Similar Work ==

* [[media-chapters|Media Chapters]]
* [[haudio|hAudio]]
* [[video-info-examples|Video Info]]
* [[photo-note-examples|Photo Notes]]

== Work in progress ==

=== Brainstorming ===

Do you want to help develop the next version of [[hmedia|hMedia]]? Please add your thoughts and insight on the [[hmedia-brainstorming]] page.

=== Discussions ===

* Please forward questions and ideas to the [http://microformats.org/mailman/listinfo/microformats-new Microformats New] mailing list.

=== Issues ===

Please see: [[hmedia-issues]]

{{Template:hmedia-related-pages}}

[[Category:Draft Specifications]]

hnews

2010-02-24T15:26:33Z

TobyInk: /* XMDP Profile */ fix the profile

<entry-title>hNews 0.1</entry-title>
{{Template:DraftSpecification}}

hNews is a microformat for news content. hNews extends [http://microformats.org/wiki/hatom hAtom], introducing a number of fields that more completely describe a journalistic work. hNews also introduces another data format, [[rel-principles]], a format that describes the journalistic principles upheld by the journalist or news organization that has published the news item. hNews will be one of several open standards.
__TOC__
== Draft Specification ==

;Editor/Author
:[[:User:JonathanMalek|Jonathan Malek]] ([http://www.ap.org Associated Press])

;Contributors
:[[:User:Smyles|Stuart Myles]] ([http://www.ap.org Associated Press])
:[[:User:Martinjemoore|Martin Moore]] ([http://mediastandardstrust.org Media Standards Trust])
:[[:User:MarkNg|Mark Ng]] ([http://mediastandardstrust.org Media Standards Trust])
:[[:User:Tbmartinwiki|Todd B. Martin]] ([http://www.ap.org Associated Press])

=== Copyright ===
Per the public domain release on the authors' user pages ([[:User:JonathanMalek|Jonathan Malek]]) this specification is released into the public domain.

{{MicroFormatPublicDomainContributionStatement}}

=== Patents ===
{{MicroFormatPatentStatement}}

== Introduction ==
hNews is a microformat for identifying semantic information in news stories. It builds on [[hAtom]], while adding a number of fields that more completely define a journalistic work. hNews can be thought of as inheriting from [[hAtom]], since parsers and tools that do not understand the hNews extensions can still parse the [[hAtom]] content. However, those parsers and applications that understand hNews can enable a richer set of semantic actions on news stories.

{{rfc-2119-intro}}

== Semantic XHTML Design Principles ==
{{semantic-xhtml-design-principles}}

== Format ==
=== In General ===
hNews extends hAtom. As the hAtom draft format notes, "Atom provides a lot more functionality than we need for a 'blog post' microformat, so we've taken the minimal number of elements needed." News stories typically introduce more fields (for instance, the publishing organization) than the current 0.1 draft of hAtom, and those fields are very important when reading or evaluating a news story. We focus on those fields that enable the development of semantic actions around news: license, principles, dateline (geo) and source organization.

=== Schema ===
The hNews schema consists of the following:

* hNews ('''<code>hnews</code>''') and '''<code>hentry</code>'''. required. Using [[hAtom]].
** '''<code>source-org</code>'''. required. Using [[hCard]].[*]
** '''<code>dateline</code>'''. optional. Using text or [[hCard]].
** '''<code>geo</code>'''. optional. Using [[geo]].[*]
** '''<code>item-license</code>'''. recommended. Using a [[licensing-brainstorming#item_as_container|brainstorm proposal]].
** '''<code>principles</code>'''. recommended. Using the draft microformat [[principles-brainstorming#rel-principles_specification|rel-principles]].

[*] Some required elements have defaults if missing, see below.

=== Field and Element Details ===

==== hAtom Fields ====

===== Entry =====
* an hNews story {{must}} be encoded as an [[hAtom]] <code>hentry</code>.
* if an hNews story cannot be parsed as an [[hAtom]] <code>hentry</code>, it is invalid hNews.

==== Additional Fields ====

===== Source Organization =====
* a Source Organization element is identified by the class name <code>source-org</code>.
* Source Organization represents the originating organization for the news story.
* a Source Organization {{must}} be encoded in an [[hCard]].
* if the Source Organization is missing
** find the [[algorithm-nearest-in-parent]] element(s) with class name <code>source-org</code> and that is/are a valid [[hCard]]
** otherwise the entry is invalid hNews

===== Dateline =====
* a dateline element is identified by the class name <code>dateline</code>.
* dateline represents the location where the news story was written or filed (see [http://en.wikipedia.org/wiki/Dateline dateline] for more details).
* a dateline element {{may}} be encoded in an [[hCard]].
* a news story {{should}} have a dateline element.
* dateline sometimes also includes the publish date of the news story. In such cases, use the [[datetime-design-pattern]] to encode the date.

===== Geo =====
* a geo element is identified by the class name <code>geo</code>
* geo represents the geographic coordinates of relevant locations in the news story.
* a geo element should be encoded in a [[geo]].
* in those cases where the latitude and longitude represent the dateline, a variant of [[geo]] should be used (see [http://microformats.org/wiki/geo-brainstorming#Geo_improvements Geo Improvements] for an example).

===== License =====
* a license element is identified by the rel value of <code>item-license</code>.
* a license element {{must}} be encoded as described in this [http://microformats.org/wiki/licensing-brainstorming#item_as_container license brainstorm proposal].
* a news story {{should}} include a license element.

===== Principles =====
* a principles element is identified by <code>rel-principles</code>.
* principles represents the statement of principles and ethics used by the news organization that produced the news story.
* a principles element {{must}} be encoded in [[principles-brainstorming#rel-principles_specification|rel-principles]].
* a news story {{should}} include principles.
* principles {{should}} be linked to using the icons http://labs.ap.org/principles-button-blue.png or http://labs.ap.org/principles-book-blue.png.

=== XMDP Profile ===
<pre>
<dl class="profile">

<dt>class</dt>
<dd>
<p><a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
HTML4 definition of the 'class' attribute.</a>
This meta data profile defines some 'class' attribute values (class names)
and their meanings as suggested by a
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile">draft of
"Hypertext Links in HTML"</a>.</p>
<dl>

<dt>hnews</dt>
<dd>Used to describe semantic information associated with news stories.</dd>

<dt>source-org</dt>
<dd>The originating organization for the news story.</dd>

<dt>dateline</dt>
<dd>Represents the location where the news story was filed.</dd>

<dt>geo</dt>
<dd>Represents geographic coordinates of relevant locations in the story.</dd>

</dl>
</dd>

<dt>rel</dt>
<dd>
<dl>

<dt>item-license</dt>
<dd>Represents the license for the story.</dd>

<dt>principles</dt>
<dd>Represents the statement of principles and ethics used by the news organization that produced the news story.</dd>

</dl>
</dd>

</dl>
</pre>

== Examples ==

See [[hnews-examples]].

=== Examples in the wild ===

See [[hnews-examples-in-wild]].

== Implementations ==

== References ==

=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0]
* [[hatom|hAtom]]
* [[hcard|hCard]]
* [http://gmpg.org/xmdp/ XMDP]
* [[rel-tag]]
* [[geo]]
* [[licensing-brainstorming#item_as_container_license|item-license brainstorm]]
* [http://newscredit.org/development/newscredit-specification/rel-principles-specification/ rel-principles]
* [http://www.ietf.org/rfc/rfc2119.txt RFC2119]
* [http://www.ietf.org/rfc/rfc4287.txt RFC4287] (Atom 1.0)

=== Informative References ===
* Other news efforts: see [[news-formats]].

== Work in progress ==
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added.

=== Version 0.1 ===

Version 0.1 was drafted August 2008.

== Further Reading ==
* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

== Related Pages ==
* hnews
* [[news-brainstorming]]: thoughts for improving hNews.
* [[hnews-faq|hNews FAQ]]: if you have any questions about hNews, check here, and if you don't find answers, add your questions!
* [[hnews-issues]]: please add any issues with the specification to the issues page.
* [[news-formats]]: existing news and news management schemas.
* [[news-examples]]: examples of news formats on the web.
** [[hnews-examples]]: examples of how to implement hNews.

[[Category:Draft Specifications]]
[[Category:hNews]]

hnews-issues

2009-10-15T08:06:34Z

TobyInk: xmsp issue

<h1> hNews issues </h1>

These are externally raised issues about [[hnews|hNews]] 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 draft.

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

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

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

See related [[hatom-issues]] and [[hcard-issues]].

== Template ==

{{issues-format}}

__TOC__

== Issues ==
=== Open Issues ===

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-15</span> raised by <span class="fn">[[User:TobyInk|TobyInk]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">XMDP defines 'principles' incorrectly.</strong> The XMDP for hNews defines 'principles' as a class, whereas the rest of the draft refers to it as a link type (i.e. 'rel' value).
</div>
</div>

<div class="hentry">
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-14</span> raised by <span class="fn">[[User:MarkNg|MarkNg]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">adr for dateline</strong>. From [[http://twitter.com/pigsonthewing/status/4831500605 Andy Mabbett on Twitter]] : hNews microformat spec "dateline. optional. Using text or hCard" should read "dateline. optional. Using text, adr or hCard".
** Seems like a useful extra to me, any objections ? [[User:MarkNg|MarkNg]]
** Agreed, makes sense. --[[User:JonathanMalek|JonathanMalek]] 00:57, 15 October 2009 (UTC)
</div>
</div>

=== Closed Issues ===
<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">2009-10-09</span> raised by <span class="fn">Miles De Feyter</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Implementation of item-license as it relates to hNews</strong>. Reading through the item-license brainstorm it seems to indicate that "item-license" would need to be nested within something with the class of "item". So as this relates to hNews is the suggestion to then have an articles containing div have the three class names of "hnews hentry item"?
** At this point, Miles, that is correct (following the [[licensing-brainstorming#item_as_container|licensing-brainstorming]] concept and guidance). I expect we'll see changes around item-license (it's still just brainstorming), but for the time being, the third class name "item" is needed. --[[User:JonathanMalek|JonathanMalek]] 16:25, 12 October 2009 (UTC)
** Added to [[hnews-faq]] --[[User:JonathanMalek|JonathanMalek]] 02:19, 14 October 2009 (UTC)
</div>
</div>
<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">2009-09-28</span> raised by <span class="fn">[[User:MilesD|Miles De Feyter]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Principles as a requirement</strong>. Working for a publishing company that owns and operates a large number of different organizations I'd love to incorporate hNews within our publishing system. The hNews requirement for a principles statement could pose a problem though or at least make rolling out hNews a more involved process then it would be otherwise. The issue is, I would now have to go to each product owner and ask then to provide this principles statement to link to. So my concern is now rather then just making a change to the publishing system to support hNews there is this requirement for some supporting content. And due to the nature of the content I can only assume our legal dep. would need to sign off as well, further complicating the adoption of hNews.
** +1 I agree that the "principles" property (and probably all other others) should be optional. [[User:Tantek|Tantek]] 18:29, 29 September 2009 (UTC)
*** I think it's important to explain why principles is a requirement. hnews is essentially a specialization of hAtom. Its purpose is to distinguish news on the web. Hence the description of source organisation, license and principles. Of these, principles is the only one which consistently distinguishes news on the web from other content (eg. commercial, government). In the future it should be distinguished further by making the principles themselves machine readable (but that is for a later date). Most professional news organisations adhere to a Statement of Principles (e.g. see http://en.wikipedia.org/wiki/Journalism_ethics_and_standards and http://www.journalism.org/resources/ethics_codes). If a site wants to mark up its content but does not want to distinguish it as news, then wouldn't it be easiest to use hAtom? [[User:martinjemoore|Martin Moore]] 9:00, 20 September 2009 (UTC)
*** Having discussed this issue at length outside this brainstorming, we understand some of the concerns of the microformat community regarding 'must', but are still convinced of the criticality of principles to hNews - therefore recommend downgrading from 'must' to 'should'. [[User:martinjemoore|Martin Moore]] 14:00, 7 October 2009 (UTC)
**** Accepted and implemented in 0.1. In keeping with the general direction here, we've changed <code>item-license</code> as well, and would consider adopting the same with <code>source-org</code> as well, if it proves to present the same problems. --[[User:JonathanMalek|JonathanMalek]] 00:53, 15 October 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">18:32, 24 August 2009 (UTC)</span> raised by <span class="fn">[[User:Kevin Marks|Kevin Marks]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">hCalendar instead of dateline?</strong> Would an [[hCalendar]] event (which can contain an hCard location) make sense for a dateline, or is the 'date' part more often omitted?
** Confusingly, the journalistic term "dateline" isn't anything to do with a date or time. It is the location from which a report is filed and is generally the main location associated with a story. Generally, a dateline consists of a city (e.g. "Rome") but could be the name of a ship at sea or even a space station. [[User:Stuart Myles|Stuart Myles]] 21:12, 24 August 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">18:32, 24 August 2009 (UTC)</span> raised by <span class="fn">[[User:Kevin Marks|Kevin Marks]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">hCard instead of geo?</strong> Is geo really in use here, or would using an hCard (that can contain geo) be a better way of representing locations referred to in the story, as more human readable?
** The reason for geo being highlighted (as an optional field) is to promote at least one location identifier in the story--preferably the most appropriate single location on a map for that particular story. Geo does not have to be related to dateline, but in some [http://labs.ap.org/wiki/hNews examples] we've worked on, we show the two collapsed into a single field. --[[User:JonathanMalek|JonathanMalek]] 23:53, 24 August 2009 (UTC)
** For locations referred to in the story, I agree--publishers should be using [[hCard]] with the contained geo to markup the locations themselves. One of the concepts I've struggled with is drawing an admittedly arbitrary line between the metadata ''about'' a story from the metadata ''within'' a story. For the former, we've focused on simplicity and minimalism, primarily as a means to encourage adoption. That has meant preferring [[rel-tag]] over in-line entity extraction and markup using compound microformats. For the latter, we feel that the field is open: use whatever microformat fits your purpose, however you can--the more, the better. This lets publishers with minimal technology capabilities at least get started by tweaking a few templates in their CMS, while those more technically inclined aren't limited by the simplicity of the format to a paucity of data. --[[User:JonathanMalek|JonathanMalek]] 23:53, 24 August 2009 (UTC)
** Also, dateline can be text or [[hCard]], as noted in the [[news-brainstorming#Common_News_Fields|Common News Fields]] section. --[[User:JonathanMalek|JonathanMalek]] 18:17, 24 September 2009 (UTC)
</div>
</div>

<div class="hentry">
{{ClosedIssue}} <span class="entry-summary author vcard"><span class="published">18:32, 24 August 2009 (UTC)</span> raised by <span class="fn">[[User:Kevin Marks|Kevin Marks]]</span></span>
<div class="entry-content discussion issues">
* <strong class="entry-title">What is item-license?</strong> Using [[rel-license]] presumably?
** We're working off the [[licensing-brainstorming#item_as_container|licensing-brainstorming]] discussions for this. Our concern with [[rel-license]] was its definition as applying to an entire page, rather than an item within a page. The current discussions around licensing definitely address that. --[[User:JonathanMalek|JonathanMalek]] 00:02, 25 August 2009 (UTC)
*** +1 using item-license for news-brainstorming makes sense. [[User:Tantek|Tantek]] 22:32, 27 August 2009 (UTC)
</div>
</div>

hatom-issues

2009-07-21T11:39:25Z

TobyInk: /* marking up comments */ separate spec for replies

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

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

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

== closed issues ==
See: [[hatom-issues-closed]]

== resolved issues ==
See: [[hatom-issues-resolved]]

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

===2009===
==== too many required hentry properties ====
* {{OpenIssue}} 2009-05-26 raised by [[User:Tantek|Tantek]]
*# hAtom 0.1 requires numerous properties for an hentry (often based directly on required elements from the Atom standard). Given the broad variety of situations that hAtom is used in content, many (or even most) of these properties are not already specified in such content, and thus it is poor methodology to require them because there is a good chance (experience has shown) either (a) the content author will ignore the requirement, or (b) will make something up to satisfy the requirement. A few similar/overlapping/sub-issues are noted below (e.g. [[#Author|author is required]], and not always available).
*#* Proposed resolution. Make nearly all hentry properties "optional" in hAtom 0.2. Consider keeping at most only one required property, perhaps "updated" - that is, if there is no date of update/publication in the content you are trying to mark up, then perhaps it doesn't make sense to mark up that content with hAtom, since hAtom is for episodic, time-based/stamped content.
*#** consider pattern abstraction: all microformats should minimize "required" properties for the same reason, and perhaps ''only'' require at most a single property which is indicative of what that microformat is for, that is, if the author does not publish that one required property, then perhaps they should not be using the microformat that requires that one property.
*#* I have the same problem. I'm collecting various feeds to analyse them. The sources are often RSS 0.9, but I want to put the results into an Atom feed. --[[User:Simon Brodtmann|Simon Brodtmann]] 00:51, 1 July 2009 (UTC)
*#** entry:author should be optional and could be either a hCard or a string
*#** entry lacks a [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.category category] and it shuld either use rel-tag or just be a string
* 2009-07-18 [[User:DavidJanes]] I would like to break this into a separate issue for each currently required element, as we're likely to have to define defaulting rules
* 2009-07-21 [[User:TobyInk|TobyInk]]: Why not have three levels of property: ''required'', ''recommended'' and ''optional''. There would be as few as possible ''required'' properties. Any properties which are needed to create a conformant application/atom+xml feed would be ''recommended''. Everything else would be ''optional''.

==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** +1 [[User:WebOrganics|Martin McEvoy]] but not recommended.
*** ... your vote here ...
** if this element is not in the [[hatom#In_General|physical model]], the logical model value should be
*** the empty string
**** +1 [[User:DavidJanes]]
**** -1 [[User:WebOrganics|Martin McEvoy]]
*** the value should not be blank.
**** +1 [[User:WebOrganics|Martin McEvoy]] see: [http://www.atomenabled.org/developers/syndication/#requiredEntryElements Required Entry Elements] from Atom Enabled.
**** [[User:DavidJanes]] what should it be then, if physically representing it is optional? Since Atom makes this a SHOULD and not a MUST (I'm not shouting, just following RFC convention), and we're assuming there's a good reason for the entry-title not to be present in the first place, why not an empty string?
***** [[User:WebOrganics|Martin McEvoy]] entry:title is a required attribute of atom at both feed and entry level, in both instances it says "Contains a human readable title" (a requirement) an empty string is not anything human readable (personal oppinion), maybe hAtom 0.2 should only recommend that the value of entry-title "should" not be an empty string.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== updated optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]] ... the demand for optionality of the issue is high (cf the microsoft web clips) and if it remains required we're just going to reinvent hAtom without this element
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]] for the same reason 'updated' should be optional: we'll just reinvent hAtom slightly differently otherwise
*** ... your vote here ...
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** "anonymous" (somewhat like [[hreview]]), except not explicit
**** +0.5 [[User:DavidJanes]]
*** make this implementation defined
*** something constructed from the page's URL & other information
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

=== 2008 ===
==== add url property to hentry ====
* {{OpenIssue}} 2008-09-10 raised by [[User:Tantek|Tantek]]
*# hAtom 0.1 uses [[rel-bookmark]] for permalinks. Permalinks may not always be hyperlinks or hyperlinkable. Thus I propose we re-use the <code>url</code> property (from [[hCard]], [[hCalendar]], [[hReview]], etc.) as a sub-property of the <code>hentry</code> property/container/root.
*#* Proposed resolution. Add "url" sub-property to "hentry" in hAtom 0.2.
*# {{ToDo}} can anyone provide examples where this would be used? [[User:DavidJanes]]

==== misuse of address element ====
* {{OpenIssue}} 2008-06-07 raised by [[User:Tantek|Tantek]]
*# hAtom 0.1 says "an Entry Author element SHOULD be encoded in an <code><address></code> element" and "find the Nearest In Parent <code><address></code> element(s) with class name author and that is/are a valid hCard" - this is a misuse of the address element. The address element means the ''contact'' for the page or major portion thereof (see [[hcard-faq#Should_I_use_ADDRESS_for_hCards|hCard FAQ: Should I use ADDRESS for hCards]]), which ''may'' also be the ''author'' but is not necessarily. See [[hcards-and-pages]] for more details on this semantic distinction.
*#* Proposed resolution: Eliminate all requirements and recommended use of the <code><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

=== 2007 ===
==== marking up comments ====
* {{OpenIssue}} 2007-11-25 raised by [http://www.wirewd.com/ Ken Wronkiewicz].
*# There's no currently defined way to exactly handle threaded discussions. I think this is quite useful to have.
*#* The prior art is RFC [http://tools.ietf.org/html/rfc4685 4864]. The microformat solution should map fairly cleanly to this.
* include in hAtom 0.2
** -1 [[User:DavidJanes]] I think hAtom Comments should be a separate spec
*** +1 to David's -1. [[User:TobyInk|TobyInk]] They're in a separate RFC, so should be separate to hAtom too. That said, it would be nice if hAtom had a clear, documented mechanism for creating extensions.
** +1 [[User:Singpolyma|Singpolyma]] Comments are the important "next step" for hAtom. The proposal I've seen that I most liked was embedding an hfeed in an hentry.
*** [[User:DavidJanes]] would you look to explicitly write out that proposal here (or in a new section); this is my preferred solution too, but there's another proposal on the table for doing this too

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''[[rel-tag#Tag_Spaces|rel-tag tagspaces]] should map to atom:category schemes''
*#* hAtom already defines how to map term and label. It seems that the tagspace can easily map to scheme
*# {{ToDo}} can we get a real-world example mapping of this? [[User:DavidJanes]]

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element
** +1 [[User:DavidJanes]] - this is just making explicit a particular composition. is it not? Also: if there's a geo in a hfeed (outside of hentry), should it be considered to apply to all entries?
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== Relationship of rel-bookmark to url+uid ====
The concept of permalink is available in hCard and hCalendar as the classes url and uid. This combination matches the permalink semantics by indicating that the url should be derefenced to find a more dynamic or up-to-date version of the content, and that that url is a stable unique id that can be used to identify the content.

hAtom 0.1 uses rel-bookmark for the permalink concept. The current state of [[uid-brainstorming]] indicates that the [[hCard]] and [[hCalendar]] permalink concept is likely to be used in subsequent microformats. It may be important to reconcile hAtom with that trajectory. Possible reconcilliations include:

1) To leave things as they are. The two permalink concepts are to be kept separate.

2) Treat the two concepts as equivalent. Allow both in hAtom, and consider allowing both in other formats. eg <a rel="bookmark" href="http://example.com/"> would fill out uid and url values if they are not supplied explicitly.

3) Choose one over the other for hAtom and perhaps for future microformats also. "url uid" allows for some greater freedom (uid can be pointed at a non-url uid), but it is unclear at this stage whether that freedom is warranted or advisable to permit.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)
** -1 [[User:Singpolyma|Singpolyma]]

==== Datetime format (atom:<i>updated</i> and atom:<i>published</i>) ====
* 2006-05-23 raised by [[User:RobertBachmann|Robert Bachmann]]
** Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.
*** ACCEPTED FAQ - hAtom references datetime-design-pattern, which discusses which date format to use
** 2009-07-20 [[User:DavidJanes]] {{ToDo}} is this moot? can we move this to resolved?

==== Feed <i>id</i> (atom:<i>id</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# atom:<i>id</i> is required for atom:feed. Thus it should be available in hAtom to.

It is suggested the Feed permalink should be used as the feed ID, however a piece by Mark Pilgrim (http://diveintomark.org/archives/2004/05/28/howto-atom-id) makes arguments against using permalinks and in favour of Tag URIs.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed <i>permalink</i> (atom:<i>permalink</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>
** I'm proposing the following rules:
**# a Feed Permalink element is identified by [[rel-bookmark]] at the feed level (inside a Feed element but not inside an Entry element)
**# a Feed <del>SHOULD</del><ins>MAY</ins> have a Feed Permalink
**# a Feed Permalink element represents the concept of an Atom link in a feed.
**# if the Feed Permalink is missing, use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI
** 2006-04-03 [[User:ChrisCasciano|ChrisCasciano]] - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.
** 2006-04-03 [[User:RobertBachmann|Robert Bachmann]]: I've replaced "SHOULD" with "MAY".
** 2006-04-24 [[User:RobertBachmann|Robert Bachmann]]: Maybe we could simplify my proposal to:
*** "''Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI''"
*** IMO this would be good enough for at least 80% of the cases.
** 2006-04-12 [[User:DavidJanes]]: {{ToDo}} can we find an example of this in the wild and if so we should add it to the -examples page.
** [[User:Singpolyma|singpolyma]] 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't [[rel-home]] make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed <i>updated</i> (atom:<i>updated</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>updated</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# The Feed Updated element is identified by the class name <code>updated</code> at the feed level (inside a Feed element but not inside an Entry element)
**# If no element with the class name <code>updated</code> is present, use the youngest <code>updated</code> from the feed's entries.
** 2006-04-12 [[User:DavidJanes]] I like this. And the definition of "feed level"
** 2007-06-20 [[User:MikeKaply]] The "youngest" thing is a really bad idea. If a page has 100 hAtom entries, a parser would have to go through all 100 looking for a low date. That's crazy.
*** 2008-03-20 [[User:TobyInk]] Not crazy at all. I've just implemented an hAtom to Atom converter and I do precisely this. Most (useful) hAtom parsers will "go through all 100 entries" anyway, won't they? So why not look for the youngest updated date as part of that loop. The only slight annoyance is that in RFC 4287, the <atom:updated> element must occur before the first <atom:entry> element -- this is easily solved by inserting a placeholder <atom:updated> element, looping through the entries and then going back and filling in the date. This is really, really, '''not''' a difficult thing to implement.

* include in hAtom 0.2
** +0.5 [[User:DavidJanes]]

==== Feed <i>title</i> (atom:<i>title</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>title</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# a Feed Title element is identified by the class name <code><del>entry</del><ins>feed</ins>-title</code>
**# a Feed SHOULD have an Feed Title
**# a Feed Title element represents the concept of an Atom feed title
**# if the Feed Title is missing, use
**#* <del>the first <code><h#></code> element in the Feed, or</del>
**#* the <code><title></code> of the page, or
**#* assume it is the empty string
** 2006-04-01 [[User:ChrisCasciano|ChrisCasciano]] - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using <code><title></code> before h# would be prefered if not the most common desire of the page author.
** 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><h#></code> to encode the date for a group of postings
** 2006-04-12 [[User:DavidJanes]]: why <code>entry-title</code> for the feed title. Why not <code>fn</code> or <code>feed-title</code>?
** 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.
** 2007-02-26 [[User:MikeKaply|Mike Kaply]]: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.

==== Feed <i>author</i> and Entry author (atom:<i>author</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules for Feed author:
**# a Feed Author element is represented by class name <code>author</code> at the feed level (inside a Feed element but not inside an Entry element)
**# a Feed Author element represents the concept of a Atom author
**# a Feed Author element MUST be encoded in a [[hcard|hCard]]
**# a Feed Author element SHOULD be encoded in a <code><address></code> element
**# a Feed MAY have more than one Feed Author elements
**# if the Feed Author is missing
**#* find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
**#* otherwise <del>the Feed is invalid hAtom</del> <ins>there is no Feed Author</ins>
** I'm proposing the following rules for entry author:
**# an Entry Author element is represented by class name <code>author</code>
**# an Entry Author element represents the concept of an Atom author
**# an Entry Author element MUST be encoded in an [[hcard|hCard]]
**# an Entry Author element SHOULD be encoded in an <code><address></code> element
**#<del> If a Feed has no Feed author each Entry MUST have at least one Entry Author element</del>
**# <ins>If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
**#* find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
**#* otherwise the Entry is invalid hAtom</ins>
**# an Entry MAY have more than one Entry Author elements
** [[User:Singpolyma|singpolyma]] 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author. Also, one or more entries may be missing an author IF feed-level has an author.
** 2006-04-17 [[User:RobertBachmann|Robert Bachmann]]: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

==== Entry <i>id</i> (atom:<i>id</i>) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>id</i> is required for atom:entry. Thus it should be available in hAtom to. The Entry permalink should be used as the entry id.
** --[[User:Federico|Federico]] 19:52, 25 Apr 2006 (PDT): I would add "Only if the id attribute is not defined for the element that contains the entry". The id attribute can be a tag uri. If you use always use the Entry permalink as the entry id and the Atom feed uses tag uris, you would end with two different ids for the same entry.
** 2006-12-31 response by [[User:ComputerKid|Emanla Eraton]] No, it shouldn't be a permalink. It should be a "tag:" id for entries.
** 2007-06-06 [[RyanKing]] - the syntax of tag URIs and html id attributes are incompatible. HTML disallows forward-slash (/) in ids [http://www.w3.org/TR/html401/types.html#type-name], while tag URIs require them [http://www.faqs.org/rfcs/rfc4151.html].

==== Author ====
===== author as an hcard is too much to require =====
The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]

* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a <div class="author"> element.
** [[Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"
** [[User:Fil|Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.

* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"
** [[Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec
***[[User:Phae|Frances]] - Just thought I'd mention a scenario I have where the author of an entry does make a pretty useless vCard - the author in each case is an entire team ("creative team", "technical department") etc., rather than a specific, identifiable, person. Some use may be regained when URL to specific team/information is included, in this circumstance.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki><span class="author"><span class="vcard"><span class="fn">My Name</span></span></span></nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki><span class="author vcard"><span class="fn">My Name</span></span></nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry <i>source</i> (atom:<i>source</i>) ====
* raised by [[User:Kevin Marks|Kevin Marks]]
** When defining hAtom 0.1, atom:source was omitted. We should consider adding this back in as a useful element for providing citations of composite feeds.
*** 2009-07-20 [[User:DavidJanes]] {{ToDo}} we need an example of how this would look in the real world

== Other Questions and Issues ==
General comments, modeling issues, algorithm issues, should have issues, etc. go here.

=== Entry Updated Required? -- Blogger Issue ===
moved to [[hatom-brainstorming]]

=== 'MAY have multiple Feed elements' -- details and viability of multiple feeds ===
moved to [[hatom-brainstorming]]

== pre 0.1 issues ==
'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''

See: [[hatom-issues-pre-0.1]]

== Template ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-21T11:22:56Z

TobyInk: /* too many required hentry properties */ Add a "recommended property" concept. Not quite required.

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

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

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

== closed issues ==
See: [[hatom-issues-closed]]

== resolved issues ==
See: [[hatom-issues-resolved]]

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

===2009===
==== too many required hentry properties ====
* {{OpenIssue}} 2009-05-26 raised by [[User:Tantek|Tantek]]
*# hAtom 0.1 requires numerous properties for an hentry (often based directly on required elements from the Atom standard). Given the broad variety of situations that hAtom is used in content, many (or even most) of these properties are not already specified in such content, and thus it is poor methodology to require them because there is a good chance (experience has shown) either (a) the content author will ignore the requirement, or (b) will make something up to satisfy the requirement. A few similar/overlapping/sub-issues are noted below (e.g. [[#Author|author is required]], and not always available).
*#* Proposed resolution. Make nearly all hentry properties "optional" in hAtom 0.2. Consider keeping at most only one required property, perhaps "updated" - that is, if there is no date of update/publication in the content you are trying to mark up, then perhaps it doesn't make sense to mark up that content with hAtom, since hAtom is for episodic, time-based/stamped content.
*#** consider pattern abstraction: all microformats should minimize "required" properties for the same reason, and perhaps ''only'' require at most a single property which is indicative of what that microformat is for, that is, if the author does not publish that one required property, then perhaps they should not be using the microformat that requires that one property.
*#* I have the same problem. I'm collecting various feeds to analyse them. The sources are often RSS 0.9, but I want to put the results into an Atom feed. --[[User:Simon Brodtmann|Simon Brodtmann]] 00:51, 1 July 2009 (UTC)
*#** entry:author should be optional and could be either a hCard or a string
*#** entry lacks a [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.category category] and it shuld either use rel-tag or just be a string
* 2009-07-18 [[User:DavidJanes]] I would like to break this into a separate issue for each currently required element, as we're likely to have to define defaulting rules
* 2009-07-21 [[User:TobyInk|TobyInk]]: Why not have three levels of property: ''required'', ''recommended'' and ''optional''. There would be as few as possible ''required'' properties. Any properties which are needed to create a conformant application/atom+xml feed would be ''recommended''. Everything else would be ''optional''.

==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** +1 [[User:WebOrganics|Martin McEvoy]] but not recommended.
*** ... your vote here ...
** if this element is not in the [[hatom#In_General|physical model]], the logical model value should be
*** the empty string
**** +1 [[User:DavidJanes]]
**** -1 [[User:WebOrganics|Martin McEvoy]]
*** the value should not be blank.
**** +1 [[User:WebOrganics|Martin McEvoy]] see: [http://www.atomenabled.org/developers/syndication/#requiredEntryElements Required Entry Elements] from Atom Enabled.
**** [[User:DavidJanes]] what should it be then, if physically representing it is optional? Since Atom makes this a SHOULD and not a MUST (I'm not shouting, just following RFC convention), and we're assuming there's a good reason for the entry-title not to be present in the first place, why not an empty string?
***** [[User:WebOrganics|Martin McEvoy]] entry:title is a required attribute of atom at both feed and entry level, in both instances it says "Contains a human readable title" (a requirement) an empty string is not anything human readable (personal oppinion), maybe hAtom 0.2 should only recommend that the value of entry-title "should" not be an empty string.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== updated optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]] ... the demand for optionality of the issue is high (cf the microsoft web clips) and if it remains required we're just going to reinvent hAtom without this element
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]] for the same reason 'updated' should be optional: we'll just reinvent hAtom slightly differently otherwise
*** ... your vote here ...
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** "anonymous" (somewhat like [[hreview]]), except not explicit
**** +0.5 [[User:DavidJanes]]
*** make this implementation defined
*** something constructed from the page's URL & other information
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

=== 2008 ===
==== add url property to hentry ====
* {{OpenIssue}} 2008-09-10 raised by [[User:Tantek|Tantek]]
*# hAtom 0.1 uses [[rel-bookmark]] for permalinks. Permalinks may not always be hyperlinks or hyperlinkable. Thus I propose we re-use the <code>url</code> property (from [[hCard]], [[hCalendar]], [[hReview]], etc.) as a sub-property of the <code>hentry</code> property/container/root.
*#* Proposed resolution. Add "url" sub-property to "hentry" in hAtom 0.2.
*# {{ToDo}} can anyone provide examples where this would be used? [[User:DavidJanes]]

==== misuse of address element ====
* {{OpenIssue}} 2008-06-07 raised by [[User:Tantek|Tantek]]
*# hAtom 0.1 says "an Entry Author element SHOULD be encoded in an <code><address></code> element" and "find the Nearest In Parent <code><address></code> element(s) with class name author and that is/are a valid hCard" - this is a misuse of the address element. The address element means the ''contact'' for the page or major portion thereof (see [[hcard-faq#Should_I_use_ADDRESS_for_hCards|hCard FAQ: Should I use ADDRESS for hCards]]), which ''may'' also be the ''author'' but is not necessarily. See [[hcards-and-pages]] for more details on this semantic distinction.
*#* Proposed resolution: Eliminate all requirements and recommended use of the <code><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

=== 2007 ===
==== marking up comments ====
* {{OpenIssue}} 2007-11-25 raised by [http://www.wirewd.com/ Ken Wronkiewicz].
*# There's no currently defined way to exactly handle threaded discussions. I think this is quite useful to have.
*#* The prior art is RFC [http://tools.ietf.org/html/rfc4685 4864]. The microformat solution should map fairly cleanly to this.
* include in hAtom 0.2
** -1 [[User:DavidJanes]] I think hAtom Comments should be a separate spec
** +1 [[User:Singpolyma|Singpolyma]] Comments are the important "next step" for hAtom. The proposal I've seen that I most liked was embedding an hfeed in an hentry.
*** [[User:DavidJanes]] would you look to explicitly write out that proposal here (or in a new section); this is my preferred solution too, but there's another proposal on the table for doing this too

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''[[rel-tag#Tag_Spaces|rel-tag tagspaces]] should map to atom:category schemes''
*#* hAtom already defines how to map term and label. It seems that the tagspace can easily map to scheme
*# {{ToDo}} can we get a real-world example mapping of this? [[User:DavidJanes]]

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element
** +1 [[User:DavidJanes]] - this is just making explicit a particular composition. is it not? Also: if there's a geo in a hfeed (outside of hentry), should it be considered to apply to all entries?
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== Relationship of rel-bookmark to url+uid ====
The concept of permalink is available in hCard and hCalendar as the classes url and uid. This combination matches the permalink semantics by indicating that the url should be derefenced to find a more dynamic or up-to-date version of the content, and that that url is a stable unique id that can be used to identify the content.

hAtom 0.1 uses rel-bookmark for the permalink concept. The current state of [[uid-brainstorming]] indicates that the [[hCard]] and [[hCalendar]] permalink concept is likely to be used in subsequent microformats. It may be important to reconcile hAtom with that trajectory. Possible reconcilliations include:

1) To leave things as they are. The two permalink concepts are to be kept separate.

2) Treat the two concepts as equivalent. Allow both in hAtom, and consider allowing both in other formats. eg <a rel="bookmark" href="http://example.com/"> would fill out uid and url values if they are not supplied explicitly.

3) Choose one over the other for hAtom and perhaps for future microformats also. "url uid" allows for some greater freedom (uid can be pointed at a non-url uid), but it is unclear at this stage whether that freedom is warranted or advisable to permit.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)
** -1 [[User:Singpolyma|Singpolyma]]

==== Datetime format (atom:<i>updated</i> and atom:<i>published</i>) ====
* 2006-05-23 raised by [[User:RobertBachmann|Robert Bachmann]]
** Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.
*** ACCEPTED FAQ - hAtom references datetime-design-pattern, which discusses which date format to use
** 2009-07-20 [[User:DavidJanes]] {{ToDo}} is this moot? can we move this to resolved?

==== Feed <i>id</i> (atom:<i>id</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# atom:<i>id</i> is required for atom:feed. Thus it should be available in hAtom to.

It is suggested the Feed permalink should be used as the feed ID, however a piece by Mark Pilgrim (http://diveintomark.org/archives/2004/05/28/howto-atom-id) makes arguments against using permalinks and in favour of Tag URIs.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed <i>permalink</i> (atom:<i>permalink</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>
** I'm proposing the following rules:
**# a Feed Permalink element is identified by [[rel-bookmark]] at the feed level (inside a Feed element but not inside an Entry element)
**# a Feed <del>SHOULD</del><ins>MAY</ins> have a Feed Permalink
**# a Feed Permalink element represents the concept of an Atom link in a feed.
**# if the Feed Permalink is missing, use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI
** 2006-04-03 [[User:ChrisCasciano|ChrisCasciano]] - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.
** 2006-04-03 [[User:RobertBachmann|Robert Bachmann]]: I've replaced "SHOULD" with "MAY".
** 2006-04-24 [[User:RobertBachmann|Robert Bachmann]]: Maybe we could simplify my proposal to:
*** "''Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI''"
*** IMO this would be good enough for at least 80% of the cases.
** 2006-04-12 [[User:DavidJanes]]: {{ToDo}} can we find an example of this in the wild and if so we should add it to the -examples page.
** [[User:Singpolyma|singpolyma]] 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't [[rel-home]] make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed <i>updated</i> (atom:<i>updated</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>updated</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# The Feed Updated element is identified by the class name <code>updated</code> at the feed level (inside a Feed element but not inside an Entry element)
**# If no element with the class name <code>updated</code> is present, use the youngest <code>updated</code> from the feed's entries.
** 2006-04-12 [[User:DavidJanes]] I like this. And the definition of "feed level"
** 2007-06-20 [[User:MikeKaply]] The "youngest" thing is a really bad idea. If a page has 100 hAtom entries, a parser would have to go through all 100 looking for a low date. That's crazy.
*** 2008-03-20 [[User:TobyInk]] Not crazy at all. I've just implemented an hAtom to Atom converter and I do precisely this. Most (useful) hAtom parsers will "go through all 100 entries" anyway, won't they? So why not look for the youngest updated date as part of that loop. The only slight annoyance is that in RFC 4287, the <atom:updated> element must occur before the first <atom:entry> element -- this is easily solved by inserting a placeholder <atom:updated> element, looping through the entries and then going back and filling in the date. This is really, really, '''not''' a difficult thing to implement.

* include in hAtom 0.2
** +0.5 [[User:DavidJanes]]

==== Feed <i>title</i> (atom:<i>title</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>title</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# a Feed Title element is identified by the class name <code><del>entry</del><ins>feed</ins>-title</code>
**# a Feed SHOULD have an Feed Title
**# a Feed Title element represents the concept of an Atom feed title
**# if the Feed Title is missing, use
**#* <del>the first <code><h#></code> element in the Feed, or</del>
**#* the <code><title></code> of the page, or
**#* assume it is the empty string
** 2006-04-01 [[User:ChrisCasciano|ChrisCasciano]] - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using <code><title></code> before h# would be prefered if not the most common desire of the page author.
** 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><h#></code> to encode the date for a group of postings
** 2006-04-12 [[User:DavidJanes]]: why <code>entry-title</code> for the feed title. Why not <code>fn</code> or <code>feed-title</code>?
** 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.
** 2007-02-26 [[User:MikeKaply|Mike Kaply]]: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.

==== Feed <i>author</i> and Entry author (atom:<i>author</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules for Feed author:
**# a Feed Author element is represented by class name <code>author</code> at the feed level (inside a Feed element but not inside an Entry element)
**# a Feed Author element represents the concept of a Atom author
**# a Feed Author element MUST be encoded in a [[hcard|hCard]]
**# a Feed Author element SHOULD be encoded in a <code><address></code> element
**# a Feed MAY have more than one Feed Author elements
**# if the Feed Author is missing
**#* find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
**#* otherwise <del>the Feed is invalid hAtom</del> <ins>there is no Feed Author</ins>
** I'm proposing the following rules for entry author:
**# an Entry Author element is represented by class name <code>author</code>
**# an Entry Author element represents the concept of an Atom author
**# an Entry Author element MUST be encoded in an [[hcard|hCard]]
**# an Entry Author element SHOULD be encoded in an <code><address></code> element
**#<del> If a Feed has no Feed author each Entry MUST have at least one Entry Author element</del>
**# <ins>If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
**#* find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
**#* otherwise the Entry is invalid hAtom</ins>
**# an Entry MAY have more than one Entry Author elements
** [[User:Singpolyma|singpolyma]] 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author. Also, one or more entries may be missing an author IF feed-level has an author.
** 2006-04-17 [[User:RobertBachmann|Robert Bachmann]]: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

==== Entry <i>id</i> (atom:<i>id</i>) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>id</i> is required for atom:entry. Thus it should be available in hAtom to. The Entry permalink should be used as the entry id.
** --[[User:Federico|Federico]] 19:52, 25 Apr 2006 (PDT): I would add "Only if the id attribute is not defined for the element that contains the entry". The id attribute can be a tag uri. If you use always use the Entry permalink as the entry id and the Atom feed uses tag uris, you would end with two different ids for the same entry.
** 2006-12-31 response by [[User:ComputerKid|Emanla Eraton]] No, it shouldn't be a permalink. It should be a "tag:" id for entries.
** 2007-06-06 [[RyanKing]] - the syntax of tag URIs and html id attributes are incompatible. HTML disallows forward-slash (/) in ids [http://www.w3.org/TR/html401/types.html#type-name], while tag URIs require them [http://www.faqs.org/rfcs/rfc4151.html].

==== Author ====
===== author as an hcard is too much to require =====
The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]

* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a <div class="author"> element.
** [[Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"
** [[User:Fil|Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.

* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"
** [[Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec
***[[User:Phae|Frances]] - Just thought I'd mention a scenario I have where the author of an entry does make a pretty useless vCard - the author in each case is an entire team ("creative team", "technical department") etc., rather than a specific, identifiable, person. Some use may be regained when URL to specific team/information is included, in this circumstance.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki><span class="author"><span class="vcard"><span class="fn">My Name</span></span></span></nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki><span class="author vcard"><span class="fn">My Name</span></span></nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry <i>source</i> (atom:<i>source</i>) ====
* raised by [[User:Kevin Marks|Kevin Marks]]
** When defining hAtom 0.1, atom:source was omitted. We should consider adding this back in as a useful element for providing citations of composite feeds.
*** 2009-07-20 [[User:DavidJanes]] {{ToDo}} we need an example of how this would look in the real world

== Other Questions and Issues ==
General comments, modeling issues, algorithm issues, should have issues, etc. go here.

=== Entry Updated Required? -- Blogger Issue ===
moved to [[hatom-brainstorming]]

=== 'MAY have multiple Feed elements' -- details and viability of multiple feeds ===
moved to [[hatom-brainstorming]]

== pre 0.1 issues ==
'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''

See: [[hatom-issues-pre-0.1]]

== Template ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

picoformats

2009-06-04T08:52:28Z

TobyInk: add non-service-specific syntaxes

<entry-title>picoformats</entry-title>

== Introduction ==
Picoformats represent an effort being undertaken led by Chris Messina to codify various standards and openly pursue a nomenclature and syntax for communicating and executing commands with mobile devices over SMS or via command line interfaces (CLI).

An example application is [http://dodgeball.com Dodgeball's] use of the at symbol (@) to express checking in to a place.

Using the Microformats process and principles of building block design, our goal is to openly develop a complete syntax for interacting with various mobile services using the characters available on most mobile devices.

== Problem Statement ==
* send messages to user mobiles - via SMS, or a small application, that contains information like appointment times, locations,
directions, and contact info. For example, when2where.com reminds users when they need to leave to get to their appointment, so the
message may be like:

leave @ 4:35PM ~Dentist Office -> Detroit, MI

where the text itself is simple and readable, but there *may* be an small utility that would parse the @ symbol to add the event to the calendar, the ~ to allow the person to quickly call that contact, or the -> to pull up a Map/directions to the location

* allow users to write messages to query an application - this is similar to what Mozes has started with notes:

when2where: ?today --- what appointments to I have today
new @ 4PM ~Olive Garden -> Novi --- add an appointment

In addition to the obvious mobile device arena, picoformats may be usable in any context where "markup" is too heavy. For example, an IRC bot, whereisbot, that announces user locations as they sign into a channel, or allows people to do:

.whereami, or .whereis <nick> to geolocate other people in a channel.

The intention is to 'markup' the information, but putting actual XHTML or XML is annoying, since IRC doesn't parse the information at all. So right now the response is:

ajturner: .whereami
whereisbot: ajturner is in Northville, MI, US [42.4365 x -83.4884]

So then someone could write a Picoformat parser for X-Chat/Colloquy/other that would parse the [ #### x #### ] and provide a Map url link.

Using arrows to denote time and place, familiar from video recorders and other devices.
Some thoughts: <past >future ^now (the hat is also mnemonic for Here + At) or >5 (in five days time) >>5 (in 5 weeks time) >>>5 (5 months)

Meeting <Leeds went well. ^Home. See you >london
Sorry, saw them <<2 wanna go see film >3?

<div id="Documented_Syntaxes">

== Syntaxes ==

=== Generic ===

* @-replies
* [http://hashtags.org/ hashtags]
* [http://buzzword.org.uk/2009/microturtle/spec MicroTurtle]
* [http://microsyntax.org/ microsyntax.org]
* [http://twitterdata.org/ twitterdata.org]

=== Service-Specific ===

* [[actiontastic-syntax | Actiontastic]]
* [[brightkite-syntax| BrightKite]]
* [[dodgeball-syntax| Dodgeball]]
* [[dopplr-syntax | Dopplr]]
* [[facebook-syntax | Facebook Mobile]]
* [[igtd-syntax | iGTD]]
* [[kiboze-syntax|Kiboze]]
* [[jaiku-syntax|Jaiku]]
* [[mixd-syntax | Mixd]]
* [[plazes-syntax | Plazes]]
* [[poi66-syntax | POI66]] - [http://www.poi66.com/maps/step1.php]
* [[quickpack-syntax | QuickPack]]
* [[remember-the-milk | Remember the Milk for Twitter]]
* [[stikkit-syntax | Stikkit]] [http://stikkit.com/]
* [[swaggle-syntax | Swaggle]] [http://swaggle.mobi/]
* [[textmarks-syntax|Textmarks]]
* [[tfl-syntax | Transport for London]]
* [[tripit-syntax | TripIt]]
* [[twitter-syntax | Twitter]]

</div>

== References ==
* [http://www.kiboze.com/kiboze/CustWorks.aspx Kiboze How it Works]
* Flagr: [http://www.flagr.com/help/howto#mobile_creating_flag Creating mobile flags]
* [http://www.dodgeball.com/glossary Dodgeball Glossary]
* [http://twttr.com/t/help/lingo twttr lingo]
* Twitter (or Jaiku) [[twitter-nanoformats]] brainstorm [http://twitternanoformats.wikispaces.com/ A proposal for Twitter nanoformats]
* [http://skobee.com/email_howto Skobee's email syntax]
* [https://www.billmonk.com/about/sms BillMonk syntax]

== concept ==
Thanks to [http://factoryjoe.com/blog Chris Messina] for collecting a bunch of common work in this area, and exploring the area of short semi-structured text for potential "formats" of a sort that could be agreed upon, perhaps among multiple providers to make it easier for users to remember a common user interface.

mailing-lists

2009-04-07T22:21:54Z

TobyInk: mailing lists down

<entry-title> Mailing Lists </entry-title>

<div style="font-size:150%; background:#ffffe0; padding:0.33em; border: 1px dashed #999999">News - April 2009<br>
All microformats.org mailing lists appear to have been down since the beginning of the month. The administrators have been made aware of this.</div>

Read the [http://microformats.org/discuss/ microformats discuss page] first.

Then read the [http://microformats.org/mailinglists-policies/ mailing list policies].

Then read the respective archives ([http://microformats.org/discuss/mail/microformats-discuss/ -discuss], [http://microformats.org/discuss/mail/microformats-dev/ -dev], [http://microformats.org/discuss/mail/microformats-new/ -new]).

After that please see the following additional notes of scope and topics for each list.

== Getting subscribed ==
To subscribe to any of the mailing lists discussed below, please see http://microformats.org/discuss/ - here you will find all relevant subscription links, archives and also access to lists you are already subscribed to where you may change the email address you are subscribed with and the level of emails you will receive (all or digest).

== General guidelines ==
Here is a list of general guidelines to follow in microformats list discussions in general. The overall goal of many of these guidelines is to increase the signal to noise ratio on the lists by encouraging signal, and discouraging noise. Maximizing the signal-to-noise ratio (S/N) is essential to scaling a list membership, and thus as microformats grow in popularity, maximizing S/N becomes more and more important. If you have suggestions for general guidelines, please post them to the microformats-discuss list so that the list-admins may consider your suggestions.

=== Be nice ===
AKA Don't be a jerk. This guideline, which may seem totally obvious, is something we need to make explicit because of a few bad examples. The microformats.org community is quite different than both other standards organizations and most open source efforts in (at least) one very important way: this community is a much nicer place to be, with people in general treating each other with a lot of respect and benefit of the doubt. This friendlier tone in the community is something that the community very much values and will fight to defend. See the article <cite>[http://headrush.typepad.com/creating_passionate_users/2006/04/angrynegative_p.html Angry/negative people can be bad for your brain]</cite> for some reasons why. The [[admins]] may take swift action to ban or moderate individuals who essentially are "jerks" on the list. Note: neutral tone emails that use simple logical/rational emotion-free language are perfectly fine. This guideline is not a request to add artificial kindness etc. to emails. [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>]

=== Be patient ===
The community, as part of its broader positive tone, tries to be fairly patient with folks, and we want to continue to encourage that. The microformats lists will always (assuming continued growth and popularity) get new subscribers, and these new subscribers may be unfamiliar with the customs and conventions of the community. As an experienced member in the community, please be patient with new subscribers, and help them improve their behavior by kindly pointing out relevant guidelines and answers on the wiki. However, if it appears that a newcomer has a negative attitude, please raise it to the attention of the admins (offlist) with an official complaint email that references (by email archive URL) or includes the email that demonstrates the negative attitude. Negativity is the biggest exception - this community has very little patience for negativity (see previous '''Be nice''' guideline).

=== Use real world examples ===
People often invent completely fictitious (and theoretical) [[examples]] in order to try to make a point they are trying to make. Microformats themselves are based on studying real world examples and designing for real world examples. Thus arguments based on theoretical examples hold much less weight in microformats discussions and are apt to be ignored. Please avoid posting arguments / questions based solely on theoretical examples. [<abbr title="guideline created due to one or more actions by Andy Mabbett and others">src:A,o</abbr>]

==== Ask for real world examples ====
If someone discusses or provides arguments based on theoretical examples, ask them to provide a real world example with URL(s) and point them to [[mailing-lists#Use_real_world_examples|the above guideline]].

==== Use URLs to examples ====
Please provide URLs to real world examples when possible. This helps to validate that such examples truly are "real world" as they are on the public Web, and provides additional context around the example which might be crucial to understanding it or answering questions about it. [<abbr title="guideline created due to one or more actions by Andy Mabbett and others">src:A,o</abbr>]

==== Ask for URLs to examples ====
When people do not provide a specific URL to a test case or example, then especially as a developer, PLEASE ask them to provide a specific URL (and cite [[mailing-lists#Use_URLs_to_examples|the previous guideline]]) rather than attempting to work out how an inline snippet of code might work.

=== Use the wiki to share state instead of email ===
<span id="usethewiki">Use the wiki.</span> When providing examples or (re-)raising/opening a discussion, please provide a URL to the relevant wiki page which captured the example or state of the discussion previously. If no such wiki page exists, ask for it. If no one can find it, ask the list for help with researching the previous discussion and creating a wiki page for it. Then [[put-it-on-the-wiki]]. [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>]

See [[wiki-better-than-email]] for some background and explanations of how and why the wiki works better than email for content in general (whether issues, brainstorms, etc.).

==== Read FAQs before asking questions ====
Especially read relevant/respective FAQs before asking questions. Before asking a question on a microformats list, read the relevant FAQs:
# Start with the general microformats [[faq]]
# Then read specific microformats FAQs, e.g. for [[rel-tag]], see the [[rel-tag|rel-tag FAQ]], for [[adr]], see the [[hcard-faq|hCard FAQ]] as the spec indicates, etc.

==== Cite URLs to answer questions ====
When answering questions on a list, cite URL(s) to FAQ answers. Despite the previous guidelines, experience has shown us that there will be time that smart, considerate individuals may attempt to look for an answer on the FAQ, and not find it despite it being there. In such cases, assume that it was a simple unintended oversight (rather than laziness or failure to check the FAQ), and when answering such a question on a microformats list:
# Please check the relevant FAQs first, and if the answer is not there, document the question and your answer there. I.e. [[put-it-on-the-wiki]]. This is so that the community memory of answers (especially the most recent and accurate state of answers) is kept and grown in a semi-organized and hopefully easily findable fashion on the wiki, rather than deep in the depths of email archives which are often much more difficult to search, and difficult to tell what answer is "the" most recent, relevant and accurate answer.
# Cite URL(s) FAQ answer(s) (that you may have just written) rather than just writing an answer, when composing your reply in email. This will hopefully encourage more reading of the wiki and thus learning of answers to microformats related questions in general.

Note: when citing URLs, make sure they answer the specific question being asked. For additional advice about providing good "RTFM" messages see JimboJW's blog post: <cite>[http://jimbojw.com/wiki/index.php?title=Irresponsible_use_of_RTFM_doesn%27t_help_anyone Irresponsible use of RTFM doesn't help anyone]</cite>.

==== Raise issues on the wiki not in email ====
If you find an issue with a microformat, please <em>first</em> read the respective [[faq]] and [[issues]] pages for that microformat before raising the issue. If the issue is already documented on the wiki, please add any new comments there (do not simply repeat statements that others have made, nor repeat your own statements). [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>]

When someone does raise issues via email, kindly request that they raise issues via the wiki instead, e.g.:

<blockquote>
<p>Please capture issues regarding microformats on the respective *-issues wiki page rather than email.</p>
</blockquote>

==== Point out reraised issues and redirect follow up to the wiki ====
When someone does (re-)raise an issue via email that is already on the wiki, rather than arguing the issue in email, point out that the issue is already documented on the wiki (preferably with a URL to the issue, add a fragment identifier if necessary), and ask them to follow-up on the wiki, e.g.:

<blockquote>
<p>Note that this is an already documented issue:
</p><p>
http://microformats.org/wiki/issues#specific-issue-fragment
</p><p>
Please add any follow-up there rather than in email.
</p><p>
Thanks,
</p></blockquote>

This will hopefully end the thread and thus avoid further email on a topic that is already documented on the wiki.

==== Reply to email followups to issues with request to use wiki instead ====
When someone debates/follows-up to an issue via email (rather than doing the above and requesting that the issue be documented in email), request to the person following-up to please add their follow-up to the wiki instead (even if that means also adding the original issue), e.g.:

<blockquote>
<p>
Please follow-up to issues raised in email by directing folks to raise issues on the respective *-issues wiki page rather than following-up to issues in email.
</p><p>
Thanks,
</p>
</blockquote>

=== Avoid wasting others time by sending a lot of email ===
Historically a few individuals have overloaded some of the microformats mailing lists with a lot of email. As each individual email costs time for everyone on the list, this is quite inconsiderate and should be avoided. Here are a few ways (but certainly not all ways) to avoid wasting others' time with too much email. [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>]

In general, if you find yourself sending more than one message in a row to *any* of the microformats lists, you are probably doing something wrong. Give others a chance to read/consider/reply to your messages one at a time. If you have a lot to say, you should instead be capturing your thoughts on the appropriate wiki page(s) per above guidelines, and simply referencing relevant URLs in *optional* notification messages to the list. [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>]

==== Avoid replying to yourself to reraise a topic ====
Especially avoid replying to yourself just to reraise a topic. Please avoid replying to yourself just to "ping" the mailing list or to ask for an update or advice. Especially avoid making assumptions / conclusions simply from the lack of a reply to you or your points. If you really think the issue is of merit, add it to the relevant [[issues]] page and just wait for it to be resolved. [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>]

==== Avoid wasting others time with simple contradictory email ====
Similar to the [[how-to-play#avoid-simple-contradictions|how to play guideline to avoid simple contradictory responses]], please avoid replying to statements made in email with nothing more than simple contradictions. Simple contradictions (like just inverting another statement as if such an inversion was an argument), both do not add anything useful to a discussion, and worse, only add noise which wastes space and everyone's time, and are thus to be avoided. E.g.:

Original statement: "It's not really got much support of tools that support it and do something useful with it".

Simple contradiction: "There *is* support and there *are* tools, not least in the fields for which it was intended."

The contradiction example provided no new information that could argue against the original statement. It is no better than endless loops of "Yes it is. No it isn't. Yes it is. No it isn't.".

Instead, provide at least a short sentence with a reason which provides information beyond what is provided, such as a specific piece of information and a URL. E.g.

Better follow-up statement: "There are tools that support it, for example application XYZ, available at <nowiki>http://example.com/xyz</nowiki> ."

[<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>([http://microformats.org/discuss/mail/microformats-new/2008-February/001385.html 1])]

==== Avoid sending one message per issue raised ====
If you add multiple issues to a microformats issues page, and wish to announce that you did so, please only send at most '''one''' email announcing the batch of issues you added and note the URL of the issue page on the wiki, rather than sending one email per issue. Direct people to the wiki to follow-up on your issues, rather that encouraging threads of conversation/discussion per issue on the email list.

[<abbr title="guideline created due to one or more actions by Manu Sporny">src:M</abbr>([http://microformats.org/discuss/mail/microformats-new/2009-February/002026.html 1], [http://microformats.org/discuss/mail/microformats-new/2009-February/002031.html 2], [http://microformats.org/discuss/mail/microformats-new/2009-February/002030.html 3], [http://microformats.org/discuss/mail/microformats-new/2009-February/002029.html 4], [http://microformats.org/discuss/mail/microformats-new/2009-February/002028.html 5], [http://microformats.org/discuss/mail/microformats-new/2009-February/002027.html 6])]

=== Avoid logical flaws ===
See [[logical-flaws]] for a list of common logical flaws seen on the mailing-list(s) which are to be avoided. [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>]

==== Point out logical flaws ====
When someone employs one or more known [[logical-flaws]] on the mailing-list(s), kindly point out the logical flaw(s), preferably with a link to the specific logical flaw(s).

== microformats-discuss ==
A mailing list for general discussion of microformats, with a strong leaning towards:

* starting out with microformats
* real-world content authoring

=== Good topics for discussion ===
Here is a list (certainly not definitive) of good topics which are appropriate for the microformats-discuss mailing list:

* general thoughts on the design and use of semantic XHTML markup
* how to use and write microformats in content
* how to use microformat design patterns in content

=== Good topics that belong somewhere else ===
* see [http://microformats.org/wiki/mailing-lists#good_topics_for_discussion_2 microformats-dev good topics for discussion]
* see [http://microformats.org/wiki/mailing-lists#good_topics_for_discussion_3 microformats-new good topics for discussion]

=== Bad topics for discussion ===

AKA topics better discussed elsewhere (somewhere other than microformats.org).

Here is a list (also not definitive) of topics which are undesired and inappopriate for the microformats-discuss mailing list. In fact, they're not even worth the time to bother discussing, so please do not bring them up on the microformats-discuss mailing list. We'll add more topics as people come up with more off-topic or out-of-scope or rathole topics.

# '''How to make a "general purpose" (micro)format.''' Go read [http://microformats.org/wiki/microformats#microformats_are_not what microformats are not], actually, go read the entire [[microformats|principles]] page. Sometimes this may masquerade as a "format of formats". Either way, it is one of those boil the ocean ratholes which are far outside the focus of microformats. If you really want to work on such subjects, teach yourself DTD (SGML, XML), XML Schema, Relax NG, RDF Schema, and find the communities working on those technologies.
# <span id="bad-topic-namespaces">'''Using namespaces and namespace prefixes.'''</span> In short, namespaces are neither necessary (the Internet ran just fine without them for decades, go read some RFCs), nor desirable (prefixes make formats far uglier and more difficult to hand-code). See also [[namespaces-considered-harmful]].
# '''Using non-English names for properties'''. This was briefly discussed on the microformats-discuss list most recently as "Language Maps" but has been raised before that. Some folks have raised the issue that microformats use English names for properties, and they would like alternate (non-English) names in other (natural) languages, and perhaps try to establish a mapping between them. As microformats property names are based on existing standards (see [[process]], and [[naming-principles]]), this is another problem that is far outside the scope of microformats. As Ryan King put it, this is a pre-existing (unsolved) "problem" with English-based HTML, the English-based CSS, the English-based HTTP and so on. Note that this is NOT about the internationalization (i18n) of the content and data itself - which is of course an excellent goal, advocated and promoted by microformats and the standards they are based on (e.g. W3C, IETF). This is purely about the names of the properties (and enumerated values) in the formats.

== microformats-dev ==
For discussion of microformats development, with a leaning towards:

* anything that involves writing code
* abstractions / models (in contrast to actual content)

=== Good topics for discussion ===
These tend to be topics that belong in microformats-dev instead of microformats-discuss. This list is also not definitive, but illustrates the general areas:

* microformat parsing
* microformat "(auto)-discovery"
* comparisons of microformats with other data abstractions or data representations (e.g. XML, RDF)
* compatibility/interoperability of microformats with other data abstractions or data representations

Formerly, the membership to this list was moderated and limited to people who had demonstrated public implementations of microformats. We've since relaxed this requirement, yet maintain the same expectations that people involved in the discussion are focused on concrete and pragmatic topics related to writing code using microformats.

== microformats-rest ==
For discussion of use of microformats with [http://en.wikipedia.org/wiki/Representational_State_Transfer REST], in protocols, services, APIs etc.

== microformats-new ==
This list is for the discussion, exploration and development of new microformats.

This list was created in February 2007 [http://microformats.org/blog/2007/02/08/new-mailing-list/] to reduce the new microformat development noise on the [http://microformats.org/wiki/mailing-lists#microformats-discuss microformats-discuss] list, and allow those that are interested in exploring new microformats to concentrate their efforts.

=== Specific posting guidelines ===
* Make sure you have read and fully understand the [[process]] and have already made your website [[POSH]] and have used existing microformats as much as you can.
* Make an effort to search the mailing list archives and the wiki to see if your suggestion has already been made, or is closely related to something in existance. It may be more advisable to build on previous work. See also [[rejected-formats]].
* Be ready to show plenty of examples of what you're trying to achieve and what real problems you're trying to resolve in the first instance. Suggested formats should expect a certain amount of interrogation about the aim of a new microformat - this shouldn't be taken as negative feedback, or taken personally!
* Please make a note of any suggested new microformats that do not make it through the [[process]] on the [[rejected-formats]] wiki page, along with a link to the discussion and the suggested resolution.

=== Good topics for discussion ===
* Discussion on how to re-use existing microformats for "new" uses.
* Discussion on extension of existing microformats syntax
* Discussion of the [[process]]
* Development of brand new microformats, adhering to the [[process]]

=== Bad topics for discussion ===
All [[mailing-lists#Bad_topics_for_discussion|microformats-discuss bad topics for discussion]] are also bad topics for microformats-new as well. In addition:
==== new microformat hXYZ ====
* '''"proposal for a new microformat: hXYZ"''' - especially if as your first post. '''Don't''' send a proposal email as your first email. You're likely to not get very far. In particular, it's also bad form to prematurely name a microformat hXYZ or whatever as well. See [[process#Naming_considerations|Naming consideration]]. And re-read the [[process|entire process]].
** '''email response template:''' when someone makes a "proposal for a new microformat: hXYZ", kindly reply with something like:
<pre><nowiki>
Please read:

http://microformats.org/wiki/process

before proposing any new microformats.

In addition, please read the specific posting guidelines for microformats-new:

http://microformats.org/wiki/mailing-lists#microformats-new
</nowiki></pre>
==== new microformat hPreviousFormatProposal ====
* '''"proposal for a new microformat: hPreviousFormatProposal"'''. This is a particular common variant of the previous bad topic for discussion. Please do not propose a microformat simply based upon taking some PreviousFormatProposal (like some random XML or RDF format proposal) and turning it into class names. While re-using an existing format (or proposal, or portion thereof) for vocabulary for a microformat ''may'' be part of developing a microformat (see [[process]]), it is insufficient.
** '''email response template:''' when someone makes a "proposal for a new microformat: hPreviousFormatProposal", in addition to the above email response template requesting that they read the [[process]] and list guidelines, kindly reply with something like:
<pre><nowiki>
Simply proposing a set of class names is not a microformat (again, see /wiki/process/) - at best it is a poshformat.

http://microformats.org/wiki/poshformat
</nowiki></pre>

== Unsure ==
If you are unsure about any of guidelines, or have any other list-specific issues, you are welcome to email the list admins, e.g. for microformat-discuss: email microformats-discuss-owner at microformats dot org.

== Help Redirect Topics ==
If you notice a topic being discussed in one list which would be more appropriate for another list (e.g. discussion of a developer topic like "parsing" in the microformats-discuss list), you can help encourage better list usage by redirecting the thread to the more appropriate list with a gentle reminder at the top, e.g.:

<blockquote>
<p>Please redirect discussions of "parsing" and other development related/centric topics to the microformats-dev list per:</p>
<p>http://microformats.org/wiki/mailing-lists#Bad_topics_for_discussion</p>
<p>http://microformats.org/wiki/mailing-lists#microformats-dev</p>
</blockquote>

== How to search the mailing list archives ==
If your post to the list starts off "I'm new to the list and microformats so I don't know if you've discussed this already" READ THROUGH THE [http://microformats.org/discuss/mail/microformats-discuss/ ARCHIVES]!

The archives are getting larger, so here are a few simple ways you can search them. Most popular search engines imploy some sort of site based results filtering. Google does this in your initial search. Type "site:http://microformats.org/discuss/ <search terms here>" to limit the search results to only our discussion list. This will help you from asking a question that has already been posted, debated, and possibly resolved. It saves everyone time and energy!

Gmane provides [http://news.gmane.org/gmane.comp.web.microformats.general an alternate search and interface] as well as [http://rss.gmane.org/gmane.comp.web.microformats.general RSS feed] for the microformats-discuss list.

== Historical ==

For the record, view our [[mailing-lists-proposals|proposals for a new mailing list]] for discussing the research and creation of new microformats (see "microformats-new" above) so that those discussions do not overwhelm microformats-discuss.

== Other ==

Items regarding the mailing lists that didn't fit anywhere else.
* [[mailing-list-unmoderation]]

==See also==
*[[discuss|Other discussion fora]]

Main Page

2009-04-07T22:16:40Z

TobyInk: restore Brian's version

<entry-title>Welcome to the microformats wiki!</entry-title>
__TOC__
Please start with the [[introduction]] page and read [[how-to-play]] before making any edits.

==Introduction==

This wiki is the central resource of the microformats community. You'll find current versions of published microformat specifications, specification drafts and publishing patterns. The wiki also hosts development resources, such as brainstorming pages for new formats and issue tracking pages for all current and in-development microformats.

To get started with microformats:

* First, be familiar writing your pages and applications with semantically rich, descriptive, ‘[http://microformats.org/wiki/posh <abbr title="Plain Old Semantic HTML">POSH</abbr>]’ <abbr title="HyperText Mark-up Language">HTML</abbr>.
* Learn about microformats from the [http://microformats.org/about/ about page], [http://microformats.org/ blog], [[press]], [[presentations]], [[books]], [[podcasts]], & [[screencasts]] pages.
* Take a look at established specifications such as [[hcard|hCard]] and [[hcalendar|hCalendar]], and follow the [[hcard-examples|examples]] to start publishing microformats.
* Have questions? Read the [[faq|frequently asked questions]] and see the [[glossary]] for terms and definitions. You can also post to the {{MicroformatsMailingList}}.
* Want to learn more in person? Check out microformats [[events]].

Also, this wiki has a number of neat enhancements to assist development and contributions to microformats. Before you start editing, see the [[wiki-2|wiki introduction page]] for instructions.

==Definition==
Microformats are small patterns of HTML to represent commonly published things like [[hcard|people]], [[hcalendar|events]], [[hatom|blog posts]], [[hreview|reviews]] and [[rel-tag|tags]] in web pages.

Microformats enable the publishing of higher fidelity information on the Web; the fastest and simplest way to provide feeds and APIs for the information in your website.

* Read more explanations of [[what-are-microformats|what microformats are]], and [[what-can-you-do-with-microformats|what you can do with them]].

== How to contribute ==
Do you want to help take microformats to the next level? You can:

* [[get-started|Get started]] by adding microformats to your website, services, and products.
* [[advocacy|Advocate]] the use of microformats on other web sites, especially those you use.
* Write a [[testimonial]].
* Do something on the [[to-do|to do list]].
* Join the [[irc|IRC Channel]] and [[mail|mailing lists]] to learn and help answer questions (read the [[mailing-lists#General_guidelines|general guidelines]] before posting).
* [[Main_Page#microformats_wiki_translations|Translate this microformats wiki into other languages]] to make microformats more accessible to readers of languages around the world.
* Before proposing any new microformats, make sure your website is [[POSH]], [[get-started|uses existing microformats]], and then read the [[process]].

== Specifications ==
The list of current, stable [[microformats|Microformats]] open standard specifications.

* [[hcalendar|hCalendar]] - [http://microformats.org/code/hcalendar/creator hCalendar creator]
* [[hcard|hCard]] - [http://microformats.org/code/hcard/creator hCard creator]
* [[rel-license]]
* [[rel-nofollow]]
* [[rel-tag]]
* [[vote-links|VoteLinks]]
* [[XFN]] - [http://gmpg.org/xfn/creator XFN creator]
* [[XMDP]]
* [[xoxo|XOXO]]

''If you're tempted to try your hand at writing a microformat please read '''[[process|the process]]''' page first!''

== Drafts ==
Drafts are newer microformats, for which the specifications haven't been completed yet. Although drafts are somewhat mature in the development process, the stability of these documents cannot be guaranteed, and implementers should be prepared to keep abreast of future developments and changes. Please watch the wiki pages for updates.

* [[adr|adr]] - for marking up address information
* [[geo|geo]] - for marking up [http://en.wikipedia.org/wiki/WGS84 WGS84] geographic coordinates (latitude; longitude)
* [[hatom|hAtom]] - syndicating episodic content (e.g. weblog postings)
* [[haudio|hAudio]]
* [[hproduct|hProduct]]
* [[recipe|hRecipe]]
* [[hresume|hResume]] - for publishing resumes and CVs
* [[hreview|hReview]] - [http://microformats.org/code/hreview/creator hReview creator]
* [[rel-directory]] - to indicate that the destination of a hyperlink is a directory listing containing an entry for the current page
* [[rel-enclosure]] - for indicating attachments (e.g. files) to download and cache
* [[rel-home]] - indicate a hyperlink to the homepage of the site
* [[rel-payment]] - indicate a payment mechanism
* [[robots-exclusion|robots exclusion]]
* [[xfolk|xFolk]]

== Design Patterns ==
{{design_patterns}} 
* [[elemental-microformat|elemental microformats]]
* [[compound-microformat|compound microformats]]

== Exploratory Discussions ==
See: [[exploratory-discussions]] for details of research and analysis of real-world [[examples]], existing formats, and brainstorming of possible new microformats, per the microformats [[process]].

== Examples ==
* [[examples-in-the-wild]]
* [[implementations]]
* [[zen-garden]]

== Resources ==
See [[resources]].

== User centric development ==
*[[user-interface]]
*[[data-portability]]
*[[social-network-portability]]

== Shared work areas ==
* [[to-do]]
* [[templates]]
* [http://microformats.org/wiki/delete pages for deletion] 
* [[Special:Specialpages|"Special" wiki pages]]
* [[year-in-review]]

== Tools, test cases, additional research ==
The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting [[tools|tools and services]] that need to process more than one microformat. That section is intended for editors, [[parsers]], [[validators]], test cases, and other information relevant across multiple microformats.

== Microformats wiki translations ==
<span id="microformats_wiki_translations_in_other_languages">You may read and edit microformats articles in many other languages:</span>

* languages with over 100 articles
** [[Main_Page-fr|<span lang="fr">Français</span> (French)]] <span lang="fr">{{UpdateMarker-fr}}</span>
* languages with over 10 articles
** [[Main_Page-pt-br|<span lang="pt-br">Português</span> (Brazilian Portuguese)]]
** [[Main_Page-ja|<span lang="ja">日本語</span> (Japanese)]]
** [[Main_Page-ru|<span lang="ru">Русский</span> (Russian)]]
* languages with over 2 articles
** [[Main_Page-cs|<span lang="cs">Česky</span> (Czech)]] {{NewMarker}}
** [[Main_Page-de|<span lang="de">Deutsch</span> (German)]]
** [[Main_Page-es|<span lang="es">Español</span> (Spanish)]]
** [[Main_Page-gl|<span lang="gl">Galego</span> (Galician)]] {{NewMarker}}
** [[Main_Page-pl|<span lang="pl">Polski</span> (Polish)]]
** [[Main_Page-ro|<span lang="ro">Română</span> (Romanian)]] {{NewMarker}}
** [[Main_Page-zh|<span lang="zh">汉语</span> (Chinese)]]
* languages just started
** [[Main_Page-ar|<span lang="ar">العربية</span> (Arabic)]]
** [[Main_Page-th|<span lang="th">ภาษาไทย</span> (Thai)]]
** [[Main_Page-it|<span lang="it">Italiano</span> (Italian)]] {{NewMarker}}
** [[Main_Page-ko|<span lang="ko">한국어</span> (Korean)]] {{NewMarker}}
* elsewhere
**[http://en.wikipedia.org/wiki/Microformat Wikipedia's article on microformats] has been translated into a number of languages.

See also [[other-languages]], and [[how-to-start-new-translation|how-to-start-a-new-translation]].

project-brainstorming

2009-03-26T10:21:09Z

TobyInk: /* Suggestion */ I did actually preview it before, but somehow didn't spot the b0rken links

=projecta=
Even though there are existing project formats, the projecta format {{must}} be developed because there is no established project format and it will enable decentralized development of projects.

__TOC__

== Contributors ==

* Derek Lewis

== See Also ==
* [[project]]
* [[project-examples]]
* [[project-brainstorming]]
* [[project-formats]]

== Format ==
=== In General ===
The projecta format is based on a set of fields common to numerous project sites and formats in use today on the web. Where possible field names have been chosen based on those defined by the related [[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], and [[hrecipe|hRecipe]].

=== Schema ===
The projecta schema consists of the following:

* projecta ('''<code>projecta</code>''')
** '''version'''. optional. text.
** '''summary'''. optional. text. serves as the title for the project.
** '''type'''. optional. abstract | practical.
** '''project''' info. required. '''<code>fn</code>''' ('''<code>url</code>''' || '''<code>photo</code>''' )
** '''author'''. optional. '''[[hcard|hCard]]'''.
** '''description'''. optional. text with optional valid HTML markup.
** '''goals'''. optional. text with valid HTML '''<code>ul</code>''' ('''<code>li</code>''') elements.
** '''instructions'''. optional. text with valid HTML '''<code>ol</code>''' ('''<code>li</code>''') elements.
** '''accomplishments'''. optional. text with valid HTML '''<code>ul</code>''' ('''<code>li</code>''') elements.
** '''requirements'''. optional. text {{may}} include valid HTML markup e.g. paragraphs or a list.
** '''tags'''. optional. keywords or phrases, using '''[[rel-tag]]''', each with optional rating.
** '''permalink'''. optional, using '''[[rel-bookmark]]''' and '''[[rel-self]]'''.

=== Field details ===
The fields of the projecta schema represent the following:

'''version''':: This optional field permits projecta publishers to specify a particular version of projecta that their content uses. This field is syntax compatible with, and thus reuses the semantics of "VERSION" as defined in vCard RFC2426 section "3.6.9 VERSION Type Definition". The value of this field for this specification is "0.1".

'''summary''':: This optional field serves as the title for the project.

'''type''':: This optional field "type" provides the type of project, one of the following: abstract, practical. If omitted, then in some cases the project type may be inferred. For projects of type "abstract" {{should}} have "goals" and/or "accomplishments" fields completed. For projects of type "practical" {{should}} have "instructions" field completed.

'''project''':: This required field {{must}} have at a minimum the name ("fn" - the [http://grammartips.homestead.com/caps.html formatted text] corresponding to the name) of ''the'' project (a projecta describes only one project), {{may}} provide at least one URI ("url") for the project, and {{may}} provide at least one URL to a photo or depiction ("photo") of the project. However, when using item info subproperties ("fn", "url", "photo"), they {{must}} be nested <em>inside</em> the project element.

'''author''':: This optional field specifies the person who authored the project. If the author is specified, an hCard representing the author {{must}} be provided.

'''description''':: This optional field contains the full text representing the input of the author. The field {{may}} include valid HTML markup (e.g. paragraphs). User agents {{should}} preserve any markup.

'''goals''':: This optional field documents the project's goals.

'''instructions''':: This optional field documents the instructions required to complete the project. Re-used from [[hrecipe|hRecipe]].

'''accomplishments''':: This optional field documents the project's accomplishments.

'''requirements''':: This optional field contains the requirements of the project. The field {{may}} include links to products or other projects.

'''tags''':: Tags are represented using a list of keywords or phrases (using the [[rel-tag]] microformat for each individual keyword or phrase tag) that the author associates with the project.

'''permalink''':: This optional field is a URL for the projecta. In addition to using the <code><a href></code> tag for this field, the attribute <code>rel="self bookmark"</code> {{must}} be used to indicate that the hyperlink is a permalink for the project itself. If the hyperlink already contains a <code>rel</code> attribute, then the values <code>self</code> and <code>bookmark</code> {{must}} be included among the space-separated set of values in the attribute. Indexers {{may}} treat the permalink of a project as a unique ID in order to identify and collate the same project from multiple sources (such as indexing a page multiple times). The permalink {{may}} also be used to indicate or imply the origin of the project. Authors {{may}} use the classname of "permalink" on the element representing the permalink.

The following field names have been reused from the [[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], and [[hrecipe|hRecipe]] microformats: <code>version, summary, url, photo, description, instructions, tags, permalink</code>. In addition, items and authors described by hCards {{may}} contain any hCard field. The rel value "self" has been reused from the [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html Atom 1.0 specification].

==Format Development==
Further development is based on your feedback.

===Project Type===
There are two [types] of project page as I see it - the abstract (name of the project, description, goals, who's in charge, related web pages, etc) and the practical (name of the project, step by step how it can be achieved).

The former overlaps with hCard / hDOAP; the latter with hRecipe (though hRecipe only suitable for a limited subset). There is very little common ground.

The World Bank site and CORDIS are examples of the former - what are the goals of the project? who is taking part? who is funding it? how much will it cost? But they don't give you step-by-step instructions for how to carry out the project in your own home in your spare time. And you won't expect them to.

The knitting site, and recipes are different. The goals are not explicitly stated; no time frame is given (I could knit a poncho tomorrow, or maybe in a few years' time). The focus is on the step by step documentation of how it can be done, so that you can replicate the project yourself. -[http://tobyinkster.co.uk Toby]

====Suggestion====

Rather than creating a large format that encompases both here's-how-you-can-do-it-at-home projects and here's-what-we're-doing projects, there is probably more value in creating two small formats, the former as perhaps an evolution of [[hRecipe]] and the latter as perhaps an extension to [[hCard]].

hCard could be extended, for example, by defining <tt>goal</tt>, <tt>benefactor</tt> (containing an embedded hCard) and <tt>beneficiary</tt> (containing an embedded hCard) classes, and borrowing the <tt>due</tt> class from [[hCalendar]].

<pre><nowiki><div class="vcard vproject">
<h3 class="fn org">United Nations Giraffism Project</h3>
<p class="goal">To cure the people of the world of giraffism,
a terrible disease that gives people long necks,
by <span class="due">2018</span>.</p>
<p>Visit our <a href="http://giraffism.example.net/"
class="url">website</a> for more details.</p>
</div></nowiki></pre>

====Digestion====
Added field named "type" (re-used from [[hreview|hReview]]) with options "abstract" and "practical".<br />
Added field named "goals".<br />
Added field named "instructions" (re-used from [[hrecipe|hRecipe]]).<br />
Added field named "accomplishments".<br />

== See Also ==
* [[project]]
* [[project-examples]]
* [[project-brainstorming]]
* [[project-formats]]

See [[projecta|projecta]] for the result and evolution of these thoughts on a microformat.

project-brainstorming

2009-03-26T10:20:10Z

TobyInk: /* Suggestion */ split the format in two

=projecta=
Even though there are existing project formats, the projecta format {{must}} be developed because there is no established project format and it will enable decentralized development of projects.

__TOC__

== Contributors ==

* Derek Lewis

== See Also ==
* [[project]]
* [[project-examples]]
* [[project-brainstorming]]
* [[project-formats]]

== Format ==
=== In General ===
The projecta format is based on a set of fields common to numerous project sites and formats in use today on the web. Where possible field names have been chosen based on those defined by the related [[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], and [[hrecipe|hRecipe]].

=== Schema ===
The projecta schema consists of the following:

* projecta ('''<code>projecta</code>''')
** '''version'''. optional. text.
** '''summary'''. optional. text. serves as the title for the project.
** '''type'''. optional. abstract | practical.
** '''project''' info. required. '''<code>fn</code>''' ('''<code>url</code>''' || '''<code>photo</code>''' )
** '''author'''. optional. '''[[hcard|hCard]]'''.
** '''description'''. optional. text with optional valid HTML markup.
** '''goals'''. optional. text with valid HTML '''<code>ul</code>''' ('''<code>li</code>''') elements.
** '''instructions'''. optional. text with valid HTML '''<code>ol</code>''' ('''<code>li</code>''') elements.
** '''accomplishments'''. optional. text with valid HTML '''<code>ul</code>''' ('''<code>li</code>''') elements.
** '''requirements'''. optional. text {{may}} include valid HTML markup e.g. paragraphs or a list.
** '''tags'''. optional. keywords or phrases, using '''[[rel-tag]]''', each with optional rating.
** '''permalink'''. optional, using '''[[rel-bookmark]]''' and '''[[rel-self]]'''.

=== Field details ===
The fields of the projecta schema represent the following:

'''version''':: This optional field permits projecta publishers to specify a particular version of projecta that their content uses. This field is syntax compatible with, and thus reuses the semantics of "VERSION" as defined in vCard RFC2426 section "3.6.9 VERSION Type Definition". The value of this field for this specification is "0.1".

'''summary''':: This optional field serves as the title for the project.

'''type''':: This optional field "type" provides the type of project, one of the following: abstract, practical. If omitted, then in some cases the project type may be inferred. For projects of type "abstract" {{should}} have "goals" and/or "accomplishments" fields completed. For projects of type "practical" {{should}} have "instructions" field completed.

'''project''':: This required field {{must}} have at a minimum the name ("fn" - the [http://grammartips.homestead.com/caps.html formatted text] corresponding to the name) of ''the'' project (a projecta describes only one project), {{may}} provide at least one URI ("url") for the project, and {{may}} provide at least one URL to a photo or depiction ("photo") of the project. However, when using item info subproperties ("fn", "url", "photo"), they {{must}} be nested <em>inside</em> the project element.

'''author''':: This optional field specifies the person who authored the project. If the author is specified, an hCard representing the author {{must}} be provided.

'''description''':: This optional field contains the full text representing the input of the author. The field {{may}} include valid HTML markup (e.g. paragraphs). User agents {{should}} preserve any markup.

'''goals''':: This optional field documents the project's goals.

'''instructions''':: This optional field documents the instructions required to complete the project. Re-used from [[hrecipe|hRecipe]].

'''accomplishments''':: This optional field documents the project's accomplishments.

'''requirements''':: This optional field contains the requirements of the project. The field {{may}} include links to products or other projects.

'''tags''':: Tags are represented using a list of keywords or phrases (using the [[rel-tag]] microformat for each individual keyword or phrase tag) that the author associates with the project.

'''permalink''':: This optional field is a URL for the projecta. In addition to using the <code><a href></code> tag for this field, the attribute <code>rel="self bookmark"</code> {{must}} be used to indicate that the hyperlink is a permalink for the project itself. If the hyperlink already contains a <code>rel</code> attribute, then the values <code>self</code> and <code>bookmark</code> {{must}} be included among the space-separated set of values in the attribute. Indexers {{may}} treat the permalink of a project as a unique ID in order to identify and collate the same project from multiple sources (such as indexing a page multiple times). The permalink {{may}} also be used to indicate or imply the origin of the project. Authors {{may}} use the classname of "permalink" on the element representing the permalink.

The following field names have been reused from the [[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], and [[hrecipe|hRecipe]] microformats: <code>version, summary, url, photo, description, instructions, tags, permalink</code>. In addition, items and authors described by hCards {{may}} contain any hCard field. The rel value "self" has been reused from the [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html Atom 1.0 specification].

==Format Development==
Further development is based on your feedback.

===Project Type===
There are two [types] of project page as I see it - the abstract (name of the project, description, goals, who's in charge, related web pages, etc) and the practical (name of the project, step by step how it can be achieved).

The former overlaps with hCard / hDOAP; the latter with hRecipe (though hRecipe only suitable for a limited subset). There is very little common ground.

The World Bank site and CORDIS are examples of the former - what are the goals of the project? who is taking part? who is funding it? how much will it cost? But they don't give you step-by-step instructions for how to carry out the project in your own home in your spare time. And you won't expect them to.

The knitting site, and recipes are different. The goals are not explicitly stated; no time frame is given (I could knit a poncho tomorrow, or maybe in a few years' time). The focus is on the step by step documentation of how it can be done, so that you can replicate the project yourself. -[http://tobyinkster.co.uk Toby]

====Suggestion====

Rather than creating a large format that encompases both here's-how-you-can-do-it-at-home projects and here's-what-we're-doing projects, there is probably more value in creating two small formats, the former as perhaps an evolution of [hRecipe] and the latter as perhaps an extension to [hCard].

hCard could be extended, for example, by defining <tt>goal</tt>, <tt>benefactor</tt> (containing an embedded hCard) and <tt>beneficiary</tt> (containing an embedded hCard) classes, and borrowing the <tt>due</tt> class from [hCalendar]

<pre><nowiki><div class="vcard vproject">
<h3 class="fn org">United Nations Giraffism Project</h3>
<p class="goal">To cure the people of the world of giraffism,
a terrible disease that gives people long necks,
by <span class="due">2018</span>.</p>
<p>Visit our <a href="http://giraffism.example.net/"
class="url">website</a> for more details.</p>
</div></nowiki></pre>

====Digestion====
Added field named "type" (re-used from [[hreview|hReview]]) with options "abstract" and "practical".<br />
Added field named "goals".<br />
Added field named "instructions" (re-used from [[hrecipe|hRecipe]]).<br />
Added field named "accomplishments".<br />

== See Also ==
* [[project]]
* [[project-examples]]
* [[project-brainstorming]]
* [[project-formats]]

See [[projecta|projecta]] for the result and evolution of these thoughts on a microformat.

vote-links-issues

2009-03-20T17:25:46Z

TobyInk: /* Issues */ who voted?

=Vote-link Issues=

These are issues that people have raised regarding [[vote-links]]. If you'd like to raise an issue here, please put the date and your name and clearly state your issue.

== Template ==
{{issues-format}}

==Issues==

* {{OpenIssue}} 2005-06-21 raised by Hixie
*# ''Issue H-1: This specification is lacking a user agent conformance section. There's basically nothing that says how VoteLinks must be parsed, how to handle errors, and so forth. Is it defined in terms of the DOM? Is it defined in terms of a serialisation? How do you handle conflicting content?

* {{OpenIssue}} 2006-08-23 by porneL
*# ''What is the relation of vote links and [[rel-nofollow|rel=nofollow]]? <a rev="vote-against"> may actually have positive effect on referenced page in search engines that don't understand vote links. <a rev="vote-against" rel="nofollow"> makes more sense in this case, however nofollow means that PR should not be affected, which might be in conflict with interpretation of vote-against.

* {{OpenIssue}} 2007-01-04 by SteveIvy (originally by tantek in irc)
*# ''[[rel-faq#Should_.27rev.27_even_be_used|According to the 'rel' FAQ]], 'Use of "rev" SHOULD be avoided. However, VoteLinks, is being grandfathered since it was such an early use. No future microformats should be developed that use "rev".' Would it be useful to put vote-links through the proper process and see what comes of it?

* {{OpenIssue}} 2009-02-02 by icoloma
*# It has been raised in the FAQ that votes should not be implemented using GET links, since GET is expected to be idempotent and in fact could be followed by search engines or link-prefetching browser plugins. Instead, the proposal should describe a method using POST forms, or using javascript code to actually cast the vote (like using Rails' POST links).
*#* I think you're misunderstanding the purpose of votelinks. They're not for polling systems. This is a non-issue; I propose that it be marked closed. [[User:TobyInk|TobyInk]] 08:31, 3 February 2009 (UTC)
*#** As someone who was similarly confused on my first encounter with vote links, I think a case could be made for clarifying this in the spec. In particular, the specification's example, which consists of two links to 'Do melt the cheese!' and 'Don't melt the cheese!', seems to be exactly the kind of polling thing that vote links isn't for. Could we come up with a better example? [[User:Chrismear|Chrismear]] 16:39, 20 February 2009 (UTC)

* {{OpenIssue}} 2009-03-20 by [[User:TobyInk|TobyInk]]
*# Who voted for the link? The author of the page or the person [[representative-hcard|represented by the page]]? It would be nice to have some clarity.

==See also==
*[[vote-links]]

project

2009-03-11T08:19:49Z

TobyInk: /* existing formats */ yes, i should have previewed

<h1>Project</h1>
This is a page for tracking the effort to develop a project microformat for authors and publishers to markup public projects like open-source software or other kinds of artistic distributions.
{{TOC-right}}
{{formatset|project}}

== problem statement ==
=== scenarios ===
One of its primary intent is to allow robots to automatically classify projects in a freshmeat  manner by browsing the web.
[[User:ZimbaTm|ZimbaTm]] 08:31, 12 Jan 2008 (PST)

== real world examples ==

=== Freshmeat.net ===
Description of the software project
* http://freshmeat.net

** full project name (This is the publicly visible project name.)
** short project name (This will be used to generate a /projects/<shortname>/ URL for your project.)
** full description
** short description
** name of author
** email address
** branch name
** branch description
** license
** homepage
** Tar/GZ
** Tar/BZ2
** Zip
** Changelog
** RPM package
** Debian package
** OS X package
** Bittorrent
** BSD Ports URL
** Autopackage URL
** Jar
** Purchase
** CVS tree (cvsweb)
** Bug tracker
** Mailing list archive
** Mirror site
** Demo site
** version
** release focus
** Dependencies

=== 43things.com ===
* http://43things.com
How I did a project

** goal title
** last words (One sentence summary.)
** how
** lessons
** time taken
** resources

== Analysis of Examples ==

=== Common project fields ===
* project (name/title|URL(s)|image)
* author (name|email|URL)
* summary

== existing formats ==
Please document in [[project-formats]].

* [http://hyperdata.org/xmlns/project/ A vocabulary for describing projects] (primarily goal-oriented)
* [http://usefulinc.com/doap/ DOAP: Description of a Project] (software project specific)
** [http://hyperdata.org/xmlns/hdoap/profile/ hDOAP] - previous [[poshformat|microformat-like]] effort
* [http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique Program Evaluation and Review Technique]

== Related microformats ==
* [[hCalendar]] for timelines, milestones, and to-do items
* Resources
** [[hCard]] for participating people
** [[product]] for stuff(?)
*** [[rel-payment]]
* [[hReview]] for debriefing

== brainstorming ==

=== Schema ===
The projecta schema consists of the following:

* Projecta ('''<code>projecta</code>''')
** '''<code>version</code>'''. optional. text.
** '''<code>summary</code>'''. optional. text.
** '''<code>project</code>''' info. required. ('''<code>url</code>''' || '''<code>photo</code>''' )
** '''<code>author</code>'''. optional. '''[[hcard|hCard]]'''.
** '''<code>description</code>'''. optional. text with optional valid HTML markup.
** requirements. optional. text with optional '''<code>url</code>''' to products or other projects.
** steps. optional. text with valid HTML '''<code>ol</code>''' ('''<code>li</code>''') elements.
** tags. optional. keywords or phrases, using '''[[rel-tag]]''', each with optional rating.
** permalink. optional, using '''[[rel-bookmark]]''' and '''[[rel-self]]'''.

=== Field details ===
The fields of the projecta schema represent the following:

'''version''':: This optional field permits projecta publishers to specify a particular version of projecta that their content uses. This field is syntax compatible with, and thus reuses the semantics of "VERSION" as defined in vCard RFC2426 section "3.6.9 VERSION Type Definition". The value of this field for this specification is "0.1".

'''summary''':: This optional field serves as a title for the project itself.

'''project info''':: This required field {{must}} have at a minimum the name However, when using item info subproperties ("fn", "url", "photo"), they {{must}} be nested <em>inside</em> the item element.

'''author''':: The optional field specifies the person who authored the project. If the author is specified, an hCard representing the author {{must}} be provided.
The projecta format is intended to be used in conjunction with MediaWiki which will require a username to submit a new project. The username will be represented with an hCard.

'''description''':: This optional field contains the full text representing the written opinion of the author. The field {{may}} include valid HTML markup (e.g. paragraphs). User agents {{should}} preserve any markup.

'''requirements''':: This optional field contains the requirements of the project. The field {{may}} include links to products or other projects.

'''steps''':: Steps are represented using an ordered list of tasks required to complete the project. Represented as an ordered list with list elements.

'''tags''':: Tags are represented using a list of keywords or phrases (using the [[rel-tag]] microformat for each individual keyword or phrase tag) that the author associates with the project.

'''permalink''':: This optional field is a URL for the projecta. In addition to using the <code><a href></code> tag for this field, the attribute <code>rel="self bookmark"</code> {{must}} be used to indicate that the hyperlink is a permalink for the project itself. If the hyperlink already contains a <code>rel</code> attribute, then the values <code>self</code> and <code>bookmark</code> {{must}} be included among the space-separated set of values in the attribute. Indexers {{may}} treat the permalink of a project as a unique ID in order to identify and collate the same project from multiple sources (such as indexing a page multiple times). The permalink {{may}} also be used to indicate or imply the origin of the project. Authors {{may}} use the classname of "permalink" on the element representing the permalink.

The following field names have been reused from the [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]] microformats: <code>version, summary, fn, url, photo, description, tags, permalink</code>. In addition, items and authors described by hCards {{may}} contain any hCard field. The rel value "self" has been reused from the [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html Atom 1.0 specification].

=== markup sample ===
<strong>Note: this markup sample is not based on any [[project-examples]] implied schema, and therefore is an <em>a priori</em> brainstorm that is not suitable for a microformat.</strong>

<pre><nowiki>
<div class="project" id="urn:uuid:233f6e5d-2ad2-4b7e-a3fe-1b90ef2fef57">
<img class="logo" src="..." />
<span class="name">Microformats</span>
<span class="desc">An initiative to extract common patterns from POSH</span>

<h1>Some informations</h1>
<a href="http://microformats.org/" rel="home">The primary home page of the project.</a>
<a href="..." rel="source">Here you can find its source code.</a>
<a href="..." rel="release">Get the releases.</a>
<-- Every hCard is looked as a participant [including venues? ] -->

<h1>Project's tags</h1>
<ul>
<li class="tag">open</li>
<li class="tag">format</li>
<li class="tag">standard</li>
</ul>
</div>
</nowiki></pre>

=== CSS selection specification ===
<strong>Note: this markup sample is not based on any [[project-examples]] implied schema, and therefore is an <em>a priori</em> brainstorm that is not suitable for a microformat.</strong>

A good way to describe the structure, is to look at it trough the view of CSS selectors. Designers sometimes need wrappers, which makes it hard to keep a strict structure. If you used jQuery, you know what I mean.

<pre><nowiki>
.project[@id] : is an UUID (see http://ietf.org/rfc/rfc4122.txt).
A unique identifier for the project.
It is used to resolve name clashes.
.project .name : the content describes the project name.
Should not appear more that one time per project.
.project IMG.logo : the src is a link to the logo.
Can have different sizes with by adding "low | mid | high" classes.
.project A[@rel=home] : a project's home page
.project A[@rel=source] : a link to the project's source.
If it is a scm, it is generally solved by using different uris.
Like git:// or bzr:// or http+git://
.project A[@rel=release] : the linked pages contains file releases.
This page can contain hRelease microformat.
.project A[@rel=...] : many extensions can be imagined, like :
"blog | wiki | parent-project | ..."
.project .tag : the content describes a project tag. You can
have as many as you wish.
</nowiki></pre>

== to-do ==
* [[project-examples]]
* [[project-formats]]
* Lots of discussion I guess, to satisfy different kinds of projects
* Semantic approval of experts

== Notes ==
Please, keep the format simple. The current brainstorms above don't follow an existing standard (existing standards must first be documented in [[project-formats]] before proceeeding). It is preferable to re-use and develop minimal modules rather than being verbose. Are these bad or good for example: the uuid:.. or scm:// ones ?

== Related ideas ==
* Release: semantic description of a project release. Possible usages : automatic tracking and/or conversion for package managers, automatic platform/mirror selection for download managers.

project

2009-03-11T08:19:04Z

TobyInk: /* existing formats */ add hdoap

<h1>Project</h1>
This is a page for tracking the effort to develop a project microformat for authors and publishers to markup public projects like open-source software or other kinds of artistic distributions.
{{TOC-right}}
{{formatset|project}}

== problem statement ==
=== scenarios ===
One of its primary intent is to allow robots to automatically classify projects in a freshmeat  manner by browsing the web.
[[User:ZimbaTm|ZimbaTm]] 08:31, 12 Jan 2008 (PST)

== real world examples ==

=== Freshmeat.net ===
Description of the software project
* http://freshmeat.net

** full project name (This is the publicly visible project name.)
** short project name (This will be used to generate a /projects/<shortname>/ URL for your project.)
** full description
** short description
** name of author
** email address
** branch name
** branch description
** license
** homepage
** Tar/GZ
** Tar/BZ2
** Zip
** Changelog
** RPM package
** Debian package
** OS X package
** Bittorrent
** BSD Ports URL
** Autopackage URL
** Jar
** Purchase
** CVS tree (cvsweb)
** Bug tracker
** Mailing list archive
** Mirror site
** Demo site
** version
** release focus
** Dependencies

=== 43things.com ===
* http://43things.com
How I did a project

** goal title
** last words (One sentence summary.)
** how
** lessons
** time taken
** resources

== Analysis of Examples ==

=== Common project fields ===
* project (name/title|URL(s)|image)
* author (name|email|URL)
* summary

== existing formats ==
Please document in [[project-formats]].

* [http://hyperdata.org/xmlns/project/ A vocabulary for describing projects] (primarily goal-oriented)
* [http://usefulinc.com/doap/ DOAP: Description of a Project] (software project specific)
** [http://hyperdata.org/xmlns/hdoap/profile/ hDOAP] - previous [poshformat|microformat-like] effort
* [http://en.wikipedia.org/wiki/Program_Evaluation_and_Review_Technique Program Evaluation and Review Technique]

== Related microformats ==
* [[hCalendar]] for timelines, milestones, and to-do items
* Resources
** [[hCard]] for participating people
** [[product]] for stuff(?)
*** [[rel-payment]]
* [[hReview]] for debriefing

== brainstorming ==

=== Schema ===
The projecta schema consists of the following:

* Projecta ('''<code>projecta</code>''')
** '''<code>version</code>'''. optional. text.
** '''<code>summary</code>'''. optional. text.
** '''<code>project</code>''' info. required. ('''<code>url</code>''' || '''<code>photo</code>''' )
** '''<code>author</code>'''. optional. '''[[hcard|hCard]]'''.
** '''<code>description</code>'''. optional. text with optional valid HTML markup.
** requirements. optional. text with optional '''<code>url</code>''' to products or other projects.
** steps. optional. text with valid HTML '''<code>ol</code>''' ('''<code>li</code>''') elements.
** tags. optional. keywords or phrases, using '''[[rel-tag]]''', each with optional rating.
** permalink. optional, using '''[[rel-bookmark]]''' and '''[[rel-self]]'''.

=== Field details ===
The fields of the projecta schema represent the following:

'''version''':: This optional field permits projecta publishers to specify a particular version of projecta that their content uses. This field is syntax compatible with, and thus reuses the semantics of "VERSION" as defined in vCard RFC2426 section "3.6.9 VERSION Type Definition". The value of this field for this specification is "0.1".

'''summary''':: This optional field serves as a title for the project itself.

'''project info''':: This required field {{must}} have at a minimum the name However, when using item info subproperties ("fn", "url", "photo"), they {{must}} be nested <em>inside</em> the item element.

'''author''':: The optional field specifies the person who authored the project. If the author is specified, an hCard representing the author {{must}} be provided.
The projecta format is intended to be used in conjunction with MediaWiki which will require a username to submit a new project. The username will be represented with an hCard.

'''description''':: This optional field contains the full text representing the written opinion of the author. The field {{may}} include valid HTML markup (e.g. paragraphs). User agents {{should}} preserve any markup.

'''requirements''':: This optional field contains the requirements of the project. The field {{may}} include links to products or other projects.

'''steps''':: Steps are represented using an ordered list of tasks required to complete the project. Represented as an ordered list with list elements.

'''tags''':: Tags are represented using a list of keywords or phrases (using the [[rel-tag]] microformat for each individual keyword or phrase tag) that the author associates with the project.

'''permalink''':: This optional field is a URL for the projecta. In addition to using the <code><a href></code> tag for this field, the attribute <code>rel="self bookmark"</code> {{must}} be used to indicate that the hyperlink is a permalink for the project itself. If the hyperlink already contains a <code>rel</code> attribute, then the values <code>self</code> and <code>bookmark</code> {{must}} be included among the space-separated set of values in the attribute. Indexers {{may}} treat the permalink of a project as a unique ID in order to identify and collate the same project from multiple sources (such as indexing a page multiple times). The permalink {{may}} also be used to indicate or imply the origin of the project. Authors {{may}} use the classname of "permalink" on the element representing the permalink.

The following field names have been reused from the [[hcard|hCard]], [[hcalendar|hCalendar]], and [[hreview|hReview]] microformats: <code>version, summary, fn, url, photo, description, tags, permalink</code>. In addition, items and authors described by hCards {{may}} contain any hCard field. The rel value "self" has been reused from the [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html Atom 1.0 specification].

=== markup sample ===
<strong>Note: this markup sample is not based on any [[project-examples]] implied schema, and therefore is an <em>a priori</em> brainstorm that is not suitable for a microformat.</strong>

<pre><nowiki>
<div class="project" id="urn:uuid:233f6e5d-2ad2-4b7e-a3fe-1b90ef2fef57">
<img class="logo" src="..." />
<span class="name">Microformats</span>
<span class="desc">An initiative to extract common patterns from POSH</span>

<h1>Some informations</h1>
<a href="http://microformats.org/" rel="home">The primary home page of the project.</a>
<a href="..." rel="source">Here you can find its source code.</a>
<a href="..." rel="release">Get the releases.</a>
<-- Every hCard is looked as a participant [including venues? ] -->

<h1>Project's tags</h1>
<ul>
<li class="tag">open</li>
<li class="tag">format</li>
<li class="tag">standard</li>
</ul>
</div>
</nowiki></pre>

=== CSS selection specification ===
<strong>Note: this markup sample is not based on any [[project-examples]] implied schema, and therefore is an <em>a priori</em> brainstorm that is not suitable for a microformat.</strong>

A good way to describe the structure, is to look at it trough the view of CSS selectors. Designers sometimes need wrappers, which makes it hard to keep a strict structure. If you used jQuery, you know what I mean.

<pre><nowiki>
.project[@id] : is an UUID (see http://ietf.org/rfc/rfc4122.txt).
A unique identifier for the project.
It is used to resolve name clashes.
.project .name : the content describes the project name.
Should not appear more that one time per project.
.project IMG.logo : the src is a link to the logo.
Can have different sizes with by adding "low | mid | high" classes.
.project A[@rel=home] : a project's home page
.project A[@rel=source] : a link to the project's source.
If it is a scm, it is generally solved by using different uris.
Like git:// or bzr:// or http+git://
.project A[@rel=release] : the linked pages contains file releases.
This page can contain hRelease microformat.
.project A[@rel=...] : many extensions can be imagined, like :
"blog | wiki | parent-project | ..."
.project .tag : the content describes a project tag. You can
have as many as you wish.
</nowiki></pre>

== to-do ==
* [[project-examples]]
* [[project-formats]]
* Lots of discussion I guess, to satisfy different kinds of projects
* Semantic approval of experts

== Notes ==
Please, keep the format simple. The current brainstorms above don't follow an existing standard (existing standards must first be documented in [[project-formats]] before proceeeding). It is preferable to re-use and develop minimal modules rather than being verbose. Are these bad or good for example: the uuid:.. or scm:// ones ?

== Related ideas ==
* Release: semantic description of a project release. Possible usages : automatic tracking and/or conversion for package managers, automatic platform/mirror selection for download managers.

to-do

2009-03-10T16:55:00Z

TobyInk: /* Wiki improvements */ openid comment

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

== Lazyweb ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

====Spelling====
Per [[how-to-play]]: for English-language pages only: Find British spellings of common words and replace them with the US spellings per [[en-US]]. Mark such edits as "minor" with the comment: <nowiki>[[en-US]]</nowiki>. Please be careful to use and maintain proper native spelling of proper nouns (see [[how-to-play]] for details).

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

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

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

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

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

=== Wiki improvements ===

* Set up a cron job to export the wiki database (without user details), and make it available in a public location.
* Add Extensions
** Evaluate against Wikipedia's [http://en.wikipedia.org/wiki/Special:Version Version Page] for a list of currently installed extensions on the English Wikipedia.
** I'd personally advise getting [http://www.mediawiki.org/wiki/Extension:Cite Cite], [http://meta.wikimedia.org/wiki/ParserFunctions ParserFunctions] --[[User:JimboJW|JimboJW]] 13:38, 25 Sep 2007 (PDT) (Syntax Highlighting is done in Wiki 2.0)
** OpenID login, on behalf of a request a while ago from [[User:DanC]]. [[User:Tantek|Tantek]] 20:50, 20 Jul 2007 (PDT) (Planned for Wiki 2.0)
*** Regarding OpenID Log-in. Needs lightweight extension. Current extension turns the wiki into an OpenID *provider*. DO NOT WANT. Anyone want to write a simple OpenID login extension for MediaWiki?
**** You could always install the OpenID extension and then use Apache to block access to ''Special:OpenIDServer''.
** [http://www.mediawiki.org/wiki/Extension:HTML_Profiles HTML Profiles] - allows people editing the wiki to add URIs to <code><head profile></code> [[User:TobyInk|TobyInk]] 16:52, 9 March 2009 (UTC)
** [http://www.mediawiki.org/wiki/Extension:Link_Attributes Link Attributes] - allows easy-ish setting of rel/rev/class attributes on links. [[User:TobyInk|TobyInk]] 16:52, 9 March 2009 (UTC)
* 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)
* add a class, <code>noprint</code> to the site's CSS, so that sections (such as "related pages" footers) can be made non- printing.
** ‘noprint’ isn't so semantic, but we should get a proper print stylesheet, for sure.
* Add admins sidebar (quick ban list access)
* Make the edit comment UI better — textarea, not single line box. (Dev Status: Might be impossible without hacking the core)
* New link styles for links to mailing list archive
* Allow <kbd>webcal://</kbd> and (other) x-protocols to be linkified
* Add proper styling to phrase elements
* Do something to allow easy copying of sample input (e.g. add ‘Copy’ UI, or abuse <code>input</code> element
* Fix MediaWiki to lowercase URLs — especially fragment identifiers generated from headings. Content ''should not'' be sub-optimally edited according to the requirements of the CMS.
* Can we imply <code>entry-title</code> from <code>h1</code>?

===-Issues 2.0===

Issue tracking at microformats.org is poor. The wiki is difficult to track, resolutions get lost. A proper bug tracking system is desirable: However, the adminstration overhead of our current infrastructure is too high for volunteers. Questionable whether maintain another custom install of something is the direct we want to move in.

Aim is:

* Investigate possibility/santity of using Launchpad/Github/Google Code for spec issue tracking
* Wiki is excellent documentation tool. Terrible issue tracking tool.
* External services avoid large maintenance burden
* Could better handle this todo list
* Better handle issue resolutions
* Better handle issue discussions

====Considering====

=====Custom Install of Trac=====

* + Reliable
* + Well Established
* + Can customise to look like µf.org
* + Flexible milestones etc.
* + Hook into source repository of our choosing
* + OpenID support
* + Support whatever licensing we like
* - Administration overhead

Need to check permissions structures. Can the hCard editor have control over /hcard, but not over /haudio? Do we care?

=====Google Code=====

Chris Messina has ‘microformats’ on Google Code

* + Reliably Hosted, minimal admin overhead
* + Very flexible milestones/tagging
* + SVN repository for test cases, libraries
* - Can't be styled to µf.org
* - No OpenID
* - Ugly as sin
* - No Public Domain license support

=====Launchpad=====

Ben Ward has ‘microformats’ on Launchpad

* + BZR repository for test cases, libraries
* + Public Domain License Support
* - Not instantly intuitive
* - Seems better suited to software than specifications
* - Can't style like µf.org, but, quite pretty
* - No OpenID

=====Github=====

* + Git repository for test cases, libraries
* - Issue tracking is external (Lighthouse)
* - No OpenID

====Process====

* Evaluate options
** Consider integration points with µf.org
** Consider open standards a plus (OpenID)
** Consider effort in porting existing content
* Copy over issues from each wiki page as standalone bugs
* Ensure that each spec editor is added with suitable authorities to manage issues

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

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

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

=== protect the community ===
* Analyze [[Special:Recentchanges]] and [http://microformats.org/discuss mailing-lists] and:
** add to [[mailing-lists]] and [[how-to-play]] policies/guidelines accordingly.
** redirect and resolve threads accordingly per guidelines
** privately email violaters kindly asking them to improve their behavior
** work with admins on next steps for individuals negatively impacting the community
** recognize noisy/distracting threads on the email list, document responses/answers to such subjects on the appropriate page(s) on the wiki, and reply to those threads with the URLs to the documentation on the wiki. Putting the responses/answers on the wiki helps by hopefully providing preemptive answers to some who might reraise the subjects on the list in the future, and helps the community quickly terminate such threads by using the answers on the wiki.
** remove noise from [[Main_Page|the wiki home page]] by simplifying/shortening it
*** <s>move exploratory discussions to a separate page (think about what to name it)</s>
*** move exploratory discussions which are failing to follow the process to a separate page from that
** repair damage done to the wiki
*** identify damage done to the wiki - often in forms as simple as content changes that hurt usability (and thus accessibility)
*** document additional [[how-to-play]] guidelines to discourage and hopefully reduce such wiki damaging behavior in the future
*** repair/undo/reorganize page section division that hurt usability (and thus accessibility)
**** [[hcalendar-examples-in-wild]]
***** afterwards add some of the excellent conference schedule calendars that [[User:Adactio]] has been creating like:
****** http://adactio.com/extras/schedules/barcampbrighton3/
*** repair/undo/reorganize page splitting that hurt usability (and thus accessibility)
**** [[to-do]]

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

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

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

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

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

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

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

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

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

=== iterate on current microformats ===
==== in general ====
===== plain language intros =====
For [[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [[xoxo|XOXO]] to start with, write up:
* brief plain-language intro at the top (say for example, something that a non-technical person like a member of the general media/press could read and understand), similar to or better than plain language intros on W3C specs.
* followed by links to more plain-language resources, e.g. *-intro pages.
In particular for [[xoxo|XOXO]], Angus McIntyre suggested:
* As well as a syntactic example, examples of use would be useful.
* when I might want to use XOXO.
* Some simple examples right upfront would probably do a lot to help users figure out whether a particular microformat is for them or not.
These suggestions could be incorporated into the other specs as well.
===== minor update current specifications =====
* double check [[value-excerption-pattern]] parsing suggested additions, issue resolutions, brainstorming
* add new [[value-excerption-pattern]] rules for datetime property extractions (special parsing of date, time, timezone, timewithzone), no special rules for url or email
* think about solving enumerated type issue (in [[hcard-issues]]) - perhaps with [[value-excerption-pattern-brainstorming]]
* resolve remaining [[hcard-issues|hCard issues]]
* resolve remaining [[hcalendar-issues|hCalendar issues]]
* iterate [[hcard-parsing]] with [[value-excerption-pattern]] as a required feature
* draft hCard 1.0.1
* draft hCalendar 1.0.1
* draft hReview 0.4
* co-edit hAtom per permission from David Janes
* draft [[hAtom]] 0.2
* add sections for comments/opinion from community as well as issues subsection
* solicit feedback
* when sufficient consensus and issue resolution achieved, archive previous versions of specs, and update spec pages accordingly.

===== exploratory discussions =====
* update [[exploratory-discussions]] with critical microformats as "active"
===== CSS enhancements for =====
Analyze existing microformats for opportunities to enhance CSS and propose to W3C.
* e.g. CSS datetime presentation (need to add links to my earlier work in CSS working group)
* brainstorm additional possibilities for better presentation of content using existing microformats.
===== update affiliations =====
* Start a minimal draft/spec style guide using outline of most readable/accessible spec so far
* Reference http://www.w3.org/2001/06/manual/#Editors for how to manage affiliations
* Update affiliations on [[hcard]], [[hcalendar]], [[hreview]], etc. per http://www.w3.org/2001/06/manual/#Editors
===== profile URLs =====
* write-up and document [[profile-uris|profile URLs]] for all established microformats and perhaps for some drafts as well

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== introduction / community ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Dimitri Glazkov ==

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

== Chris Messina ==

=== General ===

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

=== Campaigns ===

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

=== Wishlist ===

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

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

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

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

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

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

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

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

=== additions to the wiki ===

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

== Mark Rickerby ==

=== Current Tasks ===

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

=== Wishlist ===

* hmmm

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

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

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

== Dan Connolly ==

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

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

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

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

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

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

== Chris Casciano ==

[[User:ChrisCasciano|ChrisCasciano]]

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

== Drew McLellan ==

[[User:DrewMcLellan|DrewMcLellan]]

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

== Christophe Ducamp (french localization) ==

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

== Frances Berriman ==

[[User:Phae|Frances Berriman]]

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

== Ben West (bewest) ==

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

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

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

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

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

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

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

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

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

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

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

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

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

These pages would be located respectively at

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

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

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

== Matt Dertinger (Thewhoo) ==

[[User:Thewhoo]]

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

=== Microformats Proposals ===

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

== Henri Bergius ==

[[User:HenriBergius|Henri Bergius]]

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

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

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

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

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

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

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

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

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

=== Recurring ===

* Delete Wiki Spam

=== Currently ===

* [[value-excerption-pattern]] specification
* embed brainstorming
* Improve communication of various microformats wiki pages
* Considering new welcome banner of µf.org to link to various µf resources, rather than being dominated by the infrequently updated blog.

=== Next Actions ===

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

what-are-microformats

2009-03-10T12:31:07Z

TobyInk: /* From The Mailing List */ add citation

__NOTOC__

First time visitors, see the [[introduction]] page first.

<h1>What are microformats?</h1>
{{TOC-right}}

== Launch Definition ==

The current definition on the [http://microformats.org home page] says:

<blockquote style="font-size:larger">Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards.</blockquote>

originally written by Dan Cederholm with help from Tantek Çelik for the launch of [http://microformats.org microformats.org] on June 20th, 2005.

== From The Mailing List ==
<blockquote style="font-size:larger">Microformats are simple conventions for embedding semantics in HTML to enable decentralized development.</blockquote>

from someone on the microformats-discuss mailing list. Please link/cite if you know the origin of this.

* Mostly seems to originate from [http://microformats.org/discuss/mail/microformats-discuss/2005-September/000923.html Dr Ernie Prabhakar] but with [http://microformats.org/discuss/mail/microformats-discuss/2005-September/date.html#923 some later development].

== More Specifically From The Mailing List ==
One popular definition from our [http://microformats.org/discuss/ mailing list] (see also: [[mailing-lists]]) is "simple conventions for embedding semantics in HTML to enable decentralized development." More precisely, microformats can be defined as:
<blockquote style="font-size:larger" cite="http://microformats.org/discuss/mail/microformats-discuss/2005-September/000922.html">
:simple conventions
:for embedding semantic markup
::for a specific problem domain
:in human-readable (X)HTML/XML documents, Atom/RSS feeds, and "plain" XML
::that normalize existing content usage patterns
::using brief, descriptive class names
::often based on existing interoperable standards
:to enable decentralized development
::of resources, tools, and services
</blockquote>

http://microformats.org/discuss/mail/microformats-discuss/2005-September/000922.html by Dr. [http://ihack.us/ Ernie Prabhakar]

"Or do you just use your browser to browse? That's so 20th century." -- [http://diveintomark.org Mark Pilgrim]

== Chris Messina ==
<blockquote style="font-size:larger">
Microformats are simple codes that you can use to identify specific kinds of data, like people or events, in your webpages.
</blockquote>

== Tantek Çelik ==
<blockquote style="font-size:larger"><p>Microformats are the way to publish and share information on <strong>the web with higher fidelity</strong>.</p><p>For example, if a company wanted their <strong>contact information</strong> to be easily found and shared, they would publish it with [[hcard|hCard]]. Similarly if an organization is planning a series of events and wants more people to know about them and add them to their calendars, then they would publish their <strong>events listing</strong> with [[hcalendar|hCalendar]]. For advocacy groups, whenever they take a position on some political leader, some piece of legislation etc., if they wanted their <strong>evaluations/reviews/ratings</strong> of those people/laws to be more easily found and passed around, they would publish such opinions with [[hreview|hReview]]. For all of these, to make it easier, publishers can use [[implementations|tools and services that support microformats]].</p><p>The key here is that microformats are simple/easy enough that the any organizations own <strong>web authors/designers can easily add them</strong> in themselves. Adding microformats is easier than publishing an RSS feed for example. You don't have to be a programmer. Anyone with decent (X)HTML+CSS authoring/writing skills can use microformats. Pretty much anyone who is literate can be taught how to author HTML+CSS, and thus microformats makes use of very widely available skill sets.</p></blockquote>

From an IRC conversation 2006-06-06 which helped "knowprose" grok microformats. Update 2006-06-07: knowprose's blog post [http://www.knowprose.com/node/15844 Making Sense of Microformats: Have Data, Will Find It].

<blockquote style="font-size:larger"><p>microformats are carefully designed (X)HTML class names that extend the semantics of (X)HTML and enable authors to publish higher semantic fidelity content such as people, events, reviews, etc.</p></blockquote>

From an IRC conversation 2006-07-28 with tcaspers on irc.freenode.net/#wasp.

<blockquote style="font-size:larger"><p>a microformat is way of adding more meaning to web pages beyond normal HTML headings and paragraphs, so you can indicate mentions of people, companies, events, reviews, tags, etc.</p></blockquote>

From an instant message conversation 2007-07-06.

== Drew McLellan ==
<blockquote style="font-size:larger">Microformats are a way of attaching extra meaning to the information published on a web page. This extra semantic richness works alongside the information already presented, and can be used for the benefit of people and computers. This is mostly done through adding special pre-defined names to the class attribute of existing XHTML markup.</blockquote>

from an IRC conversation

== Aaron Gustafson ==
Simply put: "Microformats are a codification of convention." -- [http://easy-reader.net Aaron Gustafson]

==Alok Jain==
<blockquote style="font-size:larger">microformats are evolving frameworks for how to present commonly used data items. For e.g. hCard microformat provides framework to capture a person's details First, middle, last name,company, contact info etc.</blockquote>

In my view this is doing two things:
*a Bringing some amount of standardization to commonly used data sets, which can lead to several benefits towards data retreival
*a Bringing an implicit meta data structure which again can be used to fetch informaiton at more granular level. SO in above example one could fetch just the company name, even thought there is not meta data around company name

[http://www.iPrincipia.com Alok Jain]

== Dave Sanford ==
Chris asked me to contribute my 'definition,' although I refer to it as a distillation:

“Microformats are a way of identifying and labeling classes of commonly used data that make it easier for humans or computers to locate or distribute such information on websites.”

==Andy Mabbett==
Here's my re-write of the current opening blurb, from:

<blockquote style="font-size:larger">Designed for humans first and machines second, microformats are a set of simple, open data formats built upon existing and widely adopted standards.</blockquote>

to:

<blockquote style="font-size:larger;">Microformats are a way of adding simple markup to human-readable data items such as events, contact details or locations, on web pages, so that the information in them can be extracted by software and indexed, searched for, saved, cross-referenced or combined.</blockquote>

Which can be followed by:

<blockquote style="font-size:larger;">More technically, they are items of semantic markup, using just standard (X)HTML with a set of common class-names. They are open and available, freely, for anyone to use.</blockquote>

Principles:
*Start with "Microformats are"
*Mention web pages
*Say what purpose microformats serve
*Use plain language

== Guillaume Lebleu ==
<blockquote style="font-size:larger">Microformats are simple standardized annotations of content available on the Web that provide a practical solution today to more productive and decentralized Web-based information search and sharing. </blockquote>

<blockquote style="font-size:larger">In other words, Microformats allow you today to copy/paste information from a Web page, for instance someone's contact information from their blog to your address book, instead of manually retyping it. Eventually, microformats will allow anyone to make the information they publish easily sharable and searchable (products, events, resume, etc.) without having to duplicate and maintain up-to-date their data in centralized databases.</blockquote>

== BenWest ==
<blockquote style="font-size:larger;">
A microformat is a specific collection of names, values, and accompanying structure defined through rigorous market research intended to consider pervasive use of semantic html that increases data fidelity in HTML-borne data widely distributed on the web.

Microformats are more than one of these, eg "hcard and hcal are microformats."
</blockquote>

== DerrickPallas ==
<blockquote style="font-size:larger;">microformats are semantics with momentum, a codification of what everyone did anyway. They are what works, written down.</blockquote>

== Alessandro Martin ==
<blockquote style="font-size:larger;">
Microformats are frames for your contents. Using microformats you tell, in a way both humans and machines can understand, what is the basic meaning of what you are writing in a web document.
</blockquote>

written by [http://www.thinkpragmatic.net Alessandro Martin].

== Alan Hogan ==
<blockquote>
<p style="font-size:larger;">Microformats are a guarantee that anyone who wants to can grab certain types of data from your website without worrying much that a site redesign will require the to build a whole new parser.</p>

<p style="font-size:larger;">Microformats is to people and comptuers what Java is to operating systems. Java programs are written once and run on Mac, Windows, Linux, Solaris, etc. Microformats-enabled web pages are written once and are understandable by both humans and computers.</p>
</blockquote>

written by [http://alanhogan.com/ Alan Hogan].

==Hugh Macleod==

[http://flickr.com/photos/tantek/1385900792 http://farm2.static.flickr.com/1276/1385900792_0769162b18.jpg]

2007 September by [http://gapingvoid.com Hugh Macleod].

== Toby Inkster ==
<blockquote style="font-size:larger;">You know all that stuff you already have on your website? Microformats tell computers what that stuff is.
</blockquote>

== Asa Berdahl ==
<blockquote style="font-size:larger;">microformats are a set of rules that utilize present technology to make it not only more easily interactive, but human-friendly as well. microformats uses long standing practices of good web design techniques combined with simple changes in coding to make content far more than just plain text.</blockquote>

written by Asa Berdahl.

== Yuval Ararat ==
<blockquote style="font-size:larger;">Microformats are the incarnation of Semantic Web in the XHTML standard, they make text surrounded by markup relevant to its meaning and not its markup. The standardization effort that is collected here is the embodiment of the new Web 3.0.</blockquote>

written by Yuval Ararat.

== Add Yours Here ==
<blockquote style="font-size:larger;">microformats are...(insert your definition here)
</blockquote>

written by You.

'''Note:''' feedback on the existing definition or those on this page can be found in the [[definition-feedback]]. Please add feedback there (rather than inline here).

== See Also ==
* [[what-can-you-do-with-microformats]]
* [[faq]]
* [[definition-feedback]]

== Translation ==
* [[what-are-microformats-fr|c'est quoi les microformats]] (fr)

to-do

2009-03-09T16:52:08Z

TobyInk: /* Wiki improvements */ I created these extensions today. Might be useful.

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

== Lazyweb ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

====Spelling====
Per [[how-to-play]]: for English-language pages only: Find British spellings of common words and replace them with the US spellings per [[en-US]]. Mark such edits as "minor" with the comment: <nowiki>[[en-US]]</nowiki>. Please be careful to use and maintain proper native spelling of proper nouns (see [[how-to-play]] for details).

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

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

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

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

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

=== Wiki improvements ===

* Set up a cron job to export the wiki database (without user details), and make it available in a public location.
* Add Extensions
** Evaluate against Wikipedia's [http://en.wikipedia.org/wiki/Special:Version Version Page] for a list of currently installed extensions on the English Wikipedia.
** I'd personally advise getting [http://www.mediawiki.org/wiki/Extension:Cite Cite], [http://meta.wikimedia.org/wiki/ParserFunctions ParserFunctions] --[[User:JimboJW|JimboJW]] 13:38, 25 Sep 2007 (PDT) (Syntax Highlighting is done in Wiki 2.0)
** OpenID login, on behalf of a request a while ago from [[User:DanC]]. [[User:Tantek|Tantek]] 20:50, 20 Jul 2007 (PDT) (Planned for Wiki 2.0)
** Regarding OpenID Log-in. Needs lightweight extension. Current extension turns the wiki into an OpenID *provider*. DO NOT WANT. Anyone want to write a simple OpenID login extension for MediaWiki?
** [http://www.mediawiki.org/wiki/Extension:HTML_Profiles HTML Profiles] - allows people editing the wiki to add URIs to <code><head profile></code> [[User:TobyInk|TobyInk]] 16:52, 9 March 2009 (UTC)
** [http://www.mediawiki.org/wiki/Extension:Link_Attributes Link Attributes] - allows easy-ish setting of rel/rev/class attributes on links. [[User:TobyInk|TobyInk]] 16:52, 9 March 2009 (UTC)
* 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)
* add a class, <code>noprint</code> to the site's CSS, so that sections (such as "related pages" footers) can be made non- printing.
** ‘noprint’ isn't so semantic, but we should get a proper print stylesheet, for sure.
* Add admins sidebar (quick ban list access)
* Make the edit comment UI better — textarea, not single line box. (Dev Status: Might be impossible without hacking the core)
* New link styles for links to mailing list archive
* Allow <kbd>webcal://</kbd> and (other) x-protocols to be linkified
* Add proper styling to phrase elements
* Do something to allow easy copying of sample input (e.g. add ‘Copy’ UI, or abuse <code>input</code> element
* Fix MediaWiki to lowercase URLs — especially fragment identifiers generated from headings. Content ''should not'' be sub-optimally edited according to the requirements of the CMS.
* Can we imply <code>entry-title</code> from <code>h1</code>?

===-Issues 2.0===

Issue tracking at microformats.org is poor. The wiki is difficult to track, resolutions get lost. A proper bug tracking system is desirable: However, the adminstration overhead of our current infrastructure is too high for volunteers. Questionable whether maintain another custom install of something is the direct we want to move in.

Aim is:

* Investigate possibility/santity of using Launchpad/Github/Google Code for spec issue tracking
* Wiki is excellent documentation tool. Terrible issue tracking tool.
* External services avoid large maintenance burden
* Could better handle this todo list
* Better handle issue resolutions
* Better handle issue discussions

====Considering====

=====Custom Install of Trac=====

* + Reliable
* + Well Established
* + Can customise to look like µf.org
* + Flexible milestones etc.
* + Hook into source repository of our choosing
* + OpenID support
* + Support whatever licensing we like
* - Administration overhead

Need to check permissions structures. Can the hCard editor have control over /hcard, but not over /haudio? Do we care?

=====Google Code=====

Chris Messina has ‘microformats’ on Google Code

* + Reliably Hosted, minimal admin overhead
* + Very flexible milestones/tagging
* + SVN repository for test cases, libraries
* - Can't be styled to µf.org
* - No OpenID
* - Ugly as sin
* - No Public Domain license support

=====Launchpad=====

Ben Ward has ‘microformats’ on Launchpad

* + BZR repository for test cases, libraries
* + Public Domain License Support
* - Not instantly intuitive
* - Seems better suited to software than specifications
* - Can't style like µf.org, but, quite pretty
* - No OpenID

=====Github=====

* + Git repository for test cases, libraries
* - Issue tracking is external (Lighthouse)
* - No OpenID

====Process====

* Evaluate options
** Consider integration points with µf.org
** Consider open standards a plus (OpenID)
** Consider effort in porting existing content
* Copy over issues from each wiki page as standalone bugs
* Ensure that each spec editor is added with suitable authorities to manage issues

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

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

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

=== protect the community ===
* Analyze [[Special:Recentchanges]] and [http://microformats.org/discuss mailing-lists] and:
** add to [[mailing-lists]] and [[how-to-play]] policies/guidelines accordingly.
** redirect and resolve threads accordingly per guidelines
** privately email violaters kindly asking them to improve their behavior
** work with admins on next steps for individuals negatively impacting the community
** recognize noisy/distracting threads on the email list, document responses/answers to such subjects on the appropriate page(s) on the wiki, and reply to those threads with the URLs to the documentation on the wiki. Putting the responses/answers on the wiki helps by hopefully providing preemptive answers to some who might reraise the subjects on the list in the future, and helps the community quickly terminate such threads by using the answers on the wiki.
** remove noise from [[Main_Page|the wiki home page]] by simplifying/shortening it
*** <s>move exploratory discussions to a separate page (think about what to name it)</s>
*** move exploratory discussions which are failing to follow the process to a separate page from that
** repair damage done to the wiki
*** identify damage done to the wiki - often in forms as simple as content changes that hurt usability (and thus accessibility)
*** document additional [[how-to-play]] guidelines to discourage and hopefully reduce such wiki damaging behavior in the future
*** repair/undo/reorganize page section division that hurt usability (and thus accessibility)
**** [[hcalendar-examples-in-wild]]
***** afterwards add some of the excellent conference schedule calendars that [[User:Adactio]] has been creating like:
****** http://adactio.com/extras/schedules/barcampbrighton3/
*** repair/undo/reorganize page splitting that hurt usability (and thus accessibility)
**** [[to-do]]

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

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

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

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

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

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

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

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

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

=== iterate on current microformats ===
==== in general ====
===== plain language intros =====
For [[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [[xoxo|XOXO]] to start with, write up:
* brief plain-language intro at the top (say for example, something that a non-technical person like a member of the general media/press could read and understand), similar to or better than plain language intros on W3C specs.
* followed by links to more plain-language resources, e.g. *-intro pages.
In particular for [[xoxo|XOXO]], Angus McIntyre suggested:
* As well as a syntactic example, examples of use would be useful.
* when I might want to use XOXO.
* Some simple examples right upfront would probably do a lot to help users figure out whether a particular microformat is for them or not.
These suggestions could be incorporated into the other specs as well.
===== minor update current specifications =====
* double check [[value-excerption-pattern]] parsing suggested additions, issue resolutions, brainstorming
* add new [[value-excerption-pattern]] rules for datetime property extractions (special parsing of date, time, timezone, timewithzone), no special rules for url or email
* think about solving enumerated type issue (in [[hcard-issues]]) - perhaps with [[value-excerption-pattern-brainstorming]]
* resolve remaining [[hcard-issues|hCard issues]]
* resolve remaining [[hcalendar-issues|hCalendar issues]]
* iterate [[hcard-parsing]] with [[value-excerption-pattern]] as a required feature
* draft hCard 1.0.1
* draft hCalendar 1.0.1
* draft hReview 0.4
* co-edit hAtom per permission from David Janes
* draft [[hAtom]] 0.2
* add sections for comments/opinion from community as well as issues subsection
* solicit feedback
* when sufficient consensus and issue resolution achieved, archive previous versions of specs, and update spec pages accordingly.

===== exploratory discussions =====
* update [[exploratory-discussions]] with critical microformats as "active"
===== CSS enhancements for =====
Analyze existing microformats for opportunities to enhance CSS and propose to W3C.
* e.g. CSS datetime presentation (need to add links to my earlier work in CSS working group)
* brainstorm additional possibilities for better presentation of content using existing microformats.
===== update affiliations =====
* Start a minimal draft/spec style guide using outline of most readable/accessible spec so far
* Reference http://www.w3.org/2001/06/manual/#Editors for how to manage affiliations
* Update affiliations on [[hcard]], [[hcalendar]], [[hreview]], etc. per http://www.w3.org/2001/06/manual/#Editors
===== profile URLs =====
* write-up and document [[profile-uris|profile URLs]] for all established microformats and perhaps for some drafts as well

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=== introduction / community ===

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

== Dimitri Glazkov ==

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

== Chris Messina ==

=== General ===

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

=== Campaigns ===

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

=== Wishlist ===

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

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

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

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

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

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

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

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

=== additions to the wiki ===

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

== Mark Rickerby ==

=== Current Tasks ===

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

=== Wishlist ===

* hmmm

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

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

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

== Dan Connolly ==

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

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

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

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

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

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

== Chris Casciano ==

[[User:ChrisCasciano|ChrisCasciano]]

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

== Drew McLellan ==

[[User:DrewMcLellan|DrewMcLellan]]

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

== Christophe Ducamp (french localization) ==

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

== Frances Berriman ==

[[User:Phae|Frances Berriman]]

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

== Ben West (bewest) ==

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

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

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

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

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

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

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

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

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

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

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

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

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

These pages would be located respectively at

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

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

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

== Matt Dertinger (Thewhoo) ==

[[User:Thewhoo]]

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

=== Microformats Proposals ===

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

== Henri Bergius ==

[[User:HenriBergius|Henri Bergius]]

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

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

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

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

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

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

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

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

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

=== Recurring ===

* Delete Wiki Spam

=== Currently ===

* [[value-excerption-pattern]] specification
* embed brainstorming
* Improve communication of various microformats wiki pages
* Considering new welcome banner of µf.org to link to various µf resources, rather than being dominated by the infrequently updated blog.

=== Next Actions ===

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

profile-uris

2009-03-09T10:46:02Z

TobyInk: /* How to link to a profile URI */ Tidy up, add MediaWiki extension

<entry-title>Profile URIs</entry-title>
{{TOC-right}}

== Introduction ==

In [[hcalendar-issues]], it is ACCEPTED that each microformat should have a profile URI, like [http://gmpg.org/xfn/11 the XFN profile].

==Known URIs==

This section lists known profile URIs for microformats. To promote cacheability and recognisability of profile URIs, authors {{should}} avoid minting new URIs for existing microformats, and {{should}} re-use existing well-known profile URIs.

=== Combined Profile ===

The following URL covers all non-draft Microformats as of March 2008, except XMDP. You can mix and match it with other XMDP profiles for new/draft microformats.

http://purl.org/uF/2008/03/

=== Individual Microformats ===

<dl>
<dt>adr
<dd>(Use an hCard profile.)
<dd>(Or use the combined profile.)
<dt>figure
<dd>http://purl.org/uF/figure/draft
<dt>geo
<dd>http://purl.org/uF/geo/0.9/
<dd>(Or use an hCard profile.)
<dd>(Or use the combined profile.)
<dt>hAtom
<dd>http://purl.org/uF/hAtom/0.1/
<dt>hAudio
<dd>http://purl.org/NET/haudio &dagger;
<dd>http://purl.org/uF/hAudio/0.9/ &dagger;
<dt>hCalendar
<dd>http://purl.org/uF/hCalendar/1.0/ &dagger;
<dd>http://www.w3.org/2002/12/cal/hcal ¶&dagger;
<dd>http://dannyayers.com/microformats/hcalendar-profile &dagger;
<dd>(Or use the combined profile.)
<dt>hCard
<dd>http://purl.org/uF/hCard/1.0/ &dagger;
<dd>http://www.w3.org/2006/03/hcard &dagger;
<dd>(Or use the combined profile.)
<dt>hResume
<dd>http://microformats.org/wiki/hresume-profile
<dt>hReview
<dd>http://www.purl.org/stuff/rev# &dagger;
<dt>rel-license
<dd>http://purl.org/uF/rel-license/1.0/ &dagger;
<dd>(Or use the combined profile.)
<dt>rel-nofollow
<dd>http://purl.org/uF/rel-nofollow/1.0/
<dd>(Or use the combined profile.)
<dt>rel-tag
<dd>http://purl.org/uF/rel-tag/1.0/
<dd>(Or use the combined profile.)
<dt>VoteLinks
<dd>http://purl.org/uF/VoteLinks/1.0/ &dagger;
<dd>http://tommorris.org/profiles/votelinks ¶&dagger;
<dd>(Or use the combined profile.)
<dt>XFN
<dd>http://gmpg.org/xfn/11
<dd>http://gmpg.org/xfn/1 (older version)
<dd>(Or use the combined profile.)
<dt>xFolk
<dd>http://microformats.org/wiki/xfolk-profile
<dt>XOXO
<dd>(Use the combined profile.)
</dl>

&dagger; = GRDDL-enabled.<br/>
¶ = non-XMDP profile.

=== Other Interesting Profile URIs ===

* [http://purl.org/uF/pattern-data-class/1 Experimental data-* class pattern]
* [http://purl.org/stuff/hdoap/profile hDOAP (posh format)] ¶&dagger;

== How to link to a profile URI ==

=== HTML 4.x / XHTML 1.x ===

<pre><nowiki><html>
<head profile="http://example.com/profile1 http://example.net/profile2">
...</nowiki></pre>

=== (X)HTML 5 / XHTML 2 ===

An alternative method is provided for people using markup languages which do not support <code><nowiki><head profile></nowiki></code>. Add <code>rel="profile"</code> to either a visible link (<code><nowiki><a></nowiki></code>) or hidden link (<code><nowiki><link></nowiki></code>).

Example:
<pre><nowiki><p>This page uses
<a rel="profile" href="http://gmpg.org/xfn/11">XFN 1.1</a>!</p></nowiki></pre>

=== Content Management Systems, etc ===

* [http://www.mediawiki.org/wiki/Extension:HTML_Profiles MediaWiki extension for profile URIs]

==Implementations==

=== GRDDL ===

Tools that support [http://www.w3.org/2001/sw/grddl-wg/ GRDDL] use profiles to parse microformats.

=== Cognition===

In "strict mode", [http://buzzword.org.uk/cognition/ Cognition] refuses to parse any microformats where the profile URI has not been explicitly declared on the page. (It will however, still parse microformats for which there exists no profile URI!)

== Issues ==

Some issues include:

* what domain to use? Candidates include:
** microformats.org
** www.w3.org
** xmdp.org
* what about versioning? How to keep in sync with the wiki and test materials?
* what profile URI to use for combinations, such as [[hcard]] and [[hcalendar]]?
** note [http://www.w3.org/TR/html401/struct/global.html#adef-profile HTML4.01] states "that one or more meta data profiles, [are] separated by white space"; though it's simpler for authors if they can just use one profile URI.
* More profiles are needed.

One proposal is: use www.w3.org, following [http://www.w3.org/1999/10/nsuri W3C namespace policy]. As to versioning, change the profile whenever the wiki changes (within some reasonable latency, say, a couple weeks or a month). For example: [http://www.w3.org/2006/03/hcard an hCard Profile at w3.org], and discussion: [http://microformats.org/discuss/mail/microformats-dev/2006-March/000068.html an hCard profile that seems to work with GRDDL].

=== Validator warning ===

Due to [http://sourceforge.net/tracker/index.php?func=detail&aid=1264455&group_id=27659&atid=390963 inconsistent wording of the HTML specs], HTMLTidy (and other tools?) give "[http://sourceforge.net/mailarchive/forum.php?thread_name=oytAFzxaKxiFFwpx%40pigsonthewing.org.uk&forum_name=htmlvalidator-help Warning: <head> escaping malformed URI reference]"
when more than one profile is used, e.g.

<code><head profile="http://www.ietf.org/rfc/rfc2731.txt http://www.w3.org/2006/03/hcard"></code>

W3C HTML validator has very poor validation of attributes and is technically unable to check this case. The HTML DTD however defines <code>profile</code> attribute as <code>%URI</code> (it's an alias for <code>CDATA</code>), same as <code><a href></code> attribute.

==See also==

* [[profile-uri-examples-in-wild|Profile URI examples, in the wild]]
* [[faqs-for-rdf]] for discussion of connecting microformats to URIs.
* [[hcard-profile]].

code-brainstorming

2009-02-04T10:18:01Z

TobyInk: Existing HTML elements for markup up code.

= Code Brainstorming =

This is a brainstorm for the code microformat. See also [[code-examples|examples of code]] in the wild.

== The Problem ==

There are numerous sites on the Internet that seek to:
*Teach a programming language
*Document a programming language
*Collect examples or bits of code for reuse in the general community
*Show off a particularly interesting section of code.

Examples are:
*[http://docs.python.org/tut/ tutorials]
*[http://php.net/ language documentation]
*[http://aspn.activestate.com/ASPN/ programming communities]
*[http://www.b-list.org/weblog/2006/11/16/django-tips-get-most-out-generic-views blogs].

Each of these sites encapsulates their source code in different fashions and wraps up the metadata in different ways, this makes the source code found around the web largely indigestible by machines.

So by consolidating common practices into a standard format, you a) allow web developers a standard representation of source code online, and b) offer it in a format that is digestible by computers. This more than anything allows for interesting use by users. It would for instance allow users to collect code examples from the web and store them on their local machines in meaningful ways, which in turn allows them to organize and search that new source code repository for examples, classes or snippets that relate to their problem, and further gives them the information necessary to safely use that source code (license, author, language, etc.)

== Elements that come up often in practice ==

=== Base Elements ===

* module_title
* author(s) (might be a list)
** this should probably be an hcard
** author's name
** author's webpage
** author's email
* license (might be a link or written out)
* description (one liner)
* source-code (should always be plain-text with no additional markup)
* module_version (of source code)
* module_date (last updated)
* program-language (perl, php, python, etc.)
** language-version (5.8, 4, 2.4)
* module_url (linking back to the source of the module)
* category(s)
** a list of rel-tags

=== Strawman Outline ===

== Additional Suggestions ==

(X)HTML already contains a number of elements relevant to marking up code:

* <code><code></code> - for marking up an area of source code. (In the wild I've seen the class attribute on it often used to indicate the programming language.)
* <code><var></code> - for marking up a variable. (Not used very often for variables within <code><code></code>, but useful for, say, describing command-line parameters taken by a script.)
* <code><kbd></code> - for sample input to a program.
* <code><samp></code> - for sample output from a program.
* <code><blockcode></code> (XHTML2 only) - same semantics as <code><code></code>, but a block element with a similar presentation to <code><pre></code>.

Although there is probably some value in a code microformat, the effort should be careful to reuse these existing elements before inventing new methods of marking up code.

== Issues ==

==See also==

*[[code-examples]]