Microformats Wiki - User contributions [en]

haudio

2012-08-04T02:18:54Z

ManuSporny: Added Wikipedia to Examples in the Wild section

<entry-title>hAudio 0.9.1</entry-title>
{{Template:DraftSpecification}}
{{TOC-right}}
http://farm2.static.flickr.com/1216/604867362_da0921136a_o.png

[[haudio|hAudio]] is a simple, open, distributed format, suitable for embedding information about audio recordings in (X)HTML, Atom, RSS, and arbitrary XML. hAudio is one of several [[microformats]] open standards. This page and Microformat is in the public domain.

== hAudio Microformat Draft Specification ==

=== Editors ===
* [[User:ManuSporny | Manu Sporny]] ([http://www.bitmunk.com/ Bitmunk] - [http://blog.digitalbazaar.com Digital Bazaar], Inc.)
* [[ user:WebOrganics | Martin McEvoy ]]
=== Authors ===
* [[User:ManuSporny | Manu Sporny]]
* [[ user:WebOrganics | Martin McEvoy ]]

=== Contributors===
[[User:ManuSporny | Manu Sporny]], [[ user:WebOrganics | Martin McEvoy ]], [[ User:AlexandreVandeSande | Alexandre Van De Sande ]], Michael Johnson, Dave Longley, Brian Suda, Ben Wiley Sittler, Scott Reynen, Frances Berriman, James Craig, David Janes, [[User:AndyMabbett|Andy Mabbett]], Danny Ayers, Rudy Desjardins, Edward O'Connor, Ryan King, Chris Griego, Brad Hafichuk, Tantek Çelik, Colin Barrett, Joe Andrieu, Michael Smethurst, [[User:ChrisNewell | Chris Newell]], Julian Stahnke, Justin Maxwell, Paul Wilkins and David I. Lehn.

Microformats [[#Copyright]] and [[#Patents]] statements apply.

== Introduction ==

It is difficult for a browser to extract semantic information about an audio recording described on a web page. Metadata such as speaker, musician, publisher, label, title of the work, release date, acquisition link, related image artwork and tags provide relevant context for the audio recording.

Having such information marked up can provide a number of benefits to the viewer. If a web browser understands that a particular web page contains a song performed by an artist, it can produce richer interactions. For example, specific searches may be performed for artists and songs via general search services such as Google and Wikipedia. Specific search services may also be queried such as MusicBrainz, The Internet Archive, FreeDB, or Bitmunk. Additionally, classification by crawlers can become more accurate. If there are 20 tracks found on a page done by the same artist, and that content consumes a significant portion of the page, it can be assumed that the page is not only about music, but also about a particular artist.

In order to enable and encourage the sharing, distribution, syndication, and aggregation of audio content, the authors propose the hAudio microformat, an open standard for distributed audio metadata. The authors have researched both numerous [[audio-info-examples]] in the wild and earlier attempts at [[audio-info-formats]], and have designed hAudio around a simple minimal schema for audio content. Feedback is encouraged on the [[haudio-feedback|hAudio feedback]] page.

=== Inspiration and Acknowledgments ===

Many thanks to the various individuals that did research and proposed ideas and discussion related to media info and audio info in general. Among the many participants are [[RodBegbie]], Dean Hudson, [http://tantek.com/log/ Tantek Çelik], [http://napsterization.org/stories/ Mary Hodder], [http://joshkinberg.com/blog/ Joshua Kinberg], ChrisMessina, and [http://onlisareinsradar.com/ Lisa Rein].

=== Scope ===

Audio content consistently share several common fields. Where possible hAudio has been based on this minimal common subset.

=== Out of scope ===

Fields that are type-specific have been omitted from hAudio. It is important that hAudio be kept simple and minimal from the start. Additional features can be added as deemed necessary by practical implementation experience.

The concept of a universal audio identifier, that is, how to identify the same audio album, song, speech, or podcast across different music and audio sites, though something very useful to have, is outside the scope of this format.

== Format ==

{{rfc-2119-intro}}

=== In General ===
The hAudio format is based on a set of fields common to numerous audio content sites and formats in use today on the web. Where possible field names have been chosen based on those defined by the related [[hcard|hCard]] standards.

=== Schema ===

The hAudio schema consists of the following:

* hAudio ('''<code>haudio</code>''')
** '''fn''' or/and '''album''' required. text.
** '''contributor'''. optional. using text or [[hCard]].
** '''duration'''. optional. ISO-8601 time duration. (re-used from [[hcalendar]]).
** '''item''' optional. using text or multiple properties from [[hAudio]].
** '''position''' optional. text.
** '''category'''. optional. text.
** '''published'''. optional.
** '''photo'''. optional. using any element containing a URL, such as IMG.
** '''description''' optional. text.
** '''sample''' (rel). optional. sample file/stream using [[rel-design-pattern]] with <code>sample</code> as the <code>mf-rel-value</code>.
** '''enclosure''' (rel). optional. full download of file using [[rel-enclosure]].
** '''payment''' (rel). optional. link to purchase process using [[rel-payment]].
** '''price''' optional. Using the sub properties '''currency''' and '''amount'''.

=== Field details ===

The fields of the hAudio schema represent the following:

==== hAudio ====

An hAudio is used to identify and describe metadata associated with an audio recording.

* an hAudio element is identified by class name <code>haudio</code>

==== fn ====

The name of a single audio recording is a short textual description used to identify the work among interested parties. This can be the name of a speech, song name, or short description regarding a sound effect.

* The element is identified by the class name <code>fn</code>.
* hAudio {{must}} have <code>fn</code> or/and <code>album</code>.

==== Album ====

The title of a collection of audio recordings, such as those that are represented as a CD, album or LP. The text should be a short textual description used to identify the work among interested parties.

* The element is identified by the class name <code>album</code>.
* hAudio {{must}} have either <code>album</code> or <code>fn</code> or both.

==== Item ====

A container for another hAudio item, which MUST be considered a part of the parent audio recording. An example of an item that is part of an hAudio would be a track in an audio album, a aria in an Opera, or a section of a podcast.

* The element is identified by the class name <code>item</code>.
* hAudio {{may}} have one or more items.
* The element {{must}} be processed opaquely. No sub-elements should be read from any hAudio contained in a track element.
* The contents of the element {{must}} be marked up using properties in hAudio.

==== Position ====

The position is used to describe the position of the hAudio item in a list. Examples of hAudio lists can include album track listings, music top 10 lists, playlists, and podcast chapters.

* The element is identified by the class name <code>position</code>.
* hAudio {{may}} include one <code>position</code> element.
* The contents of the element {{must}} be a number or other sequential identifier.
* The sequential identifier {{may}} be specified out-of-sequence.

==== Contributor ====

A Contributor is any entity that takes part in the creation and distribution of an audio recording. Examples include: artist, composer, publisher, guitarist, vocalist, violinist, lead singer, backup singer, bassist, drummer, manager, and roadie.

* The element is identified by the class name <code>contributor</code>.
* hAudio {{may}} include one or more contributors.
* The contributor's name SHOULD also be marked up as a valid hCard Microformat. [[hcard]]
*# The <code>role</code> attribute {{should}} be used to specify the contributor's responsibility related to the audio recording if hCard is utilized.
* The contributor's name {{may}} be specified in plain-text without being enclosed in a hCard Microformat.

==== Published ====

The published date specifies the date that the audio recording was made available to the public. Examples include: The airing date of a radio broadcast, the day a speech was given, or the day a music album was made available for sale.

* The element is identified by the class name <code>published</code>.
* hAudio {{may}} include one or more <code>published</code> elements.
* The contents of the element {{may}} include a date format compliant with the [[datetime-design-pattern]].

==== Sample ====

A Sample URI specifies from where an excerpt of the audio recording may be retrieved.

* The element is identified by a URI fitting the [[rel-design-pattern]], the rel content being <code>sample</code>.
* hAudio {{may}} include one or more URI <code>sample</code>s.
* The URI {{should}} point to a directly accessible stream or file.
* The type of the sample {{may}} be specified by using the <code>type</code> specifier for a URI.

==== Full Download (Enclosure) ====

A Full Download URI specifies from where the full version of an audio recording may be retrieved. The URI {{must}} point to a direct link to a file retrieval process (FTP, HTTP, BitTorrent URI, etc).

* The element is identified by a URI fitting the [[rel-design-pattern]], the rel content being <code>enclosure</code>.
* hAudio {{may}} include one or more <code>enclosure</code> URIs.
* The type of the file {{should}} be specified by using the <code>type</code> specifier for a URI.

==== Purchase (Payment) ====

A Purchase URI specifies from where the full version of an audio recording may be purchased. The URI {{must}} point to the beginning of a purchase process for the hAudio.

* The element is identified by a URI fitting the [[rel-design-pattern]], the rel content being <code>payment</code>.
* hAudio {{may}} include one or more <code>payment</code> URIs.
* The type of the file {{may}} be specified by using the <code>type</code> specifier for a URI.

==== Photo ====

A photo specifies an image that should be used to summarize the audio recording. Examples include: the image of a speaker, an audio album cover image, or a picture from a concert.

* The element is identified by the class name <code>photo</code>.
* hAudio {{may}} include one or more <code>photo</code> elements.
* The element {{should}} use an <img> element.
* The element {{may}} use any other element that contains a URL, such as <a> or <object>, but it is not recommended.

==== Category ====

The Category specifies the genre or style used to classify the audio recording. Examples include: blues, rock, motivational, spoken word, or sound effect.

* The element is identified by the class name <code>category</code>.
* hAudio {{may}} include one or more <code>category</code> elements.
* This element {{may}} be expressed using the [[rel-tag]] elemental microformat. When a category is expressed using rel-tag, the content of the element is used as the text for the category. For example: <code><a class="category" rel="tag" href="/tags/symphony">Symphonic</a></code> would have "Symphonic" as the text for the category.

==== Duration ====

The Duration specifies the length in time of the audio recording. Examples include: 104 seconds, 3:23, and 4 minutes.

* The element is identified by the class name <code>duration</code>.
* hAudio {{may}} include one <code>duration</code> element.
* The contents of the element {{may}} use the [[abbr-design-pattern]] whose title attribute contains an ISO-8601 formatted duration. An example of 3:23 (i.e 3 minutes 23 seconds) would be "PT3M23S" in ISO 8601 format.
* The element {{may}} contain the following sub properties:
** '''h''' Hour.
** '''min''' Minute.
** '''s''' Second.
Example:
<pre><span class="duration">
<span class="h">1</span>:
<span class="min">3</span>:
<span class="s">23</span>
</span></pre>

==== Price ====

The Price specifies the amount of currency that must be exchanged for acquisition of a full specimen of the audio recording.

* The element is identified by the class name <code>price</code>.
* hAudio {{may}} include one or more <code>price</code> elements.
* The contents of the element {{may}} also use plain text with a currency symbol.
* The contents {{may}} contain the following sub properties:
** '''currency''' an [http://en.wikipedia.org/wiki/ISO_4217#Active_codes ISO 4217] currency name.
** '''amount''' a numerical value.
Example:
<pre><span class="price">
<abbr class="currency" title="GBP">£</abbr>
<span class="amount">4.99</span>
</span></pre>

==== Description ====

An explanation of the contents of the hAudio item. This could explain the significance of a speech, the full-text description of a sound effect, or the meaning of a song or album.

* The element is identified by the class name <code>description</code>.
* hAudio {{may}} include one or more <code>description</code> elements. If more than one description element is defined, the full description for the hAudio is the concatenation, in order, of all <code>description</code> elements.

=== Parser Processing Notes ===

* It is important to understand that ITEM is an opaque element. When processing the ITEM element, none of the properties of the child hAudio should be pulled into the parent hAudio. However, it is recommended that child hAudio {{should}} inherit the following parent hAudio properties, if they are not specified on the child:
** album
** contributor
** category
** published
** photo

=== Semantic XHTML Design Principles ===

{{semantic-xhtml-design-principles}}

==== More Semantic Equivalents ====

For some properties there is a more semantic equivalent, and therefore they get special treatment, e.g.:

* For "photo", use <code><img class="photo" src="..." alt="" /></code>
* If only 'album' is specified, then the hAudio is an album.
* If only 'fn' is specified, then the hAudio is a song, audio track, sound effect, speech, or other atomic/singular work.
* If both 'album' and 'fn' are specified, then the hAudio is a atomic/singular work that is part of an album.
** Example: <code><nowiki><span class="haudio">Side two of <span class="album">Meddle</span> opens with <span class="fn">One of These Days</span></span></nowiki></code>
* If 'fn' and one or more 'items's are specified, the hAudio is an audio recording containing multiple sections. Each item is assumed to be an hAudio that is part of the parent hAudio. None of the 'item' properties should implicitly be added to the containing hAudio. In other words, the parser shouldn't parse the contents of the 'item' into the higher-level hAudio object.

==== Language ====

* To explicitly convey the natural language that an hAudio is written in, use the standard (X)HTML 'lang' or 'xml:lang' attribute on the element with class="haudio"
**e.g. <code><nowiki><p>I like <span class="haudio" lang="de"><span class="fn">Das Lied von der Erde</span></span> best.</p></nowiki></code>
*If portions of an hAudio (e.g. the item name) are in a different language to the rest of the hAudio, use the 'lang' or 'xml:lang' attribute on those portions.
* hAudio parsers which need to handle the native language of hAudio {{must}} process the standard (X)HTML 'lang' or 'xml:lang' attribute as specified.
* hAudio parsers which need to handle native language {{may}} traverse up the DOM to discover the native language of the page and apply that to the hAudio if no other language is specified on the hAudio.

==== Human vs. Machine Readable ====

If an <code><abbr></code> element is used for a property, then its '<code>title</code>' attribute is used for the value of the property, instead of the contents of the element, which can then be used to provide a user-friendly alternate presentation of the value.

If an <code><a></code> element is used for one or more properties, it {{must}} be treated as follows:
# For the 'photo' property and any other property that takes a URL as its value, the <code>href="..."</code> attribute provides the property value.
# For other properties, the element's content is the value of the property.

If an <code><img></code> element is used for one or more properties, it {{must}} be treated as follows:
# For the 'photo' property and any other property that takes a URL as its value, the <code>src="..."</code> attribute provides the property value.
# For other properties, the <code><img></code> element's '<code>alt</code>' attribute is the value of the property.

If an <code><object></code> element is used for one or more properties, it {{must}} be treated as follows:
# For the 'photo' property and any other property that takes a URL as its value, the <code>data="..."</code> attribute provides the property value.
# For other properties, the element's content is the value of the property.

=== Notes ===

This section is informative.

* By marking up audio content with the hAudio microformat, the expectation is communicated that information about the content {{may}} be indexed. This has no impact on the copyright of the content itself which the publisher may explicitly specify using the [[rel-license]] microformat.

== XMDP Profile ==
See: [[haudio-profile]].

== Examples ==

This section is informative.

Here are a few examples of text about, and links to, audio content, from real web sites, showing how they could be easily enhanced to use hAudio.



=== Simple Song Example ===

Display:

(This is a live example, detectable in parsers)

<div class="haudio">
<span class="fn">Start Wearing Purple</span> by <span class="contributor">Gogol Bordello</span>
</div>

Microformatted XHTML:

<pre>
<div class="haudio">
<span class="fn">Start Wearing Purple</span> by
<span class="contributor">Gogol Bordello</span>
</div>
</pre>

=== Speech Example ===

(This is a live example, detectable in parsers)

Display:

<div class="haudio">
<span class="fn">I Have a Dream</span>, a <span class="category">speech</span> by <span class="contributor"><span class="vcard"><span class="fn n"><span class="given-name">Martin</span> <span class="additional-name">Luther</span> <span class="family-name">King</span>, <span class="honorific-suffix">Jr.</span></span></span></span>
</div>

Microformatted XHTML:
<pre>
<div class="haudio">
<span class="fn">I Have a Dream</span>, a
<span class="category">speech</span> by
<span class="contributor">
<span class="vcard">
<span class="fn n">
<span class="given-name">Martin</span>
<span class="additional-name">Luther</span>
<span class="family-name">King</span>,
<span class="honorific-suffix">Jr.</span>
</span>
</span>
</span>
</div>
</pre>

Note the use of [[hcard|hCard]].

=== Song and Album Example ===

(This is a live example, detectable in parsers)

Display:

<div class="haudio">
<span class="fn">Start Wearing Purple</span> by <span class="contributor"><span class="vcard"><span class="fn org">Gogol Bordello</span></span></span> found on <span class="album">Underdog World Strike</span>
</div>

Microformatted XHTML:

<pre>
<div class="haudio">
<span class="fn">Start Wearing Purple</span> by
<span class="contributor">
<span class="vcard">
<span class="fn org">Gogol Bordello</span>
</span>
</span>
found on
<span class="album">Underdog World Strike</span>
</div>
</pre>

Note that for bands, hCard's ''[[hcard#Implied_.22organization-name.22_Optimization|Implied "organization-name" Optimization]]'' is used.

=== Complete Album Example ===

An example that uses every element of hAudio:

[Image] Live Phish, Volume 15 by Phish<br/>
Released: October 31, 2002<br/>
Acquire: Sample, Live Recording, Buy High Quality Track<br/>
Category: [http://www.example.org/tags/live live]<br/>
Duration: 145 minutes, 27 seconds<br/>
Price: $14.99<br/>
<br/>
Tracks:<br/>
1. Sanity (5:48)<br/>
2. Highway To Hell (3:39)

Here is the hAudio Microformat markup:

<pre>
<div class="haudio">
<img class="photo" src="images/live_phish_vol_15.jpg" alt="" />
<span class="album">Live Phish, Volume 15</span>
<span class="contributor">
<span class="vcard">
<span class="fn org">Phish</span>
</span>
</span>
<br/>
Released on:
<abbr class="published" title="2002-10-31">October 31, 2002</abbr>
<br/>
Acquire:
<a rel="sample" href="/samples/live_phish_vol_15_sample.mp3">Sample</a>,
<a rel="enclosure" href="/live/phish_live_phish_vol_15.mp3">Live Recording</a>,
<a rel="payment" href="/buy/phish_live_phish_vol_15">Buy High Quality Track</a>
Category: <a class="category" rel="tag" href="http://www.example.org/tags/live">live</a>
Duration: <abbr class="duration" title="PT145M27S">145 minutes, 27 seconds</abbr>
Price: <div class="price"><abbr class="currency" title="USD">$</abbr><span class="amount">14.99</span></div>
Tracks:
<div class="item">
<span class="position">1</span>.
<span class="fn">Sanity</span>
(<abbr class="duration" title="PT5M48S">5:48</abbr>)
</div>
<div class="item">
<span class="position">2</span>.
<span class="fn">Highway To Hell</span>
(<abbr class="duration" title="PT3M39S">3:39</abbr>)
</div>
</div>
</pre>

=== Multi-part Podcast Example ===

DigitalPlanet Podcast: 29 Oct 07

Forensic computing: is it really possible to delete data from your machine? Grand plans for getting broadband into Africa, checking out the sky at night via the internet and answering your emails to the programme.

Download MP3

<pre>
<div class="haudio">
<p>
<span class="fn">DigitalPlanet Podcast</span>
:
<abbr class="published" title="20071029">29 Oct 07</abbr>
</p>
<p>
<div class="item">
<span class="fn">Forensic computing: is it really possible to delete data from your machine?</span>
</div>
<div class="item">
<span class="fn">Grand plans for getting broadband into Africa</span>
</div>
,
<div class="item">
<span class="fn">checking out the sky at night via the internet</span>
</div>
and
<div class="item">
<span class="fn">answering your emails</span>
</div>
to the programme.
</p>
<p>
<a rel="enclosure" href="/download/episode/DigitalPlanet-2007-10-29">Download MP3</a>
</p>
</div>
</pre>

=== Opera Example ===

(This is a live example, detectable in parsers)

<div class="haudio" lang="en">
<span class="fn" lang="fr">La Bohème</span> is an <span class="category">opera</span> in four acts by <span class="contributor" lang="it">Giacomo Puccini</span> to an <span class="category">Italian liberetto</span> by <span class="contributor" lang="it">Luigi Illica</span> and <span class="contributor" lang="it">Giuseppe Giacosais</span>. I saw it performed last week and found <span class="item"> <span class="fn">Act III</span> to be pretty interesting, especially the <span class="item"> "<span class="fn" lang="it">Sa dirmi, scusi</span>"</span> and <span class="item">"<span class="fn" lang="it">O buon Marcello, aiuto!</span>"</span> arias.</span>
</div>

<pre>
<div class="haudio" lang="en">
<span class="fn" lang="fr">La Bohème</span>
is an
<span class="category">opera</span>
in four acts by
<span class="contributor" lang="it">Giacomo Puccini</span>
to an
<span class="category">Italian liberetto</span>
by
<span class="contributor" lang="it">Luigi Illica</span>
and
<span class="contributor" lang="it">Giuseppe Giacosais</span>.
I saw it performed last week and found
<span class="item">
<span class="fn">Act III</span>
to be pretty interesting, especially the
<span class="item">
"<span class="fn" lang="it">Sa dirmi, scusi</span>"
</span>
and
<span class="item">
"<span class="fn" lang="it">O buon Marcello, aiuto!</span>"
</span>
arias.
</span>
</div>
</pre>

== Examples in the wild ==

This section is '''informative'''.

* [http://en.wikipedia.org/wiki/Category:Articles_with_hAudio_microformats Wikipedia] has 119,555 songs and albums marked up in hAudio format.
* [http://weborganics.co.uk/haudio-rss/ hAudio-RSS] uses hAudio 0.9.1 and XSLT to generate an RSS2 Playlist.
* Tara Hunt of [http://openmediaweb.org/index.php/2008/01/13/publishing-my-workout-music-in-haudio/ Open Media Web] Published her workout Music in hAudio
* Grabb.it The web music player now uses hAudio 0.9 in its [http://grabb.it/users/greg user pages]
* [http://soundcloud.com/ SoundCloud] has hAudio in its pages.
* [http://populizer.com/ Populizer] also has hAudio in its pages.
* The [http://www.numblog.de/ New Urban Music Blog] has hAudio marked up in its pages.
* [http://alpha.libre.fm/ Libre.fm] has marked up on all its user pages in hAudio see : [http://alpha.libre.fm/user/weborganics example]

== Implementations ==

This section is '''informative'''.

*[http://weborganics.co.uk/files/js/haudio.js hAudio 0.9 script] for [[operator|Operator]], updated version of the original hAudio script by David Lehn.
* Matthias Pfefferle has made some [http://notizblog.org/projects/haudio-icons/ hAudio Icons]
* [http://microform.at/ Microformat TransFormr] extracts hAudio 0.9.1 as a RSS2 Podcast.
* [http://buzzword.org.uk/cognition/ Cognition] 0.1-α11 and above will parse hAudio 0.9 and export as RDF/XML or RDF/JSON. As of 0.1-α12, it will also export in M3U playlist format and Turtle.
* [http://weborganics.co.uk/mo-haudio/ hAudio Microformat to RDF Music Ontology], a [http://www.w3.org/TR/grddl/ GRDDL] profile for hAudio 0.9.1, producing [http://musicontology.com/ Music Ontology] RDF.
* The [http://singpolyma.net/plugins/actionstream/ wp-diso-actionstream] plugin produces hAudio for last.fm scrobbles
*...


== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/ XMDP]
* [[hcard|hCard]]
* [[abbr-design-pattern]]
* [[currency-proposal]]
* [[datetime-design-pattern]]
* [[rel-design-pattern]]
* [[ISO-31-1|ISO-31-1/ISQ]]

=== Informative References ===
* [http://www.w3.org/TR/REC-CSS1 CSS1]
* ISO.8601.1988
** International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988.
* [http://www.w3.org/TR/1998/NOTE-datetime-19980827 W3C NOTE-datetime-19980827]
* [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy]
* Other audio metadata efforts. See [[audio-info-formats]].

==== Similar Work ====
* [[media-info]]
* [[grouping-examples]]
* [[grouping-brainstorming]]
* [[xoxo|XOXO]]

=== Copyright ===

This document and <span class="vevent"><span class="summary">hAudio specification was placed into the public domain</span> on <span class="dtstart">2008-11-14</span></span> by the authors. There are no usage, distribution, re-printing, or any other restrictions of any kind with regards to the text or content of this specification.

=== Patents ===

{{MicroFormatPatentStatement}}

=== Public Domain Release ===

The authors and editors of this page due hereby relinquish their copyright on the document and release the text of this page into the public domain.

* Manu Sporny - Signature /Manu Sporny/
* Alexandre Van de Sande
* [[User:WebOrganics|Martin McEvoy]]
* [[User:DavidLehn|David Lehn]] - Signature /David Lehn/
* [[User:AndyMabbett|Andy Mabbett]]

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

== Related Pages ==
{{haudio-related-pages}}
* [[audio]] (other pages about Audio on this wiki)

[[Category:Draft Specifications]]

haudio-issues

2011-07-30T19:27:17Z

ManuSporny: Re-opening D4: 2008-01-10 rel-enclosure does not allow for links to streaming files

=hAudio issues=

These are externally raised issues about [[haudio|hAudio]] with broadly varying degrees of merit. Thus some issues are <em style="text-transform:uppercase;">rejected</em> for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be <em style="text-transform:uppercase;">accepted</em> and perhaps cause changes or improved explanations in the spec.

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

== issues ==
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[haudio-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.
* You can subscribe to all haudio issues on <nowiki>webcal://feeds.technorati.com/events/http://microformats.org/wiki/haudio-issues</nowiki>

==2008==

=== D1: 2008-01-10 Contributor ===
<div class="vevent">
* {{ResolvedIssue}} D1: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011340.html microformats-discuss/2008-January/011340.html]</span>
<div class="description">
*# the wording about <code>contributor</code> could be improved to facilitate more streamlined mark-up (see above e-mail for details).
*#* A resolution to this issue is outlined in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001725.html
*#* ACCEPTED ISSUE The hAudio Contributor Specification is to be changed to:
*#** The element is identified by the class name |contributor|.
*#** hAudio /MAY/ include one or more contributors.
*#** The contributor's name SHOULD also be marked up as a valid hCard Microformat. <http://microformats.org/wiki/hcard>
*#**# The |role| attribute /SHOULD/ be used to specify the contributor's responsibility related to the audio recording if hCard is utilized.
*#** The contributor's name MAY be specified in plain-text without being enclosed in a hCard Microformat.
*#* REMOVED:
*#** If multiple contributors are specified, without |role| specifications, it /MAY/ be assumed that the first role mentioned is the primary artist or creator.
*#**# As proposed By [[User:ManuSporny|Manu Sporny]] in http://microformats.org/discuss/mail/microformats-new/2008-August/001725.html
</div>
</div>

=== D2: 2008-01-10 hAudio Title was Overloading "fn".===

<div class="vevent">
* {{ResolvedIssue}} D2: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011342.html] </span>
<div class="description">
The "overloading" of <code>fn</code> for both the tile of a work and the name of a contributor causes problems (see above e-mail for examples). Another example of this problem is a table, where the "artist" column comes before the "title" column. For discussion, see also [http://microformats.org/discuss/mail/microformats-new/2008-January/001375.html microformats-new/2008-January/001375.html].
# Existing Resolution [[User:ManuSporny|Manu Sporny]] has propsosed that <code>"fn"</code> should be replaced with <code>"title"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-February/001468.html microformats-new/2008-February/001468.html]
#* +1 [[User:ManuSporny|Manu Sporny]] (first choice)
#* +1 [[User:ManuSporny|Sarven Capadisli]] (second choice)
# Resolution 1: [[User:WebOrganics|Martin McEvoy]] proposed change <code>"title"</code> to <code>"name"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-March/001555.html microformats-new/2008-March/001555.html]
# Resolution 2: [[User:WebOrganics|Martin McEvoy]] later propsosed that <code>"title"</code> should be replaced with <code>"htitle"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html microformats-new/2008-August/001692.html]
#* +1 [[User:ManuSporny|Manu Sporny]] (second choice)
#* +1 [[User:Csarven|Sarven Capadisli]] (first choice)
# Resolution 3: Use <code>"audio-title"</code> As tentatively proposed by [[User:ManuSporny|Manu Sporny]] see:[http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html microformats-new/2008-August/001692.html]
# Resolution 4: Change <code>"title"</code> back to <code>"fn"</code> see: [http://microformats.org/wiki?title=haudio&diff=prev&oldid=25667]
#* +1 [[User:WebOrganics|Martin McEvoy]] Without Reservations see:[http://microformats.org/wiki?title=haudio-issues&diff=0&oldid=28703 haudio-issues&diff=0&oldid=28703]
#* +1 [[User:ManuSporny|Manu Sporny]] (third choice)
#* +1 [[User:DavidJanes]] this is the correct thing to do
#* +1 [[User:Csarven|Sarven Capadisli]] (third choice)
# Don't really care — just pick one. ;-)
#* +1 [[User:TobyInk|TobyInk]]
#* +1 [[User:ManuSporny|Manu Sporny]] - close this damn discussion, already! :)
* ACCEPTED ISSUE, RESOLUTION: Change <code>"title"</code> back to <code>"fn"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-September/001797.html microformats-new/2008-September/001797.html]
</div>
</div>

=== D3: 2008-01-10 Position. ===
<div class="vevent">
* {{ResolvedIssue}} D3: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011343.html microformats-discuss/2008-January/011343.html]</span>
<div class="description">
*# The [http://microformats.org/wiki/haudio#Complete_Album_Example recommended use of "position" in hAudio] is contrary to the good practice, semantic use of ordered lists (see example and suggested solution in the above e-mail; also [http://microformats.org/discuss/mail/microformats-new/2008-January/001338.html] et seq)
*#* For Cognition I'm considering an extension: if no position has been explicitly marked up, and the item is <code><li class="item"></code> within an ordered list, then the position is taken to be the numerical value of the list marker. (To calculate the numerical value for the list marker, find the most recent sibling <code><li></code> element which has a <code>value</code> attribute. The numerical value is the number in that value attribute added to the count of <code><li></code> elements after that value attribute up to the current one. If there are no such <code><li></code> elements with <code>value</code> attributes, then you should assume that the <code>value</code> attribute of the first list item is equal to the <code>start</code> attribute of the ordered list itself, or "1" if there is no such <code>start</code> attribute. [[User:TobyInk|TobyInk]] 04:24, 29 Jul 2008 (PDT)
*#* A Proposed Resolution was made in this email: ( http://microformats.org/discuss/mail/microformats-new/2008-August/001751.html)
*#* ACCEPTED ISSUE The hAudio Position Specification is to be changed to:
*#** The element is identified by the class name |position|.
*#** hAudio /MAY/ include one |position| element.
*#** The contents of the element /MUST/ be a number or other sequential identifier.
*#** The sequential identifier /MAY/ be specified out-of-sequence.
*#* ADDED:
*#** The sequential identifier /MAY/ be specified out-of-sequence.
*#**# As proposed By [[User:ManuSporny|Manu Sporny]] in http://microformats.org/discuss/mail/microformats-new/2008-August/001708.html
*#* [[User:AndyMabbett|Andy Mabbett]] also Expressed concerns that the [[haudio#Complete_Album_Example|Complete Album Example]] should be marked up as an ordered list this is unnecessary as <code>"position"</code> is not related to the order of a track item in a list.
*#* A tutorial on the correct use of semantic ordered lists and hAudio is to be added to the [[haudio-authoring|hAudio Authoring]] Page
</div>
</div>

=== D4: 2008-01-10 rel-enclosure does not allow for links to streaming files ===
<div class="vevent">
* {{OpenIssue}} D4: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html microformats-discuss/2008-January/011344.html]</span>
<div class="description">
*# The required use of [[rel-enclosure]] does not allow for links to streaming files, which are not cacheable, and are thus outside the scope of rel-enclosure. [http://www.bbc.co.uk/radio4/science/livingworld_20041121.shtml An example on the BBC website] has the relevant link is below the heading "LISTEN AGAIN". (see discussion at [http://microformats.org/discuss/mail/microformats-new/2008-January/001339.html microformats-new/2008-January/001339.html] et seq).
*#* A proposal for this issue was first made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001715.html
*#* A second proposal for this issue has been made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001727.html
*#* This can potentially be solved by recognition of downloadable/streamable MIME types. For performance reasons it is undesirable for parsers to be required to make HTTP requests for each file to determine its MIME type, so authors should be encouraged to include the MIME type in the <code>type</code> attribute. See the [[haudio-brainstorming#Download_links|related section on "brainstorming"]]. [[User:TobyInk|TobyInk]] 14:41, 20 Aug 2008 (PDT)
*#* ACCEPTED ISSUE The hAudio Enclosure Specification is to be changed to:
*#** The element is identified by a URI fitting the rel-design-pattern, the rel content being enclosure.
*#** hAudio MAY include one or more enclosure URIs.
*#** The type of the file SHOULD be specified by using the type specifier for a URI.
*#* CHANGED:
*#** The type of the file MAY be specified by using the type specifier for a URI.
*#*** As suggested by [[User:Tantek|Tantek Çelik]] in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001731.html
*#*** As Proposed by [[User:TobyInk|Toby Inkster]] on 14:41, 20 Aug 2008 (PDT)
*#* A tutorial on the importance of Type Specifiers and hAudio Enclosures is to be added to the [[haudio-authoring|hAudio Authoring]] Page
*#* BLOCKED: The [[rel-enclosure]] definition needs to be updated in order to allow specification of links to streaming files.
</div>
</div>

=== D5: 2008-01-10 there is no way of linking to an interim page ===
<div class="vevent">
* {{OpenIssue}} D5: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html microformats-discuss/2008-January/011344.html]</span>
<div class="description">
There appears to be no mechanism to mark up an hAudio, expressed in plain text on page A, which links to an interim page, B, which in turn links to a file download. For example, the radio shows listed on [http://www.westmidlandbirdclub.com/bibliography/radio].
</div>
# Resolution 1: re use <code>"url"</code> from [[hcard|hCard]].
#* +1 [[User:WebOrganics|Martin McEvoy]] all links are not clickable/hyperlinkable.
#* +1 [[User:TobyInk|TobyInk]]
# Resolution 2: use the rel <code>"bookmark"</code> [http://www.w3.org/TR/REC-html40/types.html#type-links HTML Link Type].
</div>

=== D6: 2008-01-10 hAudio notes inconsistency ===
<div class="vevent">
* {{ResolvedIssue}} D6: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011345.html microformats-discuss/2008-January/011345.html]</span>
<div class="description">
*# [[haudio#Notes|The "Notes" section of the hAudio spec]] says "By marking up audio content with the hAudio microformat, the expectation is communicated that information about the content {{may}} be indexed. This has no impact on the copyright of the content itself which the publisher may explicitly specify using rel-license as specified above.". However, that is the first and only reference to [[rel-license]] on the page.
*#* Typing error changed to "By marking up audio content with the hAudio microformat, the expectation is communicated that information about the content MAY be indexed. This has no impact on the copyright of the content itself which the publisher may explicitly specify using the rel-license microformat". [http://microformats.org/wiki?title=haudio&diff=0&oldid=27951]
*#* hAudio Specification SHOULD include the [[rel-license]] microformat [[User:WebOrganics|Martin McEvoy]] 11:57, 18 Aug 2008 (GMT)
*#* A proposed resolution to this issue has been made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001720.html
*# RESOLVED <code>rel="licence"</code> is not part of this version of hAudio (0.9) see:http://microformats.org/discuss/mail/microformats-new/2008-August/001747.html
</div>
</div>

==2009==

=== D7: 2009-01-11 Endorsement of optimization patterns in schema listing too strong ===
<div class="vevent">
* {{ResolvedIssue}} D7: <span class="summary vcard"><span class="dtstart">2009-01-11</span> raised by <span class="fn">[[User:BenWard|Ben Ward]]</span>.</span>
<p class="description">The hAudio spec schema makes references to multiple optimization patterns (datetime pattern for <code>published</code>, abbr-pattern for <code>duration</code>). It is currently worded as to imply that those patterns ''must'' be used. Given past disagreement over ABBR in particular, I think the spec should avoid specific endorsement of any pattern, at the very least reducing references to patterns to clear ‘You ''may'' use the abbr-pattern with this field' sort of phrasing.</p>
# Resolution 1: Reword schema listing to use ''may'' language clearly.
#* +1 [[User:BenWard|Ben Ward]]
#* +1 [[User:TobyInk|TobyInk]]
#* +1 [[User:WebOrganics|Martin McEvoy]]
** RESOLUTION: The schema now uses ''may'' language more clearly
</div>

=== D8: 2009-01-11 Don't link to currency proposal ===
<div class="vevent">
* {{ResolvedIssue}} D8: <span class="summary vcard"><span class="dtstart">2009-01-11</span> raised by <span class="fn">[[User:BenWard|Ben Ward]]</span>.</span>
<p class="description">The hAudio spec schema makes reference to the currency proposal. Since that is still a proposal, the spec should not endorse it or encourage too-early adoption of it, especially since it's not even a ''draft'' at this stage. Should the currency work be completed, hAudio should be updated later, rather than linking it in pre-emptively.</p>
# Resolution 1: Remove reference to currency proposal from hAudio schema.
#* +1 [[User:BenWard|Ben Ward]]
#* +1 [[User:TobyInk|TobyInk]]
#* +1 [[User:WebOrganics|Martin McEvoy]]
** RESOLUTION: The hAudio no longer references the currency proposal, only cites it as an Informative reference at the bottom of the page.
</div>

==2010==

=== D9: 2010-06-11 hAudio duration and published should adopt the value-title pattern ===
<div class="vevent">
* {{OpenIssue}} D9: <span class="summary vcard"><span class="dtstart">2010-06-11</span> raised by <span class="fn">[[User:WebOrganics|Martin McEvoy]]</span>.</span>
<p class="description">[[haudio#Duration|hAudio Duration]] and [[haudio#Published|Published]] should adopt the value-title pattern like [[hrecipe#duration|hRecipe Duration]] and [[hatom-profile|hAtom]], to prevent the user from getting machine data in a tooltip.</p>
Example:
<pre><span class="duration">
3 minutes 33 seconds
<span class="value-title" title="PT3M33S">.</span>
</span></pre>
and....
<pre><span class="published">
February 06, 2007
<span class="value-title" title="2007-02-06">.</span>
</span></pre>

# Resolution 1: Adopt the value-title pattern for both hAudio Duration and Published.
#* +1 [[User:WebOrganics|Martin McEvoy]]
#* +1 [[User:AndyMabbett|Andy Mabbett]] via: [http://twitter.com/pigsonthewing/statuses/15935702988 Twitter]
</div>

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

==see also==
*[[audio-info-issues]]

==related pages==
{{haudio-related-pages}}

microformats2

2011-06-18T19:00:12Z

ManuSporny: Added Governance, Collaboration, Innovation, and Vocabularies vs. Syntax sections

2004: In early February microformats were introduced as a concept at eTech, and in September [[hCard]] and [[hCalendar]] were proposed at FOO Camp.

2010:
* 34% of webdevs use microformats ([http://www.webdirections.org/sotw10/markup/#semantics 2010 State of Web Development survey])
* 1.88 billion hCards (per [[Yahoo]] SearchMonkey)
* 36 million hCalendar events (ibid)

* XFN -> Social Graph API -> Web as Social Network / Address Book

=== AUTHORS and PUBLISHING ===

'''How can we make it easier for authors to publish microformats?'''

Currently the simplest hCard:
<source lang=html4strict>
<span class="vcard">
<span class="fn">
Chris Messina
</span>
</span>
</source>

requires 2 elements (nested, with perhaps at least one being pre-existing), and 2 class names

Web authors/designers are used to the simplicity of most HTML tags, e.g. to mark up a heading:

<source lang=html4strict>
<h1>Chris Messina</h1>
</source>

requires just 1 element.

'''How can we make microformats just as easy?'''

'''Proposal: allow root class name only.'''

This would enable:

<source lang=html4strict>
<h1 class="vcard">Chris Messina</h1>
</source>

requiring only 1 class name for the simplest case.

'''Can we do even better?'''

One of the most common questions asked about hCard is:

[[hcard-faq#Why_does_hCard_use_vcard_as_the_root_class_name|Why does hCard use vcard as the root class name?]]

This slight inconsistency between the name of the format and the name of the root class name consistently causes confusion in a large percentage of newcomers to microformats.
* Looks like a typo (just one letter difference)
* Ambiguity in discussions, e.g. put "vcard" in your HTML - meaning, class name, or a link to a .vcf file?
* Extra bit to remember when marking up a microformat
** in contrast to [[hReview]], [[hListing]], [[hRecipe]], etc. which all have root class name same as name of microformat (lowercased).

Though in microformats we believe very strongly in the [[principle]] of [[reuse]], we have to admit that in this case experience/evidence has shown that this may be a case where we re-used something too far beyond it's original meaning. Thus:

'''Proposal: use root class name "hcard" instead of "vcard" for future hCards.'''

This would result in:

<source lang=html4strict>
<h1 class="hcard">Chris Messina</h1>
</source>

making the simple case even simpler:

Just 1 additional class name, named the same as the format you're adding. Think hCard, markup class="hcard".

It's very important for the simple case to be as simple as possible, to enable the maximum number of people to get started with minimum effort.

From there on, it's ok to require incremental effort for incremental return.

E.g. to add any additional information about a person, add explicit property names.

'''How does this simple root-only case work?'''

* root class name reflects name of the microformat
* every microformat must require at most 1 property (preferably 0)
** admit that requiring a field in an application just results in noise (the 90210 problem - apps which require zip code get lots of false 90210 entries), and specify that any application use cases which appear to "require" specific properties must instead define how to imply sensible defaults for them.
* when only a root class name is specified, imply the entire text contents of the element as the value of the primary property of the microformat. e.g.
** "hcard" implies "fn"
** hcalendar event - "hevent" - implies "summary"
** "hreview" implies "summary"
** "hentry" implies "entry-summary" (perhaps collapse into "summary" - in practice they're not sufficiently semantically distinct to require separate property names)
** '''OR''' instead of making the one implied property be vocabulary specific, introduce a new generic (applicable to all vocabularies) 'name' property (subsuming hCard's 'fn'). See [[microformats-2-brainstorming#further_simplifications|microformats 2 brainstorming: further simplifications]] for latest thoughts along these lines.

==== Additional simplifications ====

'''What more can we simplify about microformats?'''

Numerous individuals have provided the feedback that whenever there is more than one level of hierarchy in a microformat, many (most?) developers get confused - in particular Kavi Goel of Google / Rich Snippets provided this feedback at a microformats dinner. Thus depending on multiple levels of hierarchy is likely resulting in a loss of authorability, perhaps even accuracy as confusion undoubtedly leads to more errors. Thus:

'''Proposal: simplify all microformats to flat sets of properties. '''

What this means:
* all microformats are simply an object with a set of properties with values.
* no more subproperties- drop the notion of subproperties.
* use composition of multiple microformats for any further hierarchy, e.g. the "location" of an hCalendar event can be an hCard, or the "agent" of one hCard can be another hCard.

For example for hCard this would mean the following specific changes to keep relevant functionality:
* drop "n", promote all "n" subproperties to full properties
** given-name, family-name, additional-name, honorific-prefix, honorific-suffix
* treat "geo" as a nested microformat
* treat "adr" as a nested microformat (what to do about adr's "type"?)
* treat "org" as a flat string and drop "organization-name" and "organization-unit" (in practice rarely used, also not revealed or ignored in contact management user interfaces - e.g. Address Book)

Example: add a middle initial to the previous example Chris Messina's name, and markup each name component:

<source lang=html4strict>
<h1 class="hcard">
<span class="fn">
<span class="given-name">Chris</span>
<abbr class="additional-name">R.</abbr>
<span class="family-name">Messina</span>
</span>
</h1>
</source>

Note:
# use of an explicit span with "fn" to markup his entire formatted name
# use of the abbr element to explicitly indicate the semantic that "R." is merely an abbreviation for his additional-name.

=== COMMUNITY and TOOLS ===
(that) USE MICROFORMATS
* parser / parsing
* structured
* getting the data out
* json - 1:1 mapping

[[parsing]] microformats currently requires
# a list of root class names of each microformat to be parsed
# a list of properties for each specific microformats, along with knowledge of the type of each property in order to parse their data from potentially different portions of the HTML markup
# some number of format-specific specific rules (markup/content optimizations)

This has meant that whenever a new microformat is drafted/specificied/adopted, parsers need to updated to handle it correctly, at a minimum to parse them when inside other microformats and avoid errantly implying properties from one to the other (containment, [[mfo]] problem).

I think there is a fairly simple solution to #1 and #2 from the above list, and we can make progress towards minimizing #3. In short:

'''Proposal: a set of naming conventions for microformat root class names and properties that make it obvious when:'''
* a class name represents a microformat root class name
* a class name represents a microformat property name
* a class name represents a microformat property that needs special parsing (specific type of property).

In particular - derived from the real world examples of existing proven microformats (rather than any abstraction of what a schema should have)
* '''"h-*" for root class names''', e.g. "h-card", "h-event", "h-entry"
* '''"p-*" for simple (text) properties''', e.g. "p-fn", "p-summary"
** vocabulary generic parsing, element text in general, treat certain HTML element/attribute combination as special and use those first, e.g. img/alt, abbr/title.
* '''"u-*" for URL properties''', e.g. "u-url", "u-photo", "u-logo"
** special parsing required: prefer a/href, img/src, object/data etc. attributes to element contents.
* '''"d-*" for datetime properties''', e.g. "d-start", "d-end", "d-bday" (initially I had proposed "dt-*" but Chris Messina suggested reducing it to "d-*" so that all prefixes were a single letter - made sense).
** special parsing required: [[value-class-pattern]], in particular separate date time value parsing for better human readabillity / DRY balance.
possibly also:
* '''"e-*" for properties''' where the entire contained element hierarchy is the value, e.g. "e-content" (formerly "entry-content") for [[hAtom]].
** unclear if this is necessary in general. and if so, if this is only for hAtom, that's insufficient to justify putting it in the generic syntax.
* '''"i-*" for ID properties''', e.g. "i-uid" (if this is the only one, then perhaps we just always re-use "uid" or collapse with "u-*" into "u-id".)
** parsing is no different than "u-*" parsing, thus no need to introduce for now.
* '''"n-*" for numbers''', e.g. "n-rating", "n-geo", where the numbers may have different human-readable-friendly and decimal/machine values (e.g. with geo lat/long degrees minutes seconds vs decimal).
** requires definition of how would different parsing work before worthy of consideration.
* '''"t-*" for time duration''', e.g. "t-duration" in [[hCalendar]], [[hAudio]], [[hRecipe]] (note also Google's hRecipe extensions "preptime", "cooktime", "totaltime")
** requires definition of how would different parsing work before worthy of consideration.
and:
* '''reserve all other single-letter-dash prefixes for future use.''' In practice we have seen very little (if any) use of single-letter-dash prefixing of class names by web developers/designers, and thus in practice we think this will have little if any impact/collisions. Certainly far fewer than existing generic microformat property class names like "title", "note", "summary".

Example: taking that simple heading hCard example forward:

<source lang=html4strict>
<h1 class="h-card">Chris Messina</h1>
</source>

As part of microformats 2.0 we would immediately define root class names and property names for all existing microformats and drafts consistent with this naming convention, and require support thereof from all new implementations, as well as strongly encouraging existing implementations to adopt the simplified microformats 2.0 syntax and mechanism.

As a community we would continue to use the microformats [[process]] both for researching and determining the need for new microformats, and for naming new microformat property names for maximum re-use and interoperability of a shared vocabulary.

If it turns out we need a new property type in the future, we can use one of the remaining single-letter-prefixes to add it to microformats 2.0. This would require updating of parsers of course, but in practice the number of different types of properties has grown very slowly, and we know from other schema/programming languages that there's always some small limited number of scalar/atomic property types that you need, and using those you can create compound types/objects that represent richer / more complicated types of data.

==== ADVANTAGES ====
This has numerous advantages:
* '''better maintainability''' - much more obvious to web authors/designers/publishers which class names are for/from microformats.
* '''no chance of collision''' - for all practical purposes with existing class names and thus avoiding any need to add more complex CSS style rules to prevent unintended styling effects.
* '''simple universal parsing''' - parsers can now do a simple stream-parse (or in-order DOM tree walk) and parse out '''all''' microformat objects, properties, and values, without having to know anything about any specific microformats.

More examples: here is that same heading example with name components:

<source lang=html4strict>
<h1 class="h-card">
<span class="p-fn">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</span>
</h1>
</source>

with a hyperlink to Chris's URL:

<source lang=html4strict>
<h1 class="h-card">
<a class="p-fn u-url" href="http://factoryjoe.com/">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</a>
</h1>
</source>

==== COMPATIBILITY ====

microformats 2.0 is backwards compatible in that in permits content authors to markup with both old and new class names for compatibility with old tools.

Here is a simple example:

<source lang=html4strict>
<h1 class="h-card vcard">
<span class="fn">Chris Messina</span>
</h1>
</source>

a microformats 2.0 parser would see the class name "h-card" and imply the one required property from the contents, while a microformats 1.0 parser would find the class name "vcard" and then look for the class name "fn". no data duplication is required. this is a very important continuing application of the <abbr title="don't repeat yourself">DRY</abbr> [[principle]].

And the above hyperlinked example with both sets of class names:

<source lang=html4strict>
<h1 class="h-card vcard">
<a class="p-fn u-url n fn url" href="http://factoryjoe.com/">
<span class="p-given-name given-name">Chris</span>
<abbr class="p-additional-name additional-name">R.</abbr>
<span class="p-family-name family-name">Messina</span>
</a>
</h1>
</source>

==== VENDOR EXTENSIONS ====

(this section was only discussed verbally and not written up during discussions - capturing here as it is topical)

Proprietary extensions to formats have typically been shortlived experimental failures with one big recent exception.

Proprietary or experimental CSS3 property implementations have been very successful.

There has been much use of border radius properties and animations/transitions which use CSS properties with vendor-specific prefixes like:

* -moz-border-radius
* -webkit-border-radius

etc.

Note that these are merely string '''prefixes''', not bound to any URL, and thus not namespaces in any practical sense of the word. This is quite an important distinction, as avoiding the need to bind to a URL has made them easier to support and use.

This use of vendor specific CSS properties has in recent years allowed the larger web design/development/implementor communities to experiment and iterate on new CSS features while the features were being developed and standardized.

The benefits have been two-fold:
* designers have been able to make more attractive sites sooner (at least in some browsers)
* features have been market / real-world tested before being fully standardized, thus resulting in better features

Implementers have used/introduced "x-" prefixes for IETF MIME/content-types for experimental content-types, MIME parameter extensions, and HTTP header extensions, per RFC 2045 Section 6.3, RFC 3798 section 3.3, and [https://secure.wikimedia.org/wikipedia/en/wiki/List_of_HTTP_header_fields#Common_non-standard_headers Wikipedia: HTTP header fields - non-standard headers] (could use RFC reference instead) respectively, like:

* application/x-latex (per [https://secure.wikimedia.org/wikipedia/en/wiki/Internet_media_type#Type_x Wikipedia Internet media type: Type x])
* x-spam-score (in email headers)
* X-Pingback (per [http://en.wikipedia.org/wiki/Pingback Wikipedia:Pingback])

Some standard types started as experimental "x-" types, thus demonstrating this experiment first, standardize later approach has worked for at least some cases:

* image/x-png (standardized as image/png, both per [http://tools.ietf.org/html/rfc2083 RFC2083])

There have been times when specific sites have wanted to extend microformats beyond what the set of properties in the microformat, and currently lack any '''experimental''' way to do so - to try and see if a feature (or even a whole format) is interesting in the real world before bothering to pursue researching and walking it through the microformats process. Thus:

'''Proposal:'''
* '*-x-' + '-' + meaningful name for root and property class names
** where "*" indicates the single-character-prefix as defined above
** where "x" indicates a literal 'x' for an experimental extension OR
** OR "x" indicates a vendor prefix (more than one character, e.g. like CSS vendor extension abbreviations, or some stock symbols, avoiding first words/phrases/abbreviations of microformats properties like dt-)
** e.g.
** "h-bigco-one-ring" - a hypothetical "bigco" vendor-specific "onering" microformat root class name.
** "p-goog-preptime" - to represent [http://www.google.com/support/webmasters/bin/answer.py?answer=173379 Google's "preptime" property extension] to [[hRecipe]] (aside: "duration" may be another property type to consider separate from "datetime" as it may be subject to different parsing rules.)
** "p-x-prep-time" - a possible experimental property name to be added to hRecipe upon consideration/documentation of real-world usage/uptake.

Background - this proposal is a composition of the following (at least somewhat) successful vendor extension syntaxes
* [http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords CSS 2.1 4.1.2.1 Vendor-specific extensions]
* IETF MIME/content-type "x-*" extensions per RFC 2045 Section 6.3. [http://en.wikipedia.org/wiki/Internet_media_type]
* IETF MIME experimental fields (e.g. x-spam-score)
* HTTP header extensions (e.g. x-pingback)

==== FURTHER THOUGHTS REGARDING HUNGARIAN PREFIXING ====

Microformats 2.0 proposes using an explicit <code>[a-z]-</code> prefix on properties, to differentiate them from other uses of the class attribute, and identify them as microformat properties, such that they can be parsed generically.

* The differentiation use case is supported by anecdotal evidence of sites (such as Facebook, Twitter, Yahoo) removing microformats or breaking objects in page edits. The addition of a prefix assists self-documentation of code.
* The generic parsing use case is supported by Google Rich Snippets, Yahoo Search Monkey, and extensible plugins like Operator and the Firefox microformats parser. Although these extract microformats from the page, they are intermediate systems between the page content and the actual interpretation of the data. They need to parse all objects from a page, and then another developer or application will interpret some of them into something else.

(Note: the theoretical assertion "they need to parse all objects from a page" is not actually backed by *any* existing use of microformats/microdata/RDFa parsing - *none* of those parse "all objects from a page" if you consider every markup element an "object" - rather, one of the strength of microformats (mimicked by the others) is that the publisher is able to markup *just* the data to be extracted, rather than perhaps purely "presentational" content, ads, UI widgets etc. -- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC) )

The µf2 proposal goes further, though, into a small vocabulary of [http://en.wikipedia.org/wiki/Hungarian_notation Hungarian] prefixes of properties based on data type. This increases the level of understanding required to read microformats, and reduces the benefit of all microformat properties having a consistent identifying prefix.

(Debatable assertion:"increases the level of understanding required to read microformats" - how? In microformats 2.0, authors/developers know that any single-letter-and-hyphen prefixed class name is for microformats 2.0, in contrast to today - developers have consistently given feedback that's hard to tell which generic class names (other than h* names) are microformat related and which are not. As for specific prefixes, "h-*" is special and follows the pattern of existing microformats. p = generic (p)roperty, and the other prefixes have trivial mnemonics as well, d for (d)atetimes etc. (so far, hopefully we can keep that up). -- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC) )

Hungarian notation itself is controversial amongst programmers.
Plenty find it uglifies their code, can be a cause of confusion (especially when very-short prefixes are used, or esoteric types, or where the declared set of types differs from the available types in other programming languages.) Others support its benefits to type identification.

(Programmers are not the priority here, rather, designers/authors/publishers are. We design microformats for them first as they're the common use case, and we should avoid making statements that seem to imply any priority for the aesthetic preferences of programmers. -- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC))

Critically, however, there is no clear indication that either of the above use cases requires types to be strongly identified.

<div class="discussion">
* For identifying µf in pages, a differentiator is required from regular classnames. There is no evidence of further requirement to differentiate between properties beyond their name (and existing criticisms of Hungarian notation suggest it can harm understandability.)
** There is such evidence, and perhaps thus this would be a good FAQ topic. The derivation is quite simple - it comes directly from minimally affecting existing markup, and maximally using existing semantic information. Example of special purpose parsing, URL-like properties use the value of the 'href' (or equivalent) attribute because that's where that data already is in pages. Similarly with dates and datetimes - special parsing rules for that data type have permitted us to design the [[value-class-pattern]] to take advantage of specially parsing date and time separation. By re-using data *where publishers already put it, including attributes vs inline* we minimize the risk of data drift. -- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC)
** Additionally, this special type-specific parsing of microformats properties conveys microformats advantages of markup brevity that other syntaxes lack. E.g. you can convey *multiple* properties and values from a single existing element, e.g. the *very* common real-world pattern <code><br/><nowiki><a href="http://example.com/user">User Name</a></nowiki><br/></code> is minimally marked up as <code><br/><nowiki><span class="h-card"><a class="p-name u-url" href="http://example.com/user">User Name</a></span></nowiki><br/></code>
* For generic parsing, there is no requirement that datatypes be established at extraction time. Data types will instead be applied by the developers of apps and widgets that build on the generic parsers.
** There are requirements based on experience with actual markup. In order to support the patterns of where content publishers put the data we want to extract, we have determined (based on those publishing patterns) a few different ways (types) of parsing this data. This is all captured in the [[hcard-parsing]] property-specific parsing rules each of which were added one at a time as Brian Suda and myself encountered real world sites wanting to use [[hCard]] but not wanting to have to rewrite their markup (adding one span and some class names was about the limit, moving tags/attributes around was a showstopper in many/most cases), and each of the microformats 2.0 "types" are directly derived from such special purpose data/type parsing across *multiple* microformats. -- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC)
* A counter argument may be that special properties in microformats—such as URLs, or images—need to be identified because in microformats it is common to parse an attribute (href, or src) rather than inner text of an element for these properties. However, in the context of extracting and then interpreting HTML in other contexts this is insufficient: For example, though an image only exists as a single property in vcard, in HTML it is both a URL to a resource ''and'' and text string (alt) representing an accessible fallback. A ‘generic extracter’ of microformats from a page must capture all of this information from HTML, so that the interpreting application can choose which data type is most relevant to its context. Likewise, an application interpreting a URL may also consider using the original inner text as an inferred label. Both pieces of data are useful, and a generic parser should not discard elemental semantics at the extraction level.
** It's not just "*common* to parse an attribute rather than inner text of an element for these properties" - it is the vast overwhelming majority - if not all - such cases!
** One misconception: "image only exists as a single property". No, there is both 'photo' and 'logo'. The 'url' and 'sound' properties are also of type 'url'. For all of these, when parsing an "object" element, you must use the 'data' attribute first for example. hCalendar has "attachment" as well. Etc.
** Theoretical assertion: "A ‘generic extracter’ of microformats from a page must capture all of this information from HTML, so that the interpreting application can choose which data type is most relevant to its context." Why? There is no existing nor demonstrated use case for this requirement, even across other formats. While I agree it "might be nice" to develop a new "structured image" type - that's brand new work (deserving of research per the [[process]] etc.), and not a good source of reasoning to reject existing working patterns. I reject blocking microformats 2.0 on an as-yet-to-be-researched-enhancement. This is certainly a case where "better" is an enemy of the good.
** Theoretical assertion: "a generic parser should not discard elemental semantics at the extraction level" - already does for other syntaxes like both microdata and RDFa - so clearly this is not a reasonable "should not" assertion (and thus unnecessary) for development of a minimally competitive syntax. RDFa kind of cheats by overloading the 'rel' attribute in attempt to solve the name+url case as mentioned above, but that's only two types - and existing real world use of microformats has demonstrated utility of a few more. -- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC)
</div>

Given this, hungarian prefixes are of no benefit to parsers (and may in fact harm applications down the chain if parsing is prematurely strict.) It would be sufficient then not to concern embedding data types in property names, and instead settle on one single property prefix to differentiate all properties consistently. This would reduce the prefixes to just 3:

* <code>h</code> would indicates a root class name. An ‘object in HTML’.
* <code>p</code> would indicates a property within an object.
* <code>x</code> would indicates an experimental extension to an object.

--[[User:BenWard|BenWard]] 01:16, 11 April 2011 (UTC)

The primary benefit of type-specific parsing is *not* for parsers, but rather, publishers (who we still hold in higher priority than parsers).

I will also note that *each* of the type-specific parsing methods in [[hcard-parsing]] was added both conservatively, reluctantly, and only when it became clear that such type-specific publishing patterns existing across *multiple* sites that would otherwise be unable to change their markup to work with microformats (Yes, I'm wishing now that I better documented exactly *which* sites, precisely *when*, but like many startups, early on we didn't exactly know how much to document vs get things done - frankly I think we documented far more than any other comparable such efforts, e.g. we managed to at least capture/grow both an explicit [[process]] and [[principles]] in *far* greater detail than anything remotely comparable either before microformats or since!). The type-specific parsing features are certainly not overdesigned, on the contrary they've *slowly* evolved, adapting to real world data on the web.

While per the [[simplicity]] principle, I would actually *strongly* prefer to only have the three prefixes given above, or actually just *two* (I started with just two for the design of microformats 2.0 actually, just "h-*" and "p-*"), doing so would be a step *backwards* in terms of the adaptability of microformats to existing markup, and that's IMHO an unacceptable barrier, and a sufficiently high barrier to hurt the adoption/applicability of microformats 2.0.

(Aside: In addition, note that you still need h-x-* for experimental objects, and thus it's *simpler* to simply have *both* h-x-* and p-x-* rather than add x-*. Alternatively x-h-* and x-p-* is no better, in some ways worse, in that object vs. property is a more important distinction for parsers than established vs experimental, especially if/when an experimental property (or object) may be adopted. Also, mild precdent: PNG started with image/x-png, not x-image/png.).

To put it in a positive way, type-specific parsing conveys microformats a publisher-markup-density (and re-use) advantage which neither microdata nor RDFa have, and it would behoove us to *keep* this significant real-world advantage as we evolve microformats.

-- [[User:Tantek|Tantek]] 02:15, 11 April 2011 (UTC)

=== VOCABULARIES vs. SYNTAX ===

Problem: Microformats unnecessarily combines vocabularies and syntax. Split the two. Microformats vocabularies should be able to be used in all structured data languages. Microformats syntax should be available to those who want to use it.

RDFa 1.1 has added Microformats-like features over the past few years because they wanted RDFa 1.1 markup to be just as easy as Microformats markup. This example is used on the Microformats 2 page:

<source lang=html4strict>
<h1 class="h-card">
<span class="p-fn">
<span class="p-given-name">Chris</span>
<abbr class="p-additional-name">R.</abbr>
<span class="p-family-name">Messina</span>
</span>
</h1>
</source>

The markup above can be easily expressed in RDFa 1.1, using RDFa Profiles like so:

<source lang=html4strict>
<h1 typeof="hcard">
<span property="fn">
<span property="given-name">Chris</span>
<abbr property="additional-name">R.</abbr>
<span property="family-name">Messina</span>
</span>
</h1>
</source>

This is useful to the Microformats 2 work because every RDFa 1.1 compliant parser could easily become a compliant Microformats 2 parser. There are many benefits for sharing parser infrastructure.

Proposal: Map all Microformats to a schema that work with both RDFa and Microdata.

=== GOVERNANCE ===

Problem: Governance of the Microformats community is partially what derailed the first set of proposals and work - is there a better way to involve the community in governance tasks such that a meritocracy can prevail?

'''The Cabal'''. One of the strongest criticisms by the community has always been the status of the self-appointed leaders. They do a good job most of the time, but having a mechanism where the community elects the leaders and administrators would get us closer to a meritocracy. Not allowing the community to govern itself shows that you don’t trust the membership of the community. If you don’t trust us, how can we trust you? If there is a “you” and a “them”, then it becomes easy to have a “you versus them” situation. The Microformats community could learn a great deal from the Debian community in this respect.

'''The Process'''. There have been previous complaints that it was not very clear what you need to meet each hurdle in the Microformats process. This seems to have been clarified with the new Microformats 2 work. There is still concern that too much is left in the hands of the “leaders”. There was a great deal of “moving the goalposts” during the development of the hAudio work. The process kept changing. If the process keeps changing, it can mean that all of your hard work may not end up making it to the “official” Microformats standard stage. Understandably, folks will be suspect of the process if the community has no power over who gets to change the process and when.

Proposal: Kickstart the Microformats 2 work with the original founders of Microformats. Allow 1/2 of the governance seats to be replaced after the first six months. Allow 2 year terms for seats. Only people that have contributed at least 50 e-mails of discussion or have worked on Microformats specs have the ability to vote.

=== INNOVATION ===

Problem: Microformats are good at paving the cowpaths - but what about the development of innovative applications? Could there be an incubator for groundbreaking work in the Microformats community. Innovation done right?

'''Open Innovation'''. How does one innovate in the Microformats community? That is, how do we have an open discussion about the [http://purl.org/commerce Commerce], [http://purl.org/signature Signature] and [http://purl.org/payswarm PaySwarm] Web vocabularies in the Microformats community? We’re trying to solve a real-world problem – Universal Payment on the Web. We need to have an open discussion about the Web vocabularies used to accomplish this goal. How can we have this discussion in the Microformats community?

Proposal: Allow Microformats to be developed for open source software and systems without pre-existing markup. Systems could be subjected to Microformats guiding principles of simplicity and putting the target audience first.

=== COLLABORATION ===

Problem: The Microformats community and RDFa community are needlessly fragmented when they could both be working together.

'''Collaboration'''. How can the RDFa community, Microdata folks and the Microformats community work together? Manu has been trying to make this happen for several years now, each attempt met with varied levels of failure. Each community's continued track record of not reaching out and working with one another on a regular basis is damaging structured data adoption on the Web. Each community feels as if they are blame-less for the current state of affairs. “If only they’d listen to us, we wouldn’t be in this mess!”. Schema.org is just one signal that all of us need to come together and work on a unified way forward.

=== USERS ===
Need more tools and interfaces that:
* publish
* copy/paste
* right-click on a microformat
* share
* search results

discussed some existing like: [[H2VX]] converts hCard to vCard, hCalendar to iCalendar

how would we re-implement Live Clipboard today, making it easier for publishers and developers?

=== SEE ALSO ===
* [[microformats-2-brainstorming]] - moving more experimental / undeveloped / and rejected thoughts ideas here to simplify/progress *this* page further.

process-issues-closed

2011-06-15T03:06:42Z

ManuSporny: Updated link to Bitmunk/hAudio case study

<entry-title>Closed Process Issues</entry-title>

[[process-issues|Process issues]] that have been resolved and all related [[to-do]] items completed.

== 2005 ==
* 2005-07-03 raised by [[User:Bud]]
*# I would point out that the paving the cowpaths method suggests that all you are doing is enshrining current practice. One question I asked myself is how something like reltag fits into that. hCard certainly does. Not sure about hReview. What I would say more is that you are "enabling emerging practices". Maybe you should say "widening the ferrett holes".
*#* RESOLVED ACCEPTED. As with any metaphor, trying to think it through too literally will yield inaccurate results. However, given the potential for confusion this is worth some additional clarification. Explicitly noted in [[process#Document_Current_Behavior|Document Current Behavior]] that cowpaths = examples, and examples = content publishing, not existing formats.

== 2007 ==
* 2007-09-07 raised by [http://rdfa.digitalbazaar.com/bitmunk-case-study/ Manu Sporny]
*# Issue 1: What constitutes "Enough Examples"
*#* RESOLVED ACCEPTED FAQ. Added to [[process-faq]]: Some amount of diversity among large sites (e.g. social content hosts), small sites (independent publishers) helps to provide a good amount of research. If you're not sure, ask in [[IRC]] and on the mailing lists.
*# Issue 2: Proper interpretation of W3C standards
*#* RESOLVED REJECTED NO INFO. Too little information, nothing actionable, and link is dead "DBWiki has a problem". Next time, please include entire issue here rather than offsite. - [[User:Tantek|Tantek]] 20:50, 12 February 2011 (UTC)
*#* REOPEN REQUEST - case study exists here: http://rdfa.digitalbazaar.com/bitmunk-case-study/
*# Issue 3: Keeping up with changes to the process becomes frustrating
*#* RESOLVED REJECTED NO INFO. Too little information, nothing actionable, and link is dead "DBWiki has a problem". Next time, please include entire issue here rather than offsite. - [[User:Tantek|Tantek]] 20:50, 12 February 2011 (UTC)
*#* REOPEN REQUEST - case study exists here: http://rdfa.digitalbazaar.com/bitmunk-case-study/
*# Issue 4: There is no clear order of operations for "The Process". This makes uF creation a trial-and-error process that can frustrate new members, that may waste time on things that don't matter. It also annoys old members of the community, that have to answer the same questions over and over again.
*#* RESOLVED ACCEPTED. [[process]] order has been clarified. In addition, if you see a common question on email etc., please add it as a [[process-issue]] suggested FAQ and we can answer and add it to the [[process-faq]].
*# Issue 5: Analayzing the receipts-examples is difficult because we don't have a central location to dump the example, scrubbed HTML. We need a central SVN repository.
*#* RESOLVED REJECTED NO NEED. Examples should be written up and analyzed by hand on the wiki. Adding another tool that requires client-side setup and command-line proficiency raises the barrier too much for analysis and verfication thereof.
*# Issue 6: We don't have a central Microformats code repository for tools and utilities that are useful to the community.
*## RESOLVED REJECTED OFFTOPIC.
*## hg.microformats.org is the code repository we have been using for several years now. There is also a wiki that can be used to link to various implementations. A central code repository, or lack of, should not be an issue in the process when developing a new format
*## There's also: https://github.com/microformats

== see also ==
* [[process-issues]]

html5-profile

2010-02-20T18:57:01Z

ManuSporny: Minor tweaks to RDFa example to improve readability

<entry-title>HTML5 profile attribute</entry-title>
The <dfn style="font-style:normal;font-weight:bold">HTML5 profile attribute</dfn> is a simple way for authors define URLs and meanings for vocabularies used in an element and its descendants. It is based on and generalizes the HTML4 head element's profile attribute for all elements.

<div profile="http://microformarts.org/profile/hcard" class="vcard">
; <span class="role">Editor</span>
: <span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="url">http://tantek.com/</span>)
</div>
; Authors: [http://tantek.com/ Tantek Çelik] (affiliations above)
: <span class="vcard"><span class="fn"> [[User:ManuSporny | Manu Sporny]]</span> ([http://www.bitmunk.com/ Bitmunk] - [http://blog.digitalbazaar.com Digital Bazaar], Inc.)</span>

[[#Copyright|copyright]] and [[#Patents|patents]] statements apply.

== Status ==
HTML5 profile attribute is a work in progress!

Please note that currently several sections are incomplete and are being actively worked on.

This document may be useful for general conceptual review at this point, but nothing more formal.

Public discussion on HTML5 profile attribute takes place on [[html5-profile-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-new/ microformats-new mailing list].

=== Available languages ===
The English version of this document is the only normative version. For translations of this document see the [[#translations]] section.

=== Errata and Updates ===
Known errors and issues in this document are corrected in [[html5-profile-issues-resolved|resolved]] and [[html5-profile-issues-closed|closed]] issues. Please check there before reporting [[html5-profile-issues|issues]].

This document is currently under development.

== Introduction ==
HTML4 introduced the profile attribute.

[[XMDP]] clarified profile attribute processing, and introduced a profile document format based on XHTML which authors could produce and link to using the HTML4 profile attribute.

[[microformats]] have XMDP profiles and recommend linking to them using the profile attribute.

[[HTML5]] has dropped the profile attribute from the head element.

This document is an extension/addition to HTML5 which provides both a more thorough/rigorous definition of the profile attribute and generalizes it to all elements for scoped indication of vocabularies (similar to how the HTML5 microdata document extends and adds to HTML5).

{{rfc-2119-intro}}

== Format ==
formal definition of the profile attribute, processing model.

The profile attribute contains a space separated ordered list of URLs to one or more profile documents.

These profile documents define and provide URLs for vocabulary terms - profile definitions.

These profile definitions apply to the element and its descendants.

For backwards compatibility with HTML4 and XHTML1:
* profile URLs specified on the head element are considered to be at the end of the list of profile URLs of the html element, and thus apply to the entire document.

...

== Examples ==
This section is '''informative'''.

=== hCard with scoped profile ===
<source lang=html4strict>
<div profile="http://microformats.org/wiki/hcard" class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
</div>
</source>

=== RDFa example ===

<source lang=html4strict>
<div profile="http://microformats.org/wiki/hcard#" typeof="vcard">
<a rel="url" href="http://manu.sporny.org/" property="fn">Manu Sporny</a>
</div>
</source>

would generate the following triples:

<source lang=text>
_:subject0
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://microformats.org/wiki/hcard#vcard> .
_:subject0
<http://microformats.org/wiki/hcard#fn>
"Manu Sporny" .
_:subject0
<http://microformats.org/wiki/hcard#url>
<http://manu.sporny.org/> .
</source>

=== microdata example ===
- a way that microdata could use definitions provided by the profile attribute without having to use full URLs in itemtype attribute values for example.

=== hybrid example ===
- using profile attribute to introduce/define/scope a vocabulary and then use in microdata, microformats, and RDFa markup simultaneously, as a demonstration that they can be used on the same data in a complementary overlapping fashion. not sure of the utility of doing this but demonstrating that they can compatibly be used in the same document or even on the same element may help both alleviate incompatibility concerns, and how to use shared vocabularies across multiple syntaxes.

== HTML 4.01 Errata ==
This section is '''informative'''.

EDITORS NOTE: include [[XMDP]]

The [[HTML4]] recommendation is inconsistent in its description of the [http://www.w3.org/TR/html4/struct/global.html#adef-profile profile] attribute:

# The DTD specifies <tt>%URI;</tt>, which just expands to <tt>CDATA</tt>.
# On the other hand, the prose explains that <q>This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.</q>

Since the publication of HTML 4.01, a number of meta data profiles have been defined,
and many of them can be used in the same document. While the <code>profile</code>
attribute does not help in discovering which profile applies to which
part of the document, it <em>does</em> allow declaring which profiles
are in use, potentially triggering extended behavior in recipients.

This erratum restores consistency in HTML 4.01, explicitly allowing
multiple URIs in a single <code>profile</code> attribute.

=== Corrections to HTML 4.01 ===

==== Section 6.4 - URIs ====
[http://www.w3.org/TR/html4/types.html#type-uri REF-URI]

<p>
After
</p>
<blockquote>
URIs are represented in the DTD by the parameter entity %URI;.
</blockquote>
<p>
add
</p>
<blockquote>
Sets of whitespace-separated URIs are represented by the parameter entity %URIlist;.
</blockquote>

==== Section 7.4.1 - The HEAD element ====
[http://www.w3.org/TR/html4/struct/global.html#h-7.4.1 REF-HEAD]

<p>
Replace
</p>
<pre>
<tt>profile</tt> = <i>uri</i> [CT]
</pre>
<p>
with
</p>
<pre>
<tt>profile</tt> = <i>urilist</i> [CT]
</pre>
<p>
(just replacing "uri" by "urilist", but not changing the link target)
</p>

<p>
Replace
</p>
<pre>
profile %URI; #IMPLIED -- named dictionary of meta info --
</pre>
<p>
with
</p>
<pre>
profile %URIlist; #IMPLIED -- list of named meta info dictionaries, whitespace separated --
</pre>
<p>
Update the [http://www.w3.org/TR/html4/index/attributes.html attribute index] accordingly.
</p>

<p>
Replace
</p>
<blockquote>
This attribute specifies the location of one or more meta data profiles,
separated by white space. For future extensions, user agents should consider
the value to be a list even though this specification only considers the
first URI to be significant. Profiles are discussed below in the section on
meta data.
</blockquote>
<p>
with
</p>
<blockquote>
This attribute specifies the location of one or more meta data profiles,
separated by white space. In case of ambiguities, profiles that appear
earlier in the attribute value should be considered more significant.
Profiles are discussed below in the section on meta data.
</blockquote>

==== Section 7.4.4 - Meta Data Profiles ====
[http://www.w3.org/TR/html4/struct/global.html#profiles REF-PROFILES]

<p>
Replace
</p>
<blockquote>
The profile attribute of the HEAD specifies the location of a meta data
profile. The value of the profile attribute is a URI. User agents may use
this URI in two ways:
</blockquote>
<p>
with
</p>
<blockquote>
The profile attribute of the HEAD specifies a set of locations of meta data
profiles. The value of the profile attribute is a whitespace-separated list
of URIs. User agents may use these URIs in two ways:
</blockquote>

==== Section 21 - Document Type Definition ====
[http://www.w3.org/TR/html4/sgml/dtd.html REF-DTD]
<p>
Note: the changes below apply both to the copy of the DTD in the HTML 4.01 spec,
and the actual DTD files.
</p>
<p>
After the definition for <tt>URI</tt>, insert:
</p>
<pre>
<!ENTITY % URIlist "CDATA"
-- whitespace-separated list of Uniform Resource Identifiers,
see [URI]
-->
</pre>
<p>
Replace the following definition:
</p>
<pre>
<!ATTLIST HEAD
%i18n; -- lang, dir --
profile %URI; #IMPLIED -- named dictionary of meta info --
>
</pre>
<p>
with
</p>
<pre>
<!ATTLIST HEAD
%i18n; -- lang, dir --
profile %URIlist; #IMPLIED -- list of named meta info dictionaries, whitespace separated --
>
</pre>

== profile attribute for other languages ==
This section is '''informative'''.

The profile attribute as defined in this specification can be applied to other markup languages (including previous versions of HTML and XHTML) as follows.

informative profile attribute processing model for other languages

examples of HTML4, XHTML1, SVG, and other markup languages that have a class attribute

examples of Atom, and other markup languages that have a rel attribute

...

== Copyright ==
Per the [[Microformats_Wiki:Copyrights|public domain contribution requirement of the microformats.org wiki]], this specification is released into the public domain.

== Patents ==
{{MicroFormatPatentStatement}}

== References ==
=== Normative References ===
* [http://dev.w3.org/html5/spec/spec.html HTML5]
* [[rfc-2119|RFC 2119]]

=== Informative References ===
This section is '''informative'''.
* [http://w3.org/TR/html401 HTML 4.01]
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/description XMDP description]
* [http://html5.digitalbazaar.com/specs/html5-epb.html#html-4.01-errata HTML 4.01 Errata as documented in Extended Processing Behavior in HTML5]

== Related Pages ==
* [[XMDP]]
* [[rel-profile]]
[[Category:Drafts]]

== Translations ==
Read the HTML5 profile attribute document in additional <span id="languages">languages</span>:
* none yet

html5-profile

2010-02-20T18:50:09Z

ManuSporny: Minor languages changes to RDFa Example section

<entry-title>HTML5 profile attribute</entry-title>
The <dfn style="font-style:normal;font-weight:bold">HTML5 profile attribute</dfn> is a simple way for authors define URLs and meanings for vocabularies used in an element and its descendants. It is based on and generalizes the HTML4 head element's profile attribute for all elements.

<div profile="http://microformarts.org/profile/hcard" class="vcard">
; <span class="role">Editor</span>
: <span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="url">http://tantek.com/</span>)
</div>
; Authors: [http://tantek.com/ Tantek Çelik] (affiliations above)
: <span class="vcard"><span class="fn"> [[User:ManuSporny | Manu Sporny]]</span> ([http://www.bitmunk.com/ Bitmunk] - [http://blog.digitalbazaar.com Digital Bazaar], Inc.)</span>

[[#Copyright|copyright]] and [[#Patents|patents]] statements apply.

== Status ==
HTML5 profile attribute is a work in progress!

Please note that currently several sections are incomplete and are being actively worked on.

This document may be useful for general conceptual review at this point, but nothing more formal.

Public discussion on HTML5 profile attribute takes place on [[html5-profile-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-new/ microformats-new mailing list].

=== Available languages ===
The English version of this document is the only normative version. For translations of this document see the [[#translations]] section.

=== Errata and Updates ===
Known errors and issues in this document are corrected in [[html5-profile-issues-resolved|resolved]] and [[html5-profile-issues-closed|closed]] issues. Please check there before reporting [[html5-profile-issues|issues]].

This document is currently under development.

== Introduction ==
HTML4 introduced the profile attribute.

[[XMDP]] clarified profile attribute processing, and introduced a profile document format based on XHTML which authors could produce and link to using the HTML4 profile attribute.

[[microformats]] have XMDP profiles and recommend linking to them using the profile attribute.

[[HTML5]] has dropped the profile attribute from the head element.

This document is an extension/addition to HTML5 which provides both a more thorough/rigorous definition of the profile attribute and generalizes it to all elements for scoped indication of vocabularies (similar to how the HTML5 microdata document extends and adds to HTML5).

{{rfc-2119-intro}}

== Format ==
formal definition of the profile attribute, processing model.

The profile attribute contains a space separated ordered list of URLs to one or more profile documents.

These profile documents define and provide URLs for vocabulary terms - profile definitions.

These profile definitions apply to the element and its descendants.

For backwards compatibility with HTML4 and XHTML1:
* profile URLs specified on the head element are considered to be at the end of the list of profile URLs of the html element, and thus apply to the entire document.

...

== Examples ==
This section is '''informative'''.

=== hCard with scoped profile ===
<source lang=html4strict>
<div profile="http://microformats.org/wiki/hcard" class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
</div>
</source>

=== RDFa example ===

<source lang=html4strict>
<div profile="http://microformats.org/wiki/hcard#" typeof="vcard">
<a rel="url" href="http://manu.sporny.org/" property="fn">Manu Sporny</a>
</div>
</source>

would generate the following triples:

<source lang=text>
_:bnode0
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://microformats.org/wiki/hcard#vcard> .
_:bnode0
<http://microformats.org/wiki/hcard#fn>
"Manu Sporny" .
_:bnode0
<http://microformats.org/wiki/hcard#url>
<http://manu.sporny.org/> .
</source>

=== microdata example ===
- a way that microdata could use definitions provided by the profile attribute without having to use full URLs in itemtype attribute values for example.

=== hybrid example ===
- using profile attribute to introduce/define/scope a vocabulary and then use in microdata, microformats, and RDFa markup simultaneously, as a demonstration that they can be used on the same data in a complementary overlapping fashion. not sure of the utility of doing this but demonstrating that they can compatibly be used in the same document or even on the same element may help both alleviate incompatibility concerns, and how to use shared vocabularies across multiple syntaxes.

== HTML 4.01 Errata ==
This section is '''informative'''.

EDITORS NOTE: include [[XMDP]]

The [[HTML4]] recommendation is inconsistent in its description of the [http://www.w3.org/TR/html4/struct/global.html#adef-profile profile] attribute:

# The DTD specifies <tt>%URI;</tt>, which just expands to <tt>CDATA</tt>.
# On the other hand, the prose explains that <q>This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.</q>

Since the publication of HTML 4.01, a number of meta data profiles have been defined,
and many of them can be used in the same document. While the <code>profile</code>
attribute does not help in discovering which profile applies to which
part of the document, it <em>does</em> allow declaring which profiles
are in use, potentially triggering extended behavior in recipients.

This erratum restores consistency in HTML 4.01, explicitly allowing
multiple URIs in a single <code>profile</code> attribute.

=== Corrections to HTML 4.01 ===

==== Section 6.4 - URIs ====
[http://www.w3.org/TR/html4/types.html#type-uri REF-URI]

<p>
After
</p>
<blockquote>
URIs are represented in the DTD by the parameter entity %URI;.
</blockquote>
<p>
add
</p>
<blockquote>
Sets of whitespace-separated URIs are represented by the parameter entity %URIlist;.
</blockquote>

==== Section 7.4.1 - The HEAD element ====
[http://www.w3.org/TR/html4/struct/global.html#h-7.4.1 REF-HEAD]

<p>
Replace
</p>
<pre>
<tt>profile</tt> = <i>uri</i> [CT]
</pre>
<p>
with
</p>
<pre>
<tt>profile</tt> = <i>urilist</i> [CT]
</pre>
<p>
(just replacing "uri" by "urilist", but not changing the link target)
</p>

<p>
Replace
</p>
<pre>
profile %URI; #IMPLIED -- named dictionary of meta info --
</pre>
<p>
with
</p>
<pre>
profile %URIlist; #IMPLIED -- list of named meta info dictionaries, whitespace separated --
</pre>
<p>
Update the [http://www.w3.org/TR/html4/index/attributes.html attribute index] accordingly.
</p>

<p>
Replace
</p>
<blockquote>
This attribute specifies the location of one or more meta data profiles,
separated by white space. For future extensions, user agents should consider
the value to be a list even though this specification only considers the
first URI to be significant. Profiles are discussed below in the section on
meta data.
</blockquote>
<p>
with
</p>
<blockquote>
This attribute specifies the location of one or more meta data profiles,
separated by white space. In case of ambiguities, profiles that appear
earlier in the attribute value should be considered more significant.
Profiles are discussed below in the section on meta data.
</blockquote>

==== Section 7.4.4 - Meta Data Profiles ====
[http://www.w3.org/TR/html4/struct/global.html#profiles REF-PROFILES]

<p>
Replace
</p>
<blockquote>
The profile attribute of the HEAD specifies the location of a meta data
profile. The value of the profile attribute is a URI. User agents may use
this URI in two ways:
</blockquote>
<p>
with
</p>
<blockquote>
The profile attribute of the HEAD specifies a set of locations of meta data
profiles. The value of the profile attribute is a whitespace-separated list
of URIs. User agents may use these URIs in two ways:
</blockquote>

==== Section 21 - Document Type Definition ====
[http://www.w3.org/TR/html4/sgml/dtd.html REF-DTD]
<p>
Note: the changes below apply both to the copy of the DTD in the HTML 4.01 spec,
and the actual DTD files.
</p>
<p>
After the definition for <tt>URI</tt>, insert:
</p>
<pre>
<!ENTITY % URIlist "CDATA"
-- whitespace-separated list of Uniform Resource Identifiers,
see [URI]
-->
</pre>
<p>
Replace the following definition:
</p>
<pre>
<!ATTLIST HEAD
%i18n; -- lang, dir --
profile %URI; #IMPLIED -- named dictionary of meta info --
>
</pre>
<p>
with
</p>
<pre>
<!ATTLIST HEAD
%i18n; -- lang, dir --
profile %URIlist; #IMPLIED -- list of named meta info dictionaries, whitespace separated --
>
</pre>

== profile attribute for other languages ==
This section is '''informative'''.

The profile attribute as defined in this specification can be applied to other markup languages (including previous versions of HTML and XHTML) as follows.

informative profile attribute processing model for other languages

examples of HTML4, XHTML1, SVG, and other markup languages that have a class attribute

examples of Atom, and other markup languages that have a rel attribute

...

== Copyright ==
Per the [[Microformats_Wiki:Copyrights|public domain contribution requirement of the microformats.org wiki]], this specification is released into the public domain.

== Patents ==
{{MicroFormatPatentStatement}}

== References ==
=== Normative References ===
* [http://dev.w3.org/html5/spec/spec.html HTML5]
* [[rfc-2119|RFC 2119]]

=== Informative References ===
This section is '''informative'''.
* [http://w3.org/TR/html401 HTML 4.01]
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/description XMDP description]
* [http://html5.digitalbazaar.com/specs/html5-epb.html#html-4.01-errata HTML 4.01 Errata as documented in Extended Processing Behavior in HTML5]

== Related Pages ==
* [[XMDP]]
* [[rel-profile]]
[[Category:Drafts]]

== Translations ==
Read the HTML5 profile attribute document in additional <span id="languages">languages</span>:
* none yet

html5-profile

2010-02-20T18:48:54Z

ManuSporny: Filled out the RDFa example

<entry-title>HTML5 profile attribute</entry-title>
The <dfn style="font-style:normal;font-weight:bold">HTML5 profile attribute</dfn> is a simple way for authors define URLs and meanings for vocabularies used in an element and its descendants. It is based on and generalizes the HTML4 head element's profile attribute for all elements.

<div profile="http://microformarts.org/profile/hcard" class="vcard">
; <span class="role">Editor</span>
: <span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="url">http://tantek.com/</span>)
</div>
; Authors: [http://tantek.com/ Tantek Çelik] (affiliations above)
: <span class="vcard"><span class="fn"> [[User:ManuSporny | Manu Sporny]]</span> ([http://www.bitmunk.com/ Bitmunk] - [http://blog.digitalbazaar.com Digital Bazaar], Inc.)</span>

[[#Copyright|copyright]] and [[#Patents|patents]] statements apply.

== Status ==
HTML5 profile attribute is a work in progress!

Please note that currently several sections are incomplete and are being actively worked on.

This document may be useful for general conceptual review at this point, but nothing more formal.

Public discussion on HTML5 profile attribute takes place on [[html5-profile-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-new/ microformats-new mailing list].

=== Available languages ===
The English version of this document is the only normative version. For translations of this document see the [[#translations]] section.

=== Errata and Updates ===
Known errors and issues in this document are corrected in [[html5-profile-issues-resolved|resolved]] and [[html5-profile-issues-closed|closed]] issues. Please check there before reporting [[html5-profile-issues|issues]].

This document is currently under development.

== Introduction ==
HTML4 introduced the profile attribute.

[[XMDP]] clarified profile attribute processing, and introduced a profile document format based on XHTML which authors could produce and link to using the HTML4 profile attribute.

[[microformats]] have XMDP profiles and recommend linking to them using the profile attribute.

[[HTML5]] has dropped the profile attribute from the head element.

This document is an extension/addition to HTML5 which provides both a more thorough/rigorous definition of the profile attribute and generalizes it to all elements for scoped indication of vocabularies (similar to how the HTML5 microdata document extends and adds to HTML5).

{{rfc-2119-intro}}

== Format ==
formal definition of the profile attribute, processing model.

The profile attribute contains a space separated ordered list of URLs to one or more profile documents.

These profile documents define and provide URLs for vocabulary terms - profile definitions.

These profile definitions apply to the element and its descendants.

For backwards compatibility with HTML4 and XHTML1:
* profile URLs specified on the head element are considered to be at the end of the list of profile URLs of the html element, and thus apply to the entire document.

...

== Examples ==
This section is '''informative'''.

=== hCard with scoped profile ===
<source lang=html4strict>
<div profile="http://microformats.org/wiki/hcard" class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
</div>
</source>

=== RDFa example ===

<source lang=html4strict>
<div profile="http://microformats.org/wiki/hcard#" typeof="vcard">
<a rel="url" href="http://manu.sporny.org/" property="fn">Manu Sporny</a>
</div>
</source>

would express the following triples:

<source lang=text>
_:bnode0
<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>
<http://microformats.org/wiki/hcard#vcard> .
_:bnode0
<http://microformats.org/wiki/hcard#fn>
"Manu Sporny" .
_:bnode0
<http://microformats.org/wiki/hcard#url>
<http://manu.sporny.org/> .
</source>

=== microdata example ===
- a way that microdata could use definitions provided by the profile attribute without having to use full URLs in itemtype attribute values for example.

=== hybrid example ===
- using profile attribute to introduce/define/scope a vocabulary and then use in microdata, microformats, and RDFa markup simultaneously, as a demonstration that they can be used on the same data in a complementary overlapping fashion. not sure of the utility of doing this but demonstrating that they can compatibly be used in the same document or even on the same element may help both alleviate incompatibility concerns, and how to use shared vocabularies across multiple syntaxes.

== HTML 4.01 Errata ==
This section is '''informative'''.

EDITORS NOTE: include [[XMDP]]

The [[HTML4]] recommendation is inconsistent in its description of the [http://www.w3.org/TR/html4/struct/global.html#adef-profile profile] attribute:

# The DTD specifies <tt>%URI;</tt>, which just expands to <tt>CDATA</tt>.
# On the other hand, the prose explains that <q>This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.</q>

Since the publication of HTML 4.01, a number of meta data profiles have been defined,
and many of them can be used in the same document. While the <code>profile</code>
attribute does not help in discovering which profile applies to which
part of the document, it <em>does</em> allow declaring which profiles
are in use, potentially triggering extended behavior in recipients.

This erratum restores consistency in HTML 4.01, explicitly allowing
multiple URIs in a single <code>profile</code> attribute.

=== Corrections to HTML 4.01 ===

==== Section 6.4 - URIs ====
[http://www.w3.org/TR/html4/types.html#type-uri REF-URI]

<p>
After
</p>
<blockquote>
URIs are represented in the DTD by the parameter entity %URI;.
</blockquote>
<p>
add
</p>
<blockquote>
Sets of whitespace-separated URIs are represented by the parameter entity %URIlist;.
</blockquote>

==== Section 7.4.1 - The HEAD element ====
[http://www.w3.org/TR/html4/struct/global.html#h-7.4.1 REF-HEAD]

<p>
Replace
</p>
<pre>
<tt>profile</tt> = <i>uri</i> [CT]
</pre>
<p>
with
</p>
<pre>
<tt>profile</tt> = <i>urilist</i> [CT]
</pre>
<p>
(just replacing "uri" by "urilist", but not changing the link target)
</p>

<p>
Replace
</p>
<pre>
profile %URI; #IMPLIED -- named dictionary of meta info --
</pre>
<p>
with
</p>
<pre>
profile %URIlist; #IMPLIED -- list of named meta info dictionaries, whitespace separated --
</pre>
<p>
Update the [http://www.w3.org/TR/html4/index/attributes.html attribute index] accordingly.
</p>

<p>
Replace
</p>
<blockquote>
This attribute specifies the location of one or more meta data profiles,
separated by white space. For future extensions, user agents should consider
the value to be a list even though this specification only considers the
first URI to be significant. Profiles are discussed below in the section on
meta data.
</blockquote>
<p>
with
</p>
<blockquote>
This attribute specifies the location of one or more meta data profiles,
separated by white space. In case of ambiguities, profiles that appear
earlier in the attribute value should be considered more significant.
Profiles are discussed below in the section on meta data.
</blockquote>

==== Section 7.4.4 - Meta Data Profiles ====
[http://www.w3.org/TR/html4/struct/global.html#profiles REF-PROFILES]

<p>
Replace
</p>
<blockquote>
The profile attribute of the HEAD specifies the location of a meta data
profile. The value of the profile attribute is a URI. User agents may use
this URI in two ways:
</blockquote>
<p>
with
</p>
<blockquote>
The profile attribute of the HEAD specifies a set of locations of meta data
profiles. The value of the profile attribute is a whitespace-separated list
of URIs. User agents may use these URIs in two ways:
</blockquote>

==== Section 21 - Document Type Definition ====
[http://www.w3.org/TR/html4/sgml/dtd.html REF-DTD]
<p>
Note: the changes below apply both to the copy of the DTD in the HTML 4.01 spec,
and the actual DTD files.
</p>
<p>
After the definition for <tt>URI</tt>, insert:
</p>
<pre>
<!ENTITY % URIlist "CDATA"
-- whitespace-separated list of Uniform Resource Identifiers,
see [URI]
-->
</pre>
<p>
Replace the following definition:
</p>
<pre>
<!ATTLIST HEAD
%i18n; -- lang, dir --
profile %URI; #IMPLIED -- named dictionary of meta info --
>
</pre>
<p>
with
</p>
<pre>
<!ATTLIST HEAD
%i18n; -- lang, dir --
profile %URIlist; #IMPLIED -- list of named meta info dictionaries, whitespace separated --
>
</pre>

== profile attribute for other languages ==
This section is '''informative'''.

The profile attribute as defined in this specification can be applied to other markup languages (including previous versions of HTML and XHTML) as follows.

informative profile attribute processing model for other languages

examples of HTML4, XHTML1, SVG, and other markup languages that have a class attribute

examples of Atom, and other markup languages that have a rel attribute

...

== Copyright ==
Per the [[Microformats_Wiki:Copyrights|public domain contribution requirement of the microformats.org wiki]], this specification is released into the public domain.

== Patents ==
{{MicroFormatPatentStatement}}

== References ==
=== Normative References ===
* [http://dev.w3.org/html5/spec/spec.html HTML5]
* [[rfc-2119|RFC 2119]]

=== Informative References ===
This section is '''informative'''.
* [http://w3.org/TR/html401 HTML 4.01]
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/description XMDP description]
* [http://html5.digitalbazaar.com/specs/html5-epb.html#html-4.01-errata HTML 4.01 Errata as documented in Extended Processing Behavior in HTML5]

== Related Pages ==
* [[XMDP]]
* [[rel-profile]]
[[Category:Drafts]]

== Translations ==
Read the HTML5 profile attribute document in additional <span id="languages">languages</span>:
* none yet

html5-profile

2010-02-20T18:39:00Z

ManuSporny: Updated HTML4.01 Errata section with HTML5-EPB draft text

<entry-title>HTML5 profile attribute</entry-title>
The <dfn style="font-style:normal;font-weight:bold">HTML5 profile attribute</dfn> is a simple way for authors define URLs and meanings for vocabularies used in an element and its descendants. It is based on and generalizes the HTML4 head element's profile attribute for all elements.

<div profile="http://microformarts.org/profile/hcard" class="vcard">
; <span class="role">Editor</span>
: <span class="fn">[[User:Tantek|Tantek Çelik]]</span> (<span class="url">http://tantek.com/</span>)
</div>
; Authors: [http://tantek.com/ Tantek Çelik] (affiliations above)
: <span class="vcard"><span class="fn"> [[User:ManuSporny | Manu Sporny]]</span> ([http://www.bitmunk.com/ Bitmunk] - [http://blog.digitalbazaar.com Digital Bazaar], Inc.)</span>

[[#Copyright|copyright]] and [[#Patents|patents]] statements apply.

== Status ==
HTML5 profile attribute is a work in progress!

Please note that currently several sections are incomplete and are being actively worked on.

This document may be useful for general conceptual review at this point, but nothing more formal.

Public discussion on HTML5 profile attribute takes place on [[html5-profile-feedback]], the #microformats [[irc]] channel on irc.freenode.net, and [http://microformats.org/discuss/mail/microformats-new/ microformats-new mailing list].

=== Available languages ===
The English version of this document is the only normative version. For translations of this document see the [[#translations]] section.

=== Errata and Updates ===
Known errors and issues in this document are corrected in [[html5-profile-issues-resolved|resolved]] and [[html5-profile-issues-closed|closed]] issues. Please check there before reporting [[html5-profile-issues|issues]].

This document is currently under development.

== Introduction ==
HTML4 introduced the profile attribute.

[[XMDP]] clarified profile attribute processing, and introduced a profile document format based on XHTML which authors could produce and link to using the HTML4 profile attribute.

[[microformats]] have XMDP profiles and recommend linking to them using the profile attribute.

[[HTML5]] has dropped the profile attribute from the head element.

This document is an extension/addition to HTML5 which provides both a more thorough/rigorous definition of the profile attribute and generalizes it to all elements for scoped indication of vocabularies (similar to how the HTML5 microdata document extends and adds to HTML5).

{{rfc-2119-intro}}

== Format ==
formal definition of the profile attribute, processing model.

The profile attribute contains a space separated ordered list of URLs to one or more profile documents.

These profile documents define and provide URLs for vocabulary terms - profile definitions.

These profile definitions apply to the element and its descendants.

For backwards compatibility with HTML4 and XHTML1:
* profile URLs specified on the head element are considered to be at the end of the list of profile URLs of the html element, and thus apply to the entire document.

...

== Examples ==
This section is '''informative'''.

=== hCard with scoped profile ===
<source lang=html4strict>
<div profile="http://microformats.org/wiki/hcard" class="vcard">
<a class="url fn" href="http://tantek.com/">Tantek Çelik</a>
</div>
</source>

=== RDFa example ===
- using profile attribute with RDFa property attribute

=== microdata example ===
- a way that microdata could use definitions provided by the profile attribute without having to use full URLs in itemtype attribute values for example.

=== hybrid example ===
- using profile attribute to introduce/define/scope a vocabulary and then use in microdata, microformats, and RDFa markup simultaneously, as a demonstration that they can be used on the same data in a complementary overlapping fashion. not sure of the utility of doing this but demonstrating that they can compatibly be used in the same document or even on the same element may help both alleviate incompatibility concerns, and how to use shared vocabularies across multiple syntaxes.

== HTML 4.01 Errata ==
This section is '''informative'''.

EDITORS NOTE: include [[XMDP]]

The [[HTML4]] recommendation is inconsistent in its description of the [http://www.w3.org/TR/html4/struct/global.html#adef-profile profile] attribute:

# The DTD specifies <tt>%URI;</tt>, which just expands to <tt>CDATA</tt>.
# On the other hand, the prose explains that <q>This attribute specifies the location of one or more meta data profiles, separated by white space. For future extensions, user agents should consider the value to be a list even though this specification only considers the first URI to be significant. Profiles are discussed below in the section on meta data.</q>

Since the publication of HTML 4.01, a number of meta data profiles have been defined,
and many of them can be used in the same document. While the <code>profile</code>
attribute does not help in discovering which profile applies to which
part of the document, it <em>does</em> allow declaring which profiles
are in use, potentially triggering extended behavior in recipients.

This erratum restores consistency in HTML 4.01, explicitly allowing
multiple URIs in a single <code>profile</code> attribute.

=== Corrections to HTML 4.01 ===

==== Section 6.4 - URIs ====
[http://www.w3.org/TR/html4/types.html#type-uri REF-URI]

<p>
After
</p>
<blockquote>
URIs are represented in the DTD by the parameter entity %URI;.
</blockquote>
<p>
add
</p>
<blockquote>
Sets of whitespace-separated URIs are represented by the parameter entity %URIlist;.
</blockquote>

==== Section 7.4.1 - The HEAD element ====
[http://www.w3.org/TR/html4/struct/global.html#h-7.4.1 REF-HEAD]

<p>
Replace
</p>
<pre>
<tt>profile</tt> = <i>uri</i> [CT]
</pre>
<p>
with
</p>
<pre>
<tt>profile</tt> = <i>urilist</i> [CT]
</pre>
<p>
(just replacing "uri" by "urilist", but not changing the link target)
</p>

<p>
Replace
</p>
<pre>
profile %URI; #IMPLIED -- named dictionary of meta info --
</pre>
<p>
with
</p>
<pre>
profile %URIlist; #IMPLIED -- list of named meta info dictionaries, whitespace separated --
</pre>
<p>
Update the [http://www.w3.org/TR/html4/index/attributes.html attribute index] accordingly.
</p>

<p>
Replace
</p>
<blockquote>
This attribute specifies the location of one or more meta data profiles,
separated by white space. For future extensions, user agents should consider
the value to be a list even though this specification only considers the
first URI to be significant. Profiles are discussed below in the section on
meta data.
</blockquote>
<p>
with
</p>
<blockquote>
This attribute specifies the location of one or more meta data profiles,
separated by white space. In case of ambiguities, profiles that appear
earlier in the attribute value should be considered more significant.
Profiles are discussed below in the section on meta data.
</blockquote>

==== Section 7.4.4 - Meta Data Profiles ====
[http://www.w3.org/TR/html4/struct/global.html#profiles REF-PROFILES]

<p>
Replace
</p>
<blockquote>
The profile attribute of the HEAD specifies the location of a meta data
profile. The value of the profile attribute is a URI. User agents may use
this URI in two ways:
</blockquote>
<p>
with
</p>
<blockquote>
The profile attribute of the HEAD specifies a set of locations of meta data
profiles. The value of the profile attribute is a whitespace-separated list
of URIs. User agents may use these URIs in two ways:
</blockquote>

==== Section 21 - Document Type Definition ====
[http://www.w3.org/TR/html4/sgml/dtd.html REF-DTD]
<p>
Note: the changes below apply both to the copy of the DTD in the HTML 4.01 spec,
and the actual DTD files.
</p>
<p>
After the definition for <tt>URI</tt>, insert:
</p>
<pre>
<!ENTITY % URIlist "CDATA"
-- whitespace-separated list of Uniform Resource Identifiers,
see [URI]
-->
</pre>
<p>
Replace the following definition:
</p>
<pre>
<!ATTLIST HEAD
%i18n; -- lang, dir --
profile %URI; #IMPLIED -- named dictionary of meta info --
>
</pre>
<p>
with
</p>
<pre>
<!ATTLIST HEAD
%i18n; -- lang, dir --
profile %URIlist; #IMPLIED -- list of named meta info dictionaries, whitespace separated --
>
</pre>

== profile attribute for other languages ==
This section is '''informative'''.

The profile attribute as defined in this specification can be applied to other markup languages (including previous versions of HTML and XHTML) as follows.

informative profile attribute processing model for other languages

examples of HTML4, XHTML1, SVG, and other markup languages that have a class attribute

examples of Atom, and other markup languages that have a rel attribute

...

== Copyright ==
Per the [[Microformats_Wiki:Copyrights|public domain contribution requirement of the microformats.org wiki]], this specification is released into the public domain.

== Patents ==
{{MicroFormatPatentStatement}}

== References ==
=== Normative References ===
* [http://dev.w3.org/html5/spec/spec.html HTML5]
* [[rfc-2119|RFC 2119]]

=== Informative References ===
This section is '''informative'''.
* [http://w3.org/TR/html401 HTML 4.01]
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/description XMDP description]
* [http://html5.digitalbazaar.com/specs/html5-epb.html#html-4.01-errata HTML 4.01 Errata as documented in Extended Processing Behavior in HTML5]

== Related Pages ==
* [[XMDP]]
* [[rel-profile]]
[[Category:Drafts]]

== Translations ==
Read the HTML5 profile attribute document in additional <span id="languages">languages</span>:
* none yet

wiki-better-than-email

2009-02-28T03:37:48Z

ManuSporny: added signature

<entry-title>Wiki is better than email</entry-title>

The wiki works better than email for content (examples, issues, brainstorms etc.) for numerous reasons.

* No, not always, not for all workflows, this is a false assertion. Wikis are excellent at capturing the state of the art and providing a mechanism for collaborative document editing. Discussing issues that are highly controversial are bad to do via a wiki because they lead to edit wars and subsequent banning of individuals, as this community has experienced. Low-latency communication is best for that... for synchronous communication, IRC... for asynchronous communication, e-mail. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

Here are a few:

== reasons ==
* <span id="scaling">'''s/n scaling.'''</span> Not everyone is interested in every issue on every format.
** No, but there needs to be a forum other than IRC (synchronous method of communication) for discussion of these topics. E-mail is nice because it is asynchronous and allows broad consensus to be reached before moving forward. Not all of us have the luxury of being connected to IRC at all times. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
* <span id="efficiency">'''efficiency: reading current state vs deltas.'''</span> You can read one wiki page to get the status/thread of an issue whereas with emails you often have to read thru numerous emails (and threads) and apply them like deltas/diffs in your head to understand where an issue etc. ended up.
* <span id="search">'''search/discoverability.'''</span> search for the web/wikis works much better in practice than searching mailing lists (web search of email archives has no thread-smarts for example).
* <span id="pd">'''public domain.'''</span> Wiki contributions are required public domain, while in email there is no UI to enforce this, thus email should be use only "informatively" for notifications and never for capturing material of any substance.
* <span id="tradition">'''tradition.'''</span> microformats have been documented on a wiki since their inception, as a result the wiki is the definitive resource for all matters microformats; not any of the mailing lists. The community has had a longstanding tradition preferring use of the wiki for content over email. We realize this is fairly novel for a standards community, as most standards communities are email-centric (e.g. W3C, IETF). However, for all the above reasons we believe using wikis for content is far superior to email and thus hope that other standards communities shift more of their activities to being web/wiki-based rather than email lists.
** historical note: microformats have always been developed via public IRC + wiki since 2004 when Kevin Marks and Tantek Çelik first started researching/brainstorming/drafting microformats such as [[rel-license]], [[vote-links]], [[XOXO]], [[hCard]], [[hCalendar]] on the public Technorati Developer's Wiki and the Freenode IRC network. Brian Suda somehow discovered the Technorati Developer's wiki page for hCard, started editing it, and that's how he and Tantek Çelik met. The [[mailing-lists]] were not created until the microformats.org site was launched in mid 2005 and have always been considered secondary to the wiki and IRC channel.
** Tradition, in and of itself, is not a valid reason for doing something. We need an asynchronous method of communication and IRC doesn't work for some of us. Decisions shouldn't be made by a select few that hang out in an IRC channel all day, this is not how you reach consensus. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
** Another historical note: hAudio was developed almost entirely through e-mail and wiki edits. -- [[User:ManuSporny|ManuSporny]] 03:37, 28 February 2009 (UTC)

== reasons against ==

* Why is IRC okay, but e-mail not okay? In other words, why is a synchronous method of communication with a small number of contributing individuals accepted, but an asynchronous method of communication with a large number of contributing individuals not accepted as a method of resolving issues? If we are to achieve broad consensus, I would expect that we'd chose the latter over the former. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
* The Microformats wiki makes it difficult to understand the arguments behind a large number of the items on a wiki. Sometimes it is best to ask the mailing list where to start, or the reasoning behind an issue rather than state something that you have no idea is true or not on a wiki. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
* Some of us do not have the time to sit around in an IRC channel. Some of us do our communication in batches because that is most efficient for us. Constant interruption or temptation to get involved in a discussion is more prevalent in IRC than it is in e-mail. I can shut off my e-mail client and not worry that I've missed something, I can't necessarily do the same with IRC. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

== additional documentation ==

* See the book http://www.wikinomics.com/ for more details and explanations on how wikis are more efficient than email for a variety of workflows.
* This picture helps illustrate one of many scenarios - and though we are not sending word documents, the point is, that iterating content through email is far less efficient than iterating content on a wiki: <br /> [http://www.wikinomics.com/blog/index.php/2008/03/26/wiki-collaboration-leads-to-happiness/ http://www.wikinomics.com/blog/uploads/wiki_collaboration2.jpg]
** I'm not arguing for an all-or-nothing approach. I think we should discuss on IRC/e-mail, form a consensus of some kind, and then record that consensus on the wiki. The community should allow people to use whatever method works for them, rather than forcing a method of communication and issue resolution onto the community. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

== related ==
* [[mailing-lists]]
* [[how-to-play]]
* [[put-it-on-the-wiki]]

wiki-better-than-email

2009-02-28T03:37:15Z

ManuSporny: /* reasons */

<entry-title>Wiki is better than email</entry-title>

The wiki works better than email for content (examples, issues, brainstorms etc.) for numerous reasons.

* No, not always, not for all workflows, this is a false assertion. Wikis are excellent at capturing the state of the art and providing a mechanism for collaborative document editing. Discussing issues that are highly controversial are bad to do via a wiki because they lead to edit wars and subsequent banning of individuals, as this community has experienced. Low-latency communication is best for that... for synchronous communication, IRC... for asynchronous communication, e-mail. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

Here are a few:

== reasons ==
* <span id="scaling">'''s/n scaling.'''</span> Not everyone is interested in every issue on every format.
** No, but there needs to be a forum other than IRC (synchronous method of communication) for discussion of these topics. E-mail is nice because it is asynchronous and allows broad consensus to be reached before moving forward. Not all of us have the luxury of being connected to IRC at all times. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
* <span id="efficiency">'''efficiency: reading current state vs deltas.'''</span> You can read one wiki page to get the status/thread of an issue whereas with emails you often have to read thru numerous emails (and threads) and apply them like deltas/diffs in your head to understand where an issue etc. ended up.
* <span id="search">'''search/discoverability.'''</span> search for the web/wikis works much better in practice than searching mailing lists (web search of email archives has no thread-smarts for example).
* <span id="pd">'''public domain.'''</span> Wiki contributions are required public domain, while in email there is no UI to enforce this, thus email should be use only "informatively" for notifications and never for capturing material of any substance.
* <span id="tradition">'''tradition.'''</span> microformats have been documented on a wiki since their inception, as a result the wiki is the definitive resource for all matters microformats; not any of the mailing lists. The community has had a longstanding tradition preferring use of the wiki for content over email. We realize this is fairly novel for a standards community, as most standards communities are email-centric (e.g. W3C, IETF). However, for all the above reasons we believe using wikis for content is far superior to email and thus hope that other standards communities shift more of their activities to being web/wiki-based rather than email lists.
** historical note: microformats have always been developed via public IRC + wiki since 2004 when Kevin Marks and Tantek Çelik first started researching/brainstorming/drafting microformats such as [[rel-license]], [[vote-links]], [[XOXO]], [[hCard]], [[hCalendar]] on the public Technorati Developer's Wiki and the Freenode IRC network. Brian Suda somehow discovered the Technorati Developer's wiki page for hCard, started editing it, and that's how he and Tantek Çelik met. The [[mailing-lists]] were not created until the microformats.org site was launched in mid 2005 and have always been considered secondary to the wiki and IRC channel.
** Tradition, in and of itself, is not a valid reason for doing something. We need an asynchronous method of communication and IRC doesn't work for some of us. Decisions shouldn't be made by a select few that hang out in an IRC channel all day, this is not how you reach consensus. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
** Another historical note: hAudio was developed almost entirely through e-mail and wiki edits.

== reasons against ==

* Why is IRC okay, but e-mail not okay? In other words, why is a synchronous method of communication with a small number of contributing individuals accepted, but an asynchronous method of communication with a large number of contributing individuals not accepted as a method of resolving issues? If we are to achieve broad consensus, I would expect that we'd chose the latter over the former. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
* The Microformats wiki makes it difficult to understand the arguments behind a large number of the items on a wiki. Sometimes it is best to ask the mailing list where to start, or the reasoning behind an issue rather than state something that you have no idea is true or not on a wiki. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
* Some of us do not have the time to sit around in an IRC channel. Some of us do our communication in batches because that is most efficient for us. Constant interruption or temptation to get involved in a discussion is more prevalent in IRC than it is in e-mail. I can shut off my e-mail client and not worry that I've missed something, I can't necessarily do the same with IRC. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

== additional documentation ==

* See the book http://www.wikinomics.com/ for more details and explanations on how wikis are more efficient than email for a variety of workflows.
* This picture helps illustrate one of many scenarios - and though we are not sending word documents, the point is, that iterating content through email is far less efficient than iterating content on a wiki: <br /> [http://www.wikinomics.com/blog/index.php/2008/03/26/wiki-collaboration-leads-to-happiness/ http://www.wikinomics.com/blog/uploads/wiki_collaboration2.jpg]
** I'm not arguing for an all-or-nothing approach. I think we should discuss on IRC/e-mail, form a consensus of some kind, and then record that consensus on the wiki. The community should allow people to use whatever method works for them, rather than forcing a method of communication and issue resolution onto the community. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

== related ==
* [[mailing-lists]]
* [[how-to-play]]
* [[put-it-on-the-wiki]]

wiki-better-than-email

2009-02-28T03:24:05Z

ManuSporny: /* reasons */

<entry-title>Wiki is better than email</entry-title>

The wiki works better than email for content (examples, issues, brainstorms etc.) for numerous reasons.

* No, not always, not for all workflows, this is a false assertion. Wikis are excellent at capturing the state of the art and providing a mechanism for collaborative document editing. Discussing issues that are highly controversial are bad to do via a wiki because they lead to edit wars and subsequent banning of individuals, as this community has experienced. Low-latency communication is best for that... for synchronous communication, IRC... for asynchronous communication, e-mail. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

Here are a few:

== reasons ==
* <span id="scaling">'''s/n scaling.'''</span> Not everyone is interested in every issue on every format.
** No, but there needs to be a forum other than IRC (synchronous method of communication) for discussion of these topics. E-mail is nice because it is asynchronous and allows broad consensus to be reached before moving forward. Not all of us have the luxury of being connected to IRC at all times. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
* <span id="efficiency">'''efficiency: reading current state vs deltas.'''</span> You can read one wiki page to get the status/thread of an issue whereas with emails you often have to read thru numerous emails (and threads) and apply them like deltas/diffs in your head to understand where an issue etc. ended up.
* <span id="search">'''search/discoverability.'''</span> search for the web/wikis works much better in practice than searching mailing lists (web search of email archives has no thread-smarts for example).
* <span id="pd">'''public domain.'''</span> Wiki contributions are required public domain, while in email there is no UI to enforce this, thus email should be use only "informatively" for notifications and never for capturing material of any substance.
* <span id="tradition">'''tradition.'''</span> microformats have been documented on a wiki since their inception, as a result the wiki is the definitive resource for all matters microformats; not any of the mailing lists. The community has had a longstanding tradition preferring use of the wiki for content over email. We realize this is fairly novel for a standards community, as most standards communities are email-centric (e.g. W3C, IETF). However, for all the above reasons we believe using wikis for content is far superior to email and thus hope that other standards communities shift more of their activities to being web/wiki-based rather than email lists.
** historical note: microformats have always been developed via public IRC + wiki since 2004 when Kevin Marks and Tantek Çelik first started researching/brainstorming/drafting microformats such as [[rel-license]], [[vote-links]], [[XOXO]], [[hCard]], [[hCalendar]] on the public Technorati Developer's Wiki and the Freenode IRC network. Brian Suda somehow discovered the Technorati Developer's wiki page for hCard, started editing it, and that's how he and Tantek Çelik met. The [[mailing-lists]] were not created until the microformats.org site was launched in mid 2005 and have always been considered secondary to the wiki and IRC channel.
** Tradition, in and of itself, is not a valid reason for doing something. We need an asynchronous method of communication and IRC doesn't work for some of us. Decisions shouldn't be made by a select few that hang out in an IRC channel all day, this is not how you reach consensus. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

== reasons against ==

* Why is IRC okay, but e-mail not okay? In other words, why is a synchronous method of communication with a small number of contributing individuals accepted, but an asynchronous method of communication with a large number of contributing individuals not accepted as a method of resolving issues? If we are to achieve broad consensus, I would expect that we'd chose the latter over the former. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
* The Microformats wiki makes it difficult to understand the arguments behind a large number of the items on a wiki. Sometimes it is best to ask the mailing list where to start, or the reasoning behind an issue rather than state something that you have no idea is true or not on a wiki. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
* Some of us do not have the time to sit around in an IRC channel. Some of us do our communication in batches because that is most efficient for us. Constant interruption or temptation to get involved in a discussion is more prevalent in IRC than it is in e-mail. I can shut off my e-mail client and not worry that I've missed something, I can't necessarily do the same with IRC. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

== additional documentation ==

* See the book http://www.wikinomics.com/ for more details and explanations on how wikis are more efficient than email for a variety of workflows.
* This picture helps illustrate one of many scenarios - and though we are not sending word documents, the point is, that iterating content through email is far less efficient than iterating content on a wiki: <br /> [http://www.wikinomics.com/blog/index.php/2008/03/26/wiki-collaboration-leads-to-happiness/ http://www.wikinomics.com/blog/uploads/wiki_collaboration2.jpg]
** I'm not arguing for an all-or-nothing approach. I think we should discuss on IRC/e-mail, form a consensus of some kind, and then record that consensus on the wiki. The community should allow people to use whatever method works for them, rather than forcing a method of communication and issue resolution onto the community. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

== related ==
* [[mailing-lists]]
* [[how-to-play]]
* [[put-it-on-the-wiki]]

wiki-better-than-email

2009-02-28T03:22:02Z

ManuSporny: comments on e-mail vs. irc

<entry-title>Wiki is better than email</entry-title>

The wiki works better than email for content (examples, issues, brainstorms etc.) for numerous reasons.

* No, not always, not for all workflows, this is a false assertion. Wikis are excellent at capturing the state of the art and providing a mechanism for collaborative document editing. Discussing issues that are highly controversial are bad to do via a wiki because they lead to edit wars and subsequent banning of individuals, as this community has experienced. Low-latency communication is best for that... for synchronous communication, IRC... for asynchronous communication, e-mail. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

Here are a few:

== reasons ==
* <span id="scaling">'''s/n scaling.'''</span> Not everyone is interested in every issue on every format.
** No, but there needs to be a forum other than IRC (synchronous method of communication) for discussion of these topics. E-mail is nice because it is asynchronous and allows broad consensus to be reached before moving forward. Not all of us have the luxury of being connected to IRC at all times. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
* <span id="efficiency">'''efficiency: reading current state vs deltas.'''</span> You can read one wiki page to get the status/thread of an issue whereas with emails you often have to read thru numerous emails (and threads) and apply them like deltas/diffs in your head to understand where an issue etc. ended up.
* <span id="search">'''search/discoverability.'''</span> search for the web/wikis works much better in practice than searching mailing lists (web search of email archives has no thread-smarts for example).
* <span id="pd">'''public domain.'''</span> Wiki contributions are required public domain, while in email there is no UI to enforce this, thus email should be use only "informatively" for notifications and never for capturing material of any substance.
* <span id="tradition">'''tradition.'''</span> microformats have been documented on a wiki since their inception, as a result the wiki is the definitive resource for all matters microformats; not any of the mailing lists. The community has had a longstanding tradition preferring use of the wiki for content over email. We realize this is fairly novel for a standards community, as most standards communities are email-centric (e.g. W3C, IETF). However, for all the above reasons we believe using wikis for content is far superior to email and thus hope that other standards communities shift more of their activities to being web/wiki-based rather than email lists.
** historical note: microformats have always been developed via public IRC + wiki since 2004 when Kevin Marks and Tantek Çelik first started researching/brainstorming/drafting microformats such as [[rel-license]], [[vote-links]], [[XOXO]], [[hCard]], [[hCalendar]] on the public Technorati Developer's Wiki and the Freenode IRC network. Brian Suda somehow discovered the Technorati Developer's wiki page for hCard, started editing it, and that's how he and Tantek Çelik met. The [[mailing-lists]] were not created until the microformats.org site was launched in mid 2005 and have always been considered secondary to the wiki and IRC channel.
** Tradition is not a valid reason for doing something. We need an asynchronous method of communication and IRC doesn't work for some of us. Decisions shouldn't be made by a select few that hang out in an IRC channel all day, this is not how you reach consensus. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

== reasons against ==

* Why is IRC okay, but e-mail not okay? In other words, why is a synchronous method of communication with a small number of contributing individuals accepted, but an asynchronous method of communication with a large number of contributing individuals not accepted as a method of resolving issues? If we are to achieve broad consensus, I would expect that we'd chose the latter over the former. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
* The Microformats wiki makes it difficult to understand the arguments behind a large number of the items on a wiki. Sometimes it is best to ask the mailing list where to start, or the reasoning behind an issue rather than state something that you have no idea is true or not on a wiki. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)
* Some of us do not have the time to sit around in an IRC channel. Some of us do our communication in batches because that is most efficient for us. Constant interruption or temptation to get involved in a discussion is more prevalent in IRC than it is in e-mail. I can shut off my e-mail client and not worry that I've missed something, I can't necessarily do the same with IRC. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

== additional documentation ==

* See the book http://www.wikinomics.com/ for more details and explanations on how wikis are more efficient than email for a variety of workflows.
* This picture helps illustrate one of many scenarios - and though we are not sending word documents, the point is, that iterating content through email is far less efficient than iterating content on a wiki: <br /> [http://www.wikinomics.com/blog/index.php/2008/03/26/wiki-collaboration-leads-to-happiness/ http://www.wikinomics.com/blog/uploads/wiki_collaboration2.jpg]
** I'm not arguing for an all-or-nothing approach. I think we should discuss on IRC/e-mail, form a consensus of some kind, and then record that consensus on the wiki. The community should allow people to use whatever method works for them, rather than forcing a method of communication and issue resolution onto the community. -- [[User:ManuSporny|ManuSporny]] 03:22, 28 February 2009 (UTC)

== related ==
* [[mailing-lists]]
* [[how-to-play]]
* [[put-it-on-the-wiki]]

hproduct-issues

2009-02-18T06:04:40Z

ManuSporny: minor edit to HP6 title

__TOC__

== HP1 - hProduct vs hListing regarding "price" / "quantity" / "shipping" fields ==

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-12-17</span> raised by <span class="fn">NicolasLeroy</span></span>
<div class="description">
*# In the "[[hproduct#Out_of_Scope|out of scope]]" section, it is explained: _"This microformat does not intend to replicate any of the content proposed within hListing and would defer all money/transactional matters to that microformat"_
*# However, in the hProduct schema, we have the following fields:
*#* "price. optional. floating point number. can be further refined by type (msrp, regular, sale, clearance)" => if the price is the retailer price, then it should be delegated to hListing. We could imagine it represents the "manufacturer" price (which could be different from the retailer price) ; in this case, it should clearly be explained in the schema definition.
*#* I would say there is also ambiguity between the responsibilities of hProduct vs hListing for the following fields: quantity / shipping
*#** Response <span class="vcard">by <span class="fn">[[User:JayMyers|Jay Myers]]</span>, 2008-02-16</span>: I believe everyone agrees that we would borrow price from hListing for hProduct spec. I will explain the concept further in the schema.
*#** Response <span class="vcard">by <span class="fn">[[User:JayMyers|Jay Myers]]</span>, 2008-02-16</span>: I don't follow the quantity/ shipping issue. I don't see either of these on hListing, unless the concepts are somehow embedded in other attributes. Can you elaborate on what the ambiguity is?
</div>
</div>

<div class="vevent">
== <span class="summary">HP2 - FN should be used instead of N for product title</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* Why is <b>n</b> used instead of <b>fn</b> for the title of the product? hCard and hAudio both use fn for the formatted name of the product. <b>n</b> is usually an optimization.
</div>
</div>

<div class="vevent">
== <span class="summary">HP3 - BUY duplicates functionality of PAYMENT from hAudio</span> ==
* {{OpenIssue}} <span class="vcard">BUY duplicates functionality of PAYMENT from hAudio<span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* <b>buy</b> is duplicating the functionality of <b>payment</b> from hAudio.
</div>
</div>

<div class="vevent">
== <span class="summary">HP4 - Are all of the formats for PRICE in hProduct allowed</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* The way that <b>price</b> is used is iffy - do we allow anything but currency/amount in the compound statement?
</div>
</div>

<div class="vevent">
== <span class="summary">HP5 - The format for the contents of SHIPPING are vague</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* Seems like <b>shipping</b> could be abused quite a bit, resulting in a term that is fairly useless as time moves on.
</div>
</div>

<div class="vevent">
== <span class="summary">HP6 - P-V seems like a catch-all for hProduct</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* <b>p-v</b> seems like a catch-all, shoe-horn attempt at making the microformat infinitely scalable? Is this really useful?
</div>
</div>

<div class="vevent">

== <span class="summary">HP7 - Lots of vocabulary terms, does the data really back this up?</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* There seem to be a great deal of vocab terms and the terms seem to be fairly loosely defined... are they all justified? Is there a file that we can analyze (like via microformalyze)?
</div>
</div>

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

hproduct-issues

2009-02-18T05:40:06Z

ManuSporny: Broke out large issue block into work-able issues

__TOC__

== HP1 - hProduct vs hListing regarding "price" / "quantity" / "shipping" fields ==

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-12-17</span> raised by <span class="fn">NicolasLeroy</span></span>
<div class="description">
*# In the "[[hproduct#Out_of_Scope|out of scope]]" section, it is explained: _"This microformat does not intend to replicate any of the content proposed within hListing and would defer all money/transactional matters to that microformat"_
*# However, in the hProduct schema, we have the following fields:
*#* "price. optional. floating point number. can be further refined by type (msrp, regular, sale, clearance)" => if the price is the retailer price, then it should be delegated to hListing. We could imagine it represents the "manufacturer" price (which could be different from the retailer price) ; in this case, it should clearly be explained in the schema definition.
*#* I would say there is also ambiguity between the responsibilities of hProduct vs hListing for the following fields: quantity / shipping
*#** Response <span class="vcard">by <span class="fn">[[User:JayMyers|Jay Myers]]</span>, 2008-02-16</span>: I believe everyone agrees that we would borrow price from hListing for hProduct spec. I will explain the concept further in the schema.
*#** Response <span class="vcard">by <span class="fn">[[User:JayMyers|Jay Myers]]</span>, 2008-02-16</span>: I don't follow the quantity/ shipping issue. I don't see either of these on hListing, unless the concepts are somehow embedded in other attributes. Can you elaborate on what the ambiguity is?
</div>
</div>

<div class="vevent">
== <span class="summary">HP2 - FN should be used instead of N for product title</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* Why is <b>n</b> used instead of <b>fn</b> for the title of the product? hCard and hAudio both use fn for the formatted name of the product. <b>n</b> is usually an optimization.
</div>
</div>

<div class="vevent">
== <span class="summary">HP3 - BUY duplicates functionality of PAYMENT from hAudio</span> ==
* {{OpenIssue}} <span class="vcard">BUY duplicates functionality of PAYMENT from hAudio<span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* <b>buy</b> is duplicating the functionality of <b>payment</b> from hAudio.
</div>
</div>

<div class="vevent">
== <span class="summary">HP4 - Are all of the formats for PRICE in hProduct allowed</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* The way that <b>price</b> is used is iffy - do we allow anything but currency/amount in the compound statement?
</div>
</div>

<div class="vevent">
== <span class="summary">HP5 - The format for the contents of SHIPPING are vague</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* Seems like <b>shipping</b> could be abused quite a bit, resulting in a term that is fairly useless as time moves on.
</div>
</div>

<div class="vevent">
== <span class="summary">HP6 - P-V seems like it's being used as a catch-all for hProduct</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* <b>p-v</b> seems like a catch-all, shoe-horn attempt at making the microformat infinitely scalable? Is this really useful?
</div>
</div>

<div class="vevent">
== <span class="summary">HP7 - Lots of vocabulary terms, does the data really back this up?</span> ==
* {{OpenIssue}} <span class="vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
* There seem to be a great deal of vocab terms and the terms seem to be fairly loosely defined... are they all justified? Is there a file that we can analyze (like via microformalyze)?
</div>
</div>

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

hproduct-issues

2009-02-18T05:11:10Z

ManuSporny: Added hProduct issues --manu

__TOC__

== 2008-12-17 hProduct vs hListing regarding "price" / "quantity" / "shipping" fields ==

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2008-12-17</span> raised by <span class="fn">NicolasLeroy</span></span>
<div class="description">
*# In the "[[hproduct#Out_of_Scope|out of scope]]" section, it is explained: _"This microformat does not intend to replicate any of the content proposed within hListing and would defer all money/transactional matters to that microformat"_
*# However, in the hProduct schema, we have the following fields:
*#* "price. optional. floating point number. can be further refined by type (msrp, regular, sale, clearance)" => if the price is the retailer price, then it should be delegated to hListing. We could imagine it represents the "manufacturer" price (which could be different from the retailer price) ; in this case, it should clearly be explained in the schema definition.
*#* I would say there is also ambiguity between the responsibilities of hProduct vs hListing for the following fields: quantity / shipping
*#** Response <span class="vcard">by <span class="fn">[[User:JayMyers|Jay Myers]]</span>, 2008-02-16</span>: I believe everyone agrees that we would borrow price from hListing for hProduct spec. I will explain the concept further in the schema.
*#** Response <span class="vcard">by <span class="fn">[[User:JayMyers|Jay Myers]]</span>, 2008-02-16</span>: I don't follow the quantity/ shipping issue. I don't see either of these on hListing, unless the concepts are somehow embedded in other attributes. Can you elaborate on what the ambiguity is?
</div>
</div>

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2009-02-17</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
*# Why is <b>n</b> used instead of <b>fn</b> for the title of the product? hCard and hAudio both use fn for the formatted name of the product. <b>n</b> is usually an optimization.
*# <b>buy</b> is duplicating the functionality of <b>payment</b> from hAudio.
*# The way that <b>price</b> is used is iffy - do we allow anything but currency/amount in the compound statement?
*# Seems like <b>shipping</b> could be abused quite a bit, resulting in a term that is fairly useless as time moves on.
*# <b>p-v</b> seems like a catch-all, shoe-horn attempt at making the microformat infinitely scalable? Is this really useful?
*# There seem to be a great deal of vocab terms and the terms seem to be fairly loosely defined for a microformat... are they all justified?
</div>
</div>

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

haudio

2009-02-18T05:04:16Z

ManuSporny: /* Schema */ - minor typo fix

<entry-title>hAudio 0.9.1</entry-title>
{{Template:DraftSpecification}}
{{TOC-right}}
http://farm2.static.flickr.com/1216/604867362_da0921136a_o.png

[[haudio|hAudio]] is a simple, open, distributed format, suitable for embedding information about audio recordings in (X)HTML, Atom, RSS, and arbitrary XML. hAudio is one of several [[microformats]] open standards. This page and Microformat is in the public domain.

== hAudio Microformat Draft Specification ==

=== Editors ===
* [[User:ManuSporny | Manu Sporny]] ([http://www.bitmunk.com/ Bitmunk] - [http://blog.digitalbazaar.com Digital Bazaar], Inc.)
* [[ user:WebOrganics | Martin McEvoy ]]
=== Authors ===
* [[User:ManuSporny | Manu Sporny]]
* [[ user:WebOrganics | Martin McEvoy ]]

=== Contributors===
[[User:ManuSporny | Manu Sporny]], [[ user:WebOrganics | Martin McEvoy ]], [[ User:AlexandreVandeSande | Alexandre Van De Sande ]], Michael Johnson, Dave Longley, Brian Suda, Ben Wiley Sittler, Scott Reynen, Frances Berriman, James Craig, David Janes, [[User:AndyMabbett|Andy Mabbett]], Danny Ayers, Rudy Desjardins, Edward O'Connor, Ryan King, Chris Griego, Brad Hafichuk, Tantek Çelik, Colin Barrett, Joe Andrieu, Michael Smethurst, [[User:ChrisNewell | Chris Newell]], Julian Stahnke, Justin Maxwell, Paul Wilkins and David I. Lehn.

Microformats [[#Copyright]] and [[#Patents]] statements apply.

== Introduction ==

It is difficult for a browser to extract semantic information about an audio recording described on a web page. Metadata such as speaker, musician, publisher, label, title of the work, release date, acquisition link, related image artwork and tags provide relevant context for the audio recording.

Having such information marked up can provide a number of benefits to the viewer. If a web browser understands that a particular web page contains a song performed by an artist, it can produce richer interactions. For example, specific searches may be performed for artists and songs via general search services such as Google and Wikipedia. Specific search services may also be queried such as MusicBrainz, The Internet Archive, FreeDB, or Bitmunk. Additionally, classification by crawlers can become more accurate. If there are 20 tracks found on a page done by the same artist, and that content consumes a significant portion of the page, it can be assumed that the page is not only about music, but also about a particular artist.

In order to enable and encourage the sharing, distribution, syndication, and aggregation of audio content, the authors propose the hAudio microformat, an open standard for distributed audio metadata. The authors have researched both numerous [[audio-info-examples]] in the wild and earlier attempts at [[audio-info-formats]], and have designed hAudio around a simple minimal schema for audio content. Feedback is encouraged on the [[haudio-feedback|hAudio feedback]] page.

=== Inspiration and Acknowledgments ===

Many thanks to the various individuals that did research and proposed ideas and discussion related to media info and audio info in general. Among the many participants are [[RodBegbie]], Dean Hudson, [http://tantek.com/log/ Tantek Çelik], [http://napsterization.org/stories/ Mary Hodder], [http://joshkinberg.com/blog/ Joshua Kinberg], ChrisMessina, and [http://onlisareinsradar.com/ Lisa Rein].

=== Scope ===

Audio content consistently share several common fields. Where possible hAudio has been based on this minimal common subset.

=== Out of scope ===

Fields that are type-specific have been omitted from hAudio. It is important that hAudio be kept simple and minimal from the start. Additional features can be added as deemed necessary by practical implementation experience.

The concept of a universal audio identifier, that is, how to identify the same audio album, song, speech, or podcast across different music and audio sites, though something very useful to have, is outside the scope of this format.

== Format ==

{{rfc-2119-intro}}

=== In General ===
The hAudio format is based on a set of fields common to numerous audio content sites and formats in use today on the web. Where possible field names have been chosen based on those defined by the related [[hcard|hCard]] standards.

=== Schema ===

The hAudio schema consists of the following:

* hAudio ('''<code>haudio</code>''')
** '''fn''' or/and '''album''' required. text.
** '''contributor'''. optional. using text or [[hCard]].
** '''duration'''. optional. ISO-8601 time duration. (re-used from [[hcalendar]]).
** '''item''' optional. using text or multiple properties from [[hAudio]].
** '''position''' optional. text.
** '''category'''. optional. text.
** '''published'''. optional.
** '''photo'''. optional. using any element containing a URL, such as IMG.
** '''description''' optional. text.
** '''sample''' (rel). optional. sample file/stream using [[rel-design-pattern]] with <code>sample</code> as the <code>mf-rel-value</code>.
** '''enclosure''' (rel). optional. full download of file using [[rel-enclosure]].
** '''payment''' (rel). optional. link to purchase process using [[rel-payment]].
** '''price''' optional. Using the sub properties '''currency''' and '''amount'''.

=== Field details ===

The fields of the hAudio schema represent the following:

==== hAudio ====

An hAudio is used to identify and describe metadata associated with an audio recording.

* an hAudio element is identified by class name <code>haudio</code>

==== fn ====

The name of a single audio recording is a short textual description used to identify the work among interested parties. This can be the name of a speech, song name, or short description regarding a sound effect.

* The element is identified by the class name <code>fn</code>.
* hAudio {{must}} have <code>fn</code> or/and <code>album</code>.

==== Album ====

The title of a collection of audio recordings, such as those that are represented as a CD, album or LP. The text should be a short textual description used to identify the work among interested parties.

* The element is identified by the class name <code>album</code>.
* hAudio {{must}} have either <code>album</code> or <code>fn</code> or both.

==== Item ====

A container for another hAudio item, which MUST be considered a part of the parent audio recording. An example of an item that is part of an hAudio would be a track in an audio album, a aria in an Opera, or a section of a podcast.

* The element is identified by the class name <code>item</code>.
* hAudio {{may}} have one or more items.
* The element {{must}} be processed opaquely. No sub-elements should be read from any hAudio contained in a track element.
* The contents of the element {{must}} be marked up using properties in hAudio.

==== Position ====

The position is used to describe the position of the hAudio item in a list. Examples of hAudio lists can include album track listings, music top 10 lists, playlists, and podcast chapters.

* The element is identified by the class name <code>position</code>.
* hAudio {{may}} include one <code>position</code> element.
* The contents of the element {{must}} be a number or other sequential identifier.
* The sequential identifier {{may}} be specified out-of-sequence.

==== Contributor ====

A Contributor is any entity that takes part in the creation and distribution of an audio recording. Examples include: artist, composer, publisher, guitarist, vocalist, violinist, lead singer, backup singer, bassist, drummer, manager, and roadie.

* The element is identified by the class name <code>contributor</code>.
* hAudio {{may}} include one or more contributors.
* The contributor's name SHOULD also be marked up as a valid hCard Microformat. [[hcard]]
*# The <code>role</code> attribute {{should}} be used to specify the contributor's responsibility related to the audio recording if hCard is utilized.
* The contributor's name {{may}} be specified in plain-text without being enclosed in a hCard Microformat.

==== Published ====

The published date specifies the date that the audio recording was made available to the public. Examples include: The airing date of a radio broadcast, the day a speech was given, or the day a music album was made available for sale.

* The element is identified by the class name <code>published</code>.
* hAudio {{may}} include one or more <code>published</code> elements.
* The contents of the element {{may}} include a date format compliant with the [[datetime-design-pattern]].

==== Sample ====

A Sample URI specifies from where an excerpt of the audio recording may be retrieved.

* The element is identified by a URI fitting the [[rel-design-pattern]], the rel content being <code>sample</code>.
* hAudio {{may}} include one or more URI <code>sample</code>s.
* The URI {{should}} point to a directly accessible stream or file.
* The type of the sample {{may}} be specified by using the <code>type</code> specifier for a URI.

==== Full Download (Enclosure) ====

A Full Download URI specifies from where the full version of an audio recording may be retrieved. The URI {{must}} point to a direct link to a file retrieval process (FTP, HTTP, BitTorrent URI, etc).

* The element is identified by a URI fitting the [[rel-design-pattern]], the rel content being <code>enclosure</code>.
* hAudio {{may}} include one or more <code>enclosure</code> URIs.
* The type of the file {{should}} be specified by using the <code>type</code> specifier for a URI.

==== Purchase (Payment) ====

A Purchase URI specifies from where the full version of an audio recording may be purchased. The URI {{must}} point to the beginning of a purchase process for the hAudio.

* The element is identified by a URI fitting the [[rel-design-pattern]], the rel content being <code>payment</code>.
* hAudio {{may}} include one or more <code>payment</code> URIs.
* The type of the file {{may}} be specified by using the <code>type</code> specifier for a URI.

==== Photo ====

A photo specifies an image that should be used to summarize the audio recording. Examples include: the image of a speaker, an audio album cover image, or a picture from a concert.

* The element is identified by the class name <code>photo</code>.
* hAudio {{may}} include one or more <code>photo</code> elements.
* The element {{should}} use an <img> element.
* The element {{may}} use any other element that contains a URL, such as <a> or <object>, but it is not recommended.

==== Category ====

The Category specifies the genre or style used to classify the audio recording. Examples include: blues, rock, motivational, spoken word, or sound effect.

* The element is identified by the class name <code>category</code>.
* hAudio {{may}} include one or more <code>category</code> elements.
* This element {{may}} be expressed using the [[rel-tag]] elemental microformat. When a category is expressed using rel-tag, the content of the element is used as the text for the category. For example: <code><a class="category" rel="tag" href="/tags/symphony">Symphonic</a></code> would have "Symphonic" as the text for the category.

==== Duration ====

The Duration specifies the length in time of the audio recording. Examples include: 104 seconds, 3:23, and 4 minutes.

* The element is identified by the class name <code>duration</code>.
* hAudio {{may}} include one <code>duration</code> element.
* The contents of the element {{may}} use the [[abbr-design-pattern]] whose title attribute contains an ISO-8601 formatted duration. An example of 3:23 (i.e 3 minutes 23 seconds) would be "PT3M23S" in ISO 8601 format.
* The element {{may}} contain the following sub properties:
** '''h''' Hour.
** '''min''' Minute.
** '''s''' Second.
Example:
<pre><span class="duration">
<span class="h">1</span>:
<span class="min">3</span>:
<span class="s">23</span>
</span></pre>

==== Price ====

The Price specifies the amount of currency that must be exchanged for acquisition of a full specimen of the audio recording.

* The element is identified by the class name <code>price</code>.
* hAudio {{may}} include one or more <code>price</code> elements.
* The contents of the element {{may}} also use plain text with a currency symbol.
* The contents {{may}} contain the following sub properties:
** '''currency''' an [http://en.wikipedia.org/wiki/ISO_4217#Active_codes ISO 4217] currency name.
** '''amount''' a numerical value.
Example:
<pre><span class="price">
<abbr class="currency" title="GBP">£</abbr>
<span class="amount">4.99</span>
</span></pre>

==== Description ====

An explanation of the contents of the hAudio item. This could explain the significance of a speech, the full-text description of a sound effect, or the meaning of a song or album.

* The element is identified by the class name <code>description</code>.
* hAudio {{may}} include one or more <code>description</code> elements. If more than one description element is defined, the full description for the hAudio is the concatenation, in order, of all <code>description</code> elements.

=== Parser Processing Notes ===

* It is important to understand that ITEM is an opaque element. When processing the ITEM element, none of the properties of the child hAudio should be pulled into the parent hAudio. However, it is recommended that child hAudio {{should}} inherit the following parent hAudio properties, if they are not specified on the child:
** album
** contributor
** category
** published
** photo

=== Semantic XHTML Design Principles ===

{{semantic-xhtml-design-principles}}

==== More Semantic Equivalents ====

For some properties there is a more semantic equivalent, and therefore they get special treatment, e.g.:

* For "photo", use <code><img class="photo" src="..." alt="" /></code>
* If only 'album' is specified, then the hAudio is an album.
* If only 'fn' is specified, then the hAudio is a song, audio track, sound effect, speech, or other atomic/singular work.
* If both 'album' and 'fn' are specified, then the hAudio is a atomic/singular work that is part of an album.
** Example: <code><nowiki><span class="haudio">Side two of <span class="album">Meddle</span> opens with <span class="fn">One of These Days</span></span></nowiki></code>
* If 'fn' and one or more 'items's are specified, the hAudio is an audio recording containing multiple sections. Each item is assumed to be an hAudio that is part of the parent hAudio. None of the 'item' properties should implicitly be added to the containing hAudio. In other words, the parser shouldn't parse the contents of the 'item' into the higher-level hAudio object.

==== Language ====

* To explicitly convey the natural language that an hAudio is written in, use the standard (X)HTML 'lang' or 'xml:lang' attribute on the element with class="haudio"
**e.g. <code><nowiki><p>I like <span class="haudio" lang="de"><span class="fn">Das Lied von der Erde</span></span> best.</p></nowiki></code>
*If portions of an hAudio (e.g. the item name) are in a different language to the rest of the hAudio, use the 'lang' or 'xml:lang' attribute on those portions.
* hAudio parsers which need to handle the native language of hAudio {{must}} process the standard (X)HTML 'lang' or 'xml:lang' attribute as specified.
* hAudio parsers which need to handle native language {{may}} traverse up the DOM to discover the native language of the page and apply that to the hAudio if no other language is specified on the hAudio.

==== Human vs. Machine Readable ====

If an <code><abbr></code> element is used for a property, then its '<code>title</code>' attribute is used for the value of the property, instead of the contents of the element, which can then be used to provide a user-friendly alternate presentation of the value.

If an <code><a></code> element is used for one or more properties, it {{must}} be treated as follows:
# For the 'photo' property and any other property that takes a URL as its value, the <code>href="..."</code> attribute provides the property value.
# For other properties, the element's content is the value of the property.

If an <code><img></code> element is used for one or more properties, it {{must}} be treated as follows:
# For the 'photo' property and any other property that takes a URL as its value, the <code>src="..."</code> attribute provides the property value.
# For other properties, the <code><img></code> element's '<code>alt</code>' attribute is the value of the property.

If an <code><object></code> element is used for one or more properties, it {{must}} be treated as follows:
# For the 'photo' property and any other property that takes a URL as its value, the <code>data="..."</code> attribute provides the property value.
# For other properties, the element's content is the value of the property.

=== Notes ===

This section is informative.

* By marking up audio content with the hAudio microformat, the expectation is communicated that information about the content {{may}} be indexed. This has no impact on the copyright of the content itself which the publisher may explicitly specify using the [[rel-license]] microformat.

== XMDP Profile ==

<pre>
<dl class="profile">
<dt>class</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
HTML4 definition of the 'class' attribute.</a>
This meta data profile defines some 'class' attribute values (class names)
and their meanings as suggested by a
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile">
draft of "Hypertext Links in HTML"</a>.</p>
<dl>
<dt>haudio</dt>
<dd>
Used to identify and describe metadata associated with an individual audio recording.
</dd>
<dt>fn</dt>
<dd>
A short textual description used to identify an audio recording among interested parties.
</dd>
<dt>album</dt>
<dd>
A short textual description used to identify an audio recording that is an album among
interested parties.
</dd>
<dt>contributor</dt>
<dd>
An entity that takes part in the creation and distribution of an audio recording.
</dd>
<dt>published</dt>
<dd>
The date that the audio recording was made available to the public.
</dd>
<dt>description</dt>
<dd>
A verbose description of the audio recording.
</dd>
<dt>photo</dt>
<dd>
An image that should be used to summarize the audio recording.
</dd>
<dt>item</dt>
<dd>
Contains a sub-part of the current audio recording, which is marked-up using any element available in hAudio.
</dd>
<dt>sample</dt>
<dd>
A URI specifying a method of sampling a section of the audio recording.
</dd>
<dt>enclosure</dt>
<dd>
A URI specifying a method of downloading the complete version of the audio recording.
</dd>
<dt>purchase</dt>
<dd>
A URI specifying a method of purchase resulting in the acquisition of a complete version of the audio recording.
</dd>
<dt>category</dt>
<dd>
The genre or style used to classify the audio recording.
</dd>
<dt>duration</dt>
<dd>
The length of the audio recording.
</dd>
<dt>price</dt>
<dd>
The amount of currency that must be exchanged for acquisition of a full specimen of the audio recording.
</dd>
</dl>
</dd>
</dl>
</pre>

== Examples ==

This section is informative.

Here are a few examples of text about, and links to, audio content, from real web sites, showing how they could be easily enhanced to use hAudio.



=== Simple Song Example ===

Display:

(This is a live example, detectable in parsers)

<div class="haudio">
<span class="fn">Start Wearing Purple</span> by <span class="contributor">Gogol Bordello</span>
</div>

Microformatted XHTML:

<pre>
<div class="haudio">
<span class="fn">Start Wearing Purple</span> by
<span class="contributor">Gogol Bordello</span>
</div>
</pre>

=== Speech Example ===

(This is a live example, detectable in parsers)

Display:

<div class="haudio">
<span class="fn">I Have a Dream</span>, a <span class="category">speech</span> by <span class="contributor"><span class="vcard"><span class="fn n"><span class="given-name">Martin</span> <span class="additional-name">Luther</span> <span class="family-name">King</span>, <span class="honorific-suffix">Jr.</span></span></span></span>
</div>

Microformatted XHTML:
<pre>
<div class="haudio">
<span class="fn">I Have a Dream</span>, a
<span class="category">speech</span> by
<span class="contributor">
<span class="vcard">
<span class="fn n">
<span class="given-name">Martin</span>
<span class="additional-name">Luther</span>
<span class="family-name">King</span>,
<span class="honorific-suffix">Jr.</span>
</span>
</span>
</span>
</div>
</pre>

Note the use of [[hcard|hCard]].

=== Song and Album Example ===

(This is a live example, detectable in parsers)

Display:

<div class="haudio">
<span class="fn">Start Wearing Purple</span> by <span class="contributor"><span class="vcard"><span class="fn org">Gogol Bordello</span></span></span> found on <span class="album">Underdog World Strike</span>
</div>

Microformatted XHTML:

<pre>
<div class="haudio">
<span class="fn">Start Wearing Purple</span> by
<span class="contributor">
<span class="vcard">
<span class="fn org">Gogol Bordello</span>
</span>
</span>
found on
<span class="album">Underdog World Strike</span>
</div>
</pre>

Note that for bands, hCard's ''[[hcard#Implied_.22organization-name.22_Optimization|Implied "organization-name" Optimization]]'' is used.

=== Complete Album Example ===

An example that uses every element of hAudio:

[Image] Live Phish, Volume 15 by Phish<br/>
Released: October 31, 2002<br/>
Acquire: Sample, Live Recording, Buy High Quality Track<br/>
Category: [http://www.example.org/tags/live live]<br/>
Duration: 145 minutes, 27 seconds<br/>
Price: $14.99<br/>
<br/>
Tracks:<br/>
1. Sanity (5:48)<br/>
2. Highway To Hell (3:39)

Here is the hAudio Microformat markup:

<pre>
<div class="haudio">
<img class="photo" src="images/live_phish_vol_15.jpg" alt="" />
<span class="album">Live Phish, Volume 15</span>
<span class="contributor">
<span class="vcard">
<span class="fn org">Phish</span>
</span>
</span>
<br/>
Released on:
<abbr class="published" title="2002-10-31">October 31, 2002</abbr>
<br/>
Acquire:
<a rel="sample" href="/samples/live_phish_vol_15_sample.mp3">Sample</a>,
<a rel="enclosure" href="/live/phish_live_phish_vol_15.mp3">Live Recording</a>,
<a rel="payment" href="/buy/phish_live_phish_vol_15">Buy High Quality Track</a>
Category: <a class="category" rel="tag" href="http://www.example.org/tags/live">live</a>
Duration: <abbr class="duration" title="PT145M27S">145 minutes, 27 seconds</abbr>
Price: <div class="price"><abbr class="currency" title="USD">$</abbr><span class="amount">14.99</span></div>
Tracks:
<div class="item">
<span class="position">1</span>.
<span class="fn">Sanity</span>
(<abbr class="duration" title="PT5M48S">5:48</abbr>)
</div>
<div class="item">
<span class="position">2</span>.
<span class="fn">Highway To Hell</span>
(<abbr class="duration" title="PT3M39S">3:39</abbr>)
</div>
</div>
</pre>

=== Multi-part Podcast Example ===

DigitalPlanet Podcast: 29 Oct 07

Forensic computing: is it really possible to delete data from your machine? Grand plans for getting broadband into Africa, checking out the sky at night via the internet and answering your emails to the programme.

Download MP3

<pre>
<div class="haudio">
<p>
<span class="fn">DigitalPlanet Podcast</span>
:
<abbr class="published" title="20071029">29 Oct 07</abbr>
</p>
<p>
<div class="item">
<span class="fn">Forensic computing: is it really possible to delete data from your machine?</span>
</div>
<div class="item">
<span class="fn">Grand plans for getting broadband into Africa</span>
</div>
,
<div class="item">
<span class="fn">checking out the sky at night via the internet</span>
</div>
and
<div class="item">
<span class="fn">answering your emails</span>
</div>
to the programme.
</p>
<p>
<a rel="enclosure" href="/download/episode/DigitalPlanet-2007-10-29">Download MP3</a>
</p>
</div>
</pre>

=== Opera Example ===

(This is a live example, detectable in parsers)

<div class="haudio" lang="en">
<span class="fn" lang="fr">La Bohème</span> is an <span class="category">opera</span> in four acts by <span class="contributor" lang="it">Giacomo Puccini</span> to an <span class="category">Italian liberetto</span> by <span class="contributor" lang="it">Luigi Illica</span> and <span class="contributor" lang="it">Giuseppe Giacosais</span>. I saw it performed last week and found <span class="item"> <span class="fn">Act III</span> to be pretty interesting, especially the <span class="item"> "<span class="fn" lang="it">Sa dirmi, scusi</span>"</span> and <span class="item">"<span class="fn" lang="it">O buon Marcello, aiuto!</span>"</span> arias.</span>
</div>

<pre>
<div class="haudio" lang="en">
<span class="fn" lang="fr">La Bohème</span>
is an
<span class="category">opera</span>
in four acts by
<span class="contributor" lang="it">Giacomo Puccini</span>
to an
<span class="category">Italian liberetto</span>
by
<span class="contributor" lang="it">Luigi Illica</span>
and
<span class="contributor" lang="it">Giuseppe Giacosais</span>.
I saw it performed last week and found
<span class="item">
<span class="fn">Act III</span>
to be pretty interesting, especially the
<span class="item">
"<span class="fn" lang="it">Sa dirmi, scusi</span>"
</span>
and
<span class="item">
"<span class="fn" lang="it">O buon Marcello, aiuto!</span>"
</span>
arias.
</span>
</div>
</pre>

== Examples in the wild ==

This section is '''informative'''.

* [http://weborganics.co.uk/haudio-rss/ hAudio-RSS] uses hAudio 0.9.1 and XSLT to generate an RSS2 Playlist.
* Tara Hunt of [http://openmediaweb.org/index.php/2008/01/13/publishing-my-workout-music-in-haudio/ Open Media Web] Published her workout Music in hAudio
* Grabb.it The web music player now uses hAudio 0.9 in its [http://grabb.it/users/greg user pages]
* [http://soundcloud.com/ SoundCloud] has hAudio in its pages.
* [http://populizer.com/ Populizer] also has hAudio in its pages.
* The [http://www.numblog.de/ New Urban Music Blog] has hAudio marked up in its pages.

== Implementations ==

This section is '''informative'''.

*[http://weborganics.co.uk/files/js/haudio.zip hAudio 0.9 script] for [[operator|Operator]], updated version of the original hAudio script by David Lehn.
* Matthias Pfefferle has made some [http://notizblog.org/projects/haudio-icons/ hAudio Icons]
* [http://transformr.co.uk/ TransFormr] extracts hAudio 0.9.1 as either a RSS2 Podcast or an XSPF Playlist.
* [http://buzzword.org.uk/cognition/ Cognition] 0.1-α11 and above will parse hAudio 0.9 and export as RDF/XML or RDF/JSON. As of 0.1-α12, it will also export in M3U playlist format and Turtle.
* [http://weborganics.co.uk/mo-haudio/ hAudio Microformat to RDF Music Ontology], a [http://www.w3.org/TR/grddl/ GRDDL] profile for hAudio 0.9.1, producing [http://musicontology.com/ Music Ontology] RDF.
* The [http://singpolyma.net/plugins/actionstream/ wp-diso-actionstream] plugin produces hAudio for last.fm scrobbles
*...


== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://gmpg.org/xmdp/ XMDP]
* [[hcard|hCard]]
* [[abbr-design-pattern]]
* [[currency-proposal]]
* [[datetime-design-pattern]]
* [[rel-design-pattern]]
* [[ISO-31-1|ISO-31-1/ISQ]]

=== Informative References ===
* [http://www.w3.org/TR/REC-CSS1 CSS1]
* ISO.8601.1988
** International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO Standard 8601, June 1988.
* [http://www.w3.org/TR/1998/NOTE-datetime-19980827 W3C NOTE-datetime-19980827]
* [http://www.w3.org/Consortium/Patent-Policy-20040205/ W3C Patent Policy]
* Other audio metadata efforts. See [[audio-info-formats]].

==== Similar Work ====
* [[media-info]]
* [[grouping-examples]]
* [[grouping-brainstorming]]
* [[xoxo|XOXO]]

=== Copyright ===

This document and <span class="vevent"><span class="summary">hAudio specification was placed into the public domain</span> on <span class="dtstart">2008-11-14</span></span> by the authors. There are no usage, distribution, re-printing, or any other restrictions of any kind with regards to the text or content of this specification.

=== Patents ===

{{MicroFormatPatentStatement}}

=== Public Domain Release ===

The authors and editors of this page due hereby relinquish their copyright on the document and release the text of this page into the public domain.

* Manu Sporny - Signature /Manu Sporny/
* Alexandre Van de Sande
* [[User:WebOrganics|Martin McEvoy]]
* [[User:DavidLehn|David Lehn]] - Signature /David Lehn/
* [[User:AndyMabbett|Andy Mabbett]]

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

== Related Pages ==
{{haudio-related-pages}}
* [[audio]] (other pages about Audio on this wiki)

[[Category:Draft Specifications]]

hmedia-issues

2009-01-10T23:16:00Z

ManuSporny: Adding several issues with current draft

= hMedia 0.1 issues =

This page defines the current issues with the [[hmedia|hMedia draft specification]]. Any issues that have not yet been resolved are marked with an {{OpenIssue}} tag.
{{TOC-right}}

== Contributors ==

In order of contribution:

* ...

== Issues Template ==

{{issues-format}}

== 2009 issues ==

<div class="vevent">
* {{OpenIssue}} <span class="summary vcard"><span class="dtstart">2009-01-10</span> raised by <span class="fn">[[User:ManuSporny|ManuSporny]]</span></span>
<div class="description">
*# hMedia should not be marked as a "Draft" for the following reasons:
*## It has not gone through a media-info-proposal stage of the Microformats Process.
*## There has been hardly any discussion regarding the attributes selected for the vocabulary.
*## It is a bad idea to formalize hMedia until at least hVideo and hImage has been completed.
*## Marking hMedia a Draft may confuse new Microformats users into believing that it has as much thought put into it as geo, hAtom or hResume.
</div>
</div>

haudio-issues

2008-09-03T22:08:17Z

ManuSporny: /* D2: 2008-01-10 hAudio Title was Overloading "fn". */ - fixed typos

=hAudio issues=

These are externally raised issues about [[haudio|hAudio]] with broadly varying degrees of merit. Thus some issues are <em style="text-transform:uppercase;">rejected</em> for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be <em style="text-transform:uppercase;">accepted</em> and perhaps cause changes or improved explanations in the spec.

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

== issues ==
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[haudio-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.
* You can subscribe to all haudio issues on <nowiki>webcal://feeds.technorati.com/events/http://microformats.org/wiki/haudio-issues</nowiki>

==2008==

=== D1: 2008-01-10 Contributor ===
<div class="vevent">
* {{ResolvedIssue}} D1: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011340.html microformats-discuss/2008-January/011340.html]</span>
<div class="description">
*# the wording about <code>contributor</code> could be improved to facilitate more streamlined mark-up (see above e-mail for details).
*#* A resolution to this issue is outlined in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001725.html
*#* ACCEPTED ISSUE The hAudio Contributor Specification is to be changed to:
*#** The element is identified by the class name |contributor|.
*#** hAudio /MAY/ include one or more contributors.
*#** The contributor's name SHOULD also be marked up as a valid hCard Microformat. <http://microformats.org/wiki/hcard>
*#**# The |role| attribute /SHOULD/ be used to specify the contributor's responsibility related to the audio recording if hCard is utilized.
*#** The contributor's name MAY be specified in plain-text without being enclosed in a hCard Microformat.
*#* REMOVED:
*#** If multiple contributors are specified, without |role| specifications, it /MAY/ be assumed that the first role mentioned is the primary artist or creator.
*#**# As proposed By [[User:ManuSporny|Manu Sporny]] in http://microformats.org/discuss/mail/microformats-new/2008-August/001725.html
</div>
</div>

=== D2: 2008-01-10 hAudio Title was Overloading "fn".===

<div class="vevent">
* {{OpenIssue}} D2: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011342.html] </span>
<div class="description">
The "overloading" of <code>fn</code> for both the tile of a work and the name of a contributor causes problems (see above e-mail for examples). Another example of this problem is a table, where the "artist" column comes before the "title" column. For discussion, see also [http://microformats.org/discuss/mail/microformats-new/2008-January/001375.html microformats-new/2008-January/001375.html].
# Existing Resolution [[User:ManuSporny|Manu Sporny]] has propsosed that <code>"fn"</code> should be replaced with <code>"title"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-February/001468.html microformats-new/2008-February/001468.html]
#* +1 [[User:ManuSporny|Manu Sporny]] (first choice)
# Resolution 1: [[User:WebOrganics|Martin McEvoy]] proposed change <code>"title"</code> to <code>"name"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-March/001555.html microformats-new/2008-March/001555.html]
# Resolution 2: [[User:WebOrganics|Martin McEvoy]] later propsosed that <code>"title"</code> should be replaced with <code>"htitle"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html microformats-new/2008-August/001692.html]
#* +1 [[User:WebOrganics|Martin McEvoy]]
#* +1 [[User:ManuSporny|Manu Sporny]] (second choice)
# Resolution 3: Use <code>"audio-title"</code> As tentatively proposed by [[User:ManuSporny|Manu Sporny]] see:[http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html microformats-new/2008-August/001692.html]
# Resolution 4: Change <code>"title"</code> back to <code>"fn"</code> see: [http://microformats.org/wiki?title=haudio&diff=prev&oldid=25667]
#* +1 [[User:WebOrganics|Martin McEvoy]] <span style="color: rgb(204, 0, 0);">second choice if htitle is not accepted.</span>
#* +1 [[User:ManuSporny|Manu Sporny]] (third choice)
# Don't really care — just pick one. ;-)
#* +1 [[User:TobyInk|TobyInk]]
#* +1 [[User:ManuSporny|Manu Sporny]] - close this damn discussion, already! :)
</div>
</div>

=== D3: 2008-01-10 Position. ===
<div class="vevent">
* {{ResolvedIssue}} D3: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011343.html microformats-discuss/2008-January/011343.html]</span>
<div class="description">
*# The [http://microformats.org/wiki/haudio#Complete_Album_Example recommended use of "position" in hAudio] is contrary to the good practice, semantic use of ordered lists (see example and suggested solution in the above e-mail; also [http://microformats.org/discuss/mail/microformats-new/2008-January/001338.html] et seq)
*#* For Cognition I'm considering an extension: if no position has been explicitly marked up, and the item is <code><li class="item"></code> within an ordered list, then the position is taken to be the numerical value of the list marker. (To calculate the numerical value for the list marker, find the most recent sibling <code><li></code> element which has a <code>value</code> attribute. The numerical value is the number in that value attribute added to the count of <code><li></code> elements after that value attribute up to the current one. If there are no such <code><li></code> elements with <code>value</code> attributes, then you should assume that the <code>value</code> attribute of the first list item is equal to the <code>start</code> attribute of the ordered list itself, or "1" if there is no such <code>start</code> attribute. [[User:TobyInk|TobyInk]] 04:24, 29 Jul 2008 (PDT)
*#* A Proposed Resolution was made in this email: ( http://microformats.org/discuss/mail/microformats-new/2008-August/001751.html)
*#* ACCEPTED ISSUE The hAudio Position Specification is to be changed to:
*#** The element is identified by the class name |position|.
*#** hAudio /MAY/ include one |position| element.
*#** The contents of the element /MUST/ be a number or other sequential identifier.
*#** The sequential identifier /MAY/ be specified out-of-sequence.
*#* ADDED:
*#** The sequential identifier /MAY/ be specified out-of-sequence.
*#**# As proposed By [[User:ManuSporny|Manu Sporny]] in http://microformats.org/discuss/mail/microformats-new/2008-August/001708.html
*#* [[User:AndyMabbett|Andy Mabbett]] also Expressed concerns that the [[haudio#Complete_Album_Example|Complete Album Example]] should be marked up as an ordered list this is unnecessary as <code>"position"</code> is not related to the order of a track item in a list.
*#* A tutorial on the correct use of semantic ordered lists and hAudio is to be added to the [[haudio-authoring|hAudio Authoring]] Page
</div>
</div>

=== D4: 2008-01-10 rel-enclosure does not allow for links to streaming files ===
<div class="vevent">
* {{ResolvedIssue}} D4: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html microformats-discuss/2008-January/011344.html]</span>
<div class="description">
*# The required use of [[rel-enclosure]] does not allow for links to streaming files, which are not cacheable, and are thus outside the scope of rel-enclosure. [http://www.bbc.co.uk/radio4/science/livingworld_20041121.shtml An example on the BBC website] has the relevant link is below the heading "LISTEN AGAIN". (see discussion at [http://microformats.org/discuss/mail/microformats-new/2008-January/001339.html microformats-new/2008-January/001339.html] et seq).
*#* A proposal for this issue was first made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001715.html
*#* A second proposal for this issue has been made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001727.html
*#* This can potentially be solved by recognition of downloadable/streamable MIME types. For performance reasons it is undesirable for parsers to be required to make HTTP requests for each file to determine its MIME type, so authors should be encouraged to include the MIME type in the <code>type</code> attribute. See the [[haudio-brainstorming#Download_links|related section on "brainstorming"]]. [[User:TobyInk|TobyInk]] 14:41, 20 Aug 2008 (PDT)
*#* ACCEPTED ISSUE The hAudio Enclosure Specification is to be changed to:
*#** The element is identified by a URI fitting the rel-design-pattern, the rel content being enclosure.
*#** hAudio MAY include one or more enclosure URIs.
*#** The type of the file SHOULD be specified by using the type specifier for a URI.
*#* CHANGED:
*#** The type of the file MAY be specified by using the type specifier for a URI.
*#*** As suggested by [[User:Tantek|Tantek Çelik]] in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001731.html
*#*** As Proposed by [[User:TobyInk|Toby Inkster]] on 14:41, 20 Aug 2008 (PDT)
*#* A tutorial on the importance of Type Specifiers and hAudio Enclosures is to be added to the [[haudio-authoring|hAudio Authoring]] Page
</div>
</div>

=== D5: 2008-01-10 there is no way of linking to an interim page ===
<div class="vevent">
* {{OpenIssue}} D5: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html microformats-discuss/2008-January/011344.html]</span>
<div class="description">
*# There appears to be no mechanism to mark up an hAudio, expressed in plain text on page A, which links to an interim page, B, which in turn links to a file download. For example, the radio shows listed on [http://www.westmidlandbirdclub.com/bibliography/radio].
</div>
</div>

=== D6: 2008-01-10 hAudio notes inconsistency ===
<div class="vevent">
* {{ResolvedIssue}} D6: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011345.html microformats-discuss/2008-January/011345.html]</span>
<div class="description">
*# [[haudio#Notes|The "Notes" section of the hAudio spec]] says "By marking up audio content with the hAudio microformat, the expectation is communicated that information about the content {{may}} be indexed. This has no impact on the copyright of the content itself which the publisher may explicitly specify using rel-license as specified above.". However, that is the first and only reference to [[rel-license]] on the page.
*#* Typing error changed to "By marking up audio content with the hAudio microformat, the expectation is communicated that information about the content MAY be indexed. This has no impact on the copyright of the content itself which the publisher may explicitly specify using the rel-license microformat". [http://microformats.org/wiki?title=haudio&diff=0&oldid=27951]
*#* hAudio Specification SHOULD include the [[rel-license]] microformat [[User:WebOrganics|Martin McEvoy]] 11:57, 18 Aug 2008 (GMT)
*#* A proposed resolution to this issue has been made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001720.html
*# RESOLVED <code>rel="licence"</code> is not part of this version of hAudio (0.9) see:http://microformats.org/discuss/mail/microformats-new/2008-August/001747.html
</div>
</div>

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

==see also==
*[[audio-info-issues]]

==related pages==
{{haudio-related-pages}}

haudio-issues

2008-09-03T22:07:12Z

ManuSporny: /* D2: 2008-01-10 hAudio Title was Overloading "fn". */

=hAudio issues=

These are externally raised issues about [[haudio|hAudio]] with broadly varying degrees of merit. Thus some issues are <em style="text-transform:uppercase;">rejected</em> for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be <em style="text-transform:uppercase;">accepted</em> and perhaps cause changes or improved explanations in the spec.

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

== issues ==
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[haudio-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.
* You can subscribe to all haudio issues on <nowiki>webcal://feeds.technorati.com/events/http://microformats.org/wiki/haudio-issues</nowiki>

==2008==

=== D1: 2008-01-10 Contributor ===
<div class="vevent">
* {{ResolvedIssue}} D1: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011340.html microformats-discuss/2008-January/011340.html]</span>
<div class="description">
*# the wording about <code>contributor</code> could be improved to facilitate more streamlined mark-up (see above e-mail for details).
*#* A resolution to this issue is outlined in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001725.html
*#* ACCEPTED ISSUE The hAudio Contributor Specification is to be changed to:
*#** The element is identified by the class name |contributor|.
*#** hAudio /MAY/ include one or more contributors.
*#** The contributor's name SHOULD also be marked up as a valid hCard Microformat. <http://microformats.org/wiki/hcard>
*#**# The |role| attribute /SHOULD/ be used to specify the contributor's responsibility related to the audio recording if hCard is utilized.
*#** The contributor's name MAY be specified in plain-text without being enclosed in a hCard Microformat.
*#* REMOVED:
*#** If multiple contributors are specified, without |role| specifications, it /MAY/ be assumed that the first role mentioned is the primary artist or creator.
*#**# As proposed By [[User:ManuSporny|Manu Sporny]] in http://microformats.org/discuss/mail/microformats-new/2008-August/001725.html
</div>
</div>

=== D2: 2008-01-10 hAudio Title was Overloading "fn".===

<div class="vevent">
* {{OpenIssue}} D2: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011342.html] </span>
<div class="description">
The "overloading" of <code>fn</code> for both the tile of a work and the name of a contributor causes problems (see above e-mail for examples). Another example of this problem is a table, where the "artist" column comes before the "title" column. For discussion, see also [http://microformats.org/discuss/mail/microformats-new/2008-January/001375.html microformats-new/2008-January/001375.html].
# Existing Resolution [[User:ManuSporny|Manu Sporny]] has propsosed that <code>"fn"</code> should be replaced with <code>"title"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-February/001468.html microformats-new/2008-February/001468.html]
# Resolution 1: [[User:WebOrganics|Martin McEvoy]] proposed change <code>"title"</code> to <code>"name"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-March/001555.html microformats-new/2008-March/001555.html]
#* +1 [[User:ManuSporny|Manu Sporny]] (first choice)
# Resolution 2: [[User:WebOrganics|Martin McEvoy]] later propsosed that <code>"title"</code> should be replaced with <code>"htitle"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html microformats-new/2008-August/001692.html]
#* +1 [[User:WebOrganics|Martin McEvoy]]
#* +1 [[User:ManuSporny|Manu Sporny]] (second choice)
# Resoulution 3: Use <code>"audio-title"</code> As tentatively proposed by [[User:ManuSporny|Manu Sporny]] see:[http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html microformats-new/2008-August/001692.html]
# Resoulution 4: Change <code>"title"</code> back to <code>"fn"</code> see: [http://microformats.org/wiki?title=haudio&diff=prev&oldid=25667]
#* +1 [[User:WebOrganics|Martin McEvoy]] <span style="color: rgb(204, 0, 0);">second choice if htitle is not accepted.</span>
#* +1 [[User:ManuSporny|Manu Sporny]] (third choice)
# Don't really care — just pick one. ;-)
#* +1 [[User:TobyInk|TobyInk]]
#* +1 [[User:ManuSporny|Manu Sporny]] - close this damn discussion, already! :)
</div>
</div>

=== D3: 2008-01-10 Position. ===
<div class="vevent">
* {{ResolvedIssue}} D3: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011343.html microformats-discuss/2008-January/011343.html]</span>
<div class="description">
*# The [http://microformats.org/wiki/haudio#Complete_Album_Example recommended use of "position" in hAudio] is contrary to the good practice, semantic use of ordered lists (see example and suggested solution in the above e-mail; also [http://microformats.org/discuss/mail/microformats-new/2008-January/001338.html] et seq)
*#* For Cognition I'm considering an extension: if no position has been explicitly marked up, and the item is <code><li class="item"></code> within an ordered list, then the position is taken to be the numerical value of the list marker. (To calculate the numerical value for the list marker, find the most recent sibling <code><li></code> element which has a <code>value</code> attribute. The numerical value is the number in that value attribute added to the count of <code><li></code> elements after that value attribute up to the current one. If there are no such <code><li></code> elements with <code>value</code> attributes, then you should assume that the <code>value</code> attribute of the first list item is equal to the <code>start</code> attribute of the ordered list itself, or "1" if there is no such <code>start</code> attribute. [[User:TobyInk|TobyInk]] 04:24, 29 Jul 2008 (PDT)
*#* A Proposed Resolution was made in this email: ( http://microformats.org/discuss/mail/microformats-new/2008-August/001751.html)
*#* ACCEPTED ISSUE The hAudio Position Specification is to be changed to:
*#** The element is identified by the class name |position|.
*#** hAudio /MAY/ include one |position| element.
*#** The contents of the element /MUST/ be a number or other sequential identifier.
*#** The sequential identifier /MAY/ be specified out-of-sequence.
*#* ADDED:
*#** The sequential identifier /MAY/ be specified out-of-sequence.
*#**# As proposed By [[User:ManuSporny|Manu Sporny]] in http://microformats.org/discuss/mail/microformats-new/2008-August/001708.html
*#* [[User:AndyMabbett|Andy Mabbett]] also Expressed concerns that the [[haudio#Complete_Album_Example|Complete Album Example]] should be marked up as an ordered list this is unnecessary as <code>"position"</code> is not related to the order of a track item in a list.
*#* A tutorial on the correct use of semantic ordered lists and hAudio is to be added to the [[haudio-authoring|hAudio Authoring]] Page
</div>
</div>

=== D4: 2008-01-10 rel-enclosure does not allow for links to streaming files ===
<div class="vevent">
* {{ResolvedIssue}} D4: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html microformats-discuss/2008-January/011344.html]</span>
<div class="description">
*# The required use of [[rel-enclosure]] does not allow for links to streaming files, which are not cacheable, and are thus outside the scope of rel-enclosure. [http://www.bbc.co.uk/radio4/science/livingworld_20041121.shtml An example on the BBC website] has the relevant link is below the heading "LISTEN AGAIN". (see discussion at [http://microformats.org/discuss/mail/microformats-new/2008-January/001339.html microformats-new/2008-January/001339.html] et seq).
*#* A proposal for this issue was first made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001715.html
*#* A second proposal for this issue has been made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001727.html
*#* This can potentially be solved by recognition of downloadable/streamable MIME types. For performance reasons it is undesirable for parsers to be required to make HTTP requests for each file to determine its MIME type, so authors should be encouraged to include the MIME type in the <code>type</code> attribute. See the [[haudio-brainstorming#Download_links|related section on "brainstorming"]]. [[User:TobyInk|TobyInk]] 14:41, 20 Aug 2008 (PDT)
*#* ACCEPTED ISSUE The hAudio Enclosure Specification is to be changed to:
*#** The element is identified by a URI fitting the rel-design-pattern, the rel content being enclosure.
*#** hAudio MAY include one or more enclosure URIs.
*#** The type of the file SHOULD be specified by using the type specifier for a URI.
*#* CHANGED:
*#** The type of the file MAY be specified by using the type specifier for a URI.
*#*** As suggested by [[User:Tantek|Tantek Çelik]] in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001731.html
*#*** As Proposed by [[User:TobyInk|Toby Inkster]] on 14:41, 20 Aug 2008 (PDT)
*#* A tutorial on the importance of Type Specifiers and hAudio Enclosures is to be added to the [[haudio-authoring|hAudio Authoring]] Page
</div>
</div>

=== D5: 2008-01-10 there is no way of linking to an interim page ===
<div class="vevent">
* {{OpenIssue}} D5: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html microformats-discuss/2008-January/011344.html]</span>
<div class="description">
*# There appears to be no mechanism to mark up an hAudio, expressed in plain text on page A, which links to an interim page, B, which in turn links to a file download. For example, the radio shows listed on [http://www.westmidlandbirdclub.com/bibliography/radio].
</div>
</div>

=== D6: 2008-01-10 hAudio notes inconsistency ===
<div class="vevent">
* {{ResolvedIssue}} D6: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011345.html microformats-discuss/2008-January/011345.html]</span>
<div class="description">
*# [[haudio#Notes|The "Notes" section of the hAudio spec]] says "By marking up audio content with the hAudio microformat, the expectation is communicated that information about the content {{may}} be indexed. This has no impact on the copyright of the content itself which the publisher may explicitly specify using rel-license as specified above.". However, that is the first and only reference to [[rel-license]] on the page.
*#* Typing error changed to "By marking up audio content with the hAudio microformat, the expectation is communicated that information about the content MAY be indexed. This has no impact on the copyright of the content itself which the publisher may explicitly specify using the rel-license microformat". [http://microformats.org/wiki?title=haudio&diff=0&oldid=27951]
*#* hAudio Specification SHOULD include the [[rel-license]] microformat [[User:WebOrganics|Martin McEvoy]] 11:57, 18 Aug 2008 (GMT)
*#* A proposed resolution to this issue has been made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001720.html
*# RESOLVED <code>rel="licence"</code> is not part of this version of hAudio (0.9) see:http://microformats.org/discuss/mail/microformats-new/2008-August/001747.html
</div>
</div>

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

==see also==
*[[audio-info-issues]]

==related pages==
{{haudio-related-pages}}

haudio-issues

2008-09-03T22:06:08Z

ManuSporny: /* D2: 2008-01-10 hAudio Title was Overloading "fn". */

=hAudio issues=

These are externally raised issues about [[haudio|hAudio]] with broadly varying degrees of merit. Thus some issues are <em style="text-transform:uppercase;">rejected</em> for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be <em style="text-transform:uppercase;">accepted</em> and perhaps cause changes or improved explanations in the spec.

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

== issues ==
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[haudio-issues#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.
* You can subscribe to all haudio issues on <nowiki>webcal://feeds.technorati.com/events/http://microformats.org/wiki/haudio-issues</nowiki>

==2008==

=== D1: 2008-01-10 Contributor ===
<div class="vevent">
* {{ResolvedIssue}} D1: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011340.html microformats-discuss/2008-January/011340.html]</span>
<div class="description">
*# the wording about <code>contributor</code> could be improved to facilitate more streamlined mark-up (see above e-mail for details).
*#* A resolution to this issue is outlined in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001725.html
*#* ACCEPTED ISSUE The hAudio Contributor Specification is to be changed to:
*#** The element is identified by the class name |contributor|.
*#** hAudio /MAY/ include one or more contributors.
*#** The contributor's name SHOULD also be marked up as a valid hCard Microformat. <http://microformats.org/wiki/hcard>
*#**# The |role| attribute /SHOULD/ be used to specify the contributor's responsibility related to the audio recording if hCard is utilized.
*#** The contributor's name MAY be specified in plain-text without being enclosed in a hCard Microformat.
*#* REMOVED:
*#** If multiple contributors are specified, without |role| specifications, it /MAY/ be assumed that the first role mentioned is the primary artist or creator.
*#**# As proposed By [[User:ManuSporny|Manu Sporny]] in http://microformats.org/discuss/mail/microformats-new/2008-August/001725.html
</div>
</div>

=== D2: 2008-01-10 hAudio Title was Overloading "fn".===

<div class="vevent">
* {{OpenIssue}} D2: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011342.html] </span>
<div class="description">
The "overloading" of <code>fn</code> for both the tile of a work and the name of a contributor causes problems (see above e-mail for examples). Another example of this problem is a table, where the "artist" column comes before the "title" column. For discussion, see also [http://microformats.org/discuss/mail/microformats-new/2008-January/001375.html microformats-new/2008-January/001375.html].
# Existing Resolution [[User:ManuSporny|Manu Sporny]] has propsosed that <code>"fn"</code> should be replaced with <code>"title"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-February/001468.html microformats-new/2008-February/001468.html]
# Resolution 1: [[User:WebOrganics|Martin McEvoy]] proposed change <code>"title"</code> to <code>"name"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-March/001555.html microformats-new/2008-March/001555.html]
#* +1 [[User:ManuSporny|Manu Sporny]] (first choice)
# Resolution 2: [[User:WebOrganics|Martin McEvoy]] later propsosed that <code>"title"</code> should be replaced with <code>"htitle"</code> see: [http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html microformats-new/2008-August/001692.html]
#* +1 [[User:WebOrganics|Martin McEvoy]]
#* +1 [[User:ManuSporny|Manu Sporny]] (second choice)
# Resoulution 3: Use <code>"audio-title"</code> As tentatively proposed by [[User:ManuSporny|Manu Sporny]] see:[http://microformats.org/discuss/mail/microformats-new/2008-August/001692.html microformats-new/2008-August/001692.html]
# Resoulution 4: Change <code>"title"</code> back to <code>"fn"</code> see: [http://microformats.org/wiki?title=haudio&diff=prev&oldid=25667]
#* +1 [[User:WebOrganics|Martin McEvoy]] <span style="color: rgb(204, 0, 0);">second choice if htitle is not accepted.</span>
#* +1 [[User:ManuSporny|Manu Sporny]] (third choice)
# Don't really care — just pick one. ;-)
#* +1 [[User:TobyInk|TobyInk]]
</div>
</div>

=== D3: 2008-01-10 Position. ===
<div class="vevent">
* {{ResolvedIssue}} D3: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011343.html microformats-discuss/2008-January/011343.html]</span>
<div class="description">
*# The [http://microformats.org/wiki/haudio#Complete_Album_Example recommended use of "position" in hAudio] is contrary to the good practice, semantic use of ordered lists (see example and suggested solution in the above e-mail; also [http://microformats.org/discuss/mail/microformats-new/2008-January/001338.html] et seq)
*#* For Cognition I'm considering an extension: if no position has been explicitly marked up, and the item is <code><li class="item"></code> within an ordered list, then the position is taken to be the numerical value of the list marker. (To calculate the numerical value for the list marker, find the most recent sibling <code><li></code> element which has a <code>value</code> attribute. The numerical value is the number in that value attribute added to the count of <code><li></code> elements after that value attribute up to the current one. If there are no such <code><li></code> elements with <code>value</code> attributes, then you should assume that the <code>value</code> attribute of the first list item is equal to the <code>start</code> attribute of the ordered list itself, or "1" if there is no such <code>start</code> attribute. [[User:TobyInk|TobyInk]] 04:24, 29 Jul 2008 (PDT)
*#* A Proposed Resolution was made in this email: ( http://microformats.org/discuss/mail/microformats-new/2008-August/001751.html)
*#* ACCEPTED ISSUE The hAudio Position Specification is to be changed to:
*#** The element is identified by the class name |position|.
*#** hAudio /MAY/ include one |position| element.
*#** The contents of the element /MUST/ be a number or other sequential identifier.
*#** The sequential identifier /MAY/ be specified out-of-sequence.
*#* ADDED:
*#** The sequential identifier /MAY/ be specified out-of-sequence.
*#**# As proposed By [[User:ManuSporny|Manu Sporny]] in http://microformats.org/discuss/mail/microformats-new/2008-August/001708.html
*#* [[User:AndyMabbett|Andy Mabbett]] also Expressed concerns that the [[haudio#Complete_Album_Example|Complete Album Example]] should be marked up as an ordered list this is unnecessary as <code>"position"</code> is not related to the order of a track item in a list.
*#* A tutorial on the correct use of semantic ordered lists and hAudio is to be added to the [[haudio-authoring|hAudio Authoring]] Page
</div>
</div>

=== D4: 2008-01-10 rel-enclosure does not allow for links to streaming files ===
<div class="vevent">
* {{ResolvedIssue}} D4: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html microformats-discuss/2008-January/011344.html]</span>
<div class="description">
*# The required use of [[rel-enclosure]] does not allow for links to streaming files, which are not cacheable, and are thus outside the scope of rel-enclosure. [http://www.bbc.co.uk/radio4/science/livingworld_20041121.shtml An example on the BBC website] has the relevant link is below the heading "LISTEN AGAIN". (see discussion at [http://microformats.org/discuss/mail/microformats-new/2008-January/001339.html microformats-new/2008-January/001339.html] et seq).
*#* A proposal for this issue was first made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001715.html
*#* A second proposal for this issue has been made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001727.html
*#* This can potentially be solved by recognition of downloadable/streamable MIME types. For performance reasons it is undesirable for parsers to be required to make HTTP requests for each file to determine its MIME type, so authors should be encouraged to include the MIME type in the <code>type</code> attribute. See the [[haudio-brainstorming#Download_links|related section on "brainstorming"]]. [[User:TobyInk|TobyInk]] 14:41, 20 Aug 2008 (PDT)
*#* ACCEPTED ISSUE The hAudio Enclosure Specification is to be changed to:
*#** The element is identified by a URI fitting the rel-design-pattern, the rel content being enclosure.
*#** hAudio MAY include one or more enclosure URIs.
*#** The type of the file SHOULD be specified by using the type specifier for a URI.
*#* CHANGED:
*#** The type of the file MAY be specified by using the type specifier for a URI.
*#*** As suggested by [[User:Tantek|Tantek Çelik]] in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001731.html
*#*** As Proposed by [[User:TobyInk|Toby Inkster]] on 14:41, 20 Aug 2008 (PDT)
*#* A tutorial on the importance of Type Specifiers and hAudio Enclosures is to be added to the [[haudio-authoring|hAudio Authoring]] Page
</div>
</div>

=== D5: 2008-01-10 there is no way of linking to an interim page ===
<div class="vevent">
* {{OpenIssue}} D5: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011344.html microformats-discuss/2008-January/011344.html]</span>
<div class="description">
*# There appears to be no mechanism to mark up an hAudio, expressed in plain text on page A, which links to an interim page, B, which in turn links to a file download. For example, the radio shows listed on [http://www.westmidlandbirdclub.com/bibliography/radio].
</div>
</div>

=== D6: 2008-01-10 hAudio notes inconsistency ===
<div class="vevent">
* {{ResolvedIssue}} D6: <span class="summary vcard"><span class="dtstart">2008-01-10</span> raised by <span class="fn">[[User:AndyMabbett|Andy Mabbett]]</span> in [http://microformats.org/discuss/mail/microformats-discuss/2008-January/011345.html microformats-discuss/2008-January/011345.html]</span>
<div class="description">
*# [[haudio#Notes|The "Notes" section of the hAudio spec]] says "By marking up audio content with the hAudio microformat, the expectation is communicated that information about the content {{may}} be indexed. This has no impact on the copyright of the content itself which the publisher may explicitly specify using rel-license as specified above.". However, that is the first and only reference to [[rel-license]] on the page.
*#* Typing error changed to "By marking up audio content with the hAudio microformat, the expectation is communicated that information about the content MAY be indexed. This has no impact on the copyright of the content itself which the publisher may explicitly specify using the rel-license microformat". [http://microformats.org/wiki?title=haudio&diff=0&oldid=27951]
*#* hAudio Specification SHOULD include the [[rel-license]] microformat [[User:WebOrganics|Martin McEvoy]] 11:57, 18 Aug 2008 (GMT)
*#* A proposed resolution to this issue has been made in this email http://microformats.org/discuss/mail/microformats-new/2008-August/001720.html
*# RESOLVED <code>rel="licence"</code> is not part of this version of hAudio (0.9) see:http://microformats.org/discuss/mail/microformats-new/2008-August/001747.html
</div>
</div>

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

==see also==
*[[audio-info-issues]]

==related pages==
{{haudio-related-pages}}

haudio-issues

2008-09-01T20:30:05Z

ManuSporny: /* D2: 2008-01-10 hAudio Title was Overloading "fn". */

namespaces-inconsistency-issue

2008-02-05T15:59:00Z

ManuSporny: /* Brief Definitions */

2008-01-04T05:11:19Z

ManuSporny: Added JSON serialization for opera example

{{TOC-right}}

== Introduction ==

This page contains ongoing research into serialization mechanisms for hAudio semantic objects. Note that this is not part of the hAudio specification, it is a developer note on how to properly serialize hAudio semantic objects across all semantic markup languages (Microformats, eRDF and RDFa). The goal is to allow easy inter-operation of applications that produce and consume hAudio semantic data. [[User:ManuSporny|ManuSporny]] 19:37, 3 Jan 2008 (PST)

== Why JSON? ==

JSON is a very simple object representation format that can be produced from and read by almost all programming languages. There are many JSON libraries available for all the popular languages including C, C++, Java, C#, PHP, Javascript, Perl, Python, and Ruby.

It is easy to produce, easy to read, terse, and human-readable.

== Inspiration ==

The method of mapping the hAudio Microformat to RDF and back can be found on the [http://wiki.digitalbazaar.com/en/Mapping-ufs-to-rdfa#hAudio_uF_and_hAudio_RDFa Digital Bazaar hAudio Mapping page].

Much of the JSON RDF representation work was done by Keith Alexander, for more information on the thought process behind this representation format [http://n2.talis.com/wiki/RDF_JSON_Specification RDF-JSON Specification]

== JSON Serialization Examples ==

These examples show simple HTML, the Microformatted HTML, and the resulting JSON serialization.

=== Simple Song Example ===

Display:

Start Wearing Purple by Gogol Bordello

Microformatted XHTML:

<pre>
<div class="haudio">
<span class="fn">Start Wearing Purple</span> by
<span class="contributor">Gogol Bordello</span>
</div>
</pre>

RDF-based JSON representation:

<pre>
{
"_:haudio1" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "Start Wearing Purple", "type" : "literal", "lang" : "en" }
],
"http://purl.org/dc/elements/1.1/contributor" :
[
{ "value" : "Gogol Bordello", "type" : "literal", "lang" : "en" }
]
}
}
</pre>

Pure Microformat JSON representation:

<pre>
{
"haudio1":
{
"fn" :
[
{ "value" : "Start Wearing Purple", "type" : "literal", "lang" : "en" }
],
"contributor" :
[
{ "value" : "Gogol Bordello", "type" : "literal", "lang" : "en" }
]
}
}
</pre>

=== Speech Example ===

Display:

I Have a Dream, a speech by Martin Luther King Jr.

Microformatted XHTML:
<pre>
<div class="haudio">
<span class="fn">I Have a Dream</span>, a
<span class="category">speech</span> by
<span class="contributor">Martin Luther King, Jr.</span>
</div>
</pre>

RDF-based JSON representation:

<pre>
{
"_:haudio1" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "I Have a Dream", "type" : "literal", "lang" : "en" }
],
"http://purl.org/dc/elements/1.1/type" :
[
{ "value" : "speech", "type" : "literal", "lang" : "en" }
],
"http://purl.org/dc/elements/1.1/contributor" :
[
{ "value" : "Martin Luther King, Jr.", "type" : "literal", "lang" : "en" }
]
}
}
</pre>

Pure Microformat JSON representation:

<pre>
{
"haudio1":
{
"fn" :
[
{ "value" : "I Have a Dream", "type" : "literal", "lang" : "en" }
],
"category" :
[
{ "value" : "speech", "type" : "literal", "lang" : "en" }
],
"contributor" :
[
{ "value" : "Martin Luther King, Jr.", "type" : "literal", "lang" : "en" }
]
}
}
</pre>

=== Song and Album Example ===

Display:

Start Wearing Purple by Gogol Bordello found on Underdog World Strike

Microformatted XHTML:

<pre>
<div class="haudio">
<span class="fn">Start Wearing Purple</span> by
<span class="contributor">Gogol Bordello</span>
found on
<span class="album">Underdog World Strike</span>
</div>
</pre>

RDF-based JSON representation:

<pre>
{
"_:haudio1" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Album", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "Start Wearing Purple", "type" : "literal", "lang" : "en" }
],
"http://purl.org/dc/elements/1.1/contributor" :
[
{ "value" : "Gogol Bordello", "type" : "literal", "lang" : "en" }
],
"http://xmlns.com/hmedia/1.0/contains" :
[
{ "value" : "_:haudio2", "type" : "bnode" }
]
},
"_:haudio2" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "Start Wearing Purple", "type" : "literal", "lang" : "en" }
],
"http://purl.org/dc/elements/1.1/contributor" :
[
{ "value" : "Gogol Bordello", "type" : "literal", "lang" : "en" }
]
}
}
</pre>

Pure Microformat JSON representation:

<pre>
{
"haudio1":
{
"fn" :
[
{ "value" : "Start Wearing Purple", "type" : "literal", "lang" : "en" }
],
"contributor" :
[
{ "value" : "Gogol Bordello", "type" : "literal", "lang" : "en" }
]
"album" :
[
{ "value" : "Underdog World Strike", "type" : "literal", "lang" : "en" }
]
}
}
</pre>

=== Complete Album Example ===

An example that uses every element of hAudio:

[Image] Live Phish, Volume 15 by Phish<br/>
Released: October 31, 2002<br/>
Acquire: Sample, Live Recording, Buy High Quality Track<br/>
Category: [http://www.example.org/tags/live live]<br/>
Duration: 145 minutes, 27 seconds<br/>
Price: $14.99<br/>
<br/>
Tracks:<br/>
1. Sanity (5:48)<br/>
2. Highway To Hell (3:39)

Here is the hAudio Microformat markup:

<pre>
<div class="haudio">
<img class="photo" src="images/live_phish_vol_15.jpg" alt="" />
<span class="album">Live Phish, Volume 15</span>
<span class="contributor">
<span class="vcard">
<span class="fn org">Phish</span>
</span>
</span>
<br/>
Released on:
<abbr class="published" title="2002-10-31">October 31, 2002</abbr>
<br/>
Acquire:
<a rel="sample" href="/samples/live_phish_vol_15_sample.mp3">Sample</a>,
<a rel="enclosure" href="/live/phish_live_phish_vol_15.mp3">Live Recording</a>,
<a rel="payment" href="/buy/phish_live_phish_vol_15">Buy High Quality Track</a>
Category: <a class="category" rel="tag" href="http://www.example.org/tags/live">live</a>
Duration: <abbr class="duration" title="PT145M27S">145 minutes, 27 seconds</abbr>
Price: <div class="price"><abbr class="currency" title="USD 14.99">$14.99</abbr></div>
Tracks:
<div class="item">
<span class="position">1</span>.
<span class="fn">Sanity</span>
(<abbr class="duration" title="PT5M48S">5:48</abbr>)
</div>
<div class="item">
<span class="position">2</span>.
<span class="fn">Highway To Hell</span>
(<abbr class="duration" title="PT3M39S">3:39</abbr>)
</div>
</div>
</pre>

RDF-based JSON representation:

<pre>
{
"_:haudio1" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Album", "type" : "uri"}
],
"http://xmlns.com/hmedia/1.0/depiction" :
[
{ "value" : "http://www.example.org/images/live_phish_vol_15.jpg", "type" : "uri" }
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "Live Phish, Volume 15", "type" : "literal", "lang" : "en" }
],
"http://purl.org/dc/elements/1.1/contributor" :
[
{ "value" : "_:vcard1", "type" : "bnode"}
],
"http://purl.org/dc/elements/1.1/date" :
[
{ "value" : "2002-10-31", "type" : "http://www.w3.org/2001/XMLSchema#date", "lang" : "en" }
],
"http://xmlns.com/hmedia/1.0/sample" :
[
{ "value" : "http://www.example.org/samples/live_phish_vol_15_sample.mp3", "type" : "uri" }
],
"http://xmlns.com/hmedia/1.0/download" :
[
{ "value" : "http://www.example.org/live/phish_live_phish_vol_15.mp3", "type" : "uri" }
],
"http://xmlns.com/commerce/1.0/payment" :
[
{ "value" : "http://www.example.org/buy/phish_live_phish_vol_15", "type" : "uri" }
],
"http://purl.org/dc/elements/1.1/type" :
[
{ "value" : "live", "type" : "literal", "lang" : "en" }
],
"http://xmlns.com/hmedia/1.0/duration" :
[
{ "value" : "PT145M27S", "type" : "literal", "lang" : "en" }
],
"http://xmlns.com/commerce/1.0/price" :
[
{ "value" : "USD 14.99", "type" : "literal", "lang" : "en" }
],
"http://xmlns.com/hmedia/1.0/contains" :
[
{ "value" : "_:haudio2", "type" : "bnode" }
],
"http://xmlns.com/hmedia/1.0/contains" :
[
{ "value" : "_:haudio3", "type" : "bnode" }
]
},
"_:vcard1" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://www.w3.org/2001/vcard-rdf/3.0", "type" : "uri"}
],
"http://www.w3.org/2001/vcard-rdf/3.0#FN" :
[
{ "value" : "Phish", "type" : "literal", "lang" : "en" }
],
"http://www.w3.org/2001/vcard-rdf/3.0#ORG" :
[
{ "value" : "Phish", "type" : "literal", "lang" : "en" }
],

},
"_:haudio2" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://xmlns.com/hmedia/1.0/position" :
[
{ "value" : "1", "type" : "literal", "lang" : "en" }
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "Sanity", "type" : "literal", "lang" : "en" }
],
"http://xmlns.com/hmedia/1.0/duration" :
[
{ "value" : "PT5M48S", "type" : "literal", "lang" : "en" }
],
},
"_:haudio3" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://xmlns.com/hmedia/1.0/position" :
[
{ "value" : "2", "type" : "literal", "lang" : "en" }
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "Highway to Hell", "type" : "literal", "lang" : "en" }
],
"http://xmlns.com/hmedia/1.0/duration" :
[
{ "value" : "PT3M39S", "type" : "literal", "lang" : "en" }
],
}
}
</pre>

Pure Microformat JSON representation:

<pre>
{
"haudio1" :
{
"photo" :
[
{ "value" : "http://www.example.org/images/live_phish_vol_15.jpg", "type" : "uri" }
],
"fn" :
[
{ "value" : "Live Phish, Volume 15", "type" : "literal", "lang" : "en" }
],
"contributor" :
[
{
"vcard1" :
{
"fn" :
[
{ "value" : "Phish", "type" : "literal", "lang" : "en" }
],
"org" :
[
{ "value" : "Phish", "type" : "literal", "lang" : "en" }
]
}
}
],
"published" :
[
{ "value" : "2002-10-31", "type" : "literal", "lang" : "en" }
],
"sample" :
[
{ "value" : "http://www.example.org/samples/live_phish_vol_15_sample.mp3", "type" : "uri" }
],
"enclosure" :
[
{ "value" : "http://www.example.org/live/phish_live_phish_vol_15.mp3", "type" : "uri" }
],
"payment" :
[
{ "value" : "http://www.example.org/buy/phish_live_phish_vol_15", "type" : "uri" }
],
"category" :
[
{ "value" : "live", "type" : "literal", "lang" : "en" }
],
"duration" :
[
{ "value" : "PT145M27S", "type" : "literal", "lang" : "en" }
],
"price" :
[
{ "value" : "USD 14.99", "type" : "literal", "lang" : "en" }
],
"item" :
[
{
"position" :
[
{ "value" : "1", "type" : "literal", "lang" : "en" }
],
"fn" :
[
{ "value" : "Sanity", "type" : "literal", "lang" : "en" }
],
"duration" :
[
{ "value" : "PT5M48S", "type" : "literal", "lang" : "en" }
],
},
{
"position" :
[
{ "value" : "2", "type" : "literal", "lang" : "en" }
],
"fn" :
[
{ "value" : "Highway to Hell", "type" : "literal", "lang" : "en" }
],
"duration" :
[
{ "value" : "PT3M39S", "type" : "literal", "lang" : "en" }
],
}
]
}
}
</pre>

=== Multi-part Podcast Example ===

DigitalPlanet Podcast: 29 Oct 07

Forensic computing: is it really possible to delete data from your machine? Grand plans for getting broadband into Africa, checking out the sky at night via the internet and answering your emails to the programme.

Download MP3

<pre>
<div class="haudio">
<p>
<span class="fn">DigitalPlanet Podcast</span>
:
<abbr class="published" title="20071029">29 Oct 07</abbr>
</p>
<p>
<div class="item">
<span class="fn">Forensic computing: is it really possible to delete data from your machine?</span>
</div>
<div class="item">
<span class="fn">Grand plans for getting broadband into Africa</span>
</div>
,
<div class="item">
<span class="fn">checking out the sky at night via the internet</span>
</div>
and
<div class="item">
<span class="fn">answering your emails</span>
</div>
to the programme.
</p>
<p>
<a rel="enclosure" href="/download/episode/DigitalPlanet-2007-10-29">Download MP3</a>
</p>
</div>
</pre>

<pre>
{
"_:haudio1" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "DigitalPlanet Podcast", "type" : "literal", "lang" : "en" }
],
"http://purl.org/dc/elements/1.1/date" :
[
{ "value" : "2002-10-31", "type" : "http://www.w3.org/2001/XMLSchema#date", "lang" : "en" }
],
"http://xmlns.com/hmedia/1.0/download" :
[
{ "value" : "http://www.example.org/download/episode/DigitalPlanet-2007-10-29", "type" : "uri" }
],
"http://xmlns.com/hmedia/1.0/contains" :
[
{ "value" : "_:haudio2", "type" : "bnode" }
],
"http://xmlns.com/hmedia/1.0/contains" :
[
{ "value" : "_:haudio3", "type" : "bnode" }
],
"http://xmlns.com/hmedia/1.0/contains" :
[
{ "value" : "_:haudio4", "type" : "bnode" }
],
"http://xmlns.com/hmedia/1.0/contains" :
[
{ "value" : "_:haudio5", "type" : "bnode" }
]
},
"_:haudio2" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "Forensic computing: is it really possible to delete data from your machine?", "type" : "literal", "lang" : "en" }
],
},
"_:haudio3" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "Grand plans for getting broadband into Africa", "type" : "literal", "lang" : "en" }
],
},
"_:haudio4" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "checking out the sky at night via the internet", "type" : "literal", "lang" : "en" }
],
},
"_:haudio5" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "answering your emails", "type" : "literal", "lang" : "en" }
]
}
}
</pre>

Pure Microformat JSON representation:

<pre>
{
"haudio1" :
{
"fn" :
[
{ "value" : "DigitalPlanet Podcast", "type" : "literal", "lang" : "en" }
],
"published" :
[
{ "value" : "2002-10-31", "type" : "http://www.w3.org/2001/XMLSchema#date", "lang" : "en" }
],
"enclosure" :
[
{ "value" : "http://www.example.org/download/episode/DigitalPlanet-2007-10-29", "type" : "uri" }
],
"item" :
[
{
"fn" :
[
{ "value" : "Forensic computing: is it really possible to delete data from your machine?", "type" : "literal", "lang" : "en" }
],
},
{
"fn" :
[
{ "value" : "Grand plans for getting broadband into Africa", "type" : "literal", "lang" : "en" }
],
},
{
"fn" :
[
{ "value" : "checking out the sky at night via the internet", "type" : "literal", "lang" : "en" }
],
},
{
"fn" :
[
{ "value" : "answering your emails", "type" : "literal", "lang" : "en" }
]
}
]
},
}
</pre>

=== Opera Example ===

La Bohème is an opera in four acts by Giacomo Puccini to an Italian libretto by Luigi Illica and Giuseppe Giacosais. I saw it performed last week and found Act III to be pretty interesting, especially the "Sa dirmi, scusi" and "O buon Marcello, aiuto!" arias.

<pre>
<div class="haudio" lang="en">
<span class="fn" lang="it">La Bohème</span>
is an
<span class="category">opera</span>
in four acts by
<span class="contributor" lang="it">Giacomo Puccini</span>
to an
<span class="category">Italian liberetto</span>
by
<span class="contributor" lang="it">Luigi Illica</span>
and
<span class="contributor" lang="it">Giuseppe Giacosais</span>.
I saw it performed last week and found
<div class="item">
<span class="fn">Act III</span>
to be pretty interesting, especially the
<div class="item">
"<span class="fn" lang="it">Sa dirmi, scusi</span>"
</div>
and
<div class="item">
"<span class="fn" lang="it">O buon Marcello, aiuto!</span>"
</div>
arias.
</div>
</div>
</pre>

RDF-based JSON representation:

<pre>
{
"_:haudio1" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "La Bohème", "type" : "literal", "lang" : "it" }
],
"http://purl.org/dc/elements/1.1/contributor" :
[
{ "value" : "Giacomo Puccini", "type" : "literal", "lang" : "it" },
{ "value" : "Luigi Illica", "type" : "literal", "lang" : "it" },
{ "value" : "Giuseppe Giacosais", "type" : "literal", "lang" : "it" }
],
"http://purl.org/dc/elements/1.1/type" :
[
{ "value" : "opera", "type" : "literal", "lang" : "en" },
{ "value" : "Italian liberetto", "type" : "literal", "lang" : "en" }
],
"http://xmlns.com/hmedia/1.0/contains" :
[
{ "value" : "_:haudio2", "type" : "bnode" }
]
},
"_:haudio2" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "Act III", "type" : "literal", "lang" : "en" }
],
"http://xmlns.com/hmedia/1.0/contains" :
[
{ "value" : "_:haudio3", "type" : "bnode" },
]
"http://xmlns.com/hmedia/1.0/contains" :
[
{ "value" : "_:haudio4", "type" : "bnode" }
]
},
"_:haudio3" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "Sa dirmi, scusi", "type" : "literal", "lang" : "it" }
]
}
"_:haudio4" :
{
"http://www.w3.org/1999/02/22-rdf-syntax-ns#type" :
[
{ "value" : "http://xmlns.com/haudio/1.0/Recording", "type" : "uri"}
],
"http://purl.org/dc/elements/1.1/title" :
[
{ "value" : "O buon Marcello, aiuto!", "type" : "literal", "lang" : "it" }
]
}
}
</pre>

Pure Microformat JSON representation:

<pre>
{
"haudio1" :
{
"fn" :
[
{ "value" : "La Bohème", "type" : "literal", "lang" : "it" }
],
"contributor" :
[
{ "value" : "Giacomo Puccini", "type" : "literal", "lang" : "it" },
{ "value" : "Luigi Illica", "type" : "literal", "lang" : "it" },
{ "value" : "Giuseppe Giacosais", "type" : "literal", "lang" : "it" }
],
"category" :
[
{ "value" : "opera", "type" : "literal", "lang" : "en" },
{ "value" : "Italian liberetto", "type" : "literal", "lang" : "en" }
],
"item" :
[
{
"fn" :
[
{ "value" : "Act III", "type" : "literal", "lang" : "en" }
],
"item" :
[
{
"fn" :
[
{ "value" : "Sa dirmi, scusi", "type" : "literal", "lang" : "it" }
]
},
{
"fn" :
[
{ "value" : "O buon Marcello, aiuto!", "type" : "literal", "lang" : "it" }
]
}
]
}
]
}
}
</pre>