Microformats Wiki - User contributions [en]

value-class-pattern

2009-11-11T14:47:43Z

Cgriego: Fixed typo: visibile

<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
: [[User:BenWard|Ben Ward]]
: [[User:Tantek|Tantek Çelik]]
; 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>

Home:
+1.415.555.1212

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

Home:
+44 (0) 1223 123 123

</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>
I'm loitering outside The Bricklayer's Arms

51° 30' 48.45", -0° 8' 53.23"
(51.513458;-0.14812)


</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 descendant <code>bar</code> with class <code>value</code>, the content of <code>foo</code> 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>


Puppies Rule!
But kittens are better!


</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>Puppies Rule!But kittens are better!</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>
The weekly dinner will be on

<abbr class="value" title="2008-06-24">this Tuesday</abbr>
at 18:30


</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 optimizations that make use of the value-class-pattern.

;short URL for this section
: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>

The party will be on

2009-06-26, from
19:00 to
22:00.

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

The party will be on

2009-06-26, from
19:00 to
22:00.

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

short blog post example
was published on 
2009-08-01 at 12:06
and updated at 12:10.

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

short blog post example
was published on 
2009-08-01 at 12:06
and updated at 12:10.

</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 informative.

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>
It was

last year

that I realised my addiction to cashew nuts would cost this country so dear.

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


 
mobile

+44 7773 000 000

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

 
March 14th 2009, around half-past four

</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), current 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> </code>, including a single whitespace character between the opening and closing tag, is the required pattern for authors, at this time.''

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. Microformat specifications must explicitly state which properties may be used with this extension of the value-class-pattern.
* 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 advise 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'>
* '''Why use an 'empty' element? Why not embed data in the class attribute?'''
** 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’?'''
** Microformats exist and function in ''valid'' HTML4 and XHTML1. 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).
* '''The <code>title</code> attribute should only be used for 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]]).

* [[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].
* ... add your implementation(s) that parse or generate the value-class-pattern here, along with which features you support (hopefully all!) and note any limitations if any.

== Articles ==
Articles and blog posts discussing the value class pattern, most recent first.
When this section gets too big, create a separate page like: [[value-class-pattern-articles]]
* 2009-08-25 MIX Online: [http://visitmix.com/Articles/The-Value-Class-Pattern The Value Class Pattern] by Jeremy Keith
* [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]
* [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-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]

operator

2009-11-11T06:13:17Z

Cgriego: Update latest release version

<entry-title>Operator Firefox plugin</entry-title>

'''[https://addons.mozilla.org/firefox/4106/ Operator]''' is a ''must install'' Firefox plugin as it reveals and provides easy access to the [[hCard|hCards]], [[hCalendar]] events etc. that are all over numerous websites.

Operator has rapidly found favor with microformats users, publishers, and developers. It provides an architecture for microformat parsing which is likely to be incorporated into the core of future versions of Firefox.

Latest release: 0.9.5

== donate ==
<div class="discussion">
*The developer of Operator asks that you help support its continued development by making a small contribution.
** [https://addons.mozilla.org/en-US/firefox/addon/4106/developers Please DONATE]
</div>

== issues ==
See [[operator-issues]].

== see also ==
* [[firefox-extensions]]
*[http://labs.mozilla.com/2006/12/introducing-operator Mozilla Labs' Operator announcement]
*[http://www.kaply.com/weblog/ Operator author's blog]
*[http://www.kaply.com/weblog/operator-user-scripts/ Customise Operator with 'user scripts'] (needed to add hReview support)

hproduct

2009-05-17T04:30:12Z

Cgriego: Typo

<entry-title>hProduct</entry-title>
{{DraftSpecification}}
__TOC__
hProduct is a microformat suitable for publishing and embedding product data. hProduct is one of several open microformats standards suitable for embedding in HTML, XHTML, Atom, RSS, and arbitrary XML.

==hProduct Microformat Draft Specification==

; Editors/Authors
(alphabetical)
* [[User:PaulLee|Paul Lee]], Google Product Search
* [[User:JayMyers|Jay Myers]], [http://www.bestbuy.com/ Best Buy, Co., Inc.]

; Contributors
(alphabetical)
* Craig Cook, [http://focalcurve.com/ Focal Curve]
* Aaron Gustafson, [http://easy-designs.net/ Easy! Designs]

Microformats [http://microformats.org/wiki/hresume#Copyright copyright] and [http://microformats.org/wiki/hresume#Patents patents] statements apply.

== Status ==
Draft, version 0.3.

== Introduction ==
The web is a thriving consumer marketplace with a plethora of manufacturers and vendors scattered across the globe. Sifting through massive amounts of unstructured product data is a difficult task for both browsers and machines alike. The hProduct microformat gives structure to this metadata by providing constructs to identify universal product attributes, plus a mechanism to accomodate the wide variation in product attributes.

The hProduct microformat can assist consumers, manufacturers and retailers in a number of ways. If a browser or application understands that a specific web page contains the hProduct microformat, it can inform and help facilitate the best product choice by the consumer to fulfill their needs. An adopted, open standard will ensure the correct product data is published between manufacturers and retailers, to the benefit of the consumer. Bringing order and structure to product data makes it easy for people and organizations to list the products and services they offer, and easy for web services to consume that product data for analysis and syndication.

=== Semantic XHTML Design Principles ===
{{SemanticXHTMLDesignPrinciples}}

=== Inspiration and Acknowledgment ===
Many thanks go out to the contributors who laid the foundation for the current hProduct draft spec.

=== Scope ===
Giving details about a particular product is sometimes very complex as parameters are different for books and CDs than they are for iPods or cars. It should be very easy to mark up an item using hProduct and the syntax should be simple yet flexible enough for more advanced applications.

=== Out of Scope ===
This microformat does not intend to replicate any of the content proposed within [[hListing]] and would defer all money/transactional matters to that microformat. This microformat also does not attempt to specify a product ontology, or category-specific attributes; instead, it aims to create a framework to allow for flexible expression of both.

== Format ==
{{rfc-2119-intro}}

=== In General ===
The hProduct format is based on a set of fields common to numerous ecommerce sites and formats in use today on the web.

=== Schema ===
The hProduct schema consists of the following (see existing class names for reference):

*hproduct
** brand. optional. text. can also use [[hcard|hCard]] for manufacturer.
** category. optional. text. can also use rel-tag. re-used from [[hcard|hCard]].
** price. optional. floating point number. can use currency format.
** description. optional. text. can also include valid HTML markup. re-used from [[hreview|hReview]].
** fn. '''required.''' text. product name or title. re-used from [[hcard|hCard]].
** photo. optional. image element or link. re-used from [[hcard|hCard]].
** url. optional. href. can contain rel-tag rel='product'. re-used from [[hcard|hCard]].
** review. optional. [[hreview|hReview]], or [[aggregate-microformat-template-examples|hReview-aggregate]].
** listing. optional. [[hlisting|hListing]], or [[aggregate-microformat-template-examples|hListing-aggregate]].
** identifier. optional.
*** type. required. - examples:
**** model
**** mpn
**** upc
**** isbn
**** issn
**** ean
**** jan
**** sn
**** vin
**** sku
*** value. required. - label may be implied

=== Field details ===
Class names <code class="class-name">category</code>, <code class="class-name">fn</code>, <code class="class-name">photo</code>, <code class="class-name">url</code> are reused from [[hcard|hCard]]. <code class="class-name">description</code> is reused from [[hreview|hReview]].

The fields of the hProduct schema represent the following:

*'''<code class="class-name">hproduct::</code>''' Root class name
*'''<code class="class-name">brand::</code>''' the class name brand is used identify brand of the product. {{should}} use [[hcard|hCard]] for manufacturer name. {{must}} be singular.
*'''<code class="class-name">category::</code>''' the class name category identifies product category. {{may}} use [[rel-tag]] microformat. {{may}} be plural to represent multiple categories.
*'''<code class="class-name">price::</code>''' the class name price is used to indicate the price of the product. {{must}} be singular.
*'''<code class="class-name">description::</code>''' the class name description is used to describe the product. {{must}} be singular.
*'''<code class="class-name">fn::</code>''' product text name. {{must}} be singular.
*'''<code class="class-name">photo::</code>''' the class name photo {{may}} be applied to an <img> or <a> element. {{may}} be plural.
*'''<code class="class-name">url::</code>''' the class name url {{should}} refer to the web page associated with product details. {{may}} use [[rel-tag]], rel='product'. {{must}} be singular.
*'''<code class="class-name">review::</code>''' the class name review identifies review(s) for the product. {{should}} use [[hreview|hReview]]. {{may}} be plural.
*'''<code class="class-name">listing::</code>''' the class name listing identifies product listings. {{should}} use [[hlisting|hListing]]. {{may}} be plural.
*'''<code class="class-name">identifier::</code>''' the identifier structure is used to describe product identifiers like Model, UPC or SKU, and is designed to accommodate new or as-yet-unidentified identifiers. {{should}} be singular.
**'''<code class="class-name">type::</code>''' the class name type identifies the identifier type.
**'''<code class="class-name">value::</code>''' label {{may}} be implied

=== Additional Details ===
'''Note:''' If hProduct markup is used in a "standalone" fashion (eg. a manufacturer site that's not commerce enabled, strictly informational), it is assumed that the price attribute represents the manufacturer's suggested retail price. Any transactional (commerce) representation of price should be delegated to [[hlisting|hListing]].

''Internationalization'': Though there are many English-language tokens, they are only used as invisible class-names; user-visible listing information can be completely localized. Note that (X)HTML LANG attribute rules still apply as usual, for multilingual aggregators of hProduct.

=== Relationships with other microformats ===
Products can be complex structures with attributes and features that may fall outside the bounds of the proposed hProduct microformat. Care has been taken to provide just enough attributes to accurately represent products while not overloading the hProduct spec. This means that complete semantic solutions would rely on using hProduct in combination with other microformats to achieve their goals. Through [[hproduct-examples#Coded_examples|examples]] (see also: [[hproduct-recipes|recipes]]) and [[hproduct-examples#Analysis_of_Product.2FCommerce_Sites|analysis]], there are some clear relationships between hProduct and these microformats:

* [[hlisting|hListing]] :: provides additional context to the transaction side of a product, including elements like the transactional price.
* [[hReview|hReview]]/hAggregate(concept) :: research shows that many commerce sites include product reviews, and they are often aggregated to provide overall ratings and reviews on the web. Utilizing these microformats can provide additional data around a product or service.
* [[xoxo|xoxo]] :: to address property-value data that may be necessary for a complete data representation of a product.

Of course, these are just a few of many that could be used with the hProduct microformat.

=== XMDP Profile ===
<pre>
<dl class="profile">
<dt>class</dt>
<dd>
<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>.
<dl>
<dt>hproduct</dt>
<dd>Used to identify and describe metadata universally common to products.</dd>
<dt>brand</dt>
<dd>The brand name of the product.</dd>
<dt>category</dt>
<dd>The product category/ categories the product belongs to.</dd>
<dt>price</dt>
<dd>The price of the product.</dd>
<dt>description</dt>
<dd>The full text representing the written description of the product.</dd>
<dt>fn</dt>
<dd>The common name of the product.</dd>
<dt>photo</dt>
<dd>Accompanying image of the product.</dd>
<dt>url</dt>
<dd>A link to the product details.</dd>
<dt>review</dt>
<dd>A review of the product.</dd>
<dt>listing</dt>
<dd>Listing details of the product.</dd>
<dt>identifier</dt>
<dd>The product identifier like Model, SKU, ISBN, or EAN associated with the product</dd>
</dl>
</dd>
</dl>
</pre>

=== Notes ===
This section is informative.
*...

=== Other examples ===

Please see examples at [[hproduct-examples|hProduct examples]].

== Copyright ==
* [[User:JayMyers|JayMyers]]: I release all of my contributions to the public domain.

{{MicroFormatPublicDomainContributionStatement}}

== Patents ==
{{MicroFormatPatentStatement}}

== Related ==
* '''hproduct'''
* [[hproduct-issues]]
* [[hproduct-faq]]
* [[hproduct-examples]]
* [[hproduct-recipes]]

* [[product]]
* [[product-examples]]
* [[product-formats]]
* [[product-brainstorming]]

[[Category:Draft Specifications]]
[[Category:hProduct]]

User:Cgriego

2008-06-25T01:34:27Z

Cgriego:

[http://www.boldpx.com/ Chris Griego]

TZ:-06:00; CST

{{cc-public-domain-release}}

transit-table-examples

2008-01-19T02:58:17Z

Cgriego: Added Google Transit Feeds

= Transit Table Examples =

== Authors ==

* Tantek Çelik

== Acknowledgment ==

Thanks to Kevin Marks for suggesting this need for a microformat on the microformats-discuss list and providing the Caltrain example.

http://microformats.org/discuss/mail/microformats-discuss/2005-October/001595.html

== Problem Statement ==

Problem: how to markup transit tables for trains / light-rail etc. in such a way that aggregation and navigation of schedules across varying transit systems becomes possible.

== Examples ==

=== Caltrain ===

http://caltrain.com/timetable_effective_10_10_05.html

=== TTC (Subways, Buses, Light and Electric Rail) ===

Interface:
http://www.toronto.ca/ttc/schedules/index.htm

Note the horrifying frame and pulldown based interface.

Schedule page:
http://www.toronto.ca/ttc/schedules/61S.htm#AVENUE%20RD.%20at%20WILSON

=== Air Canada (Airline) ===

http://www.aircanada.com/aco/flights.do

This is fairly typical of many airlines -- a form-based query is needed to get to the interesting stuff.

=== Go Transit (Trains and Buses) ===

Interface:
http://www.gotransit.com/PUBLICROOT/NewVersion/lstNser.asp

Schedule page:
http://www.gotransit.com/PUBLICROOT/NewVersion/pubnsch.asp?table=01&direction=0&day=1&page=1

=== New Jersey Transit ===

Rail Schedule Interface (results include transfer info + rates):
http://www.njtransit.com/sf_tr_schedules.shtml

Bus Schedules:
http://www.njtransit.com/sf_bu_town2town.jsp?Center=Town

=== MTA (NYC) subways, trains, buses ===
http://www.mta.nyc.ny.us/

LIRR Train Interface:
http://lirr42.mta.info/index.asp

Metro North Train Interface (includes peak/offpeak info, travel durations)
http://as0.mta.info/mnr/schedules/sched_form.cfm

=== Google Transit Feeds ===
http://code.google.com/transit/spec/transit_feed_specification.html

== Future Thoughts ==

This probably belongs more in a transit-table-brainstorming page, but until more examples are fleshed out and previous formats are researched, we're sticking future thoughts here.

=== Tufte Transit Graph ===

An application that read a standard transit-table microformat and produced a Tuftesque timeline grid would be very nice for transit users.

User:Cgriego

2008-01-06T00:59:05Z

Cgriego: CC Public Domain Release

Chris Griego

TZ:-06:00; CST

{{cc-public-domain-release}}

events/2007-10-02-dallas-ruby-brigade

2007-10-04T19:12:02Z

Cgriego: updating attendees

<h1>Dallas Ruby Brigade October 2007</h1>
One of several microformats [[events]].

__TOC__
== details ==
<div class="vevent">
;When
:2007-10-02T19:00:00-0500
;Where
:Improving, 15950 Dallas Parkway, Suite 500 Dallas, TX 75248, USA
;What
:Microformats, building blocks of the semantic web
;Presenter
:[[User:Cgriego|Chris Griego]]
;Web
:http://dallasrb.stikipad.com/
:http://www.slideshare.net/cgriego/microformats-building-blocks-of-the-semantic-web/
</div>

'''[http://technorati.com/events/microformats.org/wiki/events/2007-10-02-dallas-ruby-brigade Add this event to your diary or calendar program]''' http://www.boogdesign.com/images/buttons/microformat_hcalendar.png

== attendees ==
Add yourself alphabetically sorted by last name if you attended.

* Elshire, Blake
*[[User:Cgriego|Griego, Chris]]
* Keys, Adam
* LaMons, Jordan
* Marvin, Kevin
* Nelson, Morgan
* ...

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

events/2007-10-02-dallas-ruby-brigade

2007-10-04T19:08:30Z

Cgriego: updating attendees

presentations

2007-10-04T19:02:10Z

Cgriego: Adding Dallas Ruby Brigade October 2007

<h1> microformats presentations </h1>

This page lists various presentations, sessions, papers and posters which have provided explanations and discusions of both [[microformats]] in general, and specific microformats. Check out microformats [[events]] for upcoming presentations. See also microformats [[podcasts]] and [[screencasts]] for audio/video presentations and discussions.

Most recent presentations/sessions listed first.

== 2007 ==
* 2007-10-04 [http://tantek.com/presentations/2007/10/social-network-portability/ Social Network Portability] presentation by Tantek Çelik at [[events/2007-10-04-fundamentos-web-social-network-portability|Fundamentos Web 2007]]
* 2007-10-02 [http://www.slideshare.net/cgriego/microformats-building-blocks-of-the-semantic-web/ Microformats, building blocks of the semantic web] presentation by Chris Griego at [[events/2007-10-02-dallas-ruby-brigade|Dallas Ruby Brigade October 2007]]
* 2007-08-30 GeekUp presentation by [http://www.ts0.com Thom Shannon] - [http://www.ts0.com/2007/09/microformats-whats-point.asp Microformats: What's the point?]
* 2007-06-.. http://tantek.com/presentations/2007/06/microformats-bb-you/
* 2007-05-.. http://tantek.com/presentations/2007/05/microformats-bb-you/
* 2007-06-02 BarCamp San Diego presentation by Joshua Brewer: [http://www.slideshare.net/jbrewer/barcamp-sd-microformats Microformats: Building a Better Web].
* 2007-05-16 [[events/2007-05-16-XTech|XTech 2007]] presentation by Jeremy Keith: [http://adactio.com/extras/slides/nanotech.pdf Microformats: the nanotechnology of the semantic web].
* 2007-04-30 [[events/2007-04-30-mix07|Microformats: Data Formats That Put Humans First]] [http://tantek.com/presentations/2007/04/microformats/ presentation by Tantek Çelik]
* 2007-03-23 [[events/2007-03-23-stanford|Microformats at Stanford]] [http://tantek.com/presentations/2007/03/microformats/ presentation by Tantek Çelik]
* 2007-03-22 [http://www.webdu.com.au/go/session/microformats--hidden-treasures Microformats—the hidden treasure] by Dmitry Baranovskiy at the [http://www.webdu.com.au/ webDU 2007] conference in Sydney, Australia, 3:00pm–4:00pm
* 2007-02-23 [http://bluesmoon.info/talks/microformats/ Microformats at the CSI Web 2.0 Conference in Bangalore] presentation by Philip Tellis
* 2007-02-19, [http://www.glennjones.net/Post/825/DestroyingWalledGardens-MicroformatssyndicationandAPI%e2%80%99s.htm Destroying Walled Gardens - Microformats syndication and API’s] at [http://barcamp.org/BarCampLondon2 BarCamp London 2], UK by Glenn Jones
* 2007-02-13, [http://groups.google.com/group/bristolskillswap/web/february-skillswap-microformats Microformats: The Semantic Web for the Rest of Us] Bristol Skillswap [rtsp://stream.watershed.co.uk/skillswap/2007.02.13.microformats.mov Streaming Video]
* 2007-02-07, [http://north.webdirections.org Web Directions North 2007], [http://north.webdirections.org/detail/venue/ Renaissance Vancouver Hotel Harbourside], 1133 West Hastings Street, Vancouver, British Columbia, V6E3T3, Canada
** [[events/2007-02-07-web-directions-north|Microformats at Web Directions North 2007]], 11:45am-12:45pm, 1:45pm-3:45pm
*** Tantek Çelik (Technorati) - "[http://tantek.com/presentations/2007/02/microformats/ Microformats — The Big Picture]"
*** John Allsopp (Westciv) - "[http://north.webdirections.org/presentations/MicroformatsForDevelopers.pdf Microformats For Developers]"
*** Dan Cederholm (Simplebits) - "[http://north.webdirections.org/presentations/MicroformatsForDesigners.pdf Microformats For Designers]"
* 2007-02-03 [http://www.glennjones.net/Post/823/Microformats%2ctheAK-47oftheweb-WebDD.htm Microformats HTML to API] at [http://www.webdd.org.uk/ WebDD], Reading UK by Glenn Jones

== 2006 ==
* 2006-11-24, Taichi Kaminogoya presented to [http://2xup.org/log/2006/11/27-2219 microformats に触れてみよう] at [http://www.asahi-net.or.jp/~eb2m-mrt/kaihatsu9.html XML Developers' Day #9], Tokyo, JAPAN.
* October 28th, [http://www.keepthebyte.ch/2006/10/microformats-speech-at-barcamp-zurich.html Microformats Speech at Barcamp Zurich]
* October 10th, Taichi Kaminogoya presented to [http://2xup.org/log/2006/10/10-1800 microformatsがもたらすドキドキする未来] at [http://lp1.cssnite.jp/ CSS Nite LP Disk 1], Tokyo, JAPAN.
* September 28th, [http://www.webdirections.org/microformats/ Microformats] at Web Directions South, Sydney Australia by John Allsopp. [http://www.webdirections.org/microformats/ slides, podcast, live blogging transcript all online now]
* September 27th, [http://tantek.com/presentations/2006/09/microformats-intro/ Microformats Intro] at New Context 2006, Radisson Miyako Hotel, Minato-ku, Tokyo, JAPAN. See also [http://flickr.com/photos/tags/microformatsnewcontext2006 photos].
* September 16th, [http://fredericdevillamil.com/presentations/2006/que-sont-les-microformats/index.html Introducing Microformats for resume publishing] in French by Frederic de Villamil at Barcamp Paris 4. Location: 43 rue d'Aboukir, 75002 Paris France
* September 13th, [http://tantek.com/presentations/2006/09/microformats-practices/ Microformats Practices] at [[events/2006-09-13-future-of-web-apps-microformats|Future of Web Apps]] in San Francisco. Location: Palace of Fine Arts Theatre, Lyon Street, San Francisco CA 94123.
* August 26th, Tantek Çelik led the [http://barcamp.org/BarCampStanfordMicroformats BarCampStanfordMicroformats] discussion at room 426, Margaret Jacks Hall, Stanford, CA 94305. There is an [http://barcamp.org/f/MF-barcamp_08_26_2006.ogg Ogg recording of the session].
* July 11th, [http://tantek.com/presentations/2006/07/what-are-microformats/ What are microformats?] at [[events/2006-07-11-an-event-apart-microformats|An Event Apart in New York City]]
* July 6th, [http://yatil.de/webmontag/ka0706/ Mikroformate Erweiterte Semantik von HTML-Dokumenten] (Präsentation von Eric Eggert) Web mondays presentation in german - translation is available here
* June 15th, Phil Wilson presented to the [http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2006/ Institutional Web Management Workshop]
* June 8, Pete Prodoehl presented [http://rasterweb.net/raster/presentations/microformats-20060608/ Microformats] to the Milwaukee Web Design Meetup Group
* May 30, [http://netsquared.org NetSquared] [http://netsquared.org/conference/ Conference], 4:15pm-5:10pm: : [http://netsquared.org/conference/conference-sessions/Mashups A web more woven - the alchemy and practicalities of Mashups]. Tantek Çelik, Taylor McKnight and Chris Messina will discuss the core utility of microformats to publish and share data for/with mashups and other applications. Location: Jordan room, Cisco Systems' Vineyard Conference Center, 260 E. Tasman Drive, San Jose, CA.
* May 25, Brian Suda and Ryan King presented [http://theryanking.com/presentations/2006/www/ Practical Microformats] at WWW 2006 ([http://www.molly.com Molly Holzschlag] was orginally scheduled to give this talk, we filled in at the last minute with our slides from XTech)
* May 24, Kevin Lawver presented [http://presentations.lawver.net/standards/a_microformat_and_proposal_for/ A Microformat and Proposal For Interoperable Widgets]
* May 18, [http://xtech06.usefulinc.com/schedule/paper/148 The Intelligent Design of Microformats] by Ryan King at XTech 2006. ([http://theryanking.com/presentations/2006/xtech/talk/ slides]).
* May 16, [http://thebigjc.org/articles/2006/05/16/is-web-2-0-changing-the-software-industry Is Web 2.0 Changing the Software Industry?] by Chris Messina at [http://meshconference.com Mesh Conference]
* May 16, [http://theryanking.com/presentations/2006/xtech/tutorial/ Microformats from the Ground Up] by Brian Suda and Ryan King @ XTech 2006
* April 25, At [http://barcamp.org/TorCampDemoCamp5 DemoCamp #5 in Toronto], [http://blog.davidjanes.com David Janes] demonstrated [http://www.blogmatrix.com/ BlogMatrix] his platform for publish which supports microformats. (see [http://accordionguy.blogware.com/blog/_archives/2006/4/26/1913279.html Accordionguy blogpost]).
* April 23, [http://jazkarta.com/presentations/microformats.pdf/view Microformats and the Future of Syndication] by Nate Aune, AdaptiveWave (CM Pros Summit, San Francisco, CA)
* April 22, Intro to Microformats, [http://barcamp.pbwiki.com/BarCampBangalore Barcamp Bangalore], Bangalore, India, (photos [http://flickr.com/photos/abgpt/133393564/ 1], [http://flickr.com/photos/abgpt/133393545/ 2], [http://flickr.com/photos/abgpt/133393626/ 3])
* March 16, [http://ono.cdlib.org/archives/shimenawa/000219.html Reading 2.0] (see [http://radar.oreilly.com/archives/2006/03/link_list_reading_20_1.html Tim O'Reilly's notes]), San Francisco, CA
** Building with MicroFormats, [http://www.chaddickerson.com/blog/2006/03/17/reading-20-and-microformats/ Chad Dickerson], Yahoo
* March 13, SXSW Interactive, Room 17AB, Austin Convention Center, Austin, TX
** [[events/2006-03-13-sxsw-microformats|Microformats: Evolving the Web]], 11:30am-12:30pm
* March 11, SXSW Interactive, Room 17AB, Austin Convention Center, Austin, TX
** [http://tantek.com/presentations/2006/03/building-blocks Creating Building Blocks For Independents], 5pm-6pm
** [http://flickr.com/photos/tags/microformatssxsw photos]
* March 7, O'Reilly Emerging Technologies (ETech) Conference, Manchester Grand Hyatt, Ballroom, San Diego, CA
** [[events/2006-03-07-etech-microformats|Microformats intro and lightning demos at O'Reilly ETech conf.]], 5:30pm-6:15pm
** [http://flickr.com/photos/tags/microformatsetech photos]
* March 1, W3C Technical Plenary Day, Hotel Sofitel Cannes Mandelieu Royal Casino, main auditorium, 605 avenuedu Général de Gaulle, BP 49, MANDELIEU LA NAPOULE CEDEX, 06212 MANDELIEU LA NAPOULE, FRANCE
** [[events/2006-03-01-w3c-plenary-microformats|Microformats panel at W3C Technical Plenary Day]], 10:30am-11:30am
*** Ian Hickson (Google) - "A billion documents and no semantics anywhere" (NEED LINK TO SLIDES OR STUDY)
*** Tantek Çelik (Technorati) - "[http://tantek.com/presentations/2006/03/what-are-microformats/ What are microformats?]"
*** Håkon Wium Lie (Opera) - "Cascading Markup Languages — boom!" (NEED LINK TO SLIDES)
*** Rohit Khare (CommerceNet) - "[http://labs.commerce.net/~rohit/Angstro-W3C-TP/ Where Angle Brackets Fear to Tread]"
*** Dan Connolly (W3C) - "[http://www.w3.org/2003/g/talk62/slides Microformats for practical Semantic Web deployment]"
*** Q&A
**** "I'm very excited about '''microformats'''. What I really want is to get all the data out of databases and expressed as part of the Semantic Web." - Tim Berners-Lee. ('''emphasis''' added)
** "Services and the Web" by Mark Nottingham (Yahoo), 12:05pm-12:10pm.
*** Request to W3T/W3M: Go After The "Real" Web: Apache, PHP, Mozilla, Intermediaries and Caches, '''Microformats''', JSON... ('''emphasis''' added)
** Attendees voted the "Microformats" session the best session of the Plenary Day. 6:17pm.
* February 24, Yahoo Speakers Series, Yahoo Mission College Campus, 2nd floor conference room, 2821 Mission College Blvd., Santa Clara, CA 95054
** [http://tantek.com/presentations/2006/02/microformats-evolution/ Microformats: Evolving the Web]
* January 18, Apple Web Publishers internal meeting, Apple Computer, Star Trek conference room, 1 Infinite Loop, Cupertino, CA 95014, 12-1:40pm
** [http://tantek.com/presentations/2006/01/microformats-evolution/ Microformats: Evolving the Web]
* January 10, SD Forum Emerging Technologies SIG, Room H1, Cubberley Community Center, Palo Alto, CA, 7-9pm
** Ryan King's presentation, Ernie Prabhakar's presentation, Rohit Khare's presentation
** Microformats panel: Ryan King, Ernie Prabhakar, Rohit Khare, Tantek Çelik, Kevin Marks

== 2005 ==
* December 15, Syndicate Conference, San Francisco, CA
** [http://tantek.com/presentations/2005/12/syndicate-microformats/ Microformats - Emerging syndication types]
* November 26, [http://barcamp.org/index.cgi?TorCamp TorCamp], Teehan+Lax, 460 Richmond St. W, Toronto, ON, CA
** [http://www.davidjanes.com/docs/2005.11.25%20Microformats%20Presentation.ppt powerpoints] (sorry)
** [http://blog.davidjanes.com/mtarchives/2005_12.html#003467 photo]
* November 12, THINK Conference, Santa Cruz room, Chaminade hotel, Santa Cruz, CA, USA
** [[presentation-think-2005-11-12]]
* November 10, (location unknown), by Kevin Yank of SitePoint Pty. Ltd.
** [http://www.sitepoint.com/examples/innovation-on-standards/ Innovating on top of standards - Not around them]
* October 5, [http://web2con.com Web 2.0 Conference], Olympic Room, Argent Hotel, San Francisco, CA, USA
** [http://tantek.com/presentations/2005/10/microformats-examples/ Microformats Examples]
* October 4, [http://osafoundation.org/ OSAF], San Francisco, CA, USA
** [http://tantek.com/presentations/2005/10/microformats-evolution/ Microformats: Evolving the Web]
* September 30, [http://we05.com/ Web Essentials 05], Guthrie auditorium, University of Technology, Sydney, Australia
** [http://tantek.com/presentations/2005/09/microformats-evolution/ Microformats: Evolving the Web] ([http://we05.com/podcast/mp3/we05-14-tantek-celik2.mp3 MP3 - incomplete])
* September 29, [http://we05.com/ Web Essentials 05], Guthrie auditorium, University of Technology, Sydney, Australia
** [http://tantek.com/presentations/2005/09/elements-of-xhtml/ The Elements of Meaningful XHTML] ([http://we05.com/podcast/mp3/we05-2-tantek-celik.mp3 MP3])
* September 25, [http://webzine2005.com/ Webzine 2005], Valhalla Room, Swedish American Hall, San Francisco, CA, USA
** [http://theryanking.com/presentations/2005/webzine/ Microformats @ Webzine 2005]
* September 21, Web Intelligence Conference, Compiegne, France
** [http://moloko.itc.it/paoloblog/presentations/presentation_wi05/presentation_wi05.html Page-reRank: using trusted links to re-rank authority] ([http://sra.itc.it/people/massa/publications/wi05_page_rerank_massa_hayes.pdf paper]) - A discussion of using [[vote-links]] to improve [http://www-db.stanford.edu/~backrub/google.html PageRank]
* June 20: Supernova 2005 ([http://supernova2005.com/ Supernova2005 site]), Microformats [http://supernova2005.com/workshops.htm Workshop], Wharton West, Suite 500, San Francisco, CA, USA
** "[http://tantek.com/presentations/2005/06/what-are-microformats/ What are Microformats?]"
** "[http://homepage.mac.com/kevinmarks/supernovatags.html A microformat for tags]"
** [http://wiki.commerce.net/wiki/ZCommerceWS#Microformats commercenet wiki page on the workshop] ([http://labs.commerce.net/wiki/index.php/ZCommerceWS#Microformats 2])
* May 14: Fourteenth International World Wide Web Conference ([http://www2005.org/ WWW2005]), 2005, Microformats Dev-Day Track, Makuhari Messe Room 303, Chiba, JAPAN
** "[http://tantek.com/presentations/2005/05/what-are-microformats/ What are Microformats?]" - Tantek Çelik
** "[http://westciv.com/WWW2005/linkmf.html Link Microformats]" - John Allsopp
** "[http://complexspiral.com/events/archive/2005/www2005/potential.html The Potential of Microformats]" - Eric Meyer
** "Distributed Social Networks (XFN Implementations)"
*** Demonstrations of [http://wordpress.org WordPress] & [http://metafilter.com Metafilter]'s builtin XFN support, and XFN search engines [http://rubhub.com/ RubHub] & [http://xhtmlfriends.net/ xhtmlfriends.net].
** "[http://tantek.com/presentations/2005/05/hcard-hcalendar/ People and Events (hCard & hCalendar)]" - Tantek Çelik
** "[http://cnlabs.commerce.net/~rohit/hReview-in-Review/ hReview in Review]" - Rohit Khare
** "Bibliographies (hBib)" - notes captured: [[hbib-discussion-2005-05-14|hBib Discussion 2005-05-14]]
** "[http://westciv.com/WWW2005/xml2mf.html a more meaningful web with microformats]"
** "Semantic Web and Microformats" panel, Room 201

* March 15: "[http://tantek.com/presentations/2005/03/decentralizednetworks/ Decentralized Social Networks]", South by South West Conference (SXSW) 2005, Austin Convention Center Room 17AB, Austin TX

* March 14: "[http://2005.sxsw.com/interactive/conference/panels/?action=show&id=IAP0060 How to Trick-Out Your Blog]", South by South West Conference (SXSW) 2005, Austin Convention Center Room 16B, Austin TX

* March 13
** "[http://complexspiral.com/events/archive/2005/sxsw/ Emergent Semantics]", South by South West Conference (SXSW) 2005, Austin Convention Center Room 15, Austin TX
** "[http://tantek.com/presentations/2005/03/leveragingtags.html Leveraging Tags]", as part of the "How to Leverage Solipsism" panel, South by South West Conference (SXSW) 2005, Austin Convention Center Room 18A, Austin TX
** "[http://tantek.com/presentations/2005/03/elementsofxhtml/ The Elements of Meaningful XHTML]", South by South West Conference (SXSW) 2005, Austin Convention Center Room 16B, Austin TX

* January 21: [http://tantek.com/presentations/2005/01/attentionxml.html Attention.xml Technology Overview], private presentation, Yahoo! campus, Santa Clara, CA

== 2004 ==

* September 28: "[http://tantek.com/presentations/20040928sdforumws/semantic-xhtml.html Semantic XHTML: Can your website be your API? - Using semantic XHTML to show what you mean]", SD Forum Web Services SIG, eBay's Silicon Valley Conference Center 2161 North First Street San Jose, CA 95131

* September 12: "[http://wiki.oreillynet.com/foocamp04/index.cgi?MVCeqXHTMLCSSJS Model+View+Controller = XHTML+CSS+JS]", O'Reilly Media Foo Camp 2004, O'Reilly Campus, Wallcreeper room, Sebastopol CA

* September 11: "[http://wiki.oreillynet.com/foocamp04/index.cgi?AttentionXML Attention.XML]", O'Reilly Media Foo Camp 2004, O'Reilly Campus, Appaloosa room, Sebastopol CA

* September 10: "[http://wiki.oreillynet.com/foocamp04/index.cgi?SimpleSemanticFormats Simple Semantic Formats]", O'Reilly Media Foo Camp 2004, O'Reilly Campus, Camel room, Sebastopol CA

* March 15: "[http://tantek.com/presentations/2004sxsw/xfn.html Ridiculously Easy Social Software]", South by South West Conference (SXSW) 2004, Austin Convention Center Room 17B, Austin TX

* February 11th: "[http://www.tantek.com/presentations/2004etech/realworldsemanticspres.html real world semantics]", O'Reilly Emerging Technology Conference (ETech) 2004 Westin Horton Plaza, San Diego, CA. This presentation was the first public discussion and introduction of the terms "microformat" and "lowercase semantic web". Reprised as a five-minute lightning talk at [http://wiki.oreillynet.com/etech/index.cgi?ConCon ConCon], Rx Gallery, San Francisco CA (16 February 2004).

This page was contributed from [http://developers.technorati.com/wiki/MicroFormatsPresentations the Technorati developers wiki].

events/2007-10-02-dallas-ruby-brigade

2007-10-04T18:59:26Z

Cgriego: Fixing wiki user links

<h1>Dallas Ruby Brigade October 2007</h1>
One of several microformats [[events]].

__TOC__
== details ==
<div class="vevent">
;When
:2007-10-02T19:00:00-0500
;Where
:Improving, 15950 Dallas Parkway, Suite 500 Dallas, TX 75248, USA
;What
:Microformats, building blocks of the semantic web
;Presenter
:[[User:Cgriego|Chris Griego]]
;Web
:http://dallasrb.stikipad.com/
:http://www.slideshare.net/cgriego/microformats-building-blocks-of-the-semantic-web/
</div>

'''[http://technorati.com/events/microformats.org/wiki/events/2007-10-02-dallas-ruby-brigade Add this event to your diary or calendar program]''' http://www.boogdesign.com/images/buttons/microformat_hcalendar.png

== attendees ==
Add yourself alphabetically sorted by last name if you attended.

*[[User:Cgriego|Griego, Chris]]
* ...

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

events/2007-10-02-dallas-ruby-brigade

2007-10-04T18:58:43Z

Cgriego:

<h1>Dallas Ruby Brigade October 2007</h1>
One of several microformats [[events]].

__TOC__
== details ==
<div class="vevent">
;When
:2007-10-02T19:00:00-0500
;Where
:Improving, 15950 Dallas Parkway, Suite 500 Dallas, TX 75248, USA
;What
:Microformats, building blocks of the semantic web
;Presenter
:[[Cgriego|Chris Griego]]
;Web
:http://dallasrb.stikipad.com/
:http://www.slideshare.net/cgriego/microformats-building-blocks-of-the-semantic-web/
</div>

'''[http://technorati.com/events/microformats.org/wiki/events/2007-10-02-dallas-ruby-brigade Add this event to your diary or calendar program]''' http://www.boogdesign.com/images/buttons/microformat_hcalendar.png

== attendees ==
Add yourself alphabetically sorted by last name if you attended.

*[[cGriego|Griego, Chris]]
* ...

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

events

2007-10-04T17:58:05Z

Cgriego: Adding Oct 2 Dallas Ruby Brigade

__NOTOC__
=Microformats related events=

Please add any microformats related events (specifically, events where there will be talks on microformats) you find here, and we'll add them to the [[hcalendar|hCalendar]] on the [http://microformats.org home page].

Create a page using the [[events-template|events template]] for each specific event, where you can list URLs for the event, event details (what, when, where including country, who), create an "Attending" section, recommended tags, link to photos afterwards, etc.

If you can (or can ask the organizers to kindly-) use microformats (especially [[hCalendar]] and [[hCard]]) on the event's web pages for the schedule/sessions and speakers/venues respectively, so much the better!

See also the [http://microformats.org/#events-list Upcoming events list on the home page], as well as subscribe to them in Apple iCal or Mozilla Sunbird with this URL: <nowiki>webcal://feeds.technorati.com/events/microformats.org</nowiki> and '''[http://technorati.com/events/microformats.org/wiki/events#Upcoming add upcoming events to your diary or calendar program]''' http://www.boogdesign.com/images/buttons/microformat_hcalendar.png

There is a separate wiki page for details of [[presentations]].

==Current==
Events in progress.

== Upcoming ==


Soonest first:
* 2007-10-04: [[events/2007-10-04-fundamentos-web-social-network-portability|Fundamentos Web: Social Network Portability]]
*2007-10-05: [[events/2007-10-05-fundamentos-web-microformats-workshop|Fundamentos Web: Microformats Workshop]] at http://www.fundamentosweb.org/2007/Programa/Dia3/
* …

== Recent ==

Most recent first:

===October===
*2007-10-02: [[events/2007-10-02-dallas-ruby-brigade|Dallas Ruby Brigade]] — Dallas, TX, USA

===September===
*2007-09-28: [[events/2007-09-28-portable-social-networks-meetup-amsterdam|Meet-up at at PICNIC in Amsterdam]], Netherlands 
*2007-09-25T17:30-0700 - 20:00-0700: [[events/2007-09-25-social-network-portability|Portable Social Network Micro Meetup]] at Citizen Space, San Francisco, CA, USA.
*2007-09-18: [[events/2007-09-18-calconnect-vcard-workshop|CalConnect vCard Workshop]] (http://www.calconnect.org/vcardworkshop.shtml) — a one day vCard-focused workshop event at M.I.T.. in Cambridge, Massachusetts, USA with the goal of bringing together the key players to help move forward vCard revision efforts.

*2007-09-08T15:45+0100-16:30+0100: [[events/2007-09-08-social-network-portability|Social Network Portability at BarCampBrighton]] at [http://barcamp.org/BarCampBrighton BarCampBrighton], Madgex, 31 North Street, Brighton, England.

*2007-09-06T17:30-0400: Meetup on Microformats (http://webstandards.meetup.com/122/calendar/6116740/) — Short introduction to microformats by Catherine Devlin, at the Web Standards Meetup Group, Panera Bread, 1203 Brown Street Dayton, Ohio OH 45409, USA (Ccoordinates: 39.7420;-84.1823).

*2007-09-05: [[events/2007-09-05-dconstruct-microformats-workshop|dConstruct Microformats Workshop]] (http://2007.dconstruct.org/workshops/#jeremytantek) — Tantek Çelik and Jeremy Keith cover just about everything related to microformats in this one-day workshop as part of the dConstruct conference in Brighton, England.

=== August ===

*2007-08-28: [[events/2007-08-28-social-network-portability-today|Social Network Portability Today lunchtime meetup]] noon-2pm at Satisfaction Unlimited, 370 Brannan St., San Francisco, CA, USA.

*2007-08-19: [[events/2007-08-19-social-network-portability-today|social network portability today with hCard and XFN]] 3pm-4pm at [http://barcamp.org/BarCampBlock BarCampBlock], Princeton Review, Palo Alto, USA.

*2007-08-18: [[events/2007-08-18-social-graph|social graph discussion]], 3:30pm-4pm at [http://barcamp.org/BarCampBlock BarCampBlock], SocialText co-working space room B, Palo Alto, USA

*2007-08-18: [[events/2007-08-18-community-meetup|microformats community meetup]], 12:15pm-1pm at [http://barcamp.org/BarCampBlock BarCampBlock], SocialText co-working space room A, Palo Alto, USA

*2007-08-18 - 2007-08-19 [http://barcamp.org/BarCampBlock BarCampBlock]

==2007==
For events earlier in 2007, see [[events-2007]]

==2006==
For events in 2006, see [[events-2006]]

== Other languages ==
* [[current_events-fr|événements en cours]] (fr)

== Quicktime Broadcaster Notes ==

See [[quicktime]]

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

profile-uris

2007-06-11T15:51:31Z

Cgriego: Reverting to latest revision by DanC

In [[hcalendar-issues]], it is ACCEPTED that each microformat should have a profile URI, like [[http://gmpg.org/xfn/11 the XFN profile]].

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

See also:

* [[profile-examples-in-wild|Profile examples, in the wild]]
* [[faqs-for-rdf]] for discussion of connecting microformats to URIs.
* [[hcard-profile]].

mfcomment

2007-04-18T16:34:38Z

Cgriego: Added helpful pointer to hAtom, wording may need revising.

{{DeprecatedHistoricalPage}}
If you are interested in using microformats to markup your comments, [[hatom] is recommended.

== Author ==
* [http://an9.org/devdev Andy Smith]

== Introduction ==
I'm no spec draft lawyer, so just take this as being "in the same vein" as hReview, hCalendar and the like. I feel the examples are pretty self-explanatory.

== Examples ==
The big example, using as many properties as seemed could apply to a comment:
<pre><nowiki>
<div class="mfcomment">
0.1
 Regarding: <a class="url" rel="target" href="http://an9.org/blog/2005/06/07/super-sekret-project/">Super Sekret Project</a>
By: 
<a class="url nickname" href="http://anarkystic.com/blog">termie</a>
Andy Smith</a>
<img class="photo" src="http://an9.org/images/small_andy.png" alt="Photo of Andy Smith" />

<a class="url" rel="thread parent" href="http://sxore.com/comment/view/14">parent</a>
<div class="summary">Just a comment...</div>
<abbr class="dtcommented" title="20050612T21:30-0700">June 12th, 2005</abbr>
<div class="description">
Boy, I really like that thing
</div>
<a class="url" rel="self bookmark" href="http://sxore.com/comment/view/14">link to this comment</a>
</div>
</nowiki></pre>
The small example, using a minimum set of data:
<pre><nowiki>
<div class="mfcomment">
<a class="url" rel="target" href="http://an9.org/blog/2005/06/07/super-sekret-project/">Super Sekret Project</a>
anonymous
<abbr class="dtcommented" title="20050612T21:30-0700">June 12th, 2005</abbr>
<div class="description">
Gosh, this is neat.
</div>
<a class="url" rel="self bookmark" href="http://sxore.com/comment/view/14">link to this comment</a>
</div>
</nowiki></pre>

events/2007-03-12-sxsw-growth-evolution-of

2007-03-12T19:22:50Z

Cgriego: /* Attending */ Added myself.

<h1>The Growth and Evolution of Microformats at SXSW 2007</h1>

One of several microformats [[events]].

__TOC__

== Summary ==
The Growth and Evolution of Microformats is a [http://2007.sxsw.com/interactive/programming/panels/ confirmed panel presentation] session to be held at the 2007 [http://2007.sxsw.com/ SXSW] Interactive Festival, on Monday, March 12th from 2:00-3:00pm in Austin, Texas.

== Tags ==
Please use ''all'' of the following tags when tagging content (blog posts, photos) published related to the microformats session at SXSW interactive 2007:

tags: '''microformats sxsw sxsw07 sxsw2007 sxswi sxswi07 sxswi2007 microformats-sxsw microformats-sxsw2007 microformats-sxswi microformats-sxswi2007'''

== Panelists ==
*[[User:Tantek|Tantek Çelik]] (moderator)
*[[User:Phae|Frances Berriman]]
*[[User:MikeKaply|Michael Kaply]]
*[http://www.glennjones.net/ Glenn Jones]

== Short Session Description ==
Was required to be 25 words or less:

Microformats.org has ushered in the rapid adoption of key formats for publishing and sharing [[rel-tag|tags]], [[rel-license|licenses]], [[hcard|contacts]], [[xfn|relationships]], [[hcalendar|events]] and [[hreview|reviews]]. What happens next?

== Longer Session Description ==

In its first year, microformats.org ushered in the rapid adoption of key formats for publishing and sharing [[rel-tag|tags]], [[rel-license|licenses]], [[hcard|contacts]], [[xfn|relationships]], [[hcalendar|events]] and [[hreview|reviews]] on the Web. See what new microformats are being developed for [[hresume|resumes]], [[hlisting|classified listings]], [[media-info|music, and media]], as well as how tens of millions of established microformats on web sites of individuals, companies, and organizations are driving innovations in desktop applications and advancing personal data portability.

== Attending ==
Please add your name here if you are attending this session, speaking or not.

*[[User:Tantek|Tantek Çelik]]
*[[User:Phae|Frances Berriman]]
*[[User:Veeliam|William Lawrence]]
*[[User:Adactio|Jeremy Keith]]
*[[User:RyanKing|Ryan King]]
*[[User:Cgriego|Chris Griego]]

== Would Like to Attend ==
Please add your name here if you might be around Austin and would like to attend.
* [[User:DanC|Dan Connolly]] (not likely)

== Session Comments and Q&A ==
* ...

== Photos ==
* ...

== Blog Posts ==
* ...

mailing-lists

2006-10-17T17:04:26Z

Cgriego: microformats-process reminds me of parsing--processing--more so than even microformats-dev

<h1> Mailing Lists </h1>

Read the [http://microformats.org/discuss/ microformats discuss page] first.

Then read the [http://microformats.org/mailinglists-policies/ mailing list policies].

Ok, now here are some additional notes of scope and topics for each list.

__TOC__

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

=== 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.
# '''Using namespaces and namespace prefixes.''' 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

== microformats-rest ==
For discussion of use of microformats with REST, in protocols, services, APIs etc.

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

== new list proposal ==

There is a proposal for creating a new mailing list for discussing the research and creation of new microformats so that those discussions do not overwhelm microformats-discuss.

Some candidates for names with the thinking behind them. Feel free to add your name and opinion (+/- 1 or 0).

* microformats-new (focusing on discussing "new" microformats)
** +1 tantek
** +1 ScottReynen
** +1 Lachlan Hunt
** +1 Joe Andrieu
** -1 Andy Mabbett
* microformats-research (focusing on the essential, and often overlooked by first-time proposers "research" phase(s) in the process)
** +1 tantek
** +1 ScottReynen
** +1 cgriego
** +1 Phae
** +1 JustinThorp
** -1 Andy Mabbett
** -1 Joe Andrieu
* microformats-process (That's really what we're talking about with research of new microformats, isn't it?)
** +1 ScottReynen
** +1 Lachlan Hunt
** -1 Andy Mabbett
** -1 Joe Andrieu
** -1 cgriego (reminds me of parsing--processing--more so than even microformats-dev)
* microformats-propose (it misses the point of the process, and implies that there is a desire for microformats proposals - there isn't)
** -1 tantek
** -1 ScottReynen
** +1 Andy Mabbett
* microformats-suggest (similar to propose but milder ;)
** +1 ChrisMessina
** 0 tantek
** -1 ScottReynen
** -1 Phae (I feel this is just -propose in disguise)
** - BenWest
** -1 Andy Mabbett
* nothing (fix uf-dev, do nothing else (for now))
** +1 RyanKing
** +1 BenWest
** +1 Tim White

to-do

2006-10-16T20:25:36Z

Cgriego: Commented in bewest's section on wiki/* as an intro page and wiki/*-spec.

<h1>To Do</h1>

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

__TOC__

== Lazyweb ==

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

=== for all microformats ===
* quick and easy "how to" pages for each microformat. [[use]] is a good overall start.
* brief summary statements for each microformat that explain why it matters, what does it accomplish for the publisher.
* write up [http://microformats.org/discuss/ mailing-list] questions and answers in the appropriate [[faq]] pages.
* validators. See the hReview section below as there has been a request for an hReview validator in particular. See [http://norman.walsh.name/2006/04/13/validatingMicroformats Norman Walsh's blog post "Validating microformats"] for some valuable analysis and validation pseudo-code (prose description), which are useful steps towards building microformat validators.
* Create a microformat (based on hCalendar?) for marking up the opening hours of stores and restaurants. Some people seem to believe hCalenders repeating event support isn't good enough for this and needs to be amended first.

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

=== hCard ===
* microformatted versions of conference pages
** Do a revision of the [http://conferences.oreillynet.com/etel2006/ ETel] [http://conferences.oreillynet.com/pub/w/44/speakers.html speaker's page] with all the speakers marked up with [[hcard|hCard]] and links to "Add hCards to Address Book" etc., similar to the [http://tantek.com/microformats/2005/web2/speakers.html Web 2.0 speakers page which Tantek did a revision of last fall].
* vcard to hcard converter
** would be nice to have a web upload UI that would take one or more vCards from apple's address book and give them back to you as hCards
** [[User:RobertBachmann | RobertBachmann]] suggests starting points:
*** For Ruby: http://vpim.rubyforge.org/
*** For C: http://freshmeat.net/projects/libvc/
*** For Python: http://www.nongnu.org/python-pdi/
*** For PHP: http://pear.php.net/package/Contact_Vcard_Parse/
* add export support for microformats to [http://www.turingart.com/abForWeb_lan__en.htm AB to Web]
* A mash-up with google maps that will take any url with a hcard (or hcard's) and map the location(s) on a map (similar to [http://austin.adactio.com/ austin.adactio.com])

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

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

=== Yahoo Open Source Library Patches ===

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

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

=== Drupal patches for microformats ===
* submit patches for Drupal code/templates for microformats improvement
* Drupal modules for microformats, specifically hReview and hCalendar

=== Adding Markup to Existing Pages (W3C track at WWW2006) ===

* DanC offers a 150 point bounty to anybody who takes [http://www.w3.org/2006/05/w3c-track the W3C track at WWW2006] and adds hCalendar markup and sends it to connolly@w3.org,www-archive@w3.org

===Geotagging on Wikipedia===
Somebody familiar with the "geo" microformat might want to add details, and a link to the relevant page on this Wiki, to the [http://en.wikipedia.org/wiki/Geotagging Wikipedia page on Geotagging].

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

=== *-authoring microformats wiki pages ===
* Add some tips to [[hcard-authoring]]
** a tutorial on creating an hCard for your site
** specific instructions for common blogging platforms
** instructions for more properties (match at least the set that is in the [http://microformats.org/code/hcard/creator hCard creator]
* Create [[hreview-authoring]] - a tutorial on how to blog reviews so that they'll be aggregated.

=== for all microformat specs ===
* 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]] - need to create new pages for [[hcard-examples-in-the-wild]] (perhaps grouped/ sorted by individuals, organizations, and hosting sites?), [[hcard-implementations]] at a minimum to separate out that content, and leave short summaries in their existing place inline in the [[hcard|hCard]] spec.
** [[rel-tag]]
** [[xoxo]]

==== update specification section organization ====
In particular, the introduction/boilerplate/headers. [[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.

==== reorg Examples in the Wild sections ====

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

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

=== iterate on current microformats ===
==== [[hreview|hReview]] ====
* 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.

==== [[hcalendar|hCalendar]] ====
* formalize [http://microformats.org/wiki/hcalendar- brainstorming#Tabular_event_calendars]
* flesh out [[hcalendar-examples]] and do a once over on markup/presentation of what RFC2445 examples would look like
* need spec details and then [[hcalendar-examples]] of multi-instance [[hcalendar|hCalendar]] events
* need spec details and then [[hcalendar-examples]] of repeating events
* add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.
* need to resolve all outstanding [[hcalendar-issues]] to-do items.
* create [[hcalendar-profile]] and have folks verify it. note that it will likely need reconciliation with the [[hcard-profile]], especially since [[hcalendar|hCalendar]] normatively depends on [[hcard|hCard]]. Probably makes sense to have a combined profile which hCalendar would use.

==== [[hcard|hCard]] ====
* [[hcard-examples]]
** 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.
* Examples in the wild - need to create a new page for them!
** Group examples in the wild according to:
*** Individuals - one card per person, perhaps sort alphabetically
*** Organizations - one card per organization, alphabetical again
*** Institutions (which list more than one person), with a count estimating the # of hCards, e.g. 40k for Avon. Also indicate complexity of information supplied, eg. just name+number vs. complete details
*** Online Profiles (which host profiles for more than one person) with a count estimating the # of hCards, e.g. 3.5m for Flickr.com
*** Online Venues (which provide listings for businesses or organizations) with a count estimating the # of venues, e.g. ~10k for Upcoming.org
*** Speakers Listings (lists of speakers on conference sites) with a count estimating the # of speakers, e.g. ~300 for SXSW 2006.
** help dglazkov markup: http://glazkov.com/blog/archive/2003/12/17/147.aspx

=== introduction / community ===
* microformats-discuss
** introductory email sent to 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.

=== 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)
** ability/suggestion to reference an XMDP using <a href> in addition to <link>

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

=== create microformats wiki pages for ===
* *-authoring for all microformats
* *-parsing for all microformats

=== improve usability and automation on the site ===
* 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.

=== help with microformat implementations ===
* wordpress improvements
** WP admin for new profiles
*** should simply read blog URL
*** 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
** We need to ASAP build a simple conference schedule creator (and editor?) that builds upon the hCalendar creator. We should make 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.

=== help with microformat examples in the wild ===
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.

=== help with 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]].

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

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

* 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

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

== Robert Bachmann ==

=== hCard Creator ===
* [http://microformats.org/code/hcard/creator hCard creator] - add features/fields
** aim / instant messaging contact info, using the techniques documented in [[hcard-examples#New_Types_of_Contact_Info|hCard Examples: New Types of Contact Info]]
*** consider a popup menu for the IM service (AIM|Yahoo|...), and a field next to it for the IM id.

=== hAtom2Atom ===

Some ideas for features which could be implemented :

(If you are interested in one of this features, add "+1 Your Name")

<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:
* MSXML
* .Net System.Xml
* Sablotron
* Oracle XSLT
* XT
</li>
<li>Support for other output formats: (hAtom2xyz.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])
* 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.
</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)

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

== Mark Rickerby ==

=== Current Tasks ===

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

=== Wishlist ===

* hmmm

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

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

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

== Dan Connolly ==

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

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

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

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

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

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

== Chris Casciano ==

[[User:ChrisCasciano|ChrisCasciano]]

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

== Drew McLellan ==

[[User:DrewMcLellan|DrewMcLellan]]

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

== Christophe Ducamp (french localization) ==

[[Christophe Ducamp]]
* translate exploraty discussions (red links on [[to-do-fr]]
** find experts for peer-reviewing
* localize an french version of the official website
** find out the original versions of pictures (in SVG ?)
** find out french skills resources to adapt the original webdesign

== 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.
* (Feel free to add suggested tasks to my list)

== Ben West (bewest) ==

[[User:BenWest|bewest]]
=== Creators ===
* <strike>Start hatom creator.</strike> http://dichtomize.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 ===
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.

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?

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)

== New Person 1 ==

etc.

mailing-lists

2006-10-16T18:46:12Z

Cgriego: Added vote for microformats-research

<h1> Mailing Lists </h1>

Read the [http://microformats.org/discuss/ microformats discuss page] first.

Then read the [http://microformats.org/mailinglists-policies/ mailing list policies].

Ok, now here are some additional notes of scope and topics for each list.

__TOC__

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

=== 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.
# '''Using namespaces and namespace prefixes.''' 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

== microformats-rest ==
For discussion of use of microformats with REST, in protocols, services, APIs etc.

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

== new list proposal ==

There is a proposal for creating a new mailing list for discussing the research and creation of new microformats so that those discussions do not overwhelm microformats-discuss.

Some candidates for names with the thinking behind them. Feel free to add your name and opinion (+/- 1 or 0).

* microformats-new (focusing on discussing "new" microformats)
** +1 tantek
** +1 ScottReynen
* microformats-research (focusing on the essential, and often overlooked by first-time proposers "research" phase(s) in the process)
** +1 tantek
** +1 ScottReynen
** +1 cgriego
* microformats-process (That's really what we're talking about with research of new microformats, isn't it?)
** +1 ScottReynen
* microformats-propose (it misses the point of the process, and implies that there is a desire for microformats proposals - there isn't)
** -1 tantek
** -1 ScottReynen
* microformats-suggest (similar to propose but milder ;)
** +1 ChrisMessina
** 0 tantek
** -1 ScottReynen
* nothing (fix uf-dev, do nothing else (for now))
** +1 RyanKing

adr

2006-01-10T05:41:58Z

Cgriego: Typo: feeback to feedback

= adr =

'''adr''' (working name, pronounced "adder") is a simple format for marking up address information, suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. '''adr''' is a 1:1 representation of the ''adr'' property in the vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) in XHTML, one of several open [[microformats|microformat]] standards.
__TOC__

== Draft Specification ==
=== Editor/Author ===
[http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]

=== Copyright ===
{{MicroFormatCopyrightStatement2005}}

=== Patents ===
{{MicroFormatPatentStatement}}

=== Inspiration and Acknowledgments ===
Thanks to everyone who participated in the [[geo-bof-2005-06-30|Geo Microformat BOF at O'Reilly's Where 2.0 conference]], and in particular to [http://radar.oreilly.com/nat/ Nat Torkington] and Vee McMillen of [http://oreilly.com O'Reilly] for [http://conferences.oreillynet.com/cs/where2005/view/e_sess/7476 arranging and hosting the BOF].

== Introduction and Background ==
The vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]), has been broadly and interoperably implemented (e.g. Apple's Address Book application). The [[hcard|hCard]] microformat has similarly received significant adoption, from numerous sites publishing the format, to hCard to vCard proxies, to clientside javascript parsers.

At the [http://conferences.oreillynet.com/where/ Where 2.0 conference] in June 2005, there was widespread recognition that the community needed a way to simply and easily publish visible, extractable, address information on the Web, given how often bloggers, and numerous other sites publish address information. The [[geo-bof-2005-06-30|geo microformat BOF]] discussed this very topic, and concluded with a consensus decision to just try using ''adr'' from vCard/hCard.

This specification introduces the '''adr''' microformat, which is a 1:1 representation of the aforementioned ''adr'' property from the vCard standard, by simply reusing the ''adr'' property and sub-properties as-is from the [[hcard|hCard]] microformat.

Publishers can both embed '''adr''' addresses directly in their web pages and feeds, as well as markup existing addresses in the context of the rest of the information in their web pages and feeds.

If the publisher knows and is publishing the ''name'' of the location in addition to its address, then the publisher MUST use [[hcard|hCard]] instead of just '''adr''' to publish the name and address of the location.

== Semantic XHTML Design Principles ==
{{semantic-xhtml-design-principles}}

== Format ==
=== Singular Properties ===

Note that all the properties in '''adr''' are singular properties, and thus the first descendant element with that class should take effect, any others being ignored.

=== Human vs. Machine readable ===

If an <code><abbr></code> element is used for a property, then the <code>title</code> attribute of the <code><abbr></code> element is the value of the property, instead of the contents of the element, which instead provide a human presentable version of the value.

Similarly, if an <code><img></code> element is used for one or more properties, it must be treated as follows:
# For the <code>PHOTO</code> property and any other property that takes a <abbr title="Uniform Resource Locator">URL</abbr> as its value, the <code>src</code> attribute provides the property value.
# For other properties, the <code><img></code> element's <code>alt</code> attribute is the value of the property.

=== Value excerpting ===

Sometimes only part of an element which is the equivalent for a property should be used for the value of the property. For this purpose, the special class name <code>value</code> is used to excerpt out the subset of the element that is the value of the property. See [[hcard|hCard]] for details on this.

=== Root Class Name ===

The root class name for an '''adr''' address is <code>adr</code>.

=== Property List ===

This is the list of properties in '''adr''', taken from [[hcard|hCard]]:

* <code>post-office-box</code>
* <code>extended-address</code>
* <code>street-address</code>
* <code>locality</code>
* <code>region</code>
* <code>postal-code</code>
* <code>country-name</code>

The <code>type</code> sub-property is omitted because without the context of a type of address for ''whom'', it doesn't make much sense.

=== XMDP Profile ===

See [[hcard-profile]] for the [http://gmpg.org/xmdp XMDP] profile of hCard which contains the above complete list of properties, with references to their RFC 2426 definitions.

=== Parsing Details ===
See [[hcard-parsing|hCard parsing]], with the only difference being that "adr" is the root class name, rather than "vcard".

== Examples ==
This section is informative.

=== Sample adr ===

Here is a sample adr:

<pre><nowiki>
<div class="adr">
<div class="street-address">665 3rd St.</div>
<div class="extended-address">Suite 207</div>
San Francisco,
CA
94107
<div class="country-name">U.S.A.</div>
</div>
</nowiki></pre>

This adr might be displayed as:

<pre>665 3rd St.
Suite 207
San Francisco, CA 94107
U.S.A.</pre>

=== More Examples ===

See [http://microformats.org/wiki/hcard-examples#3.2.1_ADR_Type_Definition hCard example ADR] for more examples.

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

The following sites have published adrs, outside their normal context of hCards, and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc., in addition to [[hcard|hCard]] examples in the wild. If you find adrs outside of hCards anywhere else, feel free to add them to the top of this list. Once the list grows too big, we'll make a separate wiki page.

* ...
* ...

== Implementations ==
This section is '''informative'''.

The following implementations have been developed which either generate or parse adrs outside the context of hCards. If you have an adr 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.

* The [http://tantek.com/microformats/hcard-creator.html hCard creator], though it creates complete hCards, can also be used simply to create adrs by filling out the address portion and simply copy and pasting the <div class="adr"> element and its contents.

== References ==
=== Normative References ===
* [[hcard|hCard]]

=== Informative References ===
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426] ([http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426])
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]

=== Similar Work ===
* [[geo]]
* [[hcalendar|hCalendar]]
* [[XOXO]]

== Work in progress ==
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added.

== Discussions ==

* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

=== Q&A ===
* If you have any questions about hCard, check the [[hcard-faq|hCard FAQ]] first, and if you don't find answers, add your questions! (Odds are that any '''adr''' question will apply to [[hCard]] as well).
* See also [http://microformats.org/discuss/ for other methods of feedback].

=== Issues ===
* Please add any issues with the specification to the separate [[hcard-issues|hCard issues]] document. Ditto.

hatom-issues

2006-01-09T15:34:38Z

Cgriego: Added reuses of 'summary' to atom:summary nomenclature

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]
* [http://www.dannyayers.com Danny Ayers]
* [http://tantek.com/ Tantek Çelik]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# Not to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave identically to what they before hAtom was applied.

= New Nomenclature =

[[User:DavidJanes|David Janes]] added this on 2006.01.03. Since we've decided that correspondence to Atom nomenclature is not going to happen, let's just decide on it here. I tried but probably haven't succeeded in pulling all the info from below up so feel free to add new things. Also feel free to change your vote if you see a consensus happening.

'''How to use this'''. If you like a particular use, place something like '<code>: +1 YourName</code>' following the name. Feel free to make as make negative votes. If you have something compelling to say, add it to the Discussion section that follows. Let's settle this out by, say the 10th of January 2006?

== Feed (atom:feed)==
* <code>class="feed"</code> (Atom consistency)
* <code>class="atom-feed"</code> (Atom consistency with prefix)
* <code>class="hfeed"</code> (h* uF consistency)
: +1 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle
: +1 MarkRickerby

=== Discussion ===

The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - Tantek

== Entry (atom:entry) ==
* <code>class="entry</code> (Atom consistency)
: +1 MarkRickerby
* <code>class="atom-entry</code> (Atom consistency with prefix)
* <code>class="hentry</code> (h* uF consistency)
: +1 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])

=== Discussion ===

Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].

If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.

Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.

-Tantek

== Entry Title (atom:title) ==
* <code>class="title"</code> (Atom consistency)
: -1 Tantek. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>class="entry-title"</code> (Atom consistency, avoid hCard conflict)
* <code>class="heading"</code> (HTML)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (hReview consistency)
: -1 KevinMarks (clashes with atom)
* <code>class="headline"</code> what they're called in the News/Journalism industry
: +1 Tantek
: +1 KevinMarks
* <code>class="fn"</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
: ±0 DavidJanes see my note below
: -1 Tantek (does not mean the "name" of the post/entry)

=== Discussion ===
BenjaminCarlyle: If one were to review a blog entry with hReview we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.

BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.

DavidJanes: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.

First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].

Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.

Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.

- Tantek

DavidJanes: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.

DavidJanes: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.

== Entry Content (atom:content) ==
* <code>class="content"</code> (Atom consistency)
: +1 Tantek
: +1 DavidJanes
* <code>class="description"</code> (vCalendar, hCalendar, xFolk, hReview consistency)

=== Discussion ===
It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture. - Tantek

BenjaminCarlyle: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

== Entry Summary (atom:summary) ==
* <code>class="summary"</code> (Atom, hReview, hCalendar, VJOURNAL consistency)
* <code>class="content-summary"</code> (Atom consistency avoiding hCalendar conflict)
* <code>class="partial-description"</code>
* <code>class="excerpt"</code>
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="abstract"</code>
: +1 KevinMarks

=== Discussion ===
Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such. - Tantek

Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we cna convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content' [[User:Kevin Marks|Kevin Marks]]

BenjaminCarlyle: I have been trying to convince meyself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.

Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts.

In addition:
* WordPress user interface calls it "excerpt"
* MovableType user interface calls it "excerpt"
Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone. - Tantek

== Entry Permalink (atom:link) ==
* <code>rel="bookmark"</code> (HTML consitency)
: +2 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle
: +1 KevinMarks

=== Discussion ===
BenjaminCarlyle: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.

== Entry Published (atom:published) ==
* <code>class="published"</code> (Atom consistency)
: +1 Tantek
* <code>class="dtpublished"</code> (Atom consistency with "dt" unofficial pattern)

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.

published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely. - Tantek

From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (or a part thereof)" - BenjaminCarlyle

== Entry Updated (atom:updated) ==
* <code>class="updated"</code> (Atom consistency)
: +1 Tantek
* <code>class="dtupdated"</code> (Atom consistency with "dt" unofficial pattern)
* <code>class="last-modified"</code>

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely. -Tantek

From [[last-modified-brainstorming]] semantics:
"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."
- BenjaminCarlyle

== Entry Author (atom:author) ==
* <code>class="author"</code> (Atom consistency)
: +1 Tantek

=== Discussion ===
BenjaminCarlyle: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?

My point is that in practice (>80% case again), contributor is not used. Thus we should consider excluding it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later. -Tantek

== Entry Contributor (atom:contributor) ==
: -1 Tantek
* <code>class="contibutor"</code> (Atom consistency)
: +1 Tantek

=== Discussion ===
I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor"). -Tantek

= Questions and Comments =

==Limitations==
There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl).
There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections.
The microformat would be much more useful with these capabilities added.
-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)

* We've deliberately restricted this to being a "blog post" microformat at this point to make the problem managable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detrement to this standard. -- DavidJanes
** You brought this microformat to my attention because you disagreed in priciple with the XOXO Blog Format (http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html)... yet the only tool that currently works with that format works with comments. note also that at ''least'' comment counts and links to comment sections are part of posts. If you don't want to encapsulate comments I suppose I understand that and can easily create my own format meant to be embedded in yours to facilitate this purpose :) -- [[User:Singpolyma|singpolyma]] 22:13, 3 Jan 2006 (PST)
** Where did I disagree in principle? A: I told you about the existence of hAtom. B: I mentioned several of the design goals for hAtom

In addition, note that frankly we don't care about invisible metadata, because most humans don't care about invisible metadata.

The info about a blog which is *visible* will likely be represented in hAtom if they pass the 80%+ test. To that extent, many blogs have visible title, description, author, and updated information. See [[blog-post-brainstorming]] for more on this. -Tantek

== Nomenclature ==

Note: microformats [[naming-principles]] include a precise means for coming up with names which should work in the 90% case.

One point to raise for hAtom in particular - we don't simply omit spaces from multiword property names, we use hyphens. E.g. "given-name" and many others in [[hcard|hCard]].

=== Why atomentry? ===
;class="atomentry" (or rather, "atom-entry")
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

'''STATUS - RESOLVED'''. We're going with "entry".

:: Tantek: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
* atom-entry
* hentry
* vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Why atomfeed? ===
;class="atomfeed" (or rather, "atom-entry")
:As above on the atomprefix. But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

* It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
** I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases
* A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
::This makes sense to me, the way vcalendar is optional since vevent is usually sufficient. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)
::Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct. - Tantek
: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again) -- [[DannyAyers]]
:: I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) -- [[User:DavidJanes|David Janes]]
:: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics". - Tantek

'''STATUS - PARTIALLY RESOLVED'''. We're going with "feed" IF and when the Feed element is used. When and where Feed is used at all is still under discussion in the mailing list as of 2005-12-26.

: Tantek: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
* atom-feed
* hfeed

=== Why rel="link" ? ===
I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
[[KevinMarks]]
* I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion -- [[DavidJanes]]
* Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom -- [[DavidJanes]]
* Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file. - Tantek
* OK, I'm happy with this -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.

* Tantek: agreed.

=== title already defined by hCard ===
The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'
* 'headline'
** as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]

=== summary already defined and used by vCalendar/iCalendar/hCalendar/hReview ===
The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):

* description, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. [[User:Kevin Marks|Kevin Marks]] 15:51, 31 Dec 2005 (PST)
** Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]]. See below for where to use "description". We must NOT use "description" to mean summary. - Tantek

* Depending on your interpretation, atom:summary could still be summary. Here is another option: subject (atom:title) -> summary (atom:summary) -> content (atom:content).

* atom:summary is described as abstract in

Tantek: We may want to avoid the use of 'summary' entirely within hAtom. Here are some alternatives:
* excerpt - in practice this is what most people provide instead of full text.
** +1 Tantek
* partial-description
* abstract - Rarely do bloggers actually provide abstracts different from the full text of their posts - this is so NOT the 80% (and thus should be rejected for microformat consideration), but see [http://microformats.org/wiki/blog-post-examples#Entry_contains_summary_content_only blog-post-examples] for some examples.
* content-summary

=== Why content? ===
The concept behind atom:content has precedent in earlier microformats derived from the iCalendar standard as "description".

=== Date and time names alternatives ===
* atom:updated
** VJOURNAL LAST-MODIFIED
*** (also used by HTTP -[[User:RobertBachmann|Robert Bachmann]])
** dtstamp
** dtupdated
* atom:published
** VJOURNAL CREATED
** dtpublished

=== Relationship to hReview definitions needs clarification ===
hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:

* atom:published -> hReview dtreviewed
* atom:author -> hReview reviewer

"Pushed back" is the wrong direction here.

The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.

In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.

- Tantek

== hCards ==

Should hCards be required for the <code><address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please -- [[DavidJanes]]

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as “The "atom:author" element is a Person construct that indicates the author of the entry or feed.” and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><addr class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI

'''STATUS - OPEN'''. "MAY" is the answer.

Tantek: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.

DavidJanes: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:

<pre><nowiki>
<div class="author">bonehead</div>
</nowiki></pre>

has an assumed defined mapping to

<pre><nowiki>
<div class="author vcard">bonehead</div></div>
</nowiki></pre>

Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmicly.

== Comparisons ==

This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:
* atomentry <-> slide
* content <-> slidecontent
* summary <-> handout
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

-- [[Ernie Prabhakar]]

* See the [[#Purpose]] section above. Basically that drove the design decision for the naming [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We're sticking with atom terminology (entry, content, summary).

See above as David says. The atom terminology is both problematic, and doesn't make sufficient reuse of existing microformat terminology. As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience. - Tantek

== Repeated Elements ==
We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].

Your thoughts please... -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.

== Opaqueness ==
If you have concerns about [[hatom#hAtom_Opaque|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.

=== Opaqueness of other microformat elements ===
How would we handle a case where someone wanted to provide a vcard under the class=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.

To summarise,
Is it possible that other microformats found under the class=entry or class=feed elements need to be considered opaque?

-- BenjaminCarlyle

* The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class="opaque"</code> element. -- [[User:DavidJanes|David Janes]]

See the [[mfo-examples]] document, and add further thoughts on this matter there. -- Tantek

=== Opaqueness of summary and content ===
What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. last-modified-brainstorming introduces an idea of using <code><ins></code> and <code><del></code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.

Perhaps content and summary should not be opaque, and instead rely on the mfo proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.

Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:
<code><div class="content"><div class="summary">...</div>...</div></code>

A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.

== Identification ==
The current spec under Schema:Nomenclature:Entry includes the text:
"if practical, also define id="unique-identifier" to the Entry"
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?

Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?

The id elements in atom are supposed to survive all future movements of the blog t new hosting arragements and the like. Are current feed URLs or even rel=bookmarks solid enough?

'''STATUS - OPEN'''.

== HTML Title ==
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?

== rel-tag ==
Should hAtom use rel-tag for atom category elements?

IMHO yes. -- Tantek

A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.

rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.

rel-tag permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

== Excess disambiguation rules? ==
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.

It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?

== Dependancies ==
=== mfo ===
Does this specification depend on acceptance of a hAtom-compatible mfo?
See [[mfo-examples]].

=== last-modified ===
Does this specification depend on acceptance of a hAtom-compatible last-modified?

== Is atom:content necessary? ==
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?

== Published as default value for atom:updated ==
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.

I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:
# If multiple updated fields exist, choose the most recent one.
# If only one updated field exists, choose that value.
# If no updated field exists but a published field exists, use the published value for atom:updated.

=See Also=
* [[hatom|hAtom]] - the draft proposal
* [[hatom-issues]] - problems? complaints? ideas? Put them here
* [[hatom-faq]] - knowledge base
* [[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]]

User:Cgriego

2006-01-04T22:03:29Z

Cgriego: TZ

Chris Griego

TZ:-06:00; CST

irc

2006-01-04T22:00:59Z

Cgriego: cgriego TZ

__NOTOC__
= Microformats IRC =

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

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

== People on irc ==
A list of IRC regulars and their normal timezones.

* [[User:RyanKing|kingryan]] (-0800)
* [[User:EdwardOConnor|hober]] (-0800)
* [[User:RobertBachmann|RobertBachmann]]
* [[User:Tantek|Tantek]] (-0800)
* [http://epeus.blogspot.com/ KevinMarks] (-0800)
* [[User:DimitriGlazkov|dglazkov]] (-0600)
* [[User:ChrisMessina|factoryjoe]] (-0800)
* [[User:IanHickson|Hixie]] (-0800)
* [[User:neuro]]
* [[User:JoeGregorio|jcgregorio]]
* [[User:Cgriego|cgriego]] (-0600)

=== bots ===

* [[mfbot]]
* [[mflogbot]]
* [[jibot]]

== IRC meetups ==

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

User:Cgriego

2006-01-04T20:23:58Z

Cgriego:

Chris Griego

irc

2006-01-04T20:16:21Z

Cgriego: Added cgriego

__NOTOC__
= Microformats IRC =

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

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

== People on irc ==

* [[User:RyanKing|kingryan]]
* [[User:EdwardOConnor|hober]]
* [[User:RobertBachmann|RobertBachmann]]
* [[User:Tantek|Tantek]]
* [http://epeus.blogspot.com/ KevinMarks]
* [[User:DimitriGlazkov|dlazkov]]
* [[User:ChrisMessina|factoryjoe]]
* [[User:IanHickson|Hixie]]
* [[User:neuro]]
* [[User:JoeGregorio|jcgregorio]]
* [[User:Cgriego|cgriego]]

=== bots ===

* [[mfbot]]
* [[mflogbot]]

== IRC meetups ==

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