Microformats Wiki - User contributions [en]

getting-started

2006-02-15T05:06:42Z

MarkRickerby: made start on addressing individual audiences

''This is aimed specifically at an audience of designers and IA's, not programmers, so excuse the non-technical language. Trying not to be too contrived or patronizing but it is a fine line, that I'll hopefully nail a bit better after a re-edit - [[MarkRickerby]]''

= Getting Started with Microformats (Draft) =

Microformats are based on simple markup conventions that enable you to add meaningful structure to your web content.

One of the key principles of Microformats, is to privelege [[humans-first|human readable]] content. This means that you should think first and foremost of your content design being readable and accessible to web viewers. Using the [[design-principles|most appropriate HTML elements]] and applying structured [[class-design-pattern|class names]] to your markup enables you to produce content that can be clearly understood by a human audience and also used in a structured way by automated programs and other online tools. But the point is that you shouldn't have to go out of your way to produce such machine friendly markup - Microformats make it easy to integrate this greater degree of structure into your websites, without the overhead of having to learn complicated new languages or formats.

== For Publishers ==

What can Microformats do for publishers?

== For Developers ==

What can Microformats do for developers?

== For Designers ==

What can Microformats do for designers?

== Moving to Microformats: A 5 Minute Primer ==

The best way to understand Microformats is to start using them straight away. Since they're embedded in ordinary HTML, you can take existing pages and add these structured class names to the markup, but it's recommended that when doing this, you also take a close look at the overall tag structure that you're using - maybe there is a better way to say what you mean using basic HTML tags.

A simple, and very popular place to start is with [[hcard|hCard]] - a microformat for displaying personal and organizational contact details. You can think of [[hcard|hCard]] as a way to embed mini business cards in web pages, but glancing over the [[hcard-examples|examples]] shows a lot more possibilities than just that.

Let's imagine a static page that contains some personal contact details, the main part of which looks something like:

<pre>
<nowiki>
<div id="contact">
<h2>Contact Me</h2>
<p>You can contact me via email to <a href="mailto:jane@example.com">jane@example.com</a>, or send stuff to me at the following address:</p>
<p>255 Some Street,<br />
Some Place,<br />
Some Town</p>
</div>
</nowiki>
</pre>

This snippet has all the human readable information needed to produce a valid [[hcard|hCard]] representation - all that is necessary is to add some additional structure that defines each particular detail. The first thing to do is to add the <code>vcard</code> wrapper class to the enclosing <code>div</code>, which identifies this particular block as an [[hcard|hCard]]:

<pre><nowiki>
<div id="contact" class="vcard">
</nowiki></pre>

One thing that is noticeably missing from this snippet is the full name of who these contact details apply to - this makes the information presented more ambiguous and harder to understand. It's good to be explicit with such things, and it just so happens that the full name property is a compulsory field within an [[hcard|hCard]] as well. So let's add it, using the <code>fn</code> class:

<pre><nowiki>
<div id="contact" class="vcard">
<h2>Contact Me</h2>
<h3 class="fn">Jane Doe</h3>
<p>You can contact me via email to <a href="mailto:jane@example.com">jane@example.com</a>, or reach me at the following address:</p>
<p>255 Some Street,<br />
Some Town,<br />
Some Place</p>
</div>
</nowiki></pre>

Another thing we can do to improve the semantics of the snippet is to add an <code>address</code> tag. This isn't strictly part of the [[hcard|hCard]] format itself, but it is good practice to use it to display contact details like this. At the same time, we should also get rid of the [http://tantek.com/log/2002/10.html#L20021022t1432 bed & breakfast] markup in the second paragraph, replacing it with structured classnames for the components of a mailing address: <code>adr</code>, <code>street-address</code>, <code>locality</code>, and <code>region</code>. We can also add the <code>email</code> class to the mailto link, to complete the structure of the [[hcard|hCard]]:

<pre><nowiki>
<div id="contact" class="vcard">
<h2>Contact Me</h2>
<h3 class="fn">Jane Doe</h3>
<p>You can contact me via email to <a class="email" href="mailto:jane@example.com">jane@example.com</a>, or reach me at the following address:</p>
<address class="adr">
<div class="street-address">255 Some Street</div>
<div class="locality">Some Town<div/>
<div class="region">Some Place</div>
</address>
</div>
</nowiki></pre>

And that's all it takes!

Aside from the advantages of having such structured visible data, providing these additional class names also increases the visual design possibilities.

to-do

2006-02-15T01:31:10Z

MarkRickerby:

= To Do =

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

== Lazyweb ==

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

=== for all microformats ===
* quick and easy "how to" pages for each microformat. [[use]] is a good overall start.
* brief summary statements for each microformat that explain why it matters, what does it accomplish for the publisher.

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

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

== Tantek ==

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

=== iterate on current microformats ===
==== [[hreview|hReview]] ====
* Write hReview 0.3 draft and get it finalized (actively working on it!)
==== [[hcalendar|hCalendar]] ====
* create [[hcalendar-profile]] and have folks verify it.
* add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.
* need examples of multi-instance [[hcalendar|hCalendar]] events
* of repeating events
==== [[hcard|hCard]] ====
* [[hcard-examples]]
** add examples of [[hcard|hCard]]s with work telephone, mailing address etc.
** add examples of marking up an organization vs. a person, then link to it from [http://microformats.org/wiki/hcard#Organization_Contact_Info hCard spec section on Organization Contact Info].
** add example of organization-name and organization-unit usage.
* more examples in the wild
** help dglazkov markup: http://glazkov.com/blog/archive/2003/12/17/147.aspx

=== introduction / community ===
* microformats-discuss
** introductory email sent to new subscribers needs to direct people to [[process]] and [[how-to-play]]

* Need to add more to the [[naming-principles]], to cover in particular:
** avoid using the same name to mean two things
** avoid using two names to mean the same thing
** seek to keep the microformats vocabulary minimal, memorable, and usable.

=== profiles ===

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

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

=== create microformats wiki pages for ===
* microformats [[history]]
** introduction of terms (when were microformats terms introduced, by whom, etc.)
** introduction of specs (when were microformats specifications first introduced)
*** use the history on Technorati's developer wiki for evidence of earliest dates.
*** use the [[presentations]] as a source as well.

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

=== help with microformat implementations ===
* [http://microformats.org/code/hcard/creator hCard creator] - add features/fields
** email
** aim / instant messaging contact info
* wordpress improvements
** WP admin for new profiles
*** should simply read blog URL
*** look for hcards and parse them
* [http://gmpg.org/xfn/creator XFN Creator] localizations
** Get someone to verify the [http://gmpg.org/xfn/creator-ru XFN Creator Russian localization].
** Add it to the [http://gmpg.org/xfn/tools XFN Tools] page.
** Add rel="alternate" href="creator-ru" <link>s to the other XFN Creators.
* Conference Schedule Creator
** We need to ASAP build a simple conference schedule creator (and editor?) that builds upon the hCalendar creator. We should make it *trivial* for conference organizers to build/edit/publish an [[hcalendar|hCalendar]] schedule for their conference, including auto-generated "Subscribe..." link which produces the proper "webcal:..." link with X2V. Note: see the "axis" and "header" attributes in HTML4, specifically in the section on Tables.

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

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

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

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

=== *-authoring microformats wiki pages ===
* [[hcard-authoring]] - a tutorial on creating an hcard for you site, blog (common platforms), etc.
* [[hcalendar-authoring]] - a tutorial on how to blog events so your friends can subscribe to them
* [[hreview-authoring]] - a tutorial on how to blog reviews so that they'll be aggregated.
=== WordPress patches for microformats ===
* submit patches for WordPress code/templates for microformats improvements
** <address class="vcard"> improvement in post author publication (e.g. home page of http://microformats.org/ )
* Wordpress plugin for microformats, specifically hReview and hCalendar
** See [http://www.surfarama.com/index.php?p=227 lazyweb request]
=== other ===
* add an example of how to use DURATION in hcalendar see http://www.policyawareweb.org/2005/ftf2/paw-mtg#item15)

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

== Dimitri Glazkov ==

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

== Chris Messina ==

* Work on a microformat for play-lists (is it just a XOXO ordererd list of play-items?)
* Work on a microformat for play-item

=== Wishlist ===

* Microformat for "buyable items" (see [[listing-examples]] and related documents)
* Location MF -- right click "map this" (see [[geo]] and [[adr]])
* Better hCard support in the browser -- right click "IM this person...", "Add to contacts"
* Better hCal support -- support many views of same hCal data on one page using XSLT

== Robert Bachmann ==

* make hatom2atom.xsl conformant to [[hatom]].

== Brian Suda ==
=== Citation Microformats ===
Add all my notes to the Wiki

=== X2V ===
Make changes and update site (almost stable)
Get ATTENDEE and other strange attributes working

== Mark Rickerby ==

=== Current Tasks ===

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

=== Wishlist ===

* hmmm

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

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

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

== New Person 2 ==

etc.

to-do

2006-02-15T01:30:29Z

MarkRickerby: /* Current Tasks */

= To Do =

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

== Lazyweb ==

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

=== for all microformats ===
* quick and easy "how to" pages for each microformat. [[use]] is a good overall start.
* brief summary statements for each microformat that explain why it matters, what does it accomplish for the publisher.

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

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

== Tantek ==

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

=== iterate on current microformats ===
==== [[hreview|hReview]] ====
* Write hReview 0.3 draft and get it finalized (actively working on it!)
==== [[hcalendar|hCalendar]] ====
* create [[hcalendar-profile]] and have folks verify it.
* add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.
* need examples of multi-instance [[hcalendar|hCalendar]] events
* of repeating events
==== [[hcard|hCard]] ====
* [[hcard-examples]]
** add examples of [[hcard|hCard]]s with work telephone, mailing address etc.
** add examples of marking up an organization vs. a person, then link to it from [http://microformats.org/wiki/hcard#Organization_Contact_Info hCard spec section on Organization Contact Info].
** add example of organization-name and organization-unit usage.
* more examples in the wild
** help dglazkov markup: http://glazkov.com/blog/archive/2003/12/17/147.aspx

=== introduction / community ===
* microformats-discuss
** introductory email sent to new subscribers needs to direct people to [[process]] and [[how-to-play]]

* Need to add more to the [[naming-principles]], to cover in particular:
** avoid using the same name to mean two things
** avoid using two names to mean the same thing
** seek to keep the microformats vocabulary minimal, memorable, and usable.

=== profiles ===

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

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

=== create microformats wiki pages for ===
* microformats [[history]]
** introduction of terms (when were microformats terms introduced, by whom, etc.)
** introduction of specs (when were microformats specifications first introduced)
*** use the history on Technorati's developer wiki for evidence of earliest dates.
*** use the [[presentations]] as a source as well.

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

=== help with microformat implementations ===
* [http://microformats.org/code/hcard/creator hCard creator] - add features/fields
** email
** aim / instant messaging contact info
* wordpress improvements
** WP admin for new profiles
*** should simply read blog URL
*** look for hcards and parse them
* [http://gmpg.org/xfn/creator XFN Creator] localizations
** Get someone to verify the [http://gmpg.org/xfn/creator-ru XFN Creator Russian localization].
** Add it to the [http://gmpg.org/xfn/tools XFN Tools] page.
** Add rel="alternate" href="creator-ru" <link>s to the other XFN Creators.
* Conference Schedule Creator
** We need to ASAP build a simple conference schedule creator (and editor?) that builds upon the hCalendar creator. We should make it *trivial* for conference organizers to build/edit/publish an [[hcalendar|hCalendar]] schedule for their conference, including auto-generated "Subscribe..." link which produces the proper "webcal:..." link with X2V. Note: see the "axis" and "header" attributes in HTML4, specifically in the section on Tables.

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

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

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

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

=== *-authoring microformats wiki pages ===
* [[hcard-authoring]] - a tutorial on creating an hcard for you site, blog (common platforms), etc.
* [[hcalendar-authoring]] - a tutorial on how to blog events so your friends can subscribe to them
* [[hreview-authoring]] - a tutorial on how to blog reviews so that they'll be aggregated.
=== WordPress patches for microformats ===
* submit patches for WordPress code/templates for microformats improvements
** <address class="vcard"> improvement in post author publication (e.g. home page of http://microformats.org/ )
* Wordpress plugin for microformats, specifically hReview and hCalendar
** See [http://www.surfarama.com/index.php?p=227 lazyweb request]
=== other ===
* add an example of how to use DURATION in hcalendar see http://www.policyawareweb.org/2005/ftf2/paw-mtg#item15)

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

== Dimitri Glazkov ==

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

== Chris Messina ==

* Work on a microformat for play-lists (is it just a XOXO ordererd list of play-items?)
* Work on a microformat for play-item

=== Wishlist ===

* Microformat for "buyable items" (see [[listing-examples]] and related documents)
* Location MF -- right click "map this" (see [[geo]] and [[adr]])
* Better hCard support in the browser -- right click "IM this person...", "Add to contacts"
* Better hCal support -- support many views of same hCal data on one page using XSLT

== Robert Bachmann ==

* make hatom2atom.xsl conformant to [[hatom]].

== Brian Suda ==
=== Citation Microformats ===
Add all my notes to the Wiki

=== X2V ===
Make changes and update site (almost stable)
Get ATTENDEE and other strange attributes working

== Mark Rickerby ==

=== Current Tasks ===

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

== Wishlist ==

* hmmm

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

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

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

== New Person 2 ==

etc.

getting-started

2006-02-14T08:55:51Z

MarkRickerby: rough draft, needs a bit of improvement to the writing and better examples

''This is aimed specifically at an audience of designers and IA's, not programmers, so excuse the non-technical language. Trying not to be too contrived or patronizing but it is a fine line, that I'll hopefully nail a bit better after a re-edit - [[MarkRickerby]]''

= Getting Started with Microformats (Draft) =

Microformats are based on simple markup conventions that enable you to add meaningful structure to your web content.

One of the key principles of Microformats, is to privelege [[humans-first|human readable]] content. This means that you should think first and foremost of your content design being readable and accessible to web viewers. Using the [[design-principles|most appropriate HTML elements]] and applying structured [[class-design-pattern|class names]] to your markup enables you to produce content that can be clearly understood by a human audience and also used in a structured way by automated programs and other online tools. But the point is that you shouldn't have to go out of your way to produce such machine friendly markup - Microformats make it easy to integrate this greater degree of structure into your websites, without the overhead of having to learn complicated new languages or formats.

== Moving to Microformats: A 5 Minute Primer ==

The best way to understand Microformats is to start using them straight away. Since they're embedded in ordinary HTML, you can take existing pages and add these structured class names to the markup, but it's recommended that when doing this, you also take a close look at the overall tag structure that you're using - maybe there is a better way to say what you mean using basic HTML tags.

A simple, and very popular place to start is with [[hcard|hCard]] - a microformat for displaying personal and organizational contact details. You can think of [[hcard|hCard]] as a way to embed mini business cards in web pages, but glancing over the [[hcard-examples|examples]] shows a lot more possibilities than just that.

Let's imagine a static page that contains some personal contact details, the main part of which looks something like:

<pre>
<nowiki>
<div id="contact">
<h2>Contact Me</h2>
<p>You can contact me via email to <a href="mailto:jane@example.com">jane@example.com</a>, or send stuff to me at the following address:</p>
<p>255 Some Street,<br />
Some Place,<br />
Some Town</p>
</div>
</nowiki>
</pre>

This snippet has all the human readable information needed to produce a valid [[hcard|hCard]] representation - all that is necessary is to add some additional structure that defines each particular detail. The first thing to do is to add the <code>vcard</code> wrapper class to the enclosing <code>div</code>, which identifies this particular block as an [[hcard|hCard]]:

<pre><nowiki>
<div id="contact" class="vcard">
</nowiki></pre>

One thing that is noticeably missing from this snippet is the full name of who these contact details apply to - this makes the information presented more ambiguous and harder to understand. It's good to be explicit with such things, and it just so happens that the full name property is a compulsory field within an [[hcard|hCard]] as well. So let's add it, using the <code>fn</code> class:

<pre><nowiki>
<div id="contact" class="vcard">
<h2>Contact Me</h2>
<h3 class="fn">Jane Doe</h3>
<p>You can contact me via email to <a href="mailto:jane@example.com">jane@example.com</a>, or reach me at the following address:</p>
<p>255 Some Street,<br />
Some Town,<br />
Some Place</p>
</div>
</nowiki></pre>

Another thing we can do to improve the semantics of the snippet is to add an <code>address</code> tag. This isn't strictly part of the [[hcard|hCard]] format itself, but it is good practice to use it to display contact details like this. At the same time, we should also get rid of the [http://tantek.com/log/2002/10.html#L20021022t1432 bed & breakfast] markup in the second paragraph, replacing it with structured classnames for the components of a mailing address: <code>adr</code>, <code>street-address</code>, <code>locality</code>, and <code>region</code>. We can also add the <code>email</code> class to the mailto link, to complete the structure of the [[hcard|hCard]]:

<pre><nowiki>
<div id="contact" class="vcard">
<h2>Contact Me</h2>
<h3 class="fn">Jane Doe</h3>
<p>You can contact me via email to <a class="email" href="mailto:jane@example.com">jane@example.com</a>, or reach me at the following address:</p>
<address class="adr">
<div class="street-address">255 Some Street</div>
<div class="locality">Some Town<div/>
<div class="region">Some Place</div>
</address>
</div>
</nowiki></pre>

And that's all it takes!

Aside from the advantages of having such structured visible data, providing these additional class names also increases the visual design possibilities.

rest/datatypes

2006-02-14T07:30:43Z

MarkRickerby: /* Analysis */

<h1> Datatypes in HTML </h1>
One of the challenges of using HTML as a data transport is that everything, by default, is a string. This page explores ways to use microformats -- specifically, class names -- to encode data type information, e.g., for use with [[xoxo]] and [[rest/ahah]], in order to allow lossless import/export from various languages. These could also be used with forms to provide [[rest/description]]s of the type of data expected.

__TOC__

== Contributors ==
* Dr. Ernie Prabhakar
* Chris RG
* Mark Rickerby
* Robert Bachmann
* Kevin Marks
* Tantek Çelik

== Examples ==

These are the primary datatypes in a range of different languages and formats. Note that we are only concerned with "primitive" datatypes (loosely defined), as structured datatypes (list/array, hash/dictionary) are handled by [[xoxo]].

{| border="1" cellpadding="2"
|+Datatype comparison table
|-
! Language/format !! string !! float !! integer !! boolean !! data || date/time || null
|-
! [http://www.w3.org/TR/xmlschema-2/#built-in-datatypes XML Schema]
| string || float, double || decimal, integer, etc. || boolean || hexBinary, base64Binary || duration, dateTime, date, time || nil
|-
! [http://ws.apache.org/xmlrpc/types.html XML-RPC]
| string || double || i4, int|| boolean || base64 || dateTime.iso8601 || nil
|-
! [http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Concepts/XMLPListsConcept.html Mac OS X plists]
| string || real || integer || true, false || data || date || nil
|-
! [http://www.crockford.com/JSON JSON] (JavaScript)
| string || number || number || true, false || N/A || Date || nil
|-
! [http://yaml.org/spec/current.html#id2503753 YAML] tags
| str || int || float || bool || null (base 64) || N/A || null
|-
! [http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html#table1 SQL (JDBC)]
| char,varchar || float, double, real || decimal, numeric || bit || binary || date, time, timestamp || ?
|-
! [http://www.sysprog.net/ctype.html C]
| char[] || float, double || int, long, short || bool, int || char[] || N/A || (void*)0
|-
! [http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html Java]
| char, String || float, double || int, long, short, byte || boolean || N/A || util.Date || null
|-
! [http://www.zend.com/manual/language.types.php PHP]
| string || float (double)|| integer || boolean || array || N/A || NULL
|-
! [http://search.cpan.org/dist/perl/pod/perldata.pod Perl]
| array || scalar || scalar || scalar || array || N/A
|-
! [http://en.wikibooks.org/wiki/Programming:Python_Numbers Python]
| str || float, complex || int, long || bool || binascii, base64 || time,datetime
|-
! [http://www.rubycentral.com/book/ext_ruby.html Ruby] + [http://www.rubycentral.com/book/lib_standard.html lib]
| String || Float || Fixnum, Bignum || TrueClass,FalseClass || Hash || Date || NilClass
|-
! [http://www.rebol.com/docs/core23/rebolcore-16.html REBOL]
| string! || decimal! || integer! || logic! || binary! || date!, time! || none!
|-
|}

== Analysis ==
The most common set of datatypes appears to be those represented by XML-RPC, which (perhaps fortunately) also has historical precedence on the web:
* string
* double
* int [i4] - 4-byte integer (32-bit)
* boolean (0,1)
* base64
** Lets call this 'binary' as the encoding is in the data: url, and DRY applies
** RFC 2426 uses "B", which, when lowercased per microformats [[naming-principles]] is 'b'. -Tantek
* dateTime[.iso8601]

Whlle not perfect, these certainly cover the 80% case, and are reasonably well-defined. That said, there are a number of open questions about how to use them:
# should 'string' also be explicitly specified, or can it be assumed?
#*Assumed, and also defined as utf-8. [[User:Kevin Marks|Kevin Marks]] 16:39, 13 Feb 2006 (PST)
#*Agreed with Kevin. 'string' should be the default if no type is specified. Publishers MAY explicitly specify 'string'.
# does 'int' always mean 32-bits?
## If so, what should be used for 64-bit integers or cryptographic (256-bit+) numbers?
###Python's 'long' is simple, but ambiguous.
###Ruby's BigNum is clear but much less common.
###XML-Schema has so many types it is hard to say.
###* In this case, XML-Schema makes the distinction that 'int' represents a standard 32 bit integer, while 'integer' represents a signed integer of arbitrary length.
###SQL's "decimal", perhaps?
## If not, how should conforming implementations react to longer integers than they can handle?
##*I think integer is fine - we don't have an explict constraint here. Do you want to define +Inf -Inf and NaN behaviour? Certainly when building testcases and examples include these.

# Is it worth deviating from the standard to allow "dateTime" as an alias? (the one case where XML Schema is actually simpler)
#* See comments below regarding date-time.

== Proposal ==
The proposal is to adopt [http://www.xmlrpc.com/spec/ XML-RPC] scalar values as the class names for typed microformats, with the following caveats:
* the alias 'i4' for integer SHOULD not be used
* the name 'long' MAY be used for 64-bit or longer integers
* for 'dateTime'
** can we make this 'datetime' ? [[User:Kevin Marks|Kevin Marks]] 16:39, 13 Feb 2006 (PST)
** microformats don't use camel case. please see [[naming-principles]]. alternatives (Tantek):
*** date-time (if you consider it to be two words)
*** datetime (as proposed by Kevin, if you think it is one word)
*** dt (reusing the common prefix shared by existing microformat class names: dtstart, dtend, dtreviewed from [[hcalendar|hCalendar]] and [[hreview|hReview]]. We could also make that a general rule for microformat class names for properties which take ISO8601 datetimes. (Tantek)
** the trailing '.iso8601' MUST be omitted, as '.' is not (always?) valid in HTML class names
*** '.' is neither a valid HTML class name, nor a valid character (unescaped at least) in a CSS class selector. - Tantek
** date/time formats SHOULD follow the [http://www.w3.org/TR/NOTE-datetime W3C profile] of [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]
** a more human-readable rendering may be used, with the ISO8601 value in an "abbr"
* binary data SHOULD be encoded in a [http://en.wikipedia.org/wiki/Data:_URI_scheme data: URI], with an explicit [http://www.htmlhelp.com/reference/html40/special/a.html ContentType] and a human-readable description as the body of the anchor.
* if no datatype is specified, an implementation MAY either attempt to infer a datatype from the syntax of the value, or simply assert that the value is a string. Thus, conforming implementations SHOULD always explicitly label strings.
** Disagree - either we are labelling datatypes and thus labelling string is redundant, or we are trying to guess from syntax. If the latter this whole spec is unnecessary. [[User:Kevin Marks|Kevin Marks]] 16:39, 13 Feb 2006 (PST)
** Agreed with Kevin. Let's keep 'string' as the default, and allow explicit usage of it. -Tantek

To indicate that a particular micforomat uses typed values, precede that microformat with the class name 'typed', as in:

<pre><nowiki>
<ol class="typed xoxo">
</nowiki></pre>

== Example ==

<dl class="typed xoxo">
<dt>key</dt><dd class="string">value</dd>
<dt>integer</dt><dd class="int">137</dd>
<dt>real</dt><dd class="double">3.14159265</dd>
<dt>date</dt><dd class="dateTime">1994-11-05T13:15:30Z</dd>
<dt>date(abbr)</dt><dd class="dateTime"><abbr title="1994-11-05">November 5, 1994</abbr></dd>
<dt>true</dt><dd class="boolean">1</dd>
<dt>false</dt><dd class="boolean">0</dd>
<dt>data</dt><dd class="base64"><a href="data:;base64,sdcfo2JTiXE=" type="image/jpg">my image</a></dd>
</dl>

Example revised with above suggestions:

<dl class="typed xoxo">
<dt>key</dt><dd>value</dd>
<dt>integer</dt><dd class="int">137</dd>
<dt>real</dt><dd class="double">3.14159265</dd>
<dt>date</dt><dd class="datetime">1994-11-05T13:15:30Z</dd>
<dt>date(abbr)</dt><dd class="datetime"><abbr title="1994-11-05">November 5, 1994</abbr></dd>
<dt>true</dt><dd class="boolean">1</dd>
<dt>false</dt><dd class="boolean">0</dd>
<dt>data</dt><dd class="binary"><a href="data:;base64,sdcfo2JTiXE=" type="image/jpg">my image</a></dd>
</dl>

'''Note:''' [[xoxo|XOXO]] always starts with either <code>ol</code> or <code>ul</code>. The <code>dl</code> in XOXO is always used to declare the properties of a specific <code>li</code>. These examples should be updated accordingly. -Tantek

== References ==
* [http://en.wikipedia.org/wiki/Datatype Datatypes] in Wikipedia
* Origional [http://microformats.org/discuss/mail/microformats-discuss/2005-September/001020.html datatype] discussion
* Original [http://homepage.mac.com/drernie/plist.html plist] datatype mapping proposal
* Revised [http://opendarwin.org/~drernie/xoxo-datatypes.html xoxo datatype] proposal

== See Also ==
* [[xoxo]]
* [[naming-principles]]

rest/datatypes

2006-02-14T07:28:46Z

MarkRickerby: int tokens in XML-Schema

<h1> Datatypes in HTML </h1>
One of the challenges of using HTML as a data transport is that everything, by default, is a string. This page explores ways to use microformats -- specifically, class names -- to encode data type information, e.g., for use with [[xoxo]] and [[rest/ahah]], in order to allow lossless import/export from various languages. These could also be used with forms to provide [[rest/description]]s of the type of data expected.

__TOC__

== Contributors ==
* Dr. Ernie Prabhakar
* Chris RG
* Mark Rickerby
* Robert Bachmann
* Kevin Marks
* Tantek Çelik

== Examples ==

These are the primary datatypes in a range of different languages and formats. Note that we are only concerned with "primitive" datatypes (loosely defined), as structured datatypes (list/array, hash/dictionary) are handled by [[xoxo]].

{| border="1" cellpadding="2"
|+Datatype comparison table
|-
! Language/format !! string !! float !! integer !! boolean !! data || date/time || null
|-
! [http://www.w3.org/TR/xmlschema-2/#built-in-datatypes XML Schema]
| string || float, double || decimal, integer, etc. || boolean || hexBinary, base64Binary || duration, dateTime, date, time || nil
|-
! [http://ws.apache.org/xmlrpc/types.html XML-RPC]
| string || double || i4, int|| boolean || base64 || dateTime.iso8601 || nil
|-
! [http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Concepts/XMLPListsConcept.html Mac OS X plists]
| string || real || integer || true, false || data || date || nil
|-
! [http://www.crockford.com/JSON JSON] (JavaScript)
| string || number || number || true, false || N/A || Date || nil
|-
! [http://yaml.org/spec/current.html#id2503753 YAML] tags
| str || int || float || bool || null (base 64) || N/A || null
|-
! [http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html#table1 SQL (JDBC)]
| char,varchar || float, double, real || decimal, numeric || bit || binary || date, time, timestamp || ?
|-
! [http://www.sysprog.net/ctype.html C]
| char[] || float, double || int, long, short || bool, int || char[] || N/A || (void*)0
|-
! [http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html Java]
| char, String || float, double || int, long, short, byte || boolean || N/A || util.Date || null
|-
! [http://www.zend.com/manual/language.types.php PHP]
| string || float (double)|| integer || boolean || array || N/A || NULL
|-
! [http://search.cpan.org/dist/perl/pod/perldata.pod Perl]
| array || scalar || scalar || scalar || array || N/A
|-
! [http://en.wikibooks.org/wiki/Programming:Python_Numbers Python]
| str || float, complex || int, long || bool || binascii, base64 || time,datetime
|-
! [http://www.rubycentral.com/book/ext_ruby.html Ruby] + [http://www.rubycentral.com/book/lib_standard.html lib]
| String || Float || Fixnum, Bignum || TrueClass,FalseClass || Hash || Date || NilClass
|-
! [http://www.rebol.com/docs/core23/rebolcore-16.html REBOL]
| string! || decimal! || integer! || logic! || binary! || date!, time! || none!
|-
|}

== Analysis ==
The most common set of datatypes appears to be those represented by XML-RPC, which (perhaps fortunately) also has historical precedence on the web:
* string
* double
* int [i4] - 4-byte integer (32-bit)
* boolean (0,1)
* base64
** Lets call this 'binary' as the encoding is in the data: url, and DRY applies
** RFC 2426 uses "B", which, when lowercased per microformats [[naming-principles]] is 'b'. -Tantek
* dateTime[.iso8601]

Whlle not perfect, these certainly cover the 80% case, and are reasonably well-defined. That said, there are a number of open questions about how to use them:
# should 'string' also be explicitly specified, or can it be assumed?
#*Assumed, and also defined as utf-8. [[User:Kevin Marks|Kevin Marks]] 16:39, 13 Feb 2006 (PST)
#*Agreed with Kevin. 'string' should be the default if no type is specified. Publishers MAY explicitly specify 'string'.
# does 'int' always mean 32-bits?
## If so, what should be used for 64-bit integers or cryptographic (256-bit+) numbers?
###Python's 'long' is simple, but ambiguous.
###Ruby's BigNum is clear but much less common.
###XML-Schema has so many types it is hard to say.
#### In this case, XML-Schema makes the distinction that 'int' represents a standard 32 bit integer, while 'integer' represents a signed integer of arbitrary length.
###SQL's "decimal", perhaps?
## If not, how should conforming implementations react to longer integers than they can handle?
##*I think integer is fine - we don't have an explict constraint here. Do you want to define +Inf -Inf and NaN behaviour? Certainly when building testcases and examples include these.

# Is it worth deviating from the standard to allow "dateTime" as an alias? (the one case where XML Schema is actually simpler)
#* See comments below regarding date-time.

== Proposal ==
The proposal is to adopt [http://www.xmlrpc.com/spec/ XML-RPC] scalar values as the class names for typed microformats, with the following caveats:
* the alias 'i4' for integer SHOULD not be used
* the name 'long' MAY be used for 64-bit or longer integers
* for 'dateTime'
** can we make this 'datetime' ? [[User:Kevin Marks|Kevin Marks]] 16:39, 13 Feb 2006 (PST)
** microformats don't use camel case. please see [[naming-principles]]. alternatives (Tantek):
*** date-time (if you consider it to be two words)
*** datetime (as proposed by Kevin, if you think it is one word)
*** dt (reusing the common prefix shared by existing microformat class names: dtstart, dtend, dtreviewed from [[hcalendar|hCalendar]] and [[hreview|hReview]]. We could also make that a general rule for microformat class names for properties which take ISO8601 datetimes. (Tantek)
** the trailing '.iso8601' MUST be omitted, as '.' is not (always?) valid in HTML class names
*** '.' is neither a valid HTML class name, nor a valid character (unescaped at least) in a CSS class selector. - Tantek
** date/time formats SHOULD follow the [http://www.w3.org/TR/NOTE-datetime W3C profile] of [http://en.wikipedia.org/wiki/ISO_8601 ISO 8601]
** a more human-readable rendering may be used, with the ISO8601 value in an "abbr"
* binary data SHOULD be encoded in a [http://en.wikipedia.org/wiki/Data:_URI_scheme data: URI], with an explicit [http://www.htmlhelp.com/reference/html40/special/a.html ContentType] and a human-readable description as the body of the anchor.
* if no datatype is specified, an implementation MAY either attempt to infer a datatype from the syntax of the value, or simply assert that the value is a string. Thus, conforming implementations SHOULD always explicitly label strings.
** Disagree - either we are labelling datatypes and thus labelling string is redundant, or we are trying to guess from syntax. If the latter this whole spec is unnecessary. [[User:Kevin Marks|Kevin Marks]] 16:39, 13 Feb 2006 (PST)
** Agreed with Kevin. Let's keep 'string' as the default, and allow explicit usage of it. -Tantek

To indicate that a particular micforomat uses typed values, precede that microformat with the class name 'typed', as in:

<pre><nowiki>
<ol class="typed xoxo">
</nowiki></pre>

== Example ==

<dl class="typed xoxo">
<dt>key</dt><dd class="string">value</dd>
<dt>integer</dt><dd class="int">137</dd>
<dt>real</dt><dd class="double">3.14159265</dd>
<dt>date</dt><dd class="dateTime">1994-11-05T13:15:30Z</dd>
<dt>date(abbr)</dt><dd class="dateTime"><abbr title="1994-11-05">November 5, 1994</abbr></dd>
<dt>true</dt><dd class="boolean">1</dd>
<dt>false</dt><dd class="boolean">0</dd>
<dt>data</dt><dd class="base64"><a href="data:;base64,sdcfo2JTiXE=" type="image/jpg">my image</a></dd>
</dl>

Example revised with above suggestions:

<dl class="typed xoxo">
<dt>key</dt><dd>value</dd>
<dt>integer</dt><dd class="int">137</dd>
<dt>real</dt><dd class="double">3.14159265</dd>
<dt>date</dt><dd class="datetime">1994-11-05T13:15:30Z</dd>
<dt>date(abbr)</dt><dd class="datetime"><abbr title="1994-11-05">November 5, 1994</abbr></dd>
<dt>true</dt><dd class="boolean">1</dd>
<dt>false</dt><dd class="boolean">0</dd>
<dt>data</dt><dd class="binary"><a href="data:;base64,sdcfo2JTiXE=" type="image/jpg">my image</a></dd>
</dl>

'''Note:''' [[xoxo|XOXO]] always starts with either <code>ol</code> or <code>ul</code>. The <code>dl</code> in XOXO is always used to declare the properties of a specific <code>li</code>. These examples should be updated accordingly. -Tantek

== References ==
* [http://en.wikipedia.org/wiki/Datatype Datatypes] in Wikipedia
* Origional [http://microformats.org/discuss/mail/microformats-discuss/2005-September/001020.html datatype] discussion
* Original [http://homepage.mac.com/drernie/plist.html plist] datatype mapping proposal
* Revised [http://opendarwin.org/~drernie/xoxo-datatypes.html xoxo datatype] proposal

== See Also ==
* [[xoxo]]
* [[naming-principles]]

hresume

2006-02-12T22:51:30Z

MarkRickerby: /* Format */

<h1> hResume </h1>

hResume is a microformat for publishing resumes and CVs.

This paragraph is where we write some thing that makes everyone in the world want to use hResume. Because, you know, hResume's the future and people like the future. And so on... [[hresume-use|Wanna get started on hResume right now?]]

<h2> Microformats Draft Specification </h2>

; Editor/Author: [http://theryanking.com Ryan King]
; Acknowledgments: See [http://microformats.org/wiki/hresume#Acknowledgements acknowledgments].

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

__TOC__

== Status ==
'''Very rough draft, work in progress.'''

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

== Format ==
=== In General ===
The hResume format is based on a set of fields common to numerous resumes published today on the web. Where possible field names have been chosen and reused from preexisting microformats.

=== Schema ===
The hResume schema consists of the following:

* hResume
** summary. optional. text.
** contact info. required. <code class="element"><address></code> + [[hcard|hCard]].
** experience. optional. One or more [[hcalendar]] events with the class name '<code class="class-name">experience</code>', with an embedded [[hcard|hCard]] indicating the job title, name of company, address of company etc.
** education. optional One or more [[hcalendar]] events with the class name '<code class="class-name">education</code>', with an embedded [[hcard|hCard]] indicating the name of school, address of school etc.
** skills. optional. phrases or keywords using the [[rel-tag]] microformat with the class name '<code class="class-name">skill</code>'.
** affiliations. optional. the class name <code class="class-name">affiliation</code> along with an [[hcard]] of the organization
** publications. optional. One or more citations. Use cite tag.
** references. optional. One or more references.

=== Field details ===
The fields of the hReview schema represent the following:

* '''summary''':: This optional field serves as a overview of qualifications and objectives.
* '''contact''':: Current contact info. The <code class="element"><address></code> with [[hCard]].
* '''education''':: the class name '<code class="class-name">education</code>' is applied to an [[hcalendar]] event.
* '''experience''':: the class name '<code class="class-name">experience</code>' is applied to an [[hcalendar]] event. Job titles/positions should use an [[hCard]].
* '''skills''':: An hResume may be tagged using the [[rel-tag]] microformat and the '<code class="class-name">skill</code>' class name.
* '''affiliations''':: The class name <code="class-name">affiliation</code> is used along with an [[hcard]] of the organization
* '''publications''':: just use <code class="element"><cite></code>. When there is a [[citation]] microformat, then that can be used in combination with the cite element to further markup the components of the citation.
* '''rel="reference"'''. For references, link to the person with rel="reference" and any other [http://gmpg.org/xfn/ XFN] values that apply (e.g. "colleague", "co-worker", "friend", "kin" etc.), and use [[hcard|hCard]] to markup the name of the reference.

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

*...

== Examples ==
=== Summary ===
An example summary:

<pre><nowiki>
<p class="summary">
I have 10 years experience with all Web 2.0 technologies– I've been working with Ajax since 1996,
designing with pastels while others will still using tiled background images and frames...
</p>
</nowiki></pre>

=== Contact ===
<pre><nowiki>
<address class="vcard">
<span class="fn">Pedro Sanchez</span>
<span class="adr">
<span class="street-address">123 Fake St.</span>
<span class="locality">Preston</span>, <span class="region">Idaho</span> <span class="postal-code">83263</span>
</span>
<span>Email: <a class="email" href="mailto:joe@example.com">pedro@vote-for-pedro.com</a></span>
<span>Homepage: <a class="url" href="http://vote-for-pedro.com/">vote-for-pedro.com</a></span>
<span>Phone: <span class="tel">+01.208.555.4567</span></span>
</address>
</nowiki></pre>

=== Education ===
<pre><nowiki>
<ol class="vcalendar">
<li class="education vevent">
<a class="url summary" href="http://example.edu/">Preston High School</a>
(<abbr class="dtstart" title="1995-01-24">2001</abbr> - <abbr class="dtend" title="2005-05-25">2005</abbr>)
</li>
...
</nowiki></pre>

=== Experience ===
==== Basic ====
A basic experience event:

<pre><nowiki>
<ol class="vcalendar">
<li class="experience vevent">
<span class="summary">President</span>,
<span class="location">Preston High School</span>,
<abbr class="dtstart" title="2004-09-01">May 2005</abbr> - <abbr title="2005-05-25">present</abbr>
</li>
...
</nowiki></pre>

==== Job Titles ====
To express multiple job titles/positions in the same experience event you should use [[hCard]]s. [[hcard]] requires the <code class="class-name">fn</code> ("formatted name") field, but it isn't reasonable to repeat your name for every job title you mark up in [[hResume]]. So, you may use an <code class="element"><object></code> with a reference to the <code class="class-name">fn</code> somewhere else on the page.

For example, this [[hCard]] refers to another [[hCard]]

<pre>
<span class="vcard">
<object data="#j" class="fn n"></object>
<span class="org">Preston High School</span>
<span class="title">Class President</span>
</span>
</pre>

Where "<code class="attr-value">j</code>" is the id attribute value of the "<code class="mf-prop">fn n</code>" element of the contact [[hCard]] at the top of the page, e.g. (shown here as a verbose [[hCard]] for purposes of illustration that the reference may be to a subtree, not just a text node):

<pre><nowiki>
<address class="vcard">
<span class="fn n" id="j">
<span class="given-name">Pedro</span>
<span class="family-name">Sanchez</span>
</span>
</address>
</nowiki></pre>

This method of hCard property indirection via an object element could be generalized to apply to any/all string/text properties in hCard.
Note: the object data attribute MUST be a local ID reference. External references (which would require a consuming application to load an external resource) are currently not supported by this method.

=== Skills ===
Some sample skills tags:
<pre><nowiki>
I have skills in <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Bow_%28weapon%29">bow hunting</a>
and <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Nunchucks">nunchucks</a>.
</nowiki></pre>

=== Affiliations ===
<pre><nowiki>
<span class="affiliation vcard"><span class="fn org">National Honor Society</span></span>
</nowiki></pre>

=== Publications ===
<pre><nowiki>
<cite>Breeding Ligers for Fun and Magic</cite>, Idaho Press, 2004.
</nowiki></pre>

== Profile ==
@TODO

== Implementations ==
@TODO

== References ==
=== Normative References ===
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML]
* [http://gmpg.org/xmdp/ XMDP]
* [[rel-tag| Rel-Tag]]
* @TODO

=== Informative References ===
@TODO

== Copyright ==
{{MicroFormatCopyrightStatement2006}}

== Patents ==
{{MicroFormatPatentStatement}}

== Acknowledgements ==

=== Concept ===
* [http://theryanking.com/ Ryan King], [http://technorati.com Technorati]
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati]
* SimplyHired guys... @TODO
* [http://epeus.blogspot.com/ Kevin Marks], [http://technorati.com Technorati]

== See also ==
* [[resume-examples]]
* [[resume-formats]]
* [[resume-brainstorming]]

hresume

2006-02-12T22:50:34Z

MarkRickerby: /* Format */ corrected placement of education/experience

<h1> hResume </h1>

hResume is a microformat for publishing resumes and CVs.

This paragraph is where we write some thing that makes everyone in the world want to use hResume. Because, you know, hResume's the future and people like the future. And so on... [[hresume-use|Wanna get started on hResume right now?]]

<h2> Microformats Draft Specification </h2>

; Editor/Author: [http://theryanking.com Ryan King]
; Acknowledgments: See [http://microformats.org/wiki/hresume#Acknowledgements acknowledgments].

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

__TOC__

== Status ==
'''Very rough draft, work in progress.'''

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

== Format ==
=== In General ===
The hResume format is based on a set of fields common to numerous resumes published today on the web. Where possible field names have been chosen and reused from preexisting microformats.

=== Schema ===
The hResume schema consists of the following:

* hResume
** summary. optional. text.
** contact info. required. <code class="element"><address></code> + [[hcard|hCard]].
** education. optional. One or more [[hcalendar]] events with the class name '<code class="class-name">education</code>', with an embedded [[hcard|hCard]] indicating the job title, name of company, address of company etc.
** experience. optional One or more [[hcalendar]] events with the class name '<code class="class-name">experience</code>', with an embedded [[hcard|hCard]] indicating the name of school, address of school etc.
** skills. optional. phrases or keywords using the [[rel-tag]] microformat with the class name '<code class="class-name">skill</code>'.
** affiliations. optional. the class name <code class="class-name">affiliation</code> along with an [[hcard]] of the organization
** publications. optional. One or more citations. Use cite tag.
** references. optional. One or more references.

=== Field details ===
The fields of the hReview schema represent the following:

* '''summary''':: This optional field serves as a overview of qualifications and objectives.
* '''contact''':: Current contact info. The <code class="element"><address></code> with [[hCard]].
* '''education''':: the class name '<code class="class-name">education</code>' is applied to an [[hcalendar]] event.
* '''experience''':: the class name '<code class="class-name">experience</code>' is applied to an [[hcalendar]] event. Job titles/positions should use an [[hCard]].
* '''skills''':: An hResume may be tagged using the [[rel-tag]] microformat and the '<code class="class-name">skill</code>' class name.
* '''affiliations''':: The class name <code="class-name">affiliation</code> is used along with an [[hcard]] of the organization
* '''publications''':: just use <code class="element"><cite></code>. When there is a [[citation]] microformat, then that can be used in combination with the cite element to further markup the components of the citation.
* '''rel="reference"'''. For references, link to the person with rel="reference" and any other [http://gmpg.org/xfn/ XFN] values that apply (e.g. "colleague", "co-worker", "friend", "kin" etc.), and use [[hcard|hCard]] to markup the name of the reference.

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

*...

== Examples ==
=== Summary ===
An example summary:

<pre><nowiki>
<p class="summary">
I have 10 years experience with all Web 2.0 technologies– I've been working with Ajax since 1996,
designing with pastels while others will still using tiled background images and frames...
</p>
</nowiki></pre>

=== Contact ===
<pre><nowiki>
<address class="vcard">
<span class="fn">Pedro Sanchez</span>
<span class="adr">
<span class="street-address">123 Fake St.</span>
<span class="locality">Preston</span>, <span class="region">Idaho</span> <span class="postal-code">83263</span>
</span>
<span>Email: <a class="email" href="mailto:joe@example.com">pedro@vote-for-pedro.com</a></span>
<span>Homepage: <a class="url" href="http://vote-for-pedro.com/">vote-for-pedro.com</a></span>
<span>Phone: <span class="tel">+01.208.555.4567</span></span>
</address>
</nowiki></pre>

=== Education ===
<pre><nowiki>
<ol class="vcalendar">
<li class="education vevent">
<a class="url summary" href="http://example.edu/">Preston High School</a>
(<abbr class="dtstart" title="1995-01-24">2001</abbr> - <abbr class="dtend" title="2005-05-25">2005</abbr>)
</li>
...
</nowiki></pre>

=== Experience ===
==== Basic ====
A basic experience event:

<pre><nowiki>
<ol class="vcalendar">
<li class="experience vevent">
<span class="summary">President</span>,
<span class="location">Preston High School</span>,
<abbr class="dtstart" title="2004-09-01">May 2005</abbr> - <abbr title="2005-05-25">present</abbr>
</li>
...
</nowiki></pre>

==== Job Titles ====
To express multiple job titles/positions in the same experience event you should use [[hCard]]s. [[hcard]] requires the <code class="class-name">fn</code> ("formatted name") field, but it isn't reasonable to repeat your name for every job title you mark up in [[hResume]]. So, you may use an <code class="element"><object></code> with a reference to the <code class="class-name">fn</code> somewhere else on the page.

For example, this [[hCard]] refers to another [[hCard]]

<pre>
<span class="vcard">
<object data="#j" class="fn n"></object>
<span class="org">Preston High School</span>
<span class="title">Class President</span>
</span>
</pre>

Where "<code class="attr-value">j</code>" is the id attribute value of the "<code class="mf-prop">fn n</code>" element of the contact [[hCard]] at the top of the page, e.g. (shown here as a verbose [[hCard]] for purposes of illustration that the reference may be to a subtree, not just a text node):

<pre><nowiki>
<address class="vcard">
<span class="fn n" id="j">
<span class="given-name">Pedro</span>
<span class="family-name">Sanchez</span>
</span>
</address>
</nowiki></pre>

This method of hCard property indirection via an object element could be generalized to apply to any/all string/text properties in hCard.
Note: the object data attribute MUST be a local ID reference. External references (which would require a consuming application to load an external resource) are currently not supported by this method.

=== Skills ===
Some sample skills tags:
<pre><nowiki>
I have skills in <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Bow_%28weapon%29">bow hunting</a>
and <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Nunchucks">nunchucks</a>.
</nowiki></pre>

=== Affiliations ===
<pre><nowiki>
<span class="affiliation vcard"><span class="fn org">National Honor Society</span></span>
</nowiki></pre>

=== Publications ===
<pre><nowiki>
<cite>Breeding Ligers for Fun and Magic</cite>, Idaho Press, 2004.
</nowiki></pre>

== Profile ==
@TODO

== Implementations ==
@TODO

== References ==
=== Normative References ===
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML]
* [http://gmpg.org/xmdp/ XMDP]
* [[rel-tag| Rel-Tag]]
* @TODO

=== Informative References ===
@TODO

== Copyright ==
{{MicroFormatCopyrightStatement2006}}

== Patents ==
{{MicroFormatPatentStatement}}

== Acknowledgements ==

=== Concept ===
* [http://theryanking.com/ Ryan King], [http://technorati.com Technorati]
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati]
* SimplyHired guys... @TODO
* [http://epeus.blogspot.com/ Kevin Marks], [http://technorati.com Technorati]

== See also ==
* [[resume-examples]]
* [[resume-formats]]
* [[resume-brainstorming]]

start-simple

2006-02-02T04:39:04Z

MarkRickerby: draft content

= Start Simple (Draft) =

The principle of <em>starting simple</em> means to focus on solving a specific and immediate problem with your efforts. Very often, the simplest thing that could possibly work turns out to be an entirely effective solution, and no more work is needed.

The Microformats [[process]] emphasises the importance of following in the footsteps of previous efforts as much as possible, which enables more effective [[reuse]] of standards and semantics. Starting simple keeps the focus on what can be accomplished immediately, and making this work effectively, rather than spending additional time chasing conceptual or theoretical chimeras - possibilities that <em>might</em> have a general impact when implementing the standard, but then again <em>might not</em>.

Microformats should remain as simple as possible for as long as possible, collecting additional element semantics <em>only</em> when a significant practical need has been demonstrated for such additions.

=== Case Study - hAtom ===

* Removing Atom specific person/author constructs in favour of hCards
* Not dealing with feed level metadata - leave this to the web page context

to-do

2006-02-02T04:06:12Z

MarkRickerby: /* New Person 2 */

= To Do =

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

== Lazyweb ==

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

* a semantic, clean css star rating picker (e.g. a UI widget to rate from 1-5 stars)
** both [http://komodomedia.com/blog/index.php/2005/08/24/creating-a-star-rater-using-css/ this] and [http://factorycity.net/demos/drupal/rating/default.html this] have some flaws. Ask [[User:RyanKing|Ryan King]] for an explanation.
* microformatted versions of conference pages
** Do a revision of the [http://conferences.oreillynet.com/etel2006/ ETel] [http://conferences.oreillynet.com/pub/w/44/speakers.html speaker's page] with all the speakers marked up with [[hcard|hCard]] and links to "Add hCards to Address Book" etc., similar to the [http://tantek.com/microformats/2005/web2/speakers.html Web 2.0 speakers page which Tantek did a revision of last fall].

* quick and easy "how to" pages for each microformat. [[use]] is a good overall start.
* brief summary statements for each microformat that explain why it matters, what does it accomplish for the publisher.

== Tantek ==

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

=== iterate on current microformats ===
* [[hreview|hReview]] 0.3 - write the draft and get it finalized (actively working on it!)

=== introduction / community ===
* microformats-discuss
** introductory email sent to new subscribers needs to direct people to [[process]] and [[how-to-play]]

* Need to add more to the [[naming-principles]], to cover in particular:
** avoid using the same name to mean two things
** avoid using two names to mean the same thing
** seek to keep the microformats vocabulary minimal, memorable, and usable.

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

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

=== create microformats wiki pages for ===
* microformats [[history]]
** introduction of terms (when were microformats terms introduced, by whom, etc.)
** introduction of specs (when were microformats specifications first introduced)
*** use the history on Technorati's developer wiki for evidence of earliest dates.
*** use the [[presentations]] as a source as well.

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

=== more microformat examples ===
==== more illustrative examples in specs ====
* need examples of multi-instance [[hcalendar|hCalendar]] events
* of repeating events
* need examples of [[hcard|hCard]]s with work telephone, mailing address etc.
==== more examples in the wild ====
* help dglazkov markup
** http://glazkov.com/blog/archive/2003/12/17/147.aspx

=== help with microformat implementations ===
* [http://microformats.org/code/hcard/creator hCard creator] - add features/fields
** email
** aim / instant messaging contact info
* wordpress improvements
** WP admin for new profiles
*** should simply read blog URL
*** look for hcards and parse them
* [http://gmpg.org/xfn/creator XFN Creator] localizations
** Get someone to verify the [http://gmpg.org/xfn/creator-ru XFN Creator Russian localization].
** Add it to the [http://gmpg.org/xfn/tools XFN Tools] page.
** Add rel="alternate" href="creator-ru" <link>s to the other XFN Creators.
* Conference Schedule Creator
** We need to ASAP build a simple conference schedule creator (and editor?) that builds upon the hCalendar creator. We should make it *trivial* for conference organizers to build/edit/publish an [[hcalendar|hCalendar]] schedule for their conference, including auto-generated "Subscribe..." link which produces the proper "webcal:..." link with X2V. Note: see the "axis" and "header" attributes in HTML4, specifically in the section on Tables.

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

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

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

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

=== *-authoring microformats wiki pages ===
* [[hcard-authoring]] - a tutorial on creating an hcard for you site, blog (common platforms), etc.
* [[hcalendar-authoring]] - a tutorial on how to blog events so your friends can subscribe to them
* [[hreview-authoring]] - a tutorial on how to blog reviews so that they'll be aggregated.
=== WordPress patches for microformats ===
* submit patches for WordPress code/templates for microformats improvements
** <address class="vcard"> improvement in post author publication (e.g. home page of http://microformats.org/ )
* Wordpress plugin for microformats, specifically hReview and hCalendar
** See [http://www.surfarama.com/index.php?p=227 lazyweb request]
=== other ===
* add an example of how to use DURATION in hcalendar see http://www.policyawareweb.org/2005/ftf2/paw-mtg#item15)

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

== Dimitri Glazkov ==

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

== Chris Messina ==

* Work on a microformat for play-lists (is it just a XOXO ordererd list of play-items?)
* Work on a microformat for play-item

=== Wishlist ===

* Microformat for "buyable items" (see [[listing-examples]] and related documents)
* Location MF -- right click "map this" (see [[geo]] and [[adr]])
* Better hCard support in the browser -- right click "IM this person...", "Add to contacts"
* Better hCal support -- support many views of same hCal data on one page using XSLT

== Robert Bachmann ==

* make hatom2atom.xsl conformant to [[hatom]].

== Brian Suda ==
=== Citation Microformats ===
Add all my notes to the Wiki

=== X2V ===
Make changes and update site (almost stable)
Get ATTENDEE and other strange attributes working

== Mark Rickerby ==

=== Writing and Copy Editing ===

* Draft of [[getting-started]] page
* Edits to homepage feature box text
* Follow up on usability review
* Review content for new pages - [[start-simple]], [[modularity]], [[reuse]], [[humans-first]]

== New Person 2 ==

etc.

hatom-issues

2006-02-02T03:22:51Z

MarkRickerby: /* Alternatives */

'''I (RyanKing) am currently working on reorganizing this page. Please hold off on adding new issues or discussion until I'm done. Thanks.'''

= hAtom issues =

__TOC__

== Feed (atom:feed)==

=== Initial proposal ===

<code>atomfeed</code> (or rather, "atom-entry")

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

=== Alternatives ===

The above proposal was not fully accepted and some other possibilities were proposed:

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

==== Discussion ====

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

== Entry (atom:entry) ==
=== Initial Proposal ===

<code>atomentry</code> (or rather, "atom-entry")

* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)
*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...
*** '''STATUS - RESOLVED'''. We're going with "entry".
*** [[Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
**** atom-entry
**** hentry
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Alternatives ===
The above proposal was not fully accepted. Other alternatives:

* <code>entry</code> (Atom consistency)
** +1 [[MarkRickerby]]
* <code>atom-entry</code> (Atom consistency with prefix)
* <code>hentry</code> (h* uF consistency)
** +1 [[DavidJanes]]
** +1 [[Tantek]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** +1 [[MarkRickerby]]
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption

==== Discussion ====
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p>

== Entry Title (atom:title) ==
=== proposals ===

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

* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.
** -1 [[KevinMarks]] (clashes with atom)
* <code>Subject</code>, as used by SMTP email
** -1 [[RyanKing]] - different semantics, doesn't fit
* <code>heading</code>
** -1 [[RyanKing]] - a replication of <h*> semantics in html
* <code>entry-title</code>
* <code>headline</code>
** +1 [[Tantek]]
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]
** +1 [[BenjaminCarlyle]], atom:entry/title only
** +½ [[DavidJanes]], atom:entry/title only
** +½ [[PaulBryson]], redundant?
* <code>title</code> (Atom consistency)
** -1 [[Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)
** +½ [[PaulBryson]], clear=good / hyphenating=bad
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
** ±0 [[DavidJanes]] see my note below
** -1 [[Tantek]] (does not mean the "name" of the post/entry)
** +1 [[BenjaminCarlyle]], atom:feed/title only

=== Discussion ===
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p> Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p>
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p>
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.

== Entry Content (atom:content) ==
* <code>content</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview consistency)
** -1 [[RyanKing]] - it has a different meaning in Atom, we should avoid the confusion

=== Discussion ===
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

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

* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly.
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.
* <code>summary</code> (re-use from and consistency with Atom)
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)
* <code>partial-description</code>
* <code>excerpt</code>
** +1 Tantek
** +1 BenjaminCarlyle
** +1 DavidJanes, my only concern being that they're not always excerpts
* <code>abstract</code>
** +1 KevinMarks

=== Discussion ===
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.
* [[Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p>
** WordPress user interface calls it "excerpt"
** MovableType user interface calls it "excerpt"
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.

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

=== Discussion ===
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.
* [[Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.
** [[RyanKing]] non-issue, you can always use both.

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

=== Discussion ===
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p>
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p>
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards

== Entry Updated (atom:updated) ==
* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with "dt" unofficial pattern)
** +½ Paul Bryson, Not as human readable
* <code>last-modified</code>
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)
** dtstamp
** dtupdated

=== Discussion ===
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p>
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p>
* [[DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards

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

=== Discussion ===
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.

== Entry Contributor (atom:contributor) ==
** -1 Tantek (what's this vote on? did I screw something up in rearranging things? --[[User:RyanKing|RyanKing]] 14:10, 1 Feb 2006 (PST))
* <code>contibutor</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes

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

== Questions and Comments ==

=== Limitations ===
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.

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

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

[[Tantek]]: "Pushed back" is the wrong direction here.

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

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

=== hCards ===

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

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as <q>The "atom:author" element is a Person construct that indicates the author of the entry or feed.</q> and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><address class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI
* '''STATUS - OPEN'''. "MAY" is the answer.
* [[Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p>

=== Comparisons ===

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

--[[Ernie Prabhakar]]

* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p>
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.

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

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

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

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

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

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

-- [[BenjaminCarlyle]]

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

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

* [[Tantek]]: IMHO yes.
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.
* rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

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

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

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

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

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

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

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

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

== Template ==

Please use this format (copy and paste this to the end of the list to add your issues):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

use

2006-01-30T04:51:30Z

MarkRickerby: flow of text, introduction

= So you wanna use microformats? =

Microformats are designed to be similar to current markup styles. This means that it is quite possible that you won't have to do much work to produce microformats on your site. Many common kinds of content can be marked up in microformats. Chances are, you already have some of them on your site. Start with the obvious ones. For example...

* Do you have events information on your site? Then mark those events up with [[hCalendar]].
** Start with the [http://microformats.org/code/hcalendar/creator hCalendar creator].
* Do you have people and their contact information? Then mark those up with [[hCard]].
** Start with the [http://microformats.org/code/hcard/creator hCard creator] and take a look at the [[hcard-examples]].
* Do you have an explicit copyright license on your content? Then markup the link to your license with [[rel-license|relLicense]].
* Do you have social networking data? Then mark that up with [http://gmpg.org/xfn/ XFN]. Are you tagging things? Then use [[rel-tag|relTag]] or [[xFolk]].
* Are you publishing lists or outlines? Then use [[XOXO]].
* Do you publish reviews? Then use [[hReview]].
** Start with the [http://microformats.org/code/hreview/creator hReview creator].
* Do you publish press releases? Then use [[hatom|hAtom]].

And here's a few more tips:

* Try to produce clean, semantic xhtml. Often this will get you very close to microformats on its own.
** [http://tantek.com/log/2004/07.html#classmeaningnotshow Class for meaning not for show]
** http://microformats.org/wiki/SemanticXHTMLDesignPrinciples
** [http://tantek.com/presentations/20040928sdforumws/semantic-xhtml.html Semantic XHTML]
** [http://tantek.com/presentations/2005/03/elementsofxhtml Meaningful XHTML]
** [http://www.tantek.com/presentations/2004etech/realworldsemanticspres.html Real World Semantics]
** ''need more links here'' --[[User:RyanKing|RyanKing]] 14:42, 17 Jan 2006 (PST)

citation-formats

2006-01-24T10:39:50Z

MarkRickerby: /* BibTeX citation Types */ more fixes

= Citation Formats =

This page will display several different types of citation format types. The idea is to compare what properties are common amonst all of the formats and which ones should be blended into this microformat.

See also:
* [[cite]]
* [[cite-brainstorming]]
* [[cite-examples]]

== Comparison chart ==
The following chart maps the terms from one implementation to another. This is important because if all the properties are introduced to this microformats, then its possible to map them to a number of different formats. The table currently only uses Dublin Core, MODS, and bibTeX. Each column has all the properties and their equivalent in each format. If there is no corresponding property the cell is grey. At the bottom of the list are the unique terms to each format. Dublin core has basic terms and terms that extend the basic ones. If the property is an extention of a basic term it is in ()'s. MODS uses XML, so any sub-properties are listed in their tree form, property/sub-property.

THIS IS NOT DEFINIATIVE, any errors should be corrected. More formats will be added to the list as they are mapped.

<table border="1">
<tr>
<th>Dublin Core</th>
<th>MODS</th>
<th>bibTeX</th>
<th>Z39.80</th>
</tr>
<tr>
<td>Title (alternative)</td>
<td>titleInfo/title<br/>titleInfo/PartNum</td>
<td>booktitle<br/>title<br/>chapter<br/>number<br/>pages<br/>volume<br/>series</td>
<td>Analytic Title<br/>
Collective or Series Title<br/>
Monographic Title<br/>
Work Fraction Title<br/>
Location of Conference<br/>
Main Entry<br/>
Name of Conference<br/>
Number of Meeting<br/>
Other Title<br/>
Parallel Title<br/>
Title Abbriviation<br/>
Title of Conference Proceedings<br/>
Translated Title<br/>
Uniform Title<br/>
Abbriviated Translated Title<br/>
Symposium or Session Title<br/>
Collective or Series Edition<br/>
Video/Film Edition<br/>
</td>
</tr>
<tr>
<td>creator</td>
<td>name/namePart</td>
<td>author<br/>creator</td>
<td>Author, Primary<br/>
Corporate Author, Primary<br/>
Abstract Author<br/>
Authorship Statement<br/>
Acknowledged Supporters<br/>
Assignee for Patents<br/>
Chairperson of Conference<br/>
Director of AV Program<br/>
Other Author<br/>
Reviewed Book Author<br/>
Studio<br/>
Sponsor of Conference<br/>
Staff/Cast<br/>
Symposium Chairperson<br/>
Author Address or Affiliation<br/>
Author Country<br/>
Electronic Address of Author<br/>
</td>
</tr>
<tr>
<td>subject</td>
<td>subject/topic</td>
<td>keywords</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Description (abstract | tableOfContents)</td>
<td>abstract<br/>note<br/>tableOfContents</td>
<td>abstract<br/>annotation<br/>note<br/>contents</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Contributer</td>
<td>name</td>
<td>editor?</td>
<td>Book/Report/Volume Editor<br/>
Producer<br/>
Translator<br/>
</td>
</tr>
<tr>
<td>Date (available | created | dateAccepted | dateCopyrighted | dateSubmitted | issued | modified | valid)</td>
<td>originInfo/dateIssued<br/>originInfo/dateCreated<br/>originInfo/dateCaptured<br/>originInfo/dateOther</td>
<td>month<br/>year</td>
<td>Copyright Year<br/>Date-generic<br/>Date of conference<br/>Date of Publication<br/>Date of Update/Revisou/Issuance of Database Record<br/>Former Date<br/>Entry date for Database Record<br/>Database Update<br/>Year of Publication</td>
</tr>
<tr>
<td>Type</td>
<td>typeOfResource<br/>genre</td>
<td>@class<br/>type</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Format (extent | medium)</td>
<td>physicalDescription/internetMediaType<br/>physicalDescription/extent<br/>physicalDescription/form</td>
<td>howpublished</td>
<td>needs mapping</td>
</tr>
<tr>
<td>identifier (bibliographicCitation)</td>
<td>identifier</td>
<td>ISBN<br/>ISSN<br/>LCCN<br/>URL</td>
<td>ISBN<br/>Identifier<br/>Report Identfier<br/>ISSN</td>
</tr>
<tr>
<td>Source</td>
<td>relatedItem</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>language</td>
<td>language</td>
<td>language</td>
<td bgcolor="#cccccc"></td>
</tr>
<tr>
<td>Relation (...)</td>
<td>relatedItem/...</td>
<td>crossRef</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Coverage (spacial | temporal)</td>
<td>subject/temporal<br/>subject/geographic<br/>subject/hierarchicalGeographic<br/>subject/cartographics</td>
<td></td>
<td>needs mapping</td>
</tr>
<tr>
<td bgcolor="#cccccc"></td>
<td>classifications</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>Rights (accessRights | license)</td>
<td>accessConditions</td>
<td>copyright</td>
<td>needs mapping</td>
</tr>
<tr>
<td>publisher</td>
<td bgcolor="#cccccc"></td>
<td>publisher</td>
<td>Publisher Name<br/>
Place of Publication<br/>
Country of Publication<br/>
Generic Address<br/>
</td>
</tr>
<tr>
<td>audience (educationLevel | mediator)</td>
<td>targetAudience</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td bgcolor="#999999">accualMethod<br/>accualPeriodicaty<br/>accualPolicy<br/>instrcutionalMethod<br/>provenance<br/>rightsHolder</td>
<td bgcolor="#999999">location<br/>extension<br/>recordInfo</td>
<td bgcolor="#999999">address<br/>afflilication<br/>location<br/>edition<br/>institution<br/>journal<br/>key<br/>mrnumber<br/>organization<br/>price<br/>school<br/>size</td>
<td bgcolor="#999999">(the following need to be mapped to the above rows or left here as other)<br/><br/>
Database Source<br/>
Databse Record Identifier<br/>
Database Producer Name<br/>
Rights Management<br/>
Subfile<br/>
Other Source Identifier<br/>
Vendor Record Identifier<br/>
Database Vendor Name<br/>
Column Number<br/>
Edition<br/>
Frequency of Publication<br/>
Internet Location for Document<br/>
Supplement/Part/Special number identifer<br/>
Issue Identifier<br/>
Location in Work<br/>
Number of the Chapter<br/>
Number in Series<br/>
Volume Identifier<br/>
Section Indentifier<br/>
</td>
</tr>
</table>

== Dublin Core Metadata ==
[http://dublincore.org/ Dublin Core] metadata uses a small vocabulary to descibe the data.
* contributor
* coverage
* creator
* date
* description
* format
* identifier
* language
* publisher
* relation
* rights
* source
* subject
* title
* type

From those there are specialised types where are just refinments of the previous, for example:

* abstract refines description.
* accessRights refines rights

[http://dublincore.org/documents/dc-citation-guidelines/ Guidelines for Encoding Bibliographic Citation Information in Dublin Core Metadata]

== MODS (Metadata Object Description Schema) ==
This is a format developed for the Libray of Congress for a bibliographic element set that may be used for a variety of purposes, and particularly for library applications.

[http://www.loc.gov/standards/mods/ http://www.loc.gov/standards/mods/]

(the schema is very big, once i devote the proper time to review it, i will post more about the structure -brian)

== XMLResume ==
<pre>
<!ELEMENT pubs (pub+)>
<!ENTITY % pubElements "(artTitle|bookTitle|author|date|pubDate|publisher|pageNums|url)">
<!ELEMENT pub (para | %pubElements;)*>
<!ATTLIST pub id ID #IMPLIED>
<!ELEMENT artTitle (#PCDATA | link)*>
<!ELEMENT bookTitle (#PCDATA | link)*>
<!ELEMENT author (#PCDATA)>
<!ATTLIST author name IDREF #IMPLIED>
<!ELEMENT pubDate (month?, year)> 
<!ELEMENT publisher (#PCDATA | link | url)*>
<!ELEMENT pageNums (#PCDATA)>
</pre>

== BibTeX ==
=== Fields Used by Bibtex ===

<table border="1" width="100%">
<tr>
<td><strong>abstract:</strong></td>
<td>An abstract of the work.</td>
</tr>
<tr>
<td><b>address:</b></td>
<td>Publisher's address. For major publishing houses,
just the city is given. For small publishers, you can help the reader by giving the complete address.</td>
</tr>
<tr>
<td><strong>affiliation:</strong></td>
<td>The author's affiliation.</td>
</tr>
<tr>
<td><b>annote:</b></td>
<td>An annotation. It is not used by he standard bibliography styles, but may be used by others that produce an annotated bibliography.</td>
</tr>
<tr>
<td><b>author:</b></td>
<td>The name(s) of the author(s).</td>
</tr>
<tr>
<td><b>booktitle: </b></td>
<td>Title of a book, part of which is being cited. For book entries, use the <strong>title</strong> field instead.</td>
</tr>
<tr>
<td><b>chapter:</b></td>
<td>A chapter (or section) number.</td>
</tr>
<tr>
<td><strong>contents:</strong></td>
<td>A Table of Contents.</td>
</tr>
<tr>
<td><strong>copyright:</strong></td>
<td>Copyright information.</td>
</tr>
<tr>
<td><strong>crossref:</strong></td>
<td>The database key of the entry being cross-referenced.</td>
</tr>
<tr>
<td><b>edition: </b></td>
<td>The edition of a book - for example
"Second". Notice that it is in capitals.</td>
</tr>
<tr>
<td><b>editor: </b></td>
<td>Name(s) of editor(s). If there is also an author field, then the editor field gives the editor of the book or collection in which the reference appears.</td>
</tr>
<tr>
<td><b>howpublished:</b></td>
<td>How something strange has been published. The first word should be capitalized.</td>
</tr>
<tr>
<td><b>institution:</b></td>
<td>The sponsoring institution of a technical report.</td>
</tr>
<tr>
<td><strong>ISBN:</strong></td>
<td>The International Standard Book Number.</td>
</tr>
<tr>
<td><strong>ISSN:</strong></td>
<td>The International Standard Serial Number. Used to
identify a journal.</td>
</tr>
<tr>
<td><b>journal: </b></td>
<td>A journal name. Abbreviations are provided for many journals.</td>
</tr>
<tr>
<td><b>key: </b></td>
<td>Used for alphabetizing and creating a label when the author and editor fields are missing. This field should not be confused with the key that appears at the beginning of the reference.</td>
</tr>
<tr>
<td><strong>keywords:</strong></td>
<td>Key words used for searching or possibly for annotation.</td>
</tr>
<tr>
<td><strong>language:</strong></td>
<td>The language the document is written in.</td>
</tr>
<tr>
<td><strong>LCCN:</strong></td>
<td>The Library of Congress Call Number.</td>
</tr>
<tr>
<td><strong>location:</strong></td>
<td>A location associated with the entry, such as the city in which a conference took place.</td>
</tr>
<tr>
<td><b>month: </b></td>
<td>The month in which the work was published or, for an unpublished work, in which it was written.</td>
</tr>
<tr>
<td><strong>mrnumber:</strong></td>
<td>The <em>Mathematical Reviews</em> number.</td>
</tr>
<tr>
<td><b>note:</b></td>
<td>Any additional information that can help the reader. First word should be capitalized.</td>
</tr>
<tr>
<td><b>number: </b></td>
<td>The number of a journal, magazine, technical report, or of a work in a series. An issue of a journal or magazine is usually identified by its volume and number; the organization that issues a technical report usually gives it a number; and sometimes books are given numbers in a named series.</td>
</tr>
<tr>
<td><b>organization: </b></td>
<td>The organization that sponsors a conference or publishes a manual.</td>
</tr>
<tr>
<td><b>pages:</b></td>
<td>One or more page numbers or ranges of number, such as 37--42, or 7,53,82--94.</td>
</tr>
<tr>
<td><strong>price:</strong></td>
<td>The price of the material.</td>
</tr>
<tr>
<td><b>publisher:</b></td>
<td>The publisher's name.</td>
</tr>
<tr>
<td><b>school:</b></td>
<td>The name of the school where a thesis was written.</td>
</tr>
<tr>
<td><b>series:</b></td>
<td>Then name given a series or set of books. When citing an entire book, the title field gives its title and the optional series field gives the name of a series in which the book was published.</td>
</tr>
<tr>
<td><strong>size:</strong></td>
<td>The physical dimensions of the work.</td>
</tr>
<tr>
<td><b>title:</b></td>
<td>The work's title.</td>
</tr>
<tr>
<td><b>type:</b></td>
<td>The type of technical report - for example,
"Research Note".</td>
</tr>
<tr>
<td><strong>url:</strong></td>
<td>The WWW Universal Resource Locator that points to the item being referenced. Often used for technical reports to point to the FTP site where it resides.</td>
</tr>
<tr>
<td><b>volume:</b></td>
<td>The volume of a journal or multivolume book.</td>
</tr>
<tr>
<td><b>year:</b></td>
<td>The year of publication or, for an unpublished work, the year it was written. It should only consist of numerals, such as 1976.</td>
</tr>
</table>

=== BibTeX citation Types ===
A reference can be to any of a variety of types. Following is a list of types. Each one also explains the fields associated with that type. Any fields not listed as required or optional are considered to be ignored.
<table border="1" width="100%">
<tr>
<td><b>article:</b></td>
<td>An article from a journal or magazine. Required fields: author, title, journal, year. Optional fields: volume, number, pages, month, note, key.</td>
</tr>
<tr>
<td><b>book:</b></td>
<td>A book with an explicit publisher. Required fields: author or editor, title, publisher, year. Optional fields: volume, series, address, edition, month, note, key.</td>
</tr>
<tr>
<td><b>booklet: </b></td>
<td>A work that is printed and bound, but without a named publisher or sponsoring institution. Required fields: title. Optional fields: author, howpublished, address, month, year, note, key.</td>
</tr>
<tr>
<td><strong>collection:</strong></td>
<td>A collection of works. Same as Proceedings.</td>
</tr>
<tr>
<td><b>conference:</b></td>
<td>The same as Inproceedings.</td>
</tr>
<tr>
<td><b>inbook:</b></td>
<td>A part of a book, which may be a chapter and/or arange of pages. Required fields: author or editor, title, chapter and/or pages, publisher, year. Optional fields: volumer, series, address, edition, month, note, key.</td>
</tr>
<tr>
<td><b>incollection:</b></td>
<td>A part of a book with its own title. Required fields: author, title, booktitle, publisher, year. Optional fields: editor, pages, organization, publisher, address, month, note, key.</td>
</tr>
<tr>
<td><b>inproceedings:</b></td>
<td>An article in a conference proceedings. Required fields: author, title, booktitle, year. Optional fields: editor, pages, organization, publisher, address, month, note, key.</td>
</tr>
<tr>
<td><b>manual: </b></td>
<td>Technical documentation. Required fields: title. Optional fields: author, organization, address, edition, month, year, note.</td>
</tr>
<tr>
<td><b>mastersthesis:</b></td>
<td>A Master's thesis. Required fields: author, title, school, year. Optional fields: address, month, note, key.</td>
</tr>
<tr>
<td><b>misc:</b></td>
<td>Use this type when nothing else fits. Required fields: none. Optional fields: author, title, howpublished, month, year, note, key.</td>
</tr>
<tr>
<td><strong>patent:</strong></td>
<td>A patent.</td>
</tr>
<tr>
<td><b>phdthesis:</b></td>
<td>A Ph.D. thesis. Required fields: author, title, school, year. Optional fields: address, month, note, key.</td>
</tr>
<tr>
<td><b>proceedings:</b></td>
<td>The proceedings of a conference. Required fields: title, year. Optional fields: editor, publisher, organization, address, month, note, key.</td>
</tr>
<tr>
<td><b>techreport:</b></td>
<td>A report published by a school or other institution, usually numbered within a series. Required fields: author, title, institution, year. Optional fields: type, number, address, month, note, key.</td>
</tr>
<tr>
<td><b>unpublished:</b></td>
<td>A document with an author and title, but not formally published. Required fields: author, title, note. Optional fields: month, year, key.</td>
</tr>
</table>

==== Examples ====
<pre><nowiki>
@book{kn:gnus,

AUTHOR = "Donald E. Knudson",
TITLE = "1966 World Gnus Almanac",
PUBLISHER = {Permafrost Press},
ADDRESS = {Novosibirsk} }

<div class="book" id="kn:gnus">
<div class="author">Donald E. Knudson</div>
<div class="title">1966 World Gnus Almanac</div>
<div class="publisher">Permafrost Press</div>
<div class="address">Novosibirsk</div>
</div>

@article{XAi_HSCheng_1994a,

author = "X. Ai and H. S. Cheng",
title = "Influence of moving dent on point {EHL} contacts",
journal = "Tribol. Trans.",
volume = "37",
year = "1994",
pages = "323--335",
}

<div class="article" id="XAi_HSCheng_1994a">
<div class="author">X. Ai and H. S. Cheng</div>
<div class="title">Influence of moving dent on point {EHL} contacts</div>
<div class="journal">Tribol. Trans.</div>
<div class="volume">37</div>
<div class="year">1994</div>
<div class="pages">323--335</div>
</div>
</nowiki></pre>

== OpenURL ==

OpenURL aka [http://www.niso.org/standards/standard_detail.cfm?std_id=783 Z39.88] defines a standard way of bundling citation data in a URL. It is widely deployed in academic libraries around the world to provide access to licensed content via link resolvers such as [http://www.exlibrisgroup.com/sfx_openurl.htm SFX]. The Context Object in Span ([http://ocoins.info/ COinS]) community standard represents one way to embed OpenURLs in XHTML without including a resolver target.

<pre>
<nowiki>
<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.issn=1045-4438"></span>
</nowiki>
</pre>

As you can see this isn't very much like semantic XHTML at all. However significant work has gone into defining the set of Key/Encoded Values (KEVs) that can be used in various [http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats types] of citations: [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:book book], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:dissertation dissertation], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:journal journal], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:patent patent]. It would be possible to simply provide a standard XHTML bundling for these keys as a microformat.

=== Example ===

<pre>
<nowiki>

<div class="openurl-journal">
<span class="aulast">Berners-Lee</span>,
<span class="aufirst">Tim</a>; Hendler, James; Lassila, Ora.</span>
"<span class="atitle">The Semantic Web</span>".
<span class="jtitle">Scientific American</span>
<span class="volume">284</span>(<span class="issue">5</span>), pp.
pp. <span class="pages">34-43</span>.
<span class="issn">0036-8733</span>
</div>

</nowiki>
</pre>

Using OpenURL in this way would enable third party applications that could, say grab citation metadata from a blog, and without much work fire it off at your university's or public libraries openurl resolver to see if the article is available via a licensed databases. The benefits [http://www.infotoday.com/newsbreaks/nb050801-1.shtml have] [http://www.ariadne.ac.uk/issue43/chudnov/ been] [http://www.wallandbinkley.com/quaedam/?p=30 noted] [http://hublog.hubmed.org/archives/001163.html elsewhere].

== Z39.80 ==
I'm not sure the best place for a guide to Z39.80 so please add links as you see fit:

[http://www.niso.org/standards/resources/drft4rev.html http://www.niso.org/standards/resources/drft4rev.html]

== DocBook ==

A subset of the DocBook vocabulary is dedicated to representing a bibliography: http://www.docbook.org/tdg/en/html/bibliography.html

<pre><nowiki>
<!DOCTYPE bibliography PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
<bibliography>
<title>Languages and Semantics</title>
<bibliodiv>
<title>Books</title>
<biblioentry>
<title>Course in General Linguistics</title>
<abbrev>deSaussure59</abbrev>
<author><firstname>Ferdinand</firstname><surname>de Saussure</surname></author>
<editor><firstname>Charles</firstname><surname>Bally</surname></editor>
<editor><firstname>Albert</firstname><surname>Sechehaye</surname></editor>
<othercredit role="translator"><firstname>Wade</firstname><surname>Baskin</surname></othercredit>
<copyright>
<year>1959</year>
<holder>The Philosophical Library Inc.</holder>
</copyright>
<isbn>07-016524-6</isbn>
<publisher>
<publishername>McGraw-Hill Book Company</publishername>
</publisher>
</biblioentry>
</bibliodiv>
</bibliography>
</nowiki></pre>

== Ann Arbor District Library XML feed ==

Here's a record in XML format from their project to simplify
access to the catalog. More discussion on [http://www.blyberg.net John Blyberg's blog].

<pre>
<nowiki>
<p:Record>
<callnum>823 Bu</callnum>
<author>Burkart, Gina, 1971-</author>
<fulltitle>A parent's guide to Harry Potter / Gina Burkart</fulltitle>
<title>A parent's guide to Harry Potter </title>
<pubinfo>Downers Grove, Ill. : InterVarsity Press, c2005</pubinfo>
<desc>112 p</desc>
<bibliography>Includes bibliographical references</bibliography>
<contents>
The Harry hype -- More than a story -- The modern fairy tale -- Discussing fantasy with children -- Morals, not magic -- The real issues in Harry Potter -- Dealing with traumatic experiences -- Facing fears -- Battling bullies -- Delving into diversity -- Hiding hurts -- Letting go of anger -- Getting help -- Choosing good over evil -- The power of love -- Facing spiritual battles
</contents>
<isbn>0830832882</isbn>
<price>$11.00</price>
<lang>eng</lang>
<copies>0</copies>
<catdate>08-16-2005</catdate>
<mattype>a</mattype>
<avail>No copies available</avail>
<recordlink xlink:href="http://www.aadl.org/cat/seek/record=1249810"/>
</p:Record>
</nowiki>
</pre>

== SimpleDC supported by the zoom toolkit ==

<pre>
<nowiki>
<dc xmlns="http/www.loc.gov/zing/srw/dcschema/v1.0/">
<title>Kantor Salomon Sulzer und seine Zeit : eine Dokumentation /</title>
<creator>Avenary, Hanoch.</creator>
<creator>Pass, Walter.</creator>
<creator>Vielmetti, Nikolaus.</creator>
<creator>Adler, Israel, (1925-)</creator>
<subject>Sulzer, Salomon, -- 1804-1890.</subject>
<subject>Jewish composers -- Austria -- Biography.</subject>
<subject>Cantors, Jewish -- Biography.</subject>
<date>1985</date>
<publisher>Sigmaringen : Jan Thorbecke Verlag</publisher>
<identifier>3799540636</identifier>
<description>300 p., [12] p. of plates : ill., music, ports. ; 24 cm.</description>
</dc>
</nowiki>
</pre>

this is the output of marc.toSimpleDC()

== SRU from the Library of Congress ==

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dinosaur&maximumRecords=1&recordSchema=dc

<pre>
<nowiki>
<?xml version="1.0"?>
<zs:searchRetrieveResponse xmlns:zs="http://www.loc.gov/zing/srw/"><zs:version>1.1</zs:version><zs:numberOfRecords>1701</zs:numberOfRecords><zs:records><zs:record><zs:recordSchema>info:srw/schema/1/dc-v1.1</zs:recordSchema><zs:recordPacking>xml</zs:recordPacking><zs:recordData><srw_dc:dc xmlns:srw_dc="info:srw/schema/1/dc-schema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://purl.org/dc/elements/1.1/" xsi:schemaLocation="info:srw/schema/1/dc-schema http://www.loc.gov/z3950/agency/zing/srw/dc-schema.xsd">
<title>3-D dinosaur adventure [computer file].</title>
<creator>Knowledge Adventure, Inc.</creator>
<type>software, multimedia</type>
<publisher>Glendale, CA : Knowledge Adventure,</publisher>

<date>c1995.</date>
<language>eng</language>
<description>Employs a dinosaur theme-park setting to introduce users to Triassic, Jurassic, and Cretaceous periods. Features hypertext dinosaur encyclopedia covering 150 million years of paleontology. Includes animated video simulations, three-dimensional dinosaur museum, narration, games, activities, and color illustrations.</description>
<description>Ages 5 to 10.</description>
<description>System requirements for PC: 486SX/25MHz processor or higher; 8MB RAM; Windows 3.1, 3.11, or 95; SVGA 256-color graphics adapter; hard drive with 5MB free space; double-speed CD-ROM drive; MPC-compatible sound card; mouse.</description>
<description>System requirements for Macintosh: 68040 or Power PC processor; 8MB RAM; System 7.0 or higher; 256-color graphics capability; thirteen-inch color monitor or larger; hard drive with 4MB free space; double-speed CD-ROM drive.</description>

<description>Ages 5 to 10.</description>
<description>Employs a dinosaur theme-park setting to introduce users to Triassic, Jurassic, and Cretaceous periods. Features hypertext dinosaur encyclopedia covering 150 million years of paleontology. Includes animated video simulations, three-dimensional dinosaur museum, narration, games, activities, and color illustrations.</description>
<subject>Dinosaurs--Juvenile software.</subject>
<subject>Dinosaurs.</subject>
<identifier>URN:ISBN:1569972133</identifier>
</srw_dc:dc></zs:recordData><zs:recordPosition>1</zs:recordPosition></zs:record></zs:records></zs:searchRetrieveResponse>

</nowiki>
</pre>

== Types and Roles ==
(Section is informative only as a place to capture various parts of publication citations.)

There are many different types of publications and this information should be captured in the citation. Possible types include:
* Novel/fiction (specify type -- literature, sci-fi, romance, etc.?)
* Non-fiction
* Poem
* Play
* Magazine
* Reference (seperate out encyclopedia, dictionary, almanac, etc.?)
* Journal
* Article within a journal
* Chapter within a book
* Dissertation
* Web Site
* Page within a web site
* Music Recording
* Video Recording
* Interview
* Physical object (Statue, Painting, etc.)
* ??

Question:
Certain works have specific types of citations, for example, the Bible--and, I assume, other religious works--have very specific citation formats with different relevant information (chapter/verse) than others, as do the works of Shakespeare. Should these be considered seperate types/roles?

A: I think in terms of types, we should at least note the items (chapter, verse, etc). How they get dealt with is still way up in the air. - [[User:Tim White|Tim White]]

Likewise, there are several different roles associated with publications -- author, co-author, editor, translator, etc. Should these be captured under a master "role" or treated as individual elements?

A: Good question. I think there is an important distinction, but whether we follow a design pattern of "role-*" (or more likely "author-*) or some other pattern hasn't been discussed yet. - Tim

citation-formats

2006-01-24T10:35:48Z

MarkRickerby: /* Fields Used by Bibtex */ fixed table formatting to improve readability

= Citation Formats =

This page will display several different types of citation format types. The idea is to compare what properties are common amonst all of the formats and which ones should be blended into this microformat.

See also:
* [[cite]]
* [[cite-brainstorming]]
* [[cite-examples]]

== Comparison chart ==
The following chart maps the terms from one implementation to another. This is important because if all the properties are introduced to this microformats, then its possible to map them to a number of different formats. The table currently only uses Dublin Core, MODS, and bibTeX. Each column has all the properties and their equivalent in each format. If there is no corresponding property the cell is grey. At the bottom of the list are the unique terms to each format. Dublin core has basic terms and terms that extend the basic ones. If the property is an extention of a basic term it is in ()'s. MODS uses XML, so any sub-properties are listed in their tree form, property/sub-property.

THIS IS NOT DEFINIATIVE, any errors should be corrected. More formats will be added to the list as they are mapped.

<table border="1">
<tr>
<th>Dublin Core</th>
<th>MODS</th>
<th>bibTeX</th>
<th>Z39.80</th>
</tr>
<tr>
<td>Title (alternative)</td>
<td>titleInfo/title<br/>titleInfo/PartNum</td>
<td>booktitle<br/>title<br/>chapter<br/>number<br/>pages<br/>volume<br/>series</td>
<td>Analytic Title<br/>
Collective or Series Title<br/>
Monographic Title<br/>
Work Fraction Title<br/>
Location of Conference<br/>
Main Entry<br/>
Name of Conference<br/>
Number of Meeting<br/>
Other Title<br/>
Parallel Title<br/>
Title Abbriviation<br/>
Title of Conference Proceedings<br/>
Translated Title<br/>
Uniform Title<br/>
Abbriviated Translated Title<br/>
Symposium or Session Title<br/>
Collective or Series Edition<br/>
Video/Film Edition<br/>
</td>
</tr>
<tr>
<td>creator</td>
<td>name/namePart</td>
<td>author<br/>creator</td>
<td>Author, Primary<br/>
Corporate Author, Primary<br/>
Abstract Author<br/>
Authorship Statement<br/>
Acknowledged Supporters<br/>
Assignee for Patents<br/>
Chairperson of Conference<br/>
Director of AV Program<br/>
Other Author<br/>
Reviewed Book Author<br/>
Studio<br/>
Sponsor of Conference<br/>
Staff/Cast<br/>
Symposium Chairperson<br/>
Author Address or Affiliation<br/>
Author Country<br/>
Electronic Address of Author<br/>
</td>
</tr>
<tr>
<td>subject</td>
<td>subject/topic</td>
<td>keywords</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Description (abstract | tableOfContents)</td>
<td>abstract<br/>note<br/>tableOfContents</td>
<td>abstract<br/>annotation<br/>note<br/>contents</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Contributer</td>
<td>name</td>
<td>editor?</td>
<td>Book/Report/Volume Editor<br/>
Producer<br/>
Translator<br/>
</td>
</tr>
<tr>
<td>Date (available | created | dateAccepted | dateCopyrighted | dateSubmitted | issued | modified | valid)</td>
<td>originInfo/dateIssued<br/>originInfo/dateCreated<br/>originInfo/dateCaptured<br/>originInfo/dateOther</td>
<td>month<br/>year</td>
<td>Copyright Year<br/>Date-generic<br/>Date of conference<br/>Date of Publication<br/>Date of Update/Revisou/Issuance of Database Record<br/>Former Date<br/>Entry date for Database Record<br/>Database Update<br/>Year of Publication</td>
</tr>
<tr>
<td>Type</td>
<td>typeOfResource<br/>genre</td>
<td>@class<br/>type</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Format (extent | medium)</td>
<td>physicalDescription/internetMediaType<br/>physicalDescription/extent<br/>physicalDescription/form</td>
<td>howpublished</td>
<td>needs mapping</td>
</tr>
<tr>
<td>identifier (bibliographicCitation)</td>
<td>identifier</td>
<td>ISBN<br/>ISSN<br/>LCCN<br/>URL</td>
<td>ISBN<br/>Identifier<br/>Report Identfier<br/>ISSN</td>
</tr>
<tr>
<td>Source</td>
<td>relatedItem</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>language</td>
<td>language</td>
<td>language</td>
<td bgcolor="#cccccc"></td>
</tr>
<tr>
<td>Relation (...)</td>
<td>relatedItem/...</td>
<td>crossRef</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Coverage (spacial | temporal)</td>
<td>subject/temporal<br/>subject/geographic<br/>subject/hierarchicalGeographic<br/>subject/cartographics</td>
<td></td>
<td>needs mapping</td>
</tr>
<tr>
<td bgcolor="#cccccc"></td>
<td>classifications</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>Rights (accessRights | license)</td>
<td>accessConditions</td>
<td>copyright</td>
<td>needs mapping</td>
</tr>
<tr>
<td>publisher</td>
<td bgcolor="#cccccc"></td>
<td>publisher</td>
<td>Publisher Name<br/>
Place of Publication<br/>
Country of Publication<br/>
Generic Address<br/>
</td>
</tr>
<tr>
<td>audience (educationLevel | mediator)</td>
<td>targetAudience</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td bgcolor="#999999">accualMethod<br/>accualPeriodicaty<br/>accualPolicy<br/>instrcutionalMethod<br/>provenance<br/>rightsHolder</td>
<td bgcolor="#999999">location<br/>extension<br/>recordInfo</td>
<td bgcolor="#999999">address<br/>afflilication<br/>location<br/>edition<br/>institution<br/>journal<br/>key<br/>mrnumber<br/>organization<br/>price<br/>school<br/>size</td>
<td bgcolor="#999999">(the following need to be mapped to the above rows or left here as other)<br/><br/>
Database Source<br/>
Databse Record Identifier<br/>
Database Producer Name<br/>
Rights Management<br/>
Subfile<br/>
Other Source Identifier<br/>
Vendor Record Identifier<br/>
Database Vendor Name<br/>
Column Number<br/>
Edition<br/>
Frequency of Publication<br/>
Internet Location for Document<br/>
Supplement/Part/Special number identifer<br/>
Issue Identifier<br/>
Location in Work<br/>
Number of the Chapter<br/>
Number in Series<br/>
Volume Identifier<br/>
Section Indentifier<br/>
</td>
</tr>
</table>

== Dublin Core Metadata ==
[http://dublincore.org/ Dublin Core] metadata uses a small vocabulary to descibe the data.
* contributor
* coverage
* creator
* date
* description
* format
* identifier
* language
* publisher
* relation
* rights
* source
* subject
* title
* type

From those there are specialised types where are just refinments of the previous, for example:

* abstract refines description.
* accessRights refines rights

[http://dublincore.org/documents/dc-citation-guidelines/ Guidelines for Encoding Bibliographic Citation Information in Dublin Core Metadata]

== MODS (Metadata Object Description Schema) ==
This is a format developed for the Libray of Congress for a bibliographic element set that may be used for a variety of purposes, and particularly for library applications.

[http://www.loc.gov/standards/mods/ http://www.loc.gov/standards/mods/]

(the schema is very big, once i devote the proper time to review it, i will post more about the structure -brian)

== XMLResume ==
<pre>
<!ELEMENT pubs (pub+)>
<!ENTITY % pubElements "(artTitle|bookTitle|author|date|pubDate|publisher|pageNums|url)">
<!ELEMENT pub (para | %pubElements;)*>
<!ATTLIST pub id ID #IMPLIED>
<!ELEMENT artTitle (#PCDATA | link)*>
<!ELEMENT bookTitle (#PCDATA | link)*>
<!ELEMENT author (#PCDATA)>
<!ATTLIST author name IDREF #IMPLIED>
<!ELEMENT pubDate (month?, year)> 
<!ELEMENT publisher (#PCDATA | link | url)*>
<!ELEMENT pageNums (#PCDATA)>
</pre>

== BibTeX ==
=== Fields Used by Bibtex ===

<table border="1" width="100%">
<tr>
<td><strong>abstract:</strong></td>
<td>An abstract of the work.</td>
</tr>
<tr>
<td><b>address:</b></td>
<td>Publisher's address. For major publishing houses,
just the city is given. For small publishers, you can help the reader by giving the complete address.</td>
</tr>
<tr>
<td><strong>affiliation:</strong></td>
<td>The author's affiliation.</td>
</tr>
<tr>
<td><b>annote:</b></td>
<td>An annotation. It is not used by he standard bibliography styles, but may be used by others that produce an annotated bibliography.</td>
</tr>
<tr>
<td><b>author:</b></td>
<td>The name(s) of the author(s).</td>
</tr>
<tr>
<td><b>booktitle: </b></td>
<td>Title of a book, part of which is being cited. For book entries, use the <strong>title</strong> field instead.</td>
</tr>
<tr>
<td><b>chapter:</b></td>
<td>A chapter (or section) number.</td>
</tr>
<tr>
<td><strong>contents:</strong></td>
<td>A Table of Contents.</td>
</tr>
<tr>
<td><strong>copyright:</strong></td>
<td>Copyright information.</td>
</tr>
<tr>
<td><strong>crossref:</strong></td>
<td>The database key of the entry being cross-referenced.</td>
</tr>
<tr>
<td><b>edition: </b></td>
<td>The edition of a book - for example
"Second". Notice that it is in capitals.</td>
</tr>
<tr>
<td><b>editor: </b></td>
<td>Name(s) of editor(s). If there is also an author field, then the editor field gives the editor of the book or collection in which the reference appears.</td>
</tr>
<tr>
<td><b>howpublished:</b></td>
<td>How something strange has been published. The first word should be capitalized.</td>
</tr>
<tr>
<td><b>institution:</b></td>
<td>The sponsoring institution of a technical report.</td>
</tr>
<tr>
<td><strong>ISBN:</strong></td>
<td>The International Standard Book Number.</td>
</tr>
<tr>
<td><strong>ISSN:</strong></td>
<td>The International Standard Serial Number. Used to
identify a journal.</td>
</tr>
<tr>
<td><b>journal: </b></td>
<td>A journal name. Abbreviations are provided for many journals.</td>
</tr>
<tr>
<td><b>key: </b></td>
<td>Used for alphabetizing and creating a label when the author and editor fields are missing. This field should not be confused with the key that appears at the beginning of the reference.</td>
</tr>
<tr>
<td><strong>keywords:</strong></td>
<td>Key words used for searching or possibly for annotation.</td>
</tr>
<tr>
<td><strong>language:</strong></td>
<td>The language the document is written in.</td>
</tr>
<tr>
<td><strong>LCCN:</strong></td>
<td>The Library of Congress Call Number.</td>
</tr>
<tr>
<td><strong>location:</strong></td>
<td>A location associated with the entry, such as the city in which a conference took place.</td>
</tr>
<tr>
<td><b>month: </b></td>
<td>The month in which the work was published or, for an unpublished work, in which it was written.</td>
</tr>
<tr>
<td><strong>mrnumber:</strong></td>
<td>The <em>Mathematical Reviews</em> number.</td>
</tr>
<tr>
<td><b>note:</b></td>
<td>Any additional information that can help the reader. First word should be capitalized.</td>
</tr>
<tr>
<td><b>number: </b></td>
<td>The number of a journal, magazine, technical report, or of a work in a series. An issue of a journal or magazine is usually identified by its volume and number; the organization that issues a technical report usually gives it a number; and sometimes books are given numbers in a named series.</td>
</tr>
<tr>
<td><b>organization: </b></td>
<td>The organization that sponsors a conference or publishes a manual.</td>
</tr>
<tr>
<td><b>pages:</b></td>
<td>One or more page numbers or ranges of number, such as 37--42, or 7,53,82--94.</td>
</tr>
<tr>
<td><strong>price:</strong></td>
<td>The price of the material.</td>
</tr>
<tr>
<td><b>publisher:</b></td>
<td>The publisher's name.</td>
</tr>
<tr>
<td><b>school:</b></td>
<td>The name of the school where a thesis was written.</td>
</tr>
<tr>
<td><b>series:</b></td>
<td>Then name given a series or set of books. When citing an entire book, the title field gives its title and the optional series field gives the name of a series in which the book was published.</td>
</tr>
<tr>
<td><strong>size:</strong></td>
<td>The physical dimensions of the work.</td>
</tr>
<tr>
<td><b>title:</b></td>
<td>The work's title.</td>
</tr>
<tr>
<td><b>type:</b></td>
<td>The type of technical report - for example,
"Research Note".</td>
</tr>
<tr>
<td><strong>url:</strong></td>
<td>The WWW Universal Resource Locator that points to the item being referenced. Often used for technical reports to point to the FTP site where it resides.</td>
</tr>
<tr>
<td><b>volume:</b></td>
<td>The volume of a journal or multivolume book.</td>
</tr>
<tr>
<td><b>year:</b></td>
<td>The year of publication or, for an unpublished work, the year it was written. It should only consist of numerals, such as 1976.</td>
</tr>
</table>

=== BibTeX citation Types ===
A reference can be to any of a variety of types. Following is a list of types. Each one also explains the fields associated with that type. Any fields not listed as required or optional are considered to be ignored.
<table border="1" width="100%">
<tr>
<td><b>article:</b></td>
<td>An article from a journal or magazine. Required
fields: author, title, journal, year. Optional fields:
volume, number, pages, month, note, key.</td>
</tr>
<tr>
<td><b>book:</b></td>
<td>A book with an explicit publisher. Required fields:
author or editor, title, publisher, year. Optional
fields: volume, series, address, edition, month, note,
key.</td>
</tr>
<tr>
<td><b>booklet: </b></td>
<td>A work that is printed and bound, but without a named
publisher or sponsoring institution. Required fields:
title. Optional fields: author, howpublished, address,
month, year, note, key.</td>
</tr>
<tr>
<td><strong>collection:</strong></td>
<td>A collection of works. Same as <a href="#proceedings">Proceedings</a>.</td>
</tr>
<tr>
<td><b>conference:</b></td>
<td>The same as <a href="#inproceedings">Inproceedings</a>.</td>
</tr>
<tr>
<td><b>inbook:</b></td>
<td>A part of a book, which may be a chapter and/or a
range of pages. Required fields: author or editor, title,
chapter and/or pages, publisher, year. Optional fields:
volumer, series, address, edition, month, note, key.</td>
</tr>
<tr>
<td><b>incollection:</b></td>
<td>A part of a book with its own title. Required fields:
author, title, booktitle, publisher, year. Optional
fields: editor, pages, organization, publisher, address,
month, note, key.</td>
</tr>
<tr>
<td><a name="inproceedings"></a><b>inproceedings:</b></td>
<td>An article in a conference proceedings. Required
fields: author, title, booktitle, year. Optional fields:
editor, pages, organization, publisher, address, month,
note, key.</td>
</tr>
<tr>
<td><b>manual: </b></td>
<td>Technical documentation. Required fields: title.
Optional fields: author, organization, address, edition,
month, year, note.</td>
</tr>
<tr>
<td><b>mastersthesis:</b></td>
<td>A Master's thesis. Required fields: author, title,
school, year. Optional fields: address, month, note, key.</td>
</tr>
<tr>
<td><b>misc:</b></td>
<td>Use this type when nothing else fits. Required
fields: none. Optional fields: author, title,
howpublished, month, year, note, key.</td>
</tr>
<tr>
<td><strong>patent:</strong></td>
<td>A patent.</td>
</tr>
<tr>
<td><b>phdthesis:</b></td>
<td>A Ph.D. thesis. Required fields: author, title,
school, year. Optional fields: address, month, note, key.</td>
</tr>
<tr>
<td><a name="proceedings"></a><b>proceedings:</b></td>
<td>The proceedings of a conference. Required fields:
title, year. Optional fields: editor, publisher,
organization, address, month, note, key.</td>
</tr>
<tr>
<td><b>techreport:</b></td>
<td>A report published by a school or other institution,
usually numbered within a series. Required fields:
author, title, institution, year. Optional fields: type,
number, address, month, note, key.</td>
</tr>
<tr>
<td><b>unpublished:</b></td>
<td>A document with an author and title, but not formally
published. Required fields: author, title, note. Optional
fields: month, year, key.</td>
</tr>
</table>

==== Examples ====
<pre><nowiki>
@book{kn:gnus,

AUTHOR = "Donald E. Knudson",
TITLE = "1966 World Gnus Almanac",
PUBLISHER = {Permafrost Press},
ADDRESS = {Novosibirsk} }

<div class="book" id="kn:gnus">
<div class="author">Donald E. Knudson</div>
<div class="title">1966 World Gnus Almanac</div>
<div class="publisher">Permafrost Press</div>
<div class="address">Novosibirsk</div>
</div>

@article{XAi_HSCheng_1994a,

author = "X. Ai and H. S. Cheng",
title = "Influence of moving dent on point {EHL} contacts",
journal = "Tribol. Trans.",
volume = "37",
year = "1994",
pages = "323--335",
}

<div class="article" id="XAi_HSCheng_1994a">
<div class="author">X. Ai and H. S. Cheng</div>
<div class="title">Influence of moving dent on point {EHL} contacts</div>
<div class="journal">Tribol. Trans.</div>
<div class="volume">37</div>
<div class="year">1994</div>
<div class="pages">323--335</div>
</div>
</nowiki></pre>

== OpenURL ==

OpenURL aka [http://www.niso.org/standards/standard_detail.cfm?std_id=783 Z39.88] defines a standard way of bundling citation data in a URL. It is widely deployed in academic libraries around the world to provide access to licensed content via link resolvers such as [http://www.exlibrisgroup.com/sfx_openurl.htm SFX]. The Context Object in Span ([http://ocoins.info/ COinS]) community standard represents one way to embed OpenURLs in XHTML without including a resolver target.

<pre>
<nowiki>
<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.issn=1045-4438"></span>
</nowiki>
</pre>

As you can see this isn't very much like semantic XHTML at all. However significant work has gone into defining the set of Key/Encoded Values (KEVs) that can be used in various [http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats types] of citations: [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:book book], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:dissertation dissertation], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:journal journal], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:patent patent]. It would be possible to simply provide a standard XHTML bundling for these keys as a microformat.

=== Example ===

<pre>
<nowiki>

<div class="openurl-journal">
<span class="aulast">Berners-Lee</span>,
<span class="aufirst">Tim</a>; Hendler, James; Lassila, Ora.</span>
"<span class="atitle">The Semantic Web</span>".
<span class="jtitle">Scientific American</span>
<span class="volume">284</span>(<span class="issue">5</span>), pp.
pp. <span class="pages">34-43</span>.
<span class="issn">0036-8733</span>
</div>

</nowiki>
</pre>

Using OpenURL in this way would enable third party applications that could, say grab citation metadata from a blog, and without much work fire it off at your university's or public libraries openurl resolver to see if the article is available via a licensed databases. The benefits [http://www.infotoday.com/newsbreaks/nb050801-1.shtml have] [http://www.ariadne.ac.uk/issue43/chudnov/ been] [http://www.wallandbinkley.com/quaedam/?p=30 noted] [http://hublog.hubmed.org/archives/001163.html elsewhere].

== Z39.80 ==
I'm not sure the best place for a guide to Z39.80 so please add links as you see fit:

[http://www.niso.org/standards/resources/drft4rev.html http://www.niso.org/standards/resources/drft4rev.html]

== DocBook ==

A subset of the DocBook vocabulary is dedicated to representing a bibliography: http://www.docbook.org/tdg/en/html/bibliography.html

<pre><nowiki>
<!DOCTYPE bibliography PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
<bibliography>
<title>Languages and Semantics</title>
<bibliodiv>
<title>Books</title>
<biblioentry>
<title>Course in General Linguistics</title>
<abbrev>deSaussure59</abbrev>
<author><firstname>Ferdinand</firstname><surname>de Saussure</surname></author>
<editor><firstname>Charles</firstname><surname>Bally</surname></editor>
<editor><firstname>Albert</firstname><surname>Sechehaye</surname></editor>
<othercredit role="translator"><firstname>Wade</firstname><surname>Baskin</surname></othercredit>
<copyright>
<year>1959</year>
<holder>The Philosophical Library Inc.</holder>
</copyright>
<isbn>07-016524-6</isbn>
<publisher>
<publishername>McGraw-Hill Book Company</publishername>
</publisher>
</biblioentry>
</bibliodiv>
</bibliography>
</nowiki></pre>

== Ann Arbor District Library XML feed ==

Here's a record in XML format from their project to simplify
access to the catalog. More discussion on [http://www.blyberg.net John Blyberg's blog].

<pre>
<nowiki>
<p:Record>
<callnum>823 Bu</callnum>
<author>Burkart, Gina, 1971-</author>
<fulltitle>A parent's guide to Harry Potter / Gina Burkart</fulltitle>
<title>A parent's guide to Harry Potter </title>
<pubinfo>Downers Grove, Ill. : InterVarsity Press, c2005</pubinfo>
<desc>112 p</desc>
<bibliography>Includes bibliographical references</bibliography>
<contents>
The Harry hype -- More than a story -- The modern fairy tale -- Discussing fantasy with children -- Morals, not magic -- The real issues in Harry Potter -- Dealing with traumatic experiences -- Facing fears -- Battling bullies -- Delving into diversity -- Hiding hurts -- Letting go of anger -- Getting help -- Choosing good over evil -- The power of love -- Facing spiritual battles
</contents>
<isbn>0830832882</isbn>
<price>$11.00</price>
<lang>eng</lang>
<copies>0</copies>
<catdate>08-16-2005</catdate>
<mattype>a</mattype>
<avail>No copies available</avail>
<recordlink xlink:href="http://www.aadl.org/cat/seek/record=1249810"/>
</p:Record>
</nowiki>
</pre>

== SimpleDC supported by the zoom toolkit ==

<pre>
<nowiki>
<dc xmlns="http/www.loc.gov/zing/srw/dcschema/v1.0/">
<title>Kantor Salomon Sulzer und seine Zeit : eine Dokumentation /</title>
<creator>Avenary, Hanoch.</creator>
<creator>Pass, Walter.</creator>
<creator>Vielmetti, Nikolaus.</creator>
<creator>Adler, Israel, (1925-)</creator>
<subject>Sulzer, Salomon, -- 1804-1890.</subject>
<subject>Jewish composers -- Austria -- Biography.</subject>
<subject>Cantors, Jewish -- Biography.</subject>
<date>1985</date>
<publisher>Sigmaringen : Jan Thorbecke Verlag</publisher>
<identifier>3799540636</identifier>
<description>300 p., [12] p. of plates : ill., music, ports. ; 24 cm.</description>
</dc>
</nowiki>
</pre>

this is the output of marc.toSimpleDC()

== SRU from the Library of Congress ==

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=dinosaur&maximumRecords=1&recordSchema=dc

<pre>
<nowiki>
<?xml version="1.0"?>
<zs:searchRetrieveResponse xmlns:zs="http://www.loc.gov/zing/srw/"><zs:version>1.1</zs:version><zs:numberOfRecords>1701</zs:numberOfRecords><zs:records><zs:record><zs:recordSchema>info:srw/schema/1/dc-v1.1</zs:recordSchema><zs:recordPacking>xml</zs:recordPacking><zs:recordData><srw_dc:dc xmlns:srw_dc="info:srw/schema/1/dc-schema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://purl.org/dc/elements/1.1/" xsi:schemaLocation="info:srw/schema/1/dc-schema http://www.loc.gov/z3950/agency/zing/srw/dc-schema.xsd">
<title>3-D dinosaur adventure [computer file].</title>
<creator>Knowledge Adventure, Inc.</creator>
<type>software, multimedia</type>
<publisher>Glendale, CA : Knowledge Adventure,</publisher>

<date>c1995.</date>
<language>eng</language>
<description>Employs a dinosaur theme-park setting to introduce users to Triassic, Jurassic, and Cretaceous periods. Features hypertext dinosaur encyclopedia covering 150 million years of paleontology. Includes animated video simulations, three-dimensional dinosaur museum, narration, games, activities, and color illustrations.</description>
<description>Ages 5 to 10.</description>
<description>System requirements for PC: 486SX/25MHz processor or higher; 8MB RAM; Windows 3.1, 3.11, or 95; SVGA 256-color graphics adapter; hard drive with 5MB free space; double-speed CD-ROM drive; MPC-compatible sound card; mouse.</description>
<description>System requirements for Macintosh: 68040 or Power PC processor; 8MB RAM; System 7.0 or higher; 256-color graphics capability; thirteen-inch color monitor or larger; hard drive with 4MB free space; double-speed CD-ROM drive.</description>

<description>Ages 5 to 10.</description>
<description>Employs a dinosaur theme-park setting to introduce users to Triassic, Jurassic, and Cretaceous periods. Features hypertext dinosaur encyclopedia covering 150 million years of paleontology. Includes animated video simulations, three-dimensional dinosaur museum, narration, games, activities, and color illustrations.</description>
<subject>Dinosaurs--Juvenile software.</subject>
<subject>Dinosaurs.</subject>
<identifier>URN:ISBN:1569972133</identifier>
</srw_dc:dc></zs:recordData><zs:recordPosition>1</zs:recordPosition></zs:record></zs:records></zs:searchRetrieveResponse>

</nowiki>
</pre>

== Types and Roles ==
(Section is informative only as a place to capture various parts of publication citations.)

There are many different types of publications and this information should be captured in the citation. Possible types include:
* Novel/fiction (specify type -- literature, sci-fi, romance, etc.?)
* Non-fiction
* Poem
* Play
* Magazine
* Reference (seperate out encyclopedia, dictionary, almanac, etc.?)
* Journal
* Article within a journal
* Chapter within a book
* Dissertation
* Web Site
* Page within a web site
* Music Recording
* Video Recording
* Interview
* Physical object (Statue, Painting, etc.)
* ??

Question:
Certain works have specific types of citations, for example, the Bible--and, I assume, other religious works--have very specific citation formats with different relevant information (chapter/verse) than others, as do the works of Shakespeare. Should these be considered seperate types/roles?

A: I think in terms of types, we should at least note the items (chapter, verse, etc). How they get dealt with is still way up in the air. - [[User:Tim White|Tim White]]

Likewise, there are several different roles associated with publications -- author, co-author, editor, translator, etc. Should these be captured under a master "role" or treated as individual elements?

A: Good question. I think there is an important distinction, but whether we follow a design pattern of "role-*" (or more likely "author-*) or some other pattern hasn't been discussed yet. - Tim

rel-bookmark

2006-01-22T07:25:18Z

MarkRickerby: removed spam links, added redirect to rel-design-pattern

#REDIRECT [[rel-design-pattern#rel.3D.22bookmark.22]]

Main Page

2006-01-22T07:09:14Z

MarkRickerby: del ( braces ) from hatom link

__NOTOC__
__NOTOC__
= Microformats Wiki =

'''Please read [[how-to-play]] before making any edits.'''

'''Please read [[process]] before proposing any new microformats.'''

== Introduction ==

What are microformats? See the [http://microformats.org/about/ about page] for an overview, and the [[introduction]] page for more info. Recent [[press]] and [[presentations]] are also a good place for some background reading as well. Frequently asked questions are answered in the [[faq]].

One popular definition from our [http://microformats.org/discuss/ mailing list] is "simple conventions for embedding semantics in HTML to enable decentralized development." More precisely, microformats can be defined as:
:simple conventions
:for embedding semantic markup
::for a specific problem domain
:in human-readable (X)HTML/XML documents, Atom/RSS feeds, and "plain" XML
::that normalize existing content usage patterns
::using brief, descriptive class names
::often based on existing interoperable standards
:to enable decentralized development
::of resources, tools, and services

"Or do you just use your browser to browse? That's so 20th century." -- [http://diveintomark.org Mark Pilgrim]

== Specifications ==
[[microformats|Microformats]] open standards specifications (see also: [[implementations]])
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[rel-license]]
* [[rel-nofollow]]
* [[rel-tag]]
* [[vote-links|VoteLinks]]
* [http://gmpg.org/xfn/ XFN] (see also: [[xfn-implementations]])
* [http://gmpg.org/xmdp/ XMDP]
* [[xoxo|XOXO]]

== Drafts ==
* [[adr|adr]]
* [[geo|geo]]
* [[hreview|hReview]]
* [[rel-directory]]
* [[rel-enclosure]]
* [[relpayment-research | rel-payment]]
* [[robots-exclusion|Robots Exclusion]]
* [[xfolk|xFolk]]
* [[rel-home]] {{NewMarker}}
* [[hatom|hAtom]] {{NewMarker}}

== Design Patterns ==

Design patterns give microformat authors a vocabulary for expressing their ideas consistently with what has already been done. ''If you're tempted to try your hand at writing a microformat '''[[process|read this first]]'''!''

* [[datetime-design-pattern]]
* [[class-design-pattern]]
* [[rel-design-pattern]]
* [[abbr-design-pattern]]
* [[existing-classes|class names defined across all microformats]]

== Exploratory discussions ==
Research and analysis of real-world [[examples]], existing formats, and brainstorming to motivate the microformat.
*[[attention]]
*[[blog-description-format]]
*[[blog-post-examples]], [[blog-post-formats]], [[blog-post-brainstorming]] (yields [[hatom|hAtom]])
*[[book-examples]], [[book-formats]], [[book-brainstorming]]
*[[chat-examples]]
*[[cite|Planning pages for a citation microformat]], [[cite-formats]], [[cite-examples]], [[citation-brainstorming]]
*[[comments-formats]]
*[[directory-inclusion-examples]], [[directory-inclusion-formats]]. (see also [[rel-directory]])
*[[forms-examples]]
*[[genealogy-formats]]
*[[last-modified-examples]], [[last-modified-formats]], [[last-modified-brainstorming]]
*[[listing-examples]], [[listing-formats]], [[listing-brainstorming]]
*[[location-formats]]. (see also [[adr]] and [[geo]])
*[[media-metadata-examples]]
*[[mfo-examples]]
*[[other-formats]]
*[[recipe-examples]]
*[[requirements-testing]], [[requirements-testing-examples]]
*[[rest-examples]]
*[[resume-brainstorming]], [[resume-formats]]
*[[search-results-example]]
*[[show-brainstorming]]
*[[showroll-brainstorming]]
*[[table-examples]]
*[[tagspeak-examples]]
*[[transit-table-examples]]
*[[widget-examples]], [[widget-brainstorming]]
*[[wiki-formats]]
*[[xmdp-brainstorming]] (see also [[xmdp-faq]])

== Examples ==
* [[examples]]
* [[zen-garden]] {{NewMarker}}

== Tools & Test Cases & Additional Research ==

The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting tools and services that need to process more than one microformat. This section is intended for editors, parsers, validators, test cases, and other information relevant across multiple microformats.

*[[parsing-microformats]]
*[[selected-test-cases-from-the-web]]
*[[vcard-implementations]], [[vcard-errata]]
*[[icalendar-implementations]]
*[[faqs-for-rdf]]
*[[why-are-content-standards-hard]]

== shared work areas ==
* [[buttons]] {{NewMarker}}
* [[demo]] - a page with links for quickly demonstrating microformats working in practice.
* [[to-do]]
* [[marked-for-deletion]]

== microformats wiki in other languages ==

You may read and edit microformats articles in <del>many different</del> other languages

=== microformats wiki languages with over 2 articles ===

* [[Main_Page-fr|Français (French)]]
* [[Main_Page-jp|日本語 (Japanese)]] {{NewMarker}}

=== Start a microformats wiki in another language ===

Don't see the language you want? Help translate the microformats wiki into another language!

We're still figuring this out.

For now, see the [http://en.wikipedia.org/wiki/Wikipedia:Multilingual_coordination Wikipedia page on Multilingual coordination], and [http://meta.wikimedia.org/wiki/How_to_start_a_new_Wikipedia How to start a new Wikipedia] for some good general tips, advice, and community conventions.

You may want to start with the list of [[stable-pages]], which are pages that are relatively stable, and have only minimal/editorial changes, which makes them much easier to keep in sync with the English versions, by using the [[Special:Watchlist|my watchlist]] feature (use it to watch the pages you've translated for changes).

Page naming: for the translated version of a page, use the same name for the page, and simply add the RFC 3066 language identifier code as a dash suffix. E.g. for the French version, [[Main_Page]] becomes [[Main_Page-fr]], and [[how-to-play]] becomes [[how-to-play-fr]].

==== more languages folks want to see ====

* Chinese: 微支付 (Microformats) (see [http://msittig.blogspot.com/2005/11/since-i-translated-schedule-of.html source of translation])

Template:NewMarker

2006-01-22T07:08:40Z

MarkRickerby: restyled to match colors from uf identity swatch

resume-examples

2006-01-18T22:56:59Z

MarkRickerby: added cv

= Resume Examples =

== Resumes from the wild ==

=== Tantek Çelik ===
* [http://tantek.com/projects/resume.html Tantek Çelik] (needs updating, this is about a year old)

==== Qualifications ====

Tantek has a list of his qualifications:
<pre><nowiki>
<ul class="quals">
<li>
Manager & technical leader (10 years). Led and set direction for teams of up to 12.
</li>
...
</nowiki></pre>

==== Employment ====

Tantek then lists his employment history:
<pre><nowiki>
<h2>Employment & Products</h2>
<ol class="experience">
<li class="job" id="technorati">
<h3><span class="dates">2004 - present</span><a href="http://www.technorati.com" class="company">Technorati</a>, <a href="http://maps.yahoo.com/py/maps.py?BFCat=&Pyt=Tmap&addr=665+3rd+St&csz=San+Francisco+CA+94107" class="location">San Francisco, CA</a></h3>
<h4><span class="dates">2004 July - present</span>
<span class="jobtitle">Senior Technologist.</span></h4>
Investigate and define new standards and new technologies companywide. Lead adoption of and implementation of valid semantic XHTML and CSS across all web sites. A primary contributor to the design, development, and launch of <a href="http://politics.technorati.com">politics.technorati.com</a> "Election Watch 2004" site in <em>13 days</em>.
<div class="completed">
<h5>Websites Developed and Launched</h5>
<ul class="websites">
<li><a href="http://www.technorati.com/">Technorati main site</a> (valid XHTML+CSS green redesign, XHTML strict update)</li>
<li><a href="http://politics.technorati.com/">Election Watch 2004</a> (initial valid XHTML+CSS release, XHTML strict update with new Attention Index, Charts features)</li>
</ul>
</div>
</li>
</nowiki></pre>

The implied scheme seems to be (in CSS selectors):

<pre><nowiki>
ol.experience
ol li.job
ol li.job .dates
ol li.job .company
ol li.job .jobtitle
ol li.job .completed
ol li.job .products
</nowiki></pre>

The set of .jobtitle, .completed and .products is repeated for cases where he had more than one position at a company.

==== patents ====
Tantek also has a section on patents:

<pre><nowiki>
<div class="patents" id="patents">
<h2><abbr title="United States">US</abbr> Patents</h2>
<div class="issued">
<h3 class="sidelabel">Issued(6):</h3>
<ol>
<li id="PatNo5752056" value="5752056">
<h4><a href="http://patft.uspto.gov/netacgi/nph-Parser?d=PALL&p=1&u=%2Fnetahtml%2Fsrchnum.htm&r=1&f=G&l=50&s1=5,752,056&OS=&RS=">System for binding document parts and handlers by fidelity of parts or by automatic translation of parts</a></h4>
<a class="altlink" href="http://www.delphion.com/details?pn=US05752056__">(delphion US05752056)</a>
<a class="inventor">[sole inventor]</a></li>
...
</nowiki></pre>

I'm not going to dig into this, because I already doubt it will be common enough for inclusion. --[[User:RyanKing|RyanKing]] 13:33, 18 Jan 2006 (PST)

==== Publications ====

<pre><nowiki>
<div class="publications" id="publications">
<h2>Publications & Presentations</h2>

<h3 id="recs">Recommendations and Candidate Recommendations (CRs)</h3>
<ol>

<li>Çelik T.
"<a class="title" href="http://www.w3.org/TR/css3-ui">CSS3 Basic User Interface Module</a>"
<a class="publisher" href="http://w3.org/TR">W3C Technical Reports and Publications</a>
<<a class="URL" href="http://www.w3.org/TR/2004/CR-css3-ui-20040511">http://www.w3.org/TR/2004/CR-css3-ui-20040511</a>>
(2004)
</li>
</nowiki></pre>

Definite material for citation microformat work. Need analysis in that context. --[[User:RyanKing|RyanKing]] 13:33, 18 Jan 2006 (PST)

==== presentations ====
<pre><nowiki>
<h3 id="presentations">Invited Presentations</h3>
<ol>
<li>Marks K, Çelik T.
"<a class="title" href="http://sdforum.org/SDForum/Templates/CalendarEvent.aspx?CID=1524"> Semantic XHTML: Can your website be your API? - Using semantic XHTML to show what you mean</a>",
<a class="publisher" href="http://sdforum.org/"><abbr title="Software Development Forum">SD Forum</abbr></a>
<a class="event" href="http://www.sdforum.org/SDForum/Templates/Level1.aspx?pid=10117&sid=7">Web Services <abbr title="Special Interest Group">SIG</abbr></a>,
<span class="location">eBay's Silicon Valley Conference Center 2161 North First Street San Jose, CA 95131</span>
(28 September 2004)
</li>
...
</nowiki></pre>

Tantek has a list of presentations, which includes presenters' names, event URL, publisher (seems to be used like 'organizer'), the event (ie, conference, workshop) URL and name, location and date.

==== Education ====
<pre><nowiki>
<div class="education">
<h2>Education</h2>
<ol>
<li class="school">
<h3><span class="dates">20 June 2001</span><a href="http://www.edwardtufte.com/tufte/" class="institution">Edward Tufte</a></h3>
<ul class="courses">
<li><a href="http://www.edwardtufte.com/tufte/courses">Presenting Data and Information</a></li>
</ul>
</li>
....
</nowiki></pre>

Tantek lists his education, including 'dates', a list of 'courses' (which includes name and optional URL) and list of degrees.

==== Awards ====
<pre><nowiki>
<div class="awards" id="awards">
<h2>Awards</h2>
<ol>
<li><span class="dates">2004</span>
<a href="http://2004.sxsw.com/interactive">SXSW interactive conference</a>,
<a href="http://2004.sxsw.com/interactive/panels/ratings04/">Top rated moderator (4.70 out of possible 5.0)</a>.</li>
</nowiki></pre>

List with dates, event name, url and award name.

==== Interests ====
<pre><nowiki>
<div class="interests">
<h2>Other Interests</h2>
<ul>
<li>Alternative transport: skate, bicycle, motorcycle. Run? Only <a href="http://www.asylumsfx.com/movies/belly.mov" target="m">when chased</a>.</li>
</nowiki></pre>

==== Affiliations ====
<pre><nowiki>
<h2>Member of</h2>
<ul><li><a href="http://www.cpsr.org">Computer Professionals for Social Responsibility (<abbr>CPSR</abbr>)</a> (life),</li>
</nowiki></pre>

List of memberships/affiliations, each with URL and name.

=== Dan Connolly ===
[http://www.w3.org/People/Connolly/misc/vita Dan Connolly] (needs elaboration for MIT purposes; has been GRDDL'd to some extent)

==== Affilitations ====
For affiliations, Dan has:
<pre><nowiki>
<div class="affiliation">
<em class="position">Research Scientist</em><br />
<b class="org">MIT Computer Science and Artificial Intelligence Laboratory (<a rel="aff"
href="http://www.csail.mit.edu/">CSAIL</a>)</b>
</div>
</nowiki></pre>

Not sure what rel="aff" means. --[[User:RyanKing|RyanKing]] 17:17, 17 Jan 2006 (PST)

==== Contact ====
For contact info:
<pre><nowiki>
<div class="contact">
<span class='street'>200 Technology Square</span>
<span class='city'>Cambridge</span>, <span class='st'>MA</span>
<span class="zip">02139</span><br />
<code class='homePageAddr'>http://www.w3.org/People/Connolly/</code>
</div>
</nowiki></pre>

==== Education ====

<pre><nowiki>
<h2>Education</h2>
</nowiki></pre>
...followed by more affiliation <code>div</code>'s (see above).

Under his education entry, he has a list of what appear to be honors/awards:

<pre><nowiki>
<ul>
<li>National Merit Scholar</li>
<li>Natural Sciences <a
href="http://www.cs.utexas.edu/users/cline/dsbrochure.html">Dean's
Scholar</a></li>
<li><a href="http://www.arlut.utexas.edu/">Applied Research
Laboratories</a> Scholarship</li>
</ul>
</nowiki></pre>

==== Publications ====

Publications section:

<pre><nowiki>
<h2>Selected Publications</h2>
<ul>
<li>Berners-Lee, Connolly, Swick, <a href="/1999/04/WebData"><cite>Web
Architecture: Describing and Exchanging Data</cite></a> (World Wide Web
Consortium Note, 1999)</li>
<li><dl>
<dt>Connolly, <a
href="http://helix.nature.com/webmatters/xml.html"><cite>The XML
Revolution</cite></a> Nature's <a
href="http://helix.nature.com/webmatters/">Web Matters</a>, Oct 1998<br
/>
</dt>
</dl>
</li>
....
</nowiki></pre>

Not sure what's up with the <code>dl</code>'s.

Dan also has a section on professional experience:

<pre><nowiki>
<div>
<h2>Professional Experience</h2>
<ul>
<li>Domain Lead, W3C Architecture Domain, 1996-1998</li>
...
</nowiki></pre>

Also a section on 'Appearance and Awards'

<pre><nowiki>
<div>
<h2>Selected Appearances and Awards</h2>
<ul>
<li><a
href="http://www.zdnet.com/intweek/printhigh/120897/top25.html"><cite>The
Top 25 Unsung Heroes Of The Net</cite></a> by <a
href="http://www.zdnet.com/intweek/">Inter@ctive Week</a> 1997</li>
....
</nowiki></pre>

=== Mark Pilgrim ===
* http://diveintomark.org/about/resume/]

== Experiments in microformatting ==
* [http://cs.usfca.edu/~rking/resume.html ryan king]
* [http://cs.usfca.edu/~rking/niall.html Niall Kennedy] (microformatted by RyanKing)
* My resume uses hCard, hCalendar, XFN, and rel-license: http://edward.oconnor.cx/resume/ [[User:EdwardOConnor|EdwardOConnor]]
* [http://steve.ganz.name/resume/resume.html Steve Ganz] - A work-in-progress. Currently using [[hCard]], [[hCalendar]], and a little [http://gmpg.org/xfn/ XFN]. Where there weren't any appropriate existing microformats to draw upon, I looked to [http://xmlresume.sourceforge.net/ XML Resume] for semantics or simply improvised (class="qualifications"). I also created a few custom link type values: rel="employer current" and rel="employer former" (no profile yet).
* [http://maetl.coretxt.net.nz/cv/ Mark Rickerby] - a barebones CV written in the first week of 2006

== Aggregate Analysis ==
To be filled in from the above examples, experience, and discussions.

== See Also ==

* [[resume-formats]]
* [[resume-brainstorming]]

Main Page

2006-01-18T05:42:08Z

MarkRickerby: added cite-formats link

__NOTOC__
__NOTOC__
= Microformats Wiki =

'''Please read [[how-to-play]] before making any edits.'''

'''Please read [[process]] before proposing any new microformats.'''

== Introduction ==

What are microformats? See the [http://microformats.org/about/ about page] for an overview, and the [[introduction]] page for more info. Recent [[press]] and [[presentations]] are also a good place for some background reading as well. Frequently asked questions are answered in the [[faq]].

One popular definition from our [http://microformats.org/discuss/ mailing list] is "simple conventions for embedding semantics in HTML to enable decentralized development." More precisely, microformats can be defined as:
:simple conventions
:for embedding semantic markup
::for a specific problem domain
:in human-readable (X)HTML/XML documents, Atom/RSS feeds, and "plain" XML
::that normalize existing content usage patterns
::using brief, descriptive class names
::often based on existing interoperable standards
:to enable decentralized development
::of resources, tools, and services

"Or do you just use your browser to browse? That's so 20th century." -- [http://diveintomark.org Mark Pilgrim]

== Specifications ==
[[microformats|Microformats]] open standards specifications (see also: [[implementations]])
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[rel-license]]
* [[rel-nofollow]]
* [[rel-tag]]
* [[vote-links|VoteLinks]]
* [http://gmpg.org/xfn/ XFN] (see also: [[xfn-implementations]])
* [http://gmpg.org/xmdp/ XMDP]
* [[xoxo|XOXO]]

== Drafts ==
* [[adr|adr]]
* [[geo|geo]]
* [[hreview|hReview]]
* [[rel-directory]]
* [[rel-enclosure]]
* [[relpayment-research | rel-payment]]
* [[robots-exclusion|Robots Exclusion]]
* [[xfolk|xFolk]]
* [[rel-home]] {{NewMarker}}
* [[hatom|hAtom]] ({{NewMarker}})

== Design Patterns ==

Design patterns give microformat authors a vocabulary for expressing their ideas consistently with what has already been done. ''If you're tempted to try your hand at writing a microformat '''[[process|read this first]]'''!''

* [[datetime-design-pattern]]
* [[class-design-pattern]]
* [[rel-design-pattern]]
* [[abbr-design-pattern]]
* [[existing-classes|class names defined across all microformats]]

== Exploratory discussions ==
Research and analysis of real-world [[examples]], existing formats, and brainstorming to motivate the microformat.
*[[attention]]
*[[blog-description-format]]
*[[blog-post-examples]], [[blog-post-formats]], [[blog-post-brainstorming]] (yields [[hatom|hAtom]])
*[[book-examples]], [[book-formats]], [[book-brainstorming]]
*[[chat-examples]]
*[[cite|Planning pages for a citation microformat]], [[cite-formats]], [[cite-examples]], [[citation-brainstorming]]
*[[comments-formats]]
*[[directory-inclusion-examples]], [[directory-inclusion-formats]]. (see also [[rel-directory]])
*[[forms-examples]]
*[[genealogy-formats]]
*[[last-modified-examples]], [[last-modified-formats]], [[last-modified-brainstorming]]
*[[listing-examples]], [[listing-formats]], [[listing-brainstorming]]
*[[location-formats]]. (see also [[adr]] and [[geo]])
*[[media-metadata-examples]]
*[[mfo-examples]]
*[[other-formats]]
*[[recipe-examples]]
*[[requirements-testing]], [[requirements-testing-examples]]
*[[rest-examples]]
*[[resume-brainstorming]], [[resume-formats]]
*[[search-results-example]]
*[[show-brainstorming]]
*[[showroll-brainstorming]]
*[[table-examples]]
*[[tagspeak-examples]]
*[[transit-table-examples]]
*[[widget-examples]], [[widget-brainstorming]]
*[[wiki-formats]]
*[[xmdp-brainstorming]] (see also [[xmdp-faq]])

== Examples ==
* [[examples]]
* [[zen-garden]] {{NewMarker}}

== Tools & Test Cases & Additional Research ==

The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting tools and services that need to process more than one microformat. This section is intended for editors, parsers, validators, test cases, and other information relevant across multiple microformats.

*[[parsing-microformats]]
*[[selected-test-cases-from-the-web]]
*[[vcard-implementations]], [[vcard-errata]]
*[[icalendar-implementations]]
*[[faqs-for-rdf]]
*[[why-are-content-standards-hard]]

== shared work areas ==
* [[buttons]] {{NewMarker}}
* [[demo]] - a page with links for quickly demonstrating microformats working in practice.
* [[to-do]]
* [[marked-for-deletion]]

== microformats wiki in other languages ==

You may read and edit microformats articles in <del>many different</del> other languages

=== microformats wiki languages with over 2 articles ===

* [[Main_Page-fr|Français (French)]]
* [[Main_Page-jp|日本語 (Japanese)]] {{NewMarker}}

=== Start a microformats wiki in another language ===

Don't see the language you want? Help translate the microformats wiki into another language!

We're still figuring this out.

For now, see the [http://en.wikipedia.org/wiki/Wikipedia:Multilingual_coordination Wikipedia page on Multilingual coordination], and [http://meta.wikimedia.org/wiki/How_to_start_a_new_Wikipedia How to start a new Wikipedia] for some good general tips, advice, and community conventions.

You may want to start with the list of [[stable-pages]], which are pages that are relatively stable, and have only minimal/editorial changes, which makes them much easier to keep in sync with the English versions, by using the [[Special:Watchlist|my watchlist]] feature (use it to watch the pages you've translated for changes).

Page naming: for the translated version of a page, use the same name for the page, and simply add the RFC 3066 language identifier code as a dash suffix. E.g. for the French version, [[Main_Page]] becomes [[Main_Page-fr]], and [[how-to-play]] becomes [[how-to-play-fr]].

==== more languages folks want to see ====

* Chinese: 微支付 (Microformats) (see [http://msittig.blogspot.com/2005/11/since-i-translated-schedule-of.html source of translation])

citation-examples

2006-01-18T05:39:23Z

MarkRickerby: added links to header

= Example Citation Formats =
The following examples are real world examples that been pulled from places around the web. Please add to this list. The idea is that we get a solid sample of examples and see what commonalities there are amonst them and try to build this microformat so that it can meet 80% of all the possible properties.

See also:
* [[cite]]
* [[cite-formats]]
* [[cite-brainstorming]]

== Citation Mark Up in the Wild ==
Mark up examples from reference publisher's websites (online catalogs), including ABC-CLIO, Greenwood Press, Marshall Cavendish, Oxford University Press (USA) and Thomson Gale. Examples are broken down and organized by element.

View complete [[citations in the wild]].

=== Book titles: ===
<pre>
<span id="title" class="producttitle">The 1920's</span>
(ABC-CLIO product detail page)

<div class="title"> <a href="...">The Greenwood Encyclopedia of World Folklore and Folklife</a> </div>
(Greenwood Press homepage)

<span id="lblTitle" class="book_headline block">The Greenwood Encyclopedia of World Folklore and Folklife</span>
(Greenwood Press product detail page)

<td width="35%"><font id="title_catalogue_title_font">Title</font></td>
<td width="65%"><font id="text">The New Terrorism: Anatomy, Trends and Counter-strategies</font></td>
(Marshall Cavendish product detail page)

<h2> <a href="...">The Glorious Cause</a> </h2>
(Oxford Univ. Press, homepage)

<h1>The Glorious Cause</h1>
(OUP, product detail page)

<h2>Contemporary Literary Criticism</h2>
(Thomson Gale, product detail page)

<span id="ctlBookDetailHeader_lblTitle" class="ProdTitle">Talk and Interaction in Social Research Methods</span> (SAGE Publications)
</pre>
Also, many examples where books presented in table format with Title as cell header, or presented "Title: "

=== Book Series Name: ===
<pre>
<span id="serieslbl" class="productsubtitle"><a href="...">Teaching With Documents Series</a></span>
(ABC-CLIO)
</pre>

=== Sub-title: ===
<pre>
<span id="subtitle" class="productsubtitle"></span>
(ABC-CLIO)

<div class="sub_title">[Four Volumes]</div>
(Greenwood, homepage)

<span id="lblSubTitle" class="book_subline">[Four Volumes]</span>
(Greenwood, product page)

<div class="subTitle"> The American Revolution, 1763-1789 </div>
(OUP)
</pre>

=== Author: ===
<pre>
<span id="credit" class="productauthor"></span>
(ABC-CLIO)

<div class="author">William M. Clements</div>
(Greenwood)

<td width="35%"><font id="title_catalogue_title_font">Authors</font></td>
<td width="65%"><font id="text">Andrew Tan & Kumar Ramakrishna (eds)</font></td>
(Marshall Cavendish)

<div class="byline"> Robert Middlekauff </div>
(OUP)
</pre>

=== Publication Date: ===
<pre>
<span id="pubdate" class="productdetailbody">11/2001</span>
(ABC-CLIO -- see table structure)

<div id="pnlPubDate"> <span class="book_options">Publication Date:</span> <span id="lblPubDate">12/30/2005</span> </div>
(Greenwood, detail page)

<span class="publicationDate"> Feb 2005 </span>
(OUP)

<li>Published/Released:<strong> March 1973</strong></li>
(Thomson Gale)
</pre>

=== Volumes: ===
<pre>
<td width="110" class="productdetailhead"><span id="volumeslabel" class="productdetailhead">Volumes</span></td>
<td width="180" class="productdetailbody"><span id="volumes" class="productdetailbody">1</span></td>
(ABC-CLIO)
</pre>

=== ISBN: ===
<pre>
<td class="productdetailhead" width="88"><span id="ISBNLabel">ISBN</span></td>
<td class="productdetailbody">1-57607-785-3</td>
(ABC-CLIO)

<div class="isbn">0-313-32847-1</div>
(Greenwood, homepage)

<div id="pnlIsbn"> <span class="book_options">ISBN:</span> <span id="lblIsbn">0-313-32847-1</span> </div>
(Greenwood, product page)

<td width="35%"><font id="title_catalogue_title_font">ISBN Number</font></td>
<td width="65%"><font id="text">9812102108</font></td>
(Marshall Cavendish)

<span class="isbnNumber">0195162471</span>
(OUP)

<li>ISBN: <strong>0-8103-0100-8</strong></li>
(Thomson Gale)
</pre>

=== Book Edition: ===
<pre>
<div class="edition"> Revised and Expanded Edition </div>
(OUP)
</pre>
Added by [[User:Tim White|Tim]]

== RFC vCard Example ==
<pre><nowiki>
9. References

[ISO 8601] ISO 8601:1988 - Data elements and interchange formats -
Information interchange - Representation of dates and
times - The International Organization for
Standardization, June, 1988.

[ISO 8601 TC] ISO 8601, Technical Corrigendum 1 - Data elements and
interchange formats - Information interchange -
Representation of dates and times - The International
Organization for Standardization, May, 1991.

[ISO 9070] ISO 9070, Information Processing - SGML support
facilities - Registration Procedures for Public Text
Owner Identifiers, April, 1991.

[CCITT E.163] Recommendation E.163 - Numbering Plan for The
International Telephone Service, CCITT Blue Book,
Fascicle II.2, pp. 128-134, November, 1988.

[CCITT X.121] Recommendation X.121 - International Numbering Plan for
Public Data Networks, CCITT Blue Book, Fascicle VIII.3,
pp. 317-332, November, 1988.

[CCITT X.520] Recommendation X.520 - The Directory - Selected
Attribute Types, November 1988.

[CCITT X.521] Recommendation X.521 - The Directory - Selected Object
Classes, November 1988.

[MIME-DIR] Howes, T., Smith, M., and F. Dawson, "A MIME Content-
Type for Directory Information", RFC 2425, September
1998.

[RFC 1738] Berners-Lee, T., Masinter, L., and M. McCahill,
"Uniform Resource Locators (URL)", RFC 1738, December
1994.

[RFC 1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.

[RFC 1872] Levinson, E., "The MIME Multipart/Related Content-
type", RFC 1872, December 1995.

[RFC 2045] Freed, N., and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) - Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.

[RFC 2046] Freed, N., and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) - Part Two: Media Types", RFC
2046, November 1996.

[RFC 2047] Moore, K., "Multipurpose Internet Mail Extensions
(MIME) - Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.

[RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) - Part Four:
Registration Procedures", RFC 2048, January 1997.

[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC 2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[UNICODE] "The Unicode Standard - Version 2.0", The Unicode
Consortium, July 1996.

[VCARD] Internet Mail Consortium, "vCard - The Electronic
Business Card Version 2.1",
http://www.imc.org/pdi/vcard-21.txt, September 18,
1996.
</nowiki></pre>
[http://www.faqs.org/rfcs/rfc2426.html vCard RFC]

== W3C XHTML Spec Example ==
<pre><nowiki>
<h1><a name="refs" id="refs">E.</a> References</h1>

<p><strong>This appendix is informative.</strong></p>

<dl>
<dt><a name="ref-css2" id="ref-css2"><strong>[CSS2]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/1998/REC-CSS2-19980512">Cascading Style Sheets, level 2 (CSS2) Specification</a></cite>", B. Bos, H. W. Lie, C. Lilley, I. Jacobs, 12 May 1998.<br />
<a href="http://www.w3.org/TR/REC-CSS2">Latest version</a> available at: http://www.w3.org/TR/REC-CSS2</dd>

<dt><a name="ref-dom" id="ref-dom"><strong>[DOM]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001">Document Object Model (DOM) Level 1 Specification</a></cite>", Lauren Wood <em lang="lt" xml:lang="lt">et al.</em>, 1 October
1998.<br />
<a href="http://www.w3.org/TR/REC-DOM-Level-1">Latest version</a> available at: http://www.w3.org/TR/REC-DOM-Level-1</dd>

<dt><a name="ref-dom2" id="ref-dom2"><strong>[DOM2]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113">Document Object Model (DOM) Level 2 Core Specification</a></cite>", A. Le Hors, <em lang="lt" xml:lang="lt">et
al.</em>, 13 November 2000.<br />
<a href="http://www.w3.org/TR/DOM-Level-2-Core">Latest version</a> available at: http://www.w3.org/TR/DOM-Level-2-Core</dd>

<dt><a name="ref-html4" id="ref-html4"><strong>[HTML]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</a></cite>", D. Raggett, A. Le Hors, I. Jacobs, 24 December 1999.<br />
<a href="http://www.w3.org/TR/html401">Latest version</a> available at: http://www.w3.org/TR/html401</dd>

<dt><a name="ref-posix.1" id="ref-posix.1"><strong>[POSIX.1]</strong></a></dt>

<dd>"<cite>ISO/IEC 9945-1:1990 Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language]</cite>", Institute of Electrical
and Electronics Engineers, Inc, 1990.</dd>

<dt><a id="ref-rfc2045" name="ref-rfc2045"><strong>[RFC2045]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2045.txt">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a></cite>", N. Freed and N. Borenstein, November
1996. Note that this RFC obsoletes RFC1521, RFC1522, and RFC1590.</dd>

<dt><a name="ref-rfc2046" id="ref-rfc2046"><strong>[RFC2046]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2046.txt">RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a></cite>", N. Freed and N. Borenstein, November 1996.<br />
Available at <a href="http://www.ietf.org/rfc/rfc2046.txt">http://www.ietf.org/rfc/rfc2046.txt</a>. Note that this RFC obsoletes RFC1521, RFC1522, and RFC1590.</dd>

<dt><a name="ref-rfc2119" id="ref-rfc2119"><strong>[RFC2119]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2119.txt">RFC2119: Key words for use in RFCs to Indicate Requirement Levels</a></cite>", S. Bradner, March 1997.<br />
Available at: http://www.ietf.org/rfc/rfc2119.txt</dd>

<dt><a name="ref-rfc2376" id="ref-rfc2376"><strong>[RFC2376]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2376.txt">RFC2376: XML Media Types</a></cite>", E. Whitehead, M. Murata, July 1998.<br />
This document is obsoleted by [<a href="#ref-rfc3023">RFC3023</a>].<br />
Available at: http://www.ietf.org/rfc/rfc2376.txt</dd>

<dt><a name="ref-rfc2396" id="ref-rfc2396"><strong>[RFC2396]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2396.txt">RFC2396: Uniform Resource Identifiers (URI): Generic Syntax</a></cite>", T. Berners-Lee, R. Fielding, L. Masinter, August 1998.<br />
This document updates RFC1738 and RFC1808.<br />
Available at: http://www.ietf.org/rfc/rfc2396.txt</dd>

<dt><a name="ref-rfc2854" id="ref-rfc2854"><strong>[RFC2854]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2854.txt">RFC2854: The text/html Media Type</a></cite>", D. Conolly, L. Masinter, June 2000.<br />
Available at: http://www.ietf.org/rfc/rfc2854.txt</dd>

<dt><a name="ref-rfc3023" id="ref-rfc3023"><strong>[RFC3023]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc3023.txt">RFC3023: XML Media Types</a></cite>", M. Murata, S. St.Laurent, D. Kohn, January 2001.<br />
This document obsoletes [<a href="#ref-rfc2376">RFC2376</a>].<br />
Available at: http://www.ietf.org/rfc/rfc3023.txt</dd>

<dt><a id="ref-rfc3066" name="ref-rfc3066"><strong>[RFC3066]</strong></a></dt>

<dd>"<a href="http://www.ietf.org/rfc/rfc3066.txt">Tags for the Identification of Languages</a>", H. Alvestrand, January 2001.<br />
Available at: http://www.ietf.org/rfc/rfc3066.txt</dd>

<dt><a id="ref-rfc3236" name="ref-rfc3236"><strong>[RFC3236]</strong></a></dt>

<dd>"<a href="http://www.ietf.org/rfc/rfc3236.txt">The 'application/xhtml+xml' Media Type</a>", M. Baker, P. Stark, January 2002.<br />
Available at: http://www.ietf.org/rfc/rfc3236.txt</dd>

<dt><a id="ref-xhtml-mathml" name="ref-xhtml-mathml"><strong>[XHTML+MathML]</strong></a></dt>

<dd><cite>"<a href="http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd">XHTML plus Math 1.1 <abbr title="Document Type Definition">DTD</abbr></a></cite>", "A.2 MathML as a DTD Module", Mathematical
Markup Language (MathML) Version 2.0. Available at: http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd</dd>

<dt><a id="ref-xhtmlmime" name="ref-xhtmlmime"><strong>[XHTMLMIME]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801">XHTML Media Types</a></cite>", Masayasu Ishikawa, 1 August 2002.<br />
<a href="http://www.w3.org/TR/xhtml-media-types">Latest version</a> available at: http://www.w3.org/TR/xhtml-media-types</dd>

<dt><a id="ref-xhtmlmod" name="ref-xhtmlmod"><strong>[XHTMLMOD]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410">Modularization of XHTML</a></cite>", M. Altheim et al., 10 April 2001.<br />
<a href="http://www.w3.org/TR/xhtml-modularization">Latest version</a> available at: http://www.w3.org/TR/xhtml-modularization</dd>

<dt><a name="ref-xml" id="ref-xml"><strong>[XML]</strong></a></dt>

<dd>"<a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible Markup Language (XML) 1.0 Specification (Second Edition)</a>", T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, 6 October
2000.<br />
<a href="http://www.w3.org/TR/REC-xml">Latest version</a> available at: http://www.w3.org/TR/REC-xml</dd>

<dt><a name="ref-xmlns" id="ref-xmlns"><strong>[XMLNS]</strong></a></dt>

<dd>"<a href="http://www.w3.org/TR/1999/REC-xml-names-19990114">Namespaces in XML</a>", T. Bray, D. Hollander, A. Layman, 14 January 1999.<br />
XML namespaces provide a simple method for qualifying names used in XML documents by associating them with namespaces identified by URI.<br />
<a href="http://www.w3.org/TR/REC-xml-names">Latest version</a> available at: http://www.w3.org/TR/REC-xml-names</dd>

<dt><a name="ref-xmlc14n" id="ref-xmlc14n"><strong>[XMLC14N]</strong></a></dt>

<dd>"<a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">Canonical XML Version 1.0</a>", J. Boyer, 15 March 2001.<br />
This document describes a method for generating a physical representation, the canonical form, of an XML document.<br />
<a href="http://www.w3.org/TR/xml-c14n">Latest version</a> available at: http://www.w3.org/TR/xml-c14n</dd>
</dl>
</nowiki></pre>
[http://www.w3.org/TR/xhtml1/#refs XHTML1.0 Spec references]

== CiteProc XHTML Output ==

The XHTML output for CiteProc[http://xbiblio.sourceforge.net/citeproc.html] wasn't designed per se as a microformat, but is probably not a bad place to start. It is desgined to handle a wide range of content. Here is the APA output:

<pre><nowiki>
<div id="bibliography">

<h3>References</h3>

<p id="Brenner2000a" class="bibref">
<span class="creator">Brenner, N.</span>
<span class="date"> (<span class="year">2000</span>) </span>
<span class="title">The Urban Question as a Scale Question: Reflections
on Henri Lefebre, Urban Theory and the Politics of Scale, </span>
<span class="container">
<span class="title" style="font-style: italic">International Journal of
Urban and Regional Research, </span>
<span class="volume">24</span>
<span class="issue">(2)</span>
<span class="locator">, pp. 361–78</span>
</span>.
</p>

<p id="NW2000-0207" class="bibref">
<span class="creator">Newsweek</span>
<span class="date">
(<span class="year">2000a</span>
<span class="month">, February</span>
<span class="day"> 7</span>)
</span>
<span class="title">The Grandmas Pay a Visit, </span>
<span class="container">
<span class="volume">135</span>
<span class="issue">(6)</span>
<span class="locator">, pp. 45</span>
</span>.
</p>

<p id="Veer1996a" class="bibref">
<span class="creator">van der Veer, P.</span>
<span class="date"><span class="year"> (1996) </span></span>
<span class="title">Riots and Rituals: The Construction of Violence
and Public Space in Hindu Nationalism</span>
<span class="container">, In Brass, P.<span class="role"> (Ed.)</span>.
<span class="title" style="font-style: italic">Riots and Pogroms.</span>
<span class="origin"><span class="place">New York</span>
<span class="publisher">: NYU Press</span></span>
<span class="locator">, pp. 154–76</span>
</span>.
</p>
</div>
</nowiki></pre>

= Styles =
This does NOT define a format, but instead shows how the format should be displayed. This is something out of the direct scope of this project. CSS styles will handle the look-and-feel of the text, and the author can put it in any order they choose. These links are mentioned for two reasons, one is informative, the other is so we know at least meet the minimum properties that are used in the styles.

* [http://www.liu.edu/cwis/cwp/library/workshop/citmla.htm MLA Style]
* [http://www.bu.edu/library/guides/citation.html Chicago, MLA, and APA styles]
* [http://www.legalbluebook.com/ Blue Book] for legal citations
* [http://www.columbia.edu/cu/cup/cgos/idx_basic.html Columbia University Citation Style] developed for modern internet citations

citation-brainstorming

2006-01-18T05:38:34Z

MarkRickerby: added links to header

= Citation Brainstroming =

See also:
* [[cite]]
* [[cite-formats]]
* [[cite-examples]]

== XHTML Structure ==
With my exprience working X2V and hCa* has taught me what elememts are easy to find and which are not. Since the Citation microformat is very new it is possible to not make a lot of the same errors twice and to make things easier for extracting application to find and imply certain properties.

* There should be some sort of 'root node' that implies all child elements are for the Citation microformat.
* Since most people will have multiple Citation there should be away to represent each Citation object as a unqiue block independant of another. This is to keep the parse from finding 'author' and applying to all citations. Each citation should be in a container (class="???") that scoped from others.

@@ more points will be posted as i remember of them

== Semantic Meaning ==
One of the guiding priniciple of Microformats is to use the most semantically rich element to describe each node (Point 2 of Semantic XHTML Design Principles: Use the most accurately precise semantic XHTML building block for each object etc). Since we are dealing with HTML and citations, several elements are candidates to be used to enrich the semantic meaning. [http://www.w3.org/TR/REC-html40/struct/text.html CITE, BLOCKQUOTE, Q, A], (are there more?)

The [[citation-brainstorming|Citation Brainstorming Page]] has a few development and ideas about how to give another person credit for a link. Some of the semantic ideas behind their choices of tags can be applied to a full bibliographic type reference.

== ISBN:// Protocol ==

''' THIS BELONGS IN [[cite-formats]], NOT HERE'''

[http://www.faqs.org/rfcs/rfc3187.html RFC3187] defines an isbn protocol

Example:

URN:ISBN:0-395-36341-1

I'm not sure if any browser uses this data, but it might be have an application in citations describing registered materials with an ISBN

Question: what about using something like OCLC's [http://www.oclc.org/worldcat/open/isbnissnlinking/default.htm WorldCat] for linking titles? - Tim White

== This and That ==
After reading through alot of different citation encoding formats, i noticed that each format was being used in onw of two ways. It was either to describe the Current page (THIS.PAGE) or being used to encode references that point to external resources (THAT.PAGE)

The informatation being encoded was identical for both resources (author, date, name, etc) they just reference different things. For this microformat, i'm not sure if we want to try to solve both problems, or just one? The meta tags in the head element would be the ideal place for information about the THIS.PAGE, but that is not in following with the ideals of microformats where information is human-readable. The THAT.PAGE idea where a list of references is at the end of a document in the form of a bibliography is more inline with the ideals of a microformat where the data is human-readable. That doesn't mean that data about the current document shouldn't be human-readable, so some of the same properties used to reference extermal resources can be used for the current document (THIS.PAGE). To do this a different root item could be used and transforming applications could either extract the citation data about the current page, or information about this page's references.

This is open for discussion, but either way, i believe that the properties used to describe a page will be the same for both THIS and THAT. [http://suda.co.uk/ brian suda]

== Date Formatting ==
Since microformats are all about re-use and the accepted way to encode Date-Time has been pretty much settled, then this is a good place to start when dealing with all the different date citation types.

These are all the different fields from various citation formats that are of temporal nature:
* Date (available | created | dateAccepted | dateCopyrighted | dateSubmitted | issued | modified | valid)
* originInfo/dateIssued
* originInfo/dateCreated
* originInfo/dateCaptured
* originInfo/dateOther
* month
* year
* Copyright Year
* Date - Generic
* Date of Confernce
* Date of Publication
* Date of update/revisou/issuance of database record
* Former Date
* Entry Date for Database Record
* Database Update
* Year of Publication

There are several common properties across several citation domains and will certainly be in the citation microformat, the unique instances will need further consideration, otherwise there could be no end to posiblities.

There are also several properties (year, month, Year of publication) that can be extracted from another source. Therefore, if you only encode a more specific property such as; Date of Publication, you can extract the 'year of publication' from that. Since the date-time format we are modeling after is the ISO date-time format, just the Year portion is an acceptable date. So if you ONLY know the year of publication, the you can form a valid 'Date of Publication' as a microformat (which inturn is a valid 'year of publication') - you milage may vary when it comes to importing into citation applications.

...

It seems to me that these can be collapsed to maybe one or two different date properties. As far as the specific human readable formatting of the date, that can be chosen per whatever the presentation style guide says, and the [[datetime-design-pattern]] used to simplify the markup. - Tantek

== Types and Roles ==
(Section is informative only as a place to capture various parts of publication citations.)

''' THIS BELONGS IN [[cite-formats]], NOT HERE'''

There are many different types of publications and this information should be captured in the citation. Possible types include:
* Novel/fiction (specify type -- literature, sci-fi, romance, etc.?)
* Non-fiction
* Poem
* Play
* Magazine
* Reference (seperate out encyclopedia, dictionary, almanac, etc.?)
* Journal
* Article within a journal
* Chapter within a book
* Dissertation
* Web Site
* Page within a web site
* Music Recording
* Video Recording
* Interview
* Physical object (Statue, Painting, etc.)
* ??

Question:
Certain works have specific types of citations, for example, the Bible--and, I assume, other religious works--have very specific citation formats with different relevant information (chapter/verse) than others, as do the works of Shakespeare. Should these be considered seperate types/roles?

A: I think in terms of types, we should at least note the items (chapter, verse, etc). How they get dealt with is still way up in the air. - Tim

Likewise, there are several different roles associated with publications -- author, co-author, editor, translator, etc. Should these be captured under a master "role" or treated as individual elements?

A: Good question. I think there is an important distinction, but whether we follow a design pattern of "role-*" (or more likely "author-*) or some other pattern hasn't been discussed yet. - Tim

== Tags ==
Some of the citation formats has a place for 'keywords' or 'generic tags', etc. This might be a good place to re-use the [http://microformats.org/wiki/rel-tag RelTag microformat]. The downside would be that they are then forced to be links, which might be the correct way to mark-up these terms.

== OpenURL ==
''' THIS BELONGS IN [[cite-formats]], NOT HERE'''

OpenURL is in use in library software around the world to allow citation metadata to be embedded in URLs. Typically these URLs are used for targeting resolvers which essentially proxy access to licensed content. OpenURL also provides an XML encoding. The [http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats key/value] pairs used in OpenURL could relatively easily be adapted to semantic HTML. This is a cow path that could be paved relatively easily using existing modules as appropriate.

OpenURL has a microformat-like encoding: [http://ocoins.info/ COinS]. This uses the 'title' attribute of HTML 'span' tags to embed OpenURL URLs.

Example (from a book review written using the Structured Blogging plugin):

<pre><nowiki>
<p><b>ISBN</b>: <span class='Z3988'
title='ctx_ver=Z39.88-2004&amp;rft_val_fmt=info:ofi/fmt:kev:mtx:book&amp;rft.isbn=0679426612'>
0679426612</span></p>
</nowiki></pre>

== MARC / MODS / Dublin Core ==

The MODS ([http://www.loc.gov/standards/marcxml/Sandburg/sandburgmods.xml example]) and Dublin Core ([http://www.loc.gov/standards/marcxml/Sandburg/sandburgdc.xml example]) transformations of MARC21 may contain some useful ideas.

Here's a first attempt at rewriting the linked examples in XHTML (written in response to a [http://microformats.org/discuss/mail/microformats-discuss/2005-December/002438.html mailing list query about encoding book information with microformats]):

<pre><nowiki>
<div class="book" lang="en">
<h3 class="fn">Arithmetic /</h3>
<p>By <span class="creator"><span class="fn">Sandburg, Carl</span>,
<span class="date">1878-1967</span></span>,
and <span class="illustrator">Rand, Ted</span></p>
<p>Publisher: <span class="publisher"><span class="fn">Harcourt Brace Jovanovich</span>,
<span class="locality">San Diego</span></span></p>
<p>Published: <span class="issued">1993</span></p>
<p class="description">A poem about numbers and their characteristics. Features
anamorphic, or distorted, drawings which can be restored to normal by viewing
from a particular angle or by viewing the image's reflection in the provided
Mylar cone.</p>
<p class="note">One Mylar sheet included in pocket.</p>
<p>Subjects:</p>
<ul>
<li class="subject">Arithmetic</li>
<li class="subject">Children's poetry, American.</li>
<li class="subject">Arithmetic</li>
<li class="subject">American poetry</li>
<li class="subject">Visual perception</li>
</ul>
</div>
</nowiki></pre>

citation-formats

2006-01-18T05:38:15Z

MarkRickerby: tidied up header

= Citation Formats =

This page will display several different types of citation format types. The idea is to compare what properties are common amonst all of the formats and which ones should be blended into this microformat.

See also:
* [[cite]]
* [[cite-brainstorming]]
* [[cite-examples]]

== Comparison chart ==
The following chart maps the terms from one implementation to another. This is important because if all the properties are introduced to this microformats, then its possible to map them to a number of different formats. The table currently only uses Dublin Core, MODS, and bibTeX. Each column has all the properties and their equivalent in each format. If there is no corresponding property the cell is grey. At the bottom of the list are the unique terms to each format. Dublin core has basic terms and terms that extend the basic ones. If the property is an extention of a basic term it is in ()'s. MODS uses XML, so any sub-properties are listed in their tree form, property/sub-property.

THIS IS NOT DEFINIATIVE, any errors should be corrected. More formats will be added to the list as they are mapped.

<table border="1">
<tr>
<th>Dublin Core</th>
<th>MODS</th>
<th>bibTeX</th>
<th>Z39.80</th>
</tr>
<tr>
<td>Title (alternative)</td>
<td>titleInfo/title<br/>titleInfo/PartNum</td>
<td>booktitle<br/>title<br/>chapter<br/>number<br/>pages<br/>volume<br/>series</td>
<td>Analytic Title<br/>
Collective or Series Title<br/>
Monographic Title<br/>
Work Fraction Title<br/>
Location of Conference<br/>
Main Entry<br/>
Name of Conference<br/>
Number of Meeting<br/>
Other Title<br/>
Parallel Title<br/>
Title Abbriviation<br/>
Title of Conference Proceedings<br/>
Translated Title<br/>
Uniform Title<br/>
Abbriviated Translated Title<br/>
Symposium or Session Title<br/>
Collective or Series Edition<br/>
Video/Film Edition<br/>
</td>
</tr>
<tr>
<td>creator</td>
<td>name/namePart</td>
<td>author<br/>creator</td>
<td>Author, Primary<br/>
Corporate Author, Primary<br/>
Abstract Author<br/>
Authorship Statement<br/>
Acknowledged Supporters<br/>
Assignee for Patents<br/>
Chairperson of Conference<br/>
Director of AV Program<br/>
Other Author<br/>
Reviewed Book Author<br/>
Studio<br/>
Sponsor of Conference<br/>
Staff/Cast<br/>
Symposium Chairperson<br/>
Author Address or Affiliation<br/>
Author Country<br/>
Electronic Address of Author<br/>
</td>
</tr>
<tr>
<td>subject</td>
<td>subject/topic</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>Description (abstract | tableOfContents)</td>
<td>abstract<br/>note<br/>tableOfContents</td>
<td>abstract<br/>annotation<br/>note<br/>contents</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Contributer</td>
<td>name</td>
<td>editor?</td>
<td>Book/Report/Volume Editor<br/>
Producer<br/>
Translator<br/>
</td>
</tr>
<tr>
<td>Date (available | created | dateAccepted | dateCopyrighted | dateSubmitted | issued | modified | valid)</td>
<td>originInfo/dateIssued<br/>originInfo/dateCreated<br/>originInfo/dateCaptured<br/>originInfo/dateOther</td>
<td>month<br/>year</td>
<td>Copyright Year<br/>Date-generic<br/>Date of conference<br/>Date of Publication<br/>Date of Update/Revisou/Issuance of Database Record<br/>Former Date<br/>Entry date for Database Record<br/>Database Update<br/>Year of Publication</td>
</tr>
<tr>
<td>Type</td>
<td>typeOfResource<br/>genre</td>
<td>@class<br/>type</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Format (extent | medium)</td>
<td>physicalDescription/internetMediaType<br/>physicalDescription/extent<br/>physicalDescription/form</td>
<td>published</td>
<td>needs mapping</td>
</tr>
<tr>
<td>identifier (bibliographicCitation)</td>
<td>identifier</td>
<td>ISBN<br/>ISSN<br/>LCCN<br/>URL</td>
<td>ISBN<br/>Identifier<br/>Report Identfier<br/>ISSN</td>
</tr>
<tr>
<td>Source</td>
<td>relatedItem</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>language</td>
<td>language</td>
<td>language</td>
<td bgcolor="#cccccc"></td>
</tr>
<tr>
<td>Relation (...)</td>
<td>relatedItem/...</td>
<td>crossRef</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Coverage (spacial | temporal)</td>
<td>subject/temporal<br/>subject/geographic<br/>subject/hierarchicalGeographic<br/>subject/cartographics</td>
<td></td>
<td>needs mapping</td>
</tr>
<tr>
<td bgcolor="#cccccc"></td>
<td>classifications</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>Rights (accessRights | license)</td>
<td>accessConditions</td>
<td>copyright</td>
<td>needs mapping</td>
</tr>
<tr>
<td>publisher</td>
<td bgcolor="#cccccc"></td>
<td>publisher</td>
<td>Publisher Name<br/>
Place of Publication<br/>
Country of Publication<br/>
Generic Address<br/>
</td>
</tr>
<tr>
<td>audience (educationLevel | mediator)</td>
<td>targetAudience</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td bgcolor="#999999">accualMethod<br/>accualPeriodicaty<br/>accualPolicy<br/>instrcutionalMethod<br/>provenance<br/>rightsHolder</td>
<td bgcolor="#999999">location<br/>extension<br/>recordInfo</td>
<td bgcolor="#999999">address<br/>afflilication<br/>location<br/>edition<br/>institution<br/>journal<br/>key<br/>keywords<br/>mrnumber<br/>organization<br/>price<br/>school<br/>size</td>
<td bgcolor="#999999">(the following need to be mapped to the above rows or left here as other)<br/><br/>
Database Source<br/>
Databse Record Identifier<br/>
Database Producer Name<br/>
Rights Management<br/>
Subfile<br/>
Other Source Identifier<br/>
Vendor Record Identifier<br/>
Database Vendor Name<br/>
Column Number<br/>
Edition<br/>
Frequency of Publication<br/>
Internet Location for Document<br/>
Supplement/Part/Special number identifer<br/>
Issue Identifier<br/>
Location in Work<br/>
Number of the Chapter<br/>
Number in Series<br/>
Volume Identifier<br/>
Section Indentifier<br/>
</td>
</tr>
</table>

== Dublin Core Metadata ==
[http://dublincore.org/ Dublin Core] metadata uses a small vocabulary to descibe the data.
* contributor
* coverage
* creator
* date
* description
* format
* identifier
* language
* publisher
* relation
* rights
* source
* subject
* title
* type

From those there are specialised types where are just refinments of the previous, for example:

* abstract refines description.
* accessRights refines rights

[http://dublincore.org/documents/dc-citation-guidelines/ Guidelines for Encoding Bibliographic Citation Information in Dublin Core Metadata]

== MODS (Metadata Object Description Schema) ==
This is a format developed for the Libray of Congress for a bibliographic element set that may be used for a variety of purposes, and particularly for library applications.

[http://www.loc.gov/standards/mods/ http://www.loc.gov/standards/mods/]

(the schema is very big, once i devote the proper time to review it, i will post more about the structure -brian)

== XMLResume ==
<pre>
<!ELEMENT pubs (pub+)>
<!ENTITY % pubElements "(artTitle|bookTitle|author|date|pubDate|publisher|pageNums|url)">
<!ELEMENT pub (para | %pubElements;)*>
<!ATTLIST pub id ID #IMPLIED>
<!ELEMENT artTitle (#PCDATA | link)*>
<!ELEMENT bookTitle (#PCDATA | link)*>
<!ELEMENT author (#PCDATA)>
<!ATTLIST author name IDREF #IMPLIED>
<!ELEMENT pubDate (month?, year)> 
<!ELEMENT publisher (#PCDATA | link | url)*>
<!ELEMENT pageNums (#PCDATA)>
</pre>

== BibTeX ==
=== Fields Used by Bibtex ===
<table border="1" width="100%">
<tr>
<td><strong>abstract:</strong></td>
<td>An abstract of the work.</td>
</tr>
<tr>
<td><b>address:</b></td>
<td>Publisher's address. For major publishing houses,
just the city is given. For small publishers, you can
help the reader by giving the complete address.</td>
</tr>
<tr>
<td><strong>affiliation:</strong></td>
<td>The author's affiliation.</td>
</tr>
<tr>
<td><b>annote:</b></td>
<td>An annotation. It is not used by he standard
bibliography styles, but may be used by others that
produce an annotated bibliography.</td>
</tr>
<tr>
<td><b>author:</b></td>
<td>The name(s) of the author(s).</td>
</tr>
<tr>
<td><b>booktitle: </b></td>
<td>Title of a book, part of which is being cited. For
book entries, use the <strong>title</strong> field
instead.</td>
</tr>
<tr>
<td><b>chapter:</b></td>
<td>A chapter (or section) number.</td>
</tr>
<tr>
<td><strong>contents:</strong></td>
<td>A Table of Contents.</td>
</tr>
<tr>
<td><strong>copyright:</strong></td>
<td>Copyright information.</td>
</tr>
<tr>
<td><strong>crossref:</strong></td>
<td>The database key of the entry being cross-referenced.</td>
</tr>
<tr>
<td><b>edition: </b></td>
<td>The edition of a book - for example
"Second". Notice that it is in capitals.</td>
</tr>
<tr>
<td><b>editor: </b></td>
<td>Name(s) of editor(s). If there is also an author
field, then the editor field gives the editor of the book
or collection in which the reference appears.</td>
</tr>
<tr>
<td><b>howpublished:</b></td>
<td>How something strange has been published. The first
word should be capitalized.</td>
</tr>
<tr>
<td><b>institution:</b></td>
<td>The sponsoring institution of a technical report.</td>
</tr>
<tr>
<td><strong>ISBN:</strong></td>
<td>The International Standard Book Number.</td>
</tr>
<tr>
<td><strong>ISSN:</strong></td>
<td>The International Standard Serial Number. Used to
identify a journal.</td>
</tr>
<tr>
<td><b>journal: </b></td>
<td>A journal name. Abbreviations are provided for many
journals.</td>
</tr>
<tr>
<td><b>key: </b></td>
<td>Used for alphabetizing and creating a label when the
author and editor fields are missing. This field should
not be confused with the key that appears at the
beginning of the reference.</td>
</tr>
<tr>
<td><strong>keywords:</strong></td>
<td>Key words used for searching or possibly for
annotation.</td>
</tr>
<tr>
<td><strong>language:</strong></td>
<td>The language the document is written in.</td>
</tr>
<tr>
<td><strong>LCCN:</strong></td>
<td>The Library of Congress Call Number.</td>
</tr>
<tr>
<td><strong>location:</strong></td>
<td>A location associated with the entry, such as the
city in which a conference took place.</td>
</tr>
<tr>
<td><b>month: </b></td>
<td>The month in which the work was published or, for an
unpublished work, in which it was written.</td>
</tr>
<tr>
<td><strong>mrnumber:</strong></td>
<td>The <em>Mathematical Reviews</em> number.</td>
</tr>
<tr>
<td><b>note:</b></td>
<td>Any additional information that can help the reader.
First word should be capitalized.</td>
</tr>
<tr>
<td><b>number: </b></td>
<td>The number of a journal, magazine, technical report,
or of a work in a series. An issue of a journal or
magazine is usually identified by its volume and number;
the organization that issues a technical report usually
gives it a number; and sometimes books are given numbers
in a named series.</td>
</tr>
<tr>
<td><b>organization: </b></td>
<td>The organization that sponsors a conference or
publishes a manual.</td>
</tr>
<tr>
<td><b>pages:</b></td>
<td>One or more page numbers or ranges of number, such as
37--42, or 7,53,82--94.</td>
</tr>
<tr>
<td><strong>price:</strong></td>
<td>The price of the material.</td>
</tr>
<tr>
<td><b>publisher:</b></td>
<td>The publisher's name.</td>
</tr>
<tr>
<td><b>school:</b></td>
<td>The name of the school where a thesis was written.</td>
</tr>
<tr>
<td><b>series:</b></td>
<td>Then name given a series or set of books. When citing
an entire book, the title field gives its title and the
optional series field gives the name of a series in which
the book was published.</td>
</tr>
<tr>
<td><strong>size:</strong></td>
<td>The physical dimensions of the work.</td>
</tr>
<tr>
<td><b>title:</b></td>
<td>The work's title.</td>
</tr>
<tr>
<td><b>type:</b></td>
<td>The type of technical report - for example,
"Research Note".</td>
</tr>
<tr>
<td><strong>url:</strong></td>
<td>The WWW Universal Resource Locator that points to the
item being referenced. Often used for technical reports
to point to the FTP site where it resides.</td>
</tr>
<tr>
<td><b>volume:</b></td>
<td>The volume of a journal or multivolume book.</td>
</tr>
<tr>
<td><b>year:</b></td>
<td>The year of publication or, for an unpublished work,
the year it was written. It should only consist of
numerals, such as 1976.</td>
</tr>
</table>
=== BibTeX citation Types ===
A reference can be to any of a variety of types. Following is a list of types. Each one also explains the fields associated with that type. Any fields not listed as required or optional are considered to be ignored.
<table border="1" width="100%">
<tr>
<td><b>article:</b></td>
<td>An article from a journal or magazine. Required
fields: author, title, journal, year. Optional fields:
volume, number, pages, month, note, key.</td>
</tr>
<tr>
<td><b>book:</b></td>
<td>A book with an explicit publisher. Required fields:
author or editor, title, publisher, year. Optional
fields: volume, series, address, edition, month, note,
key.</td>
</tr>
<tr>
<td><b>booklet: </b></td>
<td>A work that is printed and bound, but without a named
publisher or sponsoring institution. Required fields:
title. Optional fields: author, howpublished, address,
month, year, note, key.</td>
</tr>
<tr>
<td><strong>collection:</strong></td>
<td>A collection of works. Same as <a href="#proceedings">Proceedings</a>.</td>
</tr>
<tr>
<td><b>conference:</b></td>
<td>The same as <a href="#inproceedings">Inproceedings</a>.</td>
</tr>
<tr>
<td><b>inbook:</b></td>
<td>A part of a book, which may be a chapter and/or a
range of pages. Required fields: author or editor, title,
chapter and/or pages, publisher, year. Optional fields:
volumer, series, address, edition, month, note, key.</td>
</tr>
<tr>
<td><b>incollection:</b></td>
<td>A part of a book with its own title. Required fields:
author, title, booktitle, publisher, year. Optional
fields: editor, pages, organization, publisher, address,
month, note, key.</td>
</tr>
<tr>
<td><a name="inproceedings"></a><b>inproceedings:</b></td>
<td>An article in a conference proceedings. Required
fields: author, title, booktitle, year. Optional fields:
editor, pages, organization, publisher, address, month,
note, key.</td>
</tr>
<tr>
<td><b>manual: </b></td>
<td>Technical documentation. Required fields: title.
Optional fields: author, organization, address, edition,
month, year, note.</td>
</tr>
<tr>
<td><b>mastersthesis:</b></td>
<td>A Master's thesis. Required fields: author, title,
school, year. Optional fields: address, month, note, key.</td>
</tr>
<tr>
<td><b>misc:</b></td>
<td>Use this type when nothing else fits. Required
fields: none. Optional fields: author, title,
howpublished, month, year, note, key.</td>
</tr>
<tr>
<td><strong>patent:</strong></td>
<td>A patent.</td>
</tr>
<tr>
<td><b>phdthesis:</b></td>
<td>A Ph.D. thesis. Required fields: author, title,
school, year. Optional fields: address, month, note, key.</td>
</tr>
<tr>
<td><a name="proceedings"></a><b>proceedings:</b></td>
<td>The proceedings of a conference. Required fields:
title, year. Optional fields: editor, publisher,
organization, address, month, note, key.</td>
</tr>
<tr>
<td><b>techreport:</b></td>
<td>A report published by a school or other institution,
usually numbered within a series. Required fields:
author, title, institution, year. Optional fields: type,
number, address, month, note, key.</td>
</tr>
<tr>
<td><b>unpublished:</b></td>
<td>A document with an author and title, but not formally
published. Required fields: author, title, note. Optional
fields: month, year, key.</td>
</tr>
</table>

==== Examples ====
<pre><nowiki>
@book{kn:gnus,

AUTHOR = "Donald E. Knudson",
TITLE = "1966 World Gnus Almanac",
PUBLISHER = {Permafrost Press},
ADDRESS = {Novosibirsk} }

<div class="book" id="kn:gnus">
<div class="author">Donald E. Knudson</div>
<div class="title">1966 World Gnus Almanac</div>
<div class="publisher">Permafrost Press</div>
<div class="address">Novosibirsk</div>
</div>

@article{XAi_HSCheng_1994a,

author = "X. Ai and H. S. Cheng",
title = "Influence of moving dent on point {EHL} contacts",
journal = "Tribol. Trans.",
volume = "37",
year = "1994",
pages = "323--335",
}

<div class="article" id="XAi_HSCheng_1994a">
<div class="author">X. Ai and H. S. Cheng</div>
<div class="title">Influence of moving dent on point {EHL} contacts</div>
<div class="journal">Tribol. Trans.</div>
<div class="volume">37</div>
<div class="year">1994</div>
<div class="pages">323--335</div>
</div>
</nowiki></pre>

== OpenURL ==

OpenURL aka [http://www.niso.org/standards/standard_detail.cfm?std_id=783 Z39.88] defines a standard way of bundling citation data in a URL. It is widely deployed in academic libraries around the world to provide access to licensed content via link resolvers such as [http://www.exlibrisgroup.com/sfx_openurl.htm SFX]. The Context Object in Span ([http://ocoins.info/ COinS]) community standard represents one way to embed OpenURLs in XHTML without including a resolver target.

<pre>
<nowiki>
<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.issn=1045-4438"></span>
</nowiki>
</pre>

As you can see this isn't very much like semantic XHTML at all. However significant work has gone into defining the set of Key/Encoded Values (KEVs) that can be used in various [http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats types] of citations: [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:book book], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:dissertation dissertation], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:journal journal], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:patent patent]. It would be possible to simply provide a standard XHTML bundling for these keys as a microformat.

=== Example ===

<pre>
<nowiki>

<div class="openurl-journal">
<span class="aulast">Berners-Lee</span>,
<span class="aufirst">Tim</a>; Hendler, James; Lassila, Ora.</span>
"<span class="atitle">The Semantic Web</span>".
<span class="jtitle">Scientific American</span>
<span class="volume">284</span>(<span class="issue">5</span>), pp.
pp. <span class="pages">34-43</span>.
<span class="issn">0036-8733</span>
</div>

</nowiki>
</pre>

Using OpenURL in this way would enable third party applications that could, say grab citation metadata from a blog, and without much work fire it off at your university's or public libraries openurl resolver to see if the article is available via a licensed databases. The benefits [http://www.infotoday.com/newsbreaks/nb050801-1.shtml have] [http://www.ariadne.ac.uk/issue43/chudnov/ been] [http://www.wallandbinkley.com/quaedam/?p=30 noted] [http://hublog.hubmed.org/archives/001163.html elsewhere].

== Z39.80 ==
I'm not sure the best place for a guide to Z39.80 so please add links as you see fit:

[http://www.niso.org/standards/resources/drft4rev.html http://www.niso.org/standards/resources/drft4rev.html]

== DocBook ==

A subset of the DocBook vocabulary is dedicated to representing a bibliography: http://www.docbook.org/tdg/en/html/bibliography.html

<pre><nowiki>
<!DOCTYPE bibliography PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
<bibliography>
<title>Languages and Semantics</title>
<bibliodiv>
<title>Books</title>
<biblioentry>
<title>Course in General Linguistics</title>
<abbrev>deSaussure59</abbrev>
<author><firstname>Ferdinand</firstname><surname>de Saussure</surname></author>
<editor><firstname>Charles</firstname><surname>Bally</surname></editor>
<editor><firstname>Albert</firstname><surname>Sechehaye</surname></editor>
<othercredit role="translator"><firstname>Wade</firstname><surname>Baskin</surname></othercredit>
<copyright>
<year>1959</year>
<holder>The Philosophical Library Inc.</holder>
</copyright>
<isbn>07-016524-6</isbn>
<publisher>
<publishername>McGraw-Hill Book Company</publishername>
</publisher>
</biblioentry>
</bibliodiv>
</bibliography>
</nowiki></pre>

== Ann Arbor District Library XML feed ==

Here's a record in XML format from their project to simplify
access to the catalog. More discussion on [http://www.blyberg.net John Blyberg's blog].

<pre>
<nowiki>
<p:Record>
<callnum>823 Bu</callnum>
<author>Burkart, Gina, 1971-</author>
<fulltitle>A parent's guide to Harry Potter / Gina Burkart</fulltitle>
<title>A parent's guide to Harry Potter </title>
<pubinfo>Downers Grove, Ill. : InterVarsity Press, c2005</pubinfo>
<desc>112 p</desc>
<bibliography>Includes bibliographical references</bibliography>
<contents>
The Harry hype -- More than a story -- The modern fairy tale -- Discussing fantasy with children -- Morals, not magic -- The real issues in Harry Potter -- Dealing with traumatic experiences -- Facing fears -- Battling bullies -- Delving into diversity -- Hiding hurts -- Letting go of anger -- Getting help -- Choosing good over evil -- The power of love -- Facing spiritual battles
</contents>
<isbn>0830832882</isbn>
<price>$11.00</price>
<lang>eng</lang>
<copies>0</copies>
<catdate>08-16-2005</catdate>
<mattype>a</mattype>
<avail>No copies available</avail>
<recordlink xlink:href="http://www.aadl.org/cat/seek/record=1249810"/>
</p:Record>
</nowiki>
</pre>

citation-formats

2006-01-18T05:29:22Z

MarkRickerby: /* DocBook */

This page will display several different types of citation format types. The idea is to compare what properties are common amonst all of the formats and which ones should be blended into this microformat.

== Comparison chart ==
The following chart maps the terms from one implementation to another. This is important because if all the properties are introduced to this microformats, then its possible to map them to a number of different formats. The table currently only uses Dublin Core, MODS, and bibTeX. Each column has all the properties and their equivalent in each format. If there is no corresponding property the cell is grey. At the bottom of the list are the unique terms to each format. Dublin core has basic terms and terms that extend the basic ones. If the property is an extention of a basic term it is in ()'s. MODS uses XML, so any sub-properties are listed in their tree form, property/sub-property.

THIS IS NOT DEFINIATIVE, any errors should be corrected. More formats will be added to the list as they are mapped.

<table border="1">
<tr>
<th>Dublin Core</th>
<th>MODS</th>
<th>bibTeX</th>
<th>Z39.80</th>
</tr>
<tr>
<td>Title (alternative)</td>
<td>titleInfo/title<br/>titleInfo/PartNum</td>
<td>booktitle<br/>title<br/>chapter<br/>number<br/>pages<br/>volume<br/>series</td>
<td>Analytic Title<br/>
Collective or Series Title<br/>
Monographic Title<br/>
Work Fraction Title<br/>
Location of Conference<br/>
Main Entry<br/>
Name of Conference<br/>
Number of Meeting<br/>
Other Title<br/>
Parallel Title<br/>
Title Abbriviation<br/>
Title of Conference Proceedings<br/>
Translated Title<br/>
Uniform Title<br/>
Abbriviated Translated Title<br/>
Symposium or Session Title<br/>
Collective or Series Edition<br/>
Video/Film Edition<br/>
</td>
</tr>
<tr>
<td>creator</td>
<td>name/namePart</td>
<td>author<br/>creator</td>
<td>Author, Primary<br/>
Corporate Author, Primary<br/>
Abstract Author<br/>
Authorship Statement<br/>
Acknowledged Supporters<br/>
Assignee for Patents<br/>
Chairperson of Conference<br/>
Director of AV Program<br/>
Other Author<br/>
Reviewed Book Author<br/>
Studio<br/>
Sponsor of Conference<br/>
Staff/Cast<br/>
Symposium Chairperson<br/>
Author Address or Affiliation<br/>
Author Country<br/>
Electronic Address of Author<br/>
</td>
</tr>
<tr>
<td>subject</td>
<td>subject/topic</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>Description (abstract | tableOfContents)</td>
<td>abstract<br/>note<br/>tableOfContents</td>
<td>abstract<br/>annotation<br/>note<br/>contents</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Contributer</td>
<td>name</td>
<td>editor?</td>
<td>Book/Report/Volume Editor<br/>
Producer<br/>
Translator<br/>
</td>
</tr>
<tr>
<td>Date (available | created | dateAccepted | dateCopyrighted | dateSubmitted | issued | modified | valid)</td>
<td>originInfo/dateIssued<br/>originInfo/dateCreated<br/>originInfo/dateCaptured<br/>originInfo/dateOther</td>
<td>month<br/>year</td>
<td>Copyright Year<br/>Date-generic<br/>Date of conference<br/>Date of Publication<br/>Date of Update/Revisou/Issuance of Database Record<br/>Former Date<br/>Entry date for Database Record<br/>Database Update<br/>Year of Publication</td>
</tr>
<tr>
<td>Type</td>
<td>typeOfResource<br/>genre</td>
<td>@class<br/>type</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Format (extent | medium)</td>
<td>physicalDescription/internetMediaType<br/>physicalDescription/extent<br/>physicalDescription/form</td>
<td>published</td>
<td>needs mapping</td>
</tr>
<tr>
<td>identifier (bibliographicCitation)</td>
<td>identifier</td>
<td>ISBN<br/>ISSN<br/>LCCN<br/>URL</td>
<td>ISBN<br/>Identifier<br/>Report Identfier<br/>ISSN</td>
</tr>
<tr>
<td>Source</td>
<td>relatedItem</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>language</td>
<td>language</td>
<td>language</td>
<td bgcolor="#cccccc"></td>
</tr>
<tr>
<td>Relation (...)</td>
<td>relatedItem/...</td>
<td>crossRef</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Coverage (spacial | temporal)</td>
<td>subject/temporal<br/>subject/geographic<br/>subject/hierarchicalGeographic<br/>subject/cartographics</td>
<td></td>
<td>needs mapping</td>
</tr>
<tr>
<td bgcolor="#cccccc"></td>
<td>classifications</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>Rights (accessRights | license)</td>
<td>accessConditions</td>
<td>copyright</td>
<td>needs mapping</td>
</tr>
<tr>
<td>publisher</td>
<td bgcolor="#cccccc"></td>
<td>publisher</td>
<td>Publisher Name<br/>
Place of Publication<br/>
Country of Publication<br/>
Generic Address<br/>
</td>
</tr>
<tr>
<td>audience (educationLevel | mediator)</td>
<td>targetAudience</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td bgcolor="#999999">accualMethod<br/>accualPeriodicaty<br/>accualPolicy<br/>instrcutionalMethod<br/>provenance<br/>rightsHolder</td>
<td bgcolor="#999999">location<br/>extension<br/>recordInfo</td>
<td bgcolor="#999999">address<br/>afflilication<br/>location<br/>edition<br/>institution<br/>journal<br/>key<br/>keywords<br/>mrnumber<br/>organization<br/>price<br/>school<br/>size</td>
<td bgcolor="#999999">(the following need to be mapped to the above rows or left here as other)<br/><br/>
Database Source<br/>
Databse Record Identifier<br/>
Database Producer Name<br/>
Rights Management<br/>
Subfile<br/>
Other Source Identifier<br/>
Vendor Record Identifier<br/>
Database Vendor Name<br/>
Column Number<br/>
Edition<br/>
Frequency of Publication<br/>
Internet Location for Document<br/>
Supplement/Part/Special number identifer<br/>
Issue Identifier<br/>
Location in Work<br/>
Number of the Chapter<br/>
Number in Series<br/>
Volume Identifier<br/>
Section Indentifier<br/>
</td>
</tr>
</table>

== Dublin Core Metadata ==
[http://dublincore.org/ Dublin Core] metadata uses a small vocabulary to descibe the data.
* contributor
* coverage
* creator
* date
* description
* format
* identifier
* language
* publisher
* relation
* rights
* source
* subject
* title
* type

From those there are specialised types where are just refinments of the previous, for example:

* abstract refines description.
* accessRights refines rights

[http://dublincore.org/documents/dc-citation-guidelines/ Guidelines for Encoding Bibliographic Citation Information in Dublin Core Metadata]

== MODS (Metadata Object Description Schema) ==
This is a format developed for the Libray of Congress for a bibliographic element set that may be used for a variety of purposes, and particularly for library applications.

[http://www.loc.gov/standards/mods/ http://www.loc.gov/standards/mods/]

(the schema is very big, once i devote the proper time to review it, i will post more about the structure -brian)

== XMLResume ==
<pre>
<!ELEMENT pubs (pub+)>
<!ENTITY % pubElements "(artTitle|bookTitle|author|date|pubDate|publisher|pageNums|url)">
<!ELEMENT pub (para | %pubElements;)*>
<!ATTLIST pub id ID #IMPLIED>
<!ELEMENT artTitle (#PCDATA | link)*>
<!ELEMENT bookTitle (#PCDATA | link)*>
<!ELEMENT author (#PCDATA)>
<!ATTLIST author name IDREF #IMPLIED>
<!ELEMENT pubDate (month?, year)> 
<!ELEMENT publisher (#PCDATA | link | url)*>
<!ELEMENT pageNums (#PCDATA)>
</pre>

== BibTeX ==
=== Fields Used by Bibtex ===
<table border="1" width="100%">
<tr>
<td><strong>abstract:</strong></td>
<td>An abstract of the work.</td>
</tr>
<tr>
<td><b>address:</b></td>
<td>Publisher's address. For major publishing houses,
just the city is given. For small publishers, you can
help the reader by giving the complete address.</td>
</tr>
<tr>
<td><strong>affiliation:</strong></td>
<td>The author's affiliation.</td>
</tr>
<tr>
<td><b>annote:</b></td>
<td>An annotation. It is not used by he standard
bibliography styles, but may be used by others that
produce an annotated bibliography.</td>
</tr>
<tr>
<td><b>author:</b></td>
<td>The name(s) of the author(s).</td>
</tr>
<tr>
<td><b>booktitle: </b></td>
<td>Title of a book, part of which is being cited. For
book entries, use the <strong>title</strong> field
instead.</td>
</tr>
<tr>
<td><b>chapter:</b></td>
<td>A chapter (or section) number.</td>
</tr>
<tr>
<td><strong>contents:</strong></td>
<td>A Table of Contents.</td>
</tr>
<tr>
<td><strong>copyright:</strong></td>
<td>Copyright information.</td>
</tr>
<tr>
<td><strong>crossref:</strong></td>
<td>The database key of the entry being cross-referenced.</td>
</tr>
<tr>
<td><b>edition: </b></td>
<td>The edition of a book - for example
"Second". Notice that it is in capitals.</td>
</tr>
<tr>
<td><b>editor: </b></td>
<td>Name(s) of editor(s). If there is also an author
field, then the editor field gives the editor of the book
or collection in which the reference appears.</td>
</tr>
<tr>
<td><b>howpublished:</b></td>
<td>How something strange has been published. The first
word should be capitalized.</td>
</tr>
<tr>
<td><b>institution:</b></td>
<td>The sponsoring institution of a technical report.</td>
</tr>
<tr>
<td><strong>ISBN:</strong></td>
<td>The International Standard Book Number.</td>
</tr>
<tr>
<td><strong>ISSN:</strong></td>
<td>The International Standard Serial Number. Used to
identify a journal.</td>
</tr>
<tr>
<td><b>journal: </b></td>
<td>A journal name. Abbreviations are provided for many
journals.</td>
</tr>
<tr>
<td><b>key: </b></td>
<td>Used for alphabetizing and creating a label when the
author and editor fields are missing. This field should
not be confused with the key that appears at the
beginning of the reference.</td>
</tr>
<tr>
<td><strong>keywords:</strong></td>
<td>Key words used for searching or possibly for
annotation.</td>
</tr>
<tr>
<td><strong>language:</strong></td>
<td>The language the document is written in.</td>
</tr>
<tr>
<td><strong>LCCN:</strong></td>
<td>The Library of Congress Call Number.</td>
</tr>
<tr>
<td><strong>location:</strong></td>
<td>A location associated with the entry, such as the
city in which a conference took place.</td>
</tr>
<tr>
<td><b>month: </b></td>
<td>The month in which the work was published or, for an
unpublished work, in which it was written.</td>
</tr>
<tr>
<td><strong>mrnumber:</strong></td>
<td>The <em>Mathematical Reviews</em> number.</td>
</tr>
<tr>
<td><b>note:</b></td>
<td>Any additional information that can help the reader.
First word should be capitalized.</td>
</tr>
<tr>
<td><b>number: </b></td>
<td>The number of a journal, magazine, technical report,
or of a work in a series. An issue of a journal or
magazine is usually identified by its volume and number;
the organization that issues a technical report usually
gives it a number; and sometimes books are given numbers
in a named series.</td>
</tr>
<tr>
<td><b>organization: </b></td>
<td>The organization that sponsors a conference or
publishes a manual.</td>
</tr>
<tr>
<td><b>pages:</b></td>
<td>One or more page numbers or ranges of number, such as
37--42, or 7,53,82--94.</td>
</tr>
<tr>
<td><strong>price:</strong></td>
<td>The price of the material.</td>
</tr>
<tr>
<td><b>publisher:</b></td>
<td>The publisher's name.</td>
</tr>
<tr>
<td><b>school:</b></td>
<td>The name of the school where a thesis was written.</td>
</tr>
<tr>
<td><b>series:</b></td>
<td>Then name given a series or set of books. When citing
an entire book, the title field gives its title and the
optional series field gives the name of a series in which
the book was published.</td>
</tr>
<tr>
<td><strong>size:</strong></td>
<td>The physical dimensions of the work.</td>
</tr>
<tr>
<td><b>title:</b></td>
<td>The work's title.</td>
</tr>
<tr>
<td><b>type:</b></td>
<td>The type of technical report - for example,
"Research Note".</td>
</tr>
<tr>
<td><strong>url:</strong></td>
<td>The WWW Universal Resource Locator that points to the
item being referenced. Often used for technical reports
to point to the FTP site where it resides.</td>
</tr>
<tr>
<td><b>volume:</b></td>
<td>The volume of a journal or multivolume book.</td>
</tr>
<tr>
<td><b>year:</b></td>
<td>The year of publication or, for an unpublished work,
the year it was written. It should only consist of
numerals, such as 1976.</td>
</tr>
</table>
=== BibTeX citation Types ===
A reference can be to any of a variety of types. Following is a list of types. Each one also explains the fields associated with that type. Any fields not listed as required or optional are considered to be ignored.
<table border="1" width="100%">
<tr>
<td><b>article:</b></td>
<td>An article from a journal or magazine. Required
fields: author, title, journal, year. Optional fields:
volume, number, pages, month, note, key.</td>
</tr>
<tr>
<td><b>book:</b></td>
<td>A book with an explicit publisher. Required fields:
author or editor, title, publisher, year. Optional
fields: volume, series, address, edition, month, note,
key.</td>
</tr>
<tr>
<td><b>booklet: </b></td>
<td>A work that is printed and bound, but without a named
publisher or sponsoring institution. Required fields:
title. Optional fields: author, howpublished, address,
month, year, note, key.</td>
</tr>
<tr>
<td><strong>collection:</strong></td>
<td>A collection of works. Same as <a href="#proceedings">Proceedings</a>.</td>
</tr>
<tr>
<td><b>conference:</b></td>
<td>The same as <a href="#inproceedings">Inproceedings</a>.</td>
</tr>
<tr>
<td><b>inbook:</b></td>
<td>A part of a book, which may be a chapter and/or a
range of pages. Required fields: author or editor, title,
chapter and/or pages, publisher, year. Optional fields:
volumer, series, address, edition, month, note, key.</td>
</tr>
<tr>
<td><b>incollection:</b></td>
<td>A part of a book with its own title. Required fields:
author, title, booktitle, publisher, year. Optional
fields: editor, pages, organization, publisher, address,
month, note, key.</td>
</tr>
<tr>
<td><a name="inproceedings"></a><b>inproceedings:</b></td>
<td>An article in a conference proceedings. Required
fields: author, title, booktitle, year. Optional fields:
editor, pages, organization, publisher, address, month,
note, key.</td>
</tr>
<tr>
<td><b>manual: </b></td>
<td>Technical documentation. Required fields: title.
Optional fields: author, organization, address, edition,
month, year, note.</td>
</tr>
<tr>
<td><b>mastersthesis:</b></td>
<td>A Master's thesis. Required fields: author, title,
school, year. Optional fields: address, month, note, key.</td>
</tr>
<tr>
<td><b>misc:</b></td>
<td>Use this type when nothing else fits. Required
fields: none. Optional fields: author, title,
howpublished, month, year, note, key.</td>
</tr>
<tr>
<td><strong>patent:</strong></td>
<td>A patent.</td>
</tr>
<tr>
<td><b>phdthesis:</b></td>
<td>A Ph.D. thesis. Required fields: author, title,
school, year. Optional fields: address, month, note, key.</td>
</tr>
<tr>
<td><a name="proceedings"></a><b>proceedings:</b></td>
<td>The proceedings of a conference. Required fields:
title, year. Optional fields: editor, publisher,
organization, address, month, note, key.</td>
</tr>
<tr>
<td><b>techreport:</b></td>
<td>A report published by a school or other institution,
usually numbered within a series. Required fields:
author, title, institution, year. Optional fields: type,
number, address, month, note, key.</td>
</tr>
<tr>
<td><b>unpublished:</b></td>
<td>A document with an author and title, but not formally
published. Required fields: author, title, note. Optional
fields: month, year, key.</td>
</tr>
</table>

==== Examples ====
<pre><nowiki>
@book{kn:gnus,

AUTHOR = "Donald E. Knudson",
TITLE = "1966 World Gnus Almanac",
PUBLISHER = {Permafrost Press},
ADDRESS = {Novosibirsk} }

<div class="book" id="kn:gnus">
<div class="author">Donald E. Knudson</div>
<div class="title">1966 World Gnus Almanac</div>
<div class="publisher">Permafrost Press</div>
<div class="address">Novosibirsk</div>
</div>

@article{XAi_HSCheng_1994a,

author = "X. Ai and H. S. Cheng",
title = "Influence of moving dent on point {EHL} contacts",
journal = "Tribol. Trans.",
volume = "37",
year = "1994",
pages = "323--335",
}

<div class="article" id="XAi_HSCheng_1994a">
<div class="author">X. Ai and H. S. Cheng</div>
<div class="title">Influence of moving dent on point {EHL} contacts</div>
<div class="journal">Tribol. Trans.</div>
<div class="volume">37</div>
<div class="year">1994</div>
<div class="pages">323--335</div>
</div>
</nowiki></pre>

== OpenURL ==

OpenURL aka [http://www.niso.org/standards/standard_detail.cfm?std_id=783 Z39.88] defines a standard way of bundling citation data in a URL. It is widely deployed in academic libraries around the world to provide access to licensed content via link resolvers such as [http://www.exlibrisgroup.com/sfx_openurl.htm SFX]. The Context Object in Span ([http://ocoins.info/ COinS]) community standard represents one way to embed OpenURLs in XHTML without including a resolver target.

<pre>
<nowiki>
<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.issn=1045-4438"></span>
</nowiki>
</pre>

As you can see this isn't very much like semantic XHTML at all. However significant work has gone into defining the set of Key/Encoded Values (KEVs) that can be used in various [http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats types] of citations: [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:book book], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:dissertation dissertation], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:journal journal], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:patent patent]. It would be possible to simply provide a standard XHTML bundling for these keys as a microformat.

=== Example ===

<pre>
<nowiki>

<div class="openurl-journal">
<span class="aulast">Berners-Lee</span>,
<span class="aufirst">Tim</a>; Hendler, James; Lassila, Ora.</span>
"<span class="atitle">The Semantic Web</span>".
<span class="jtitle">Scientific American</span>
<span class="volume">284</span>(<span class="issue">5</span>), pp.
pp. <span class="pages">34-43</span>.
<span class="issn">0036-8733</span>
</div>

</nowiki>
</pre>

Using OpenURL in this way would enable third party applications that could, say grab citation metadata from a blog, and without much work fire it off at your university's or public libraries openurl resolver to see if the article is available via a licensed databases. The benefits [http://www.infotoday.com/newsbreaks/nb050801-1.shtml have] [http://www.ariadne.ac.uk/issue43/chudnov/ been] [http://www.wallandbinkley.com/quaedam/?p=30 noted] [http://hublog.hubmed.org/archives/001163.html elsewhere].

== Z39.80 ==
I'm not sure the best place for a guide to Z39.80 so please add links as you see fit:

[http://www.niso.org/standards/resources/drft4rev.html http://www.niso.org/standards/resources/drft4rev.html]

== DocBook ==

A subset of the DocBook vocabulary is dedicated to representing a bibliography: http://www.docbook.org/tdg/en/html/bibliography.html

<pre><nowiki>
<!DOCTYPE bibliography PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
<bibliography>
<title>Languages and Semantics</title>
<bibliodiv>
<title>Books</title>
<biblioentry>
<title>Course in General Linguistics</title>
<abbrev>deSaussure59</abbrev>
<author><firstname>Ferdinand</firstname><surname>de Saussure</surname></author>
<editor><firstname>Charles</firstname><surname>Bally</surname></editor>
<editor><firstname>Albert</firstname><surname>Sechehaye</surname></editor>
<othercredit role="translator"><firstname>Wade</firstname><surname>Baskin</surname></othercredit>
<copyright>
<year>1959</year>
<holder>The Philosophical Library Inc.</holder>
</copyright>
<isbn>07-016524-6</isbn>
<publisher>
<publishername>McGraw-Hill Book Company</publishername>
</publisher>
</biblioentry>
</bibliodiv>
</bibliography>
</nowiki></pre>

citation-formats

2006-01-18T05:13:37Z

MarkRickerby: added DocBook section

This page will display several different types of citation format types. The idea is to compare what properties are common amonst all of the formats and which ones should be blended into this microformat.

== Comparison chart ==
The following chart maps the terms from one implementation to another. This is important because if all the properties are introduced to this microformats, then its possible to map them to a number of different formats. The table currently only uses Dublin Core, MODS, and bibTeX. Each column has all the properties and their equivalent in each format. If there is no corresponding property the cell is grey. At the bottom of the list are the unique terms to each format. Dublin core has basic terms and terms that extend the basic ones. If the property is an extention of a basic term it is in ()'s. MODS uses XML, so any sub-properties are listed in their tree form, property/sub-property.

THIS IS NOT DEFINIATIVE, any errors should be corrected. More formats will be added to the list as they are mapped.

<table border="1">
<tr>
<th>Dublin Core</th>
<th>MODS</th>
<th>bibTeX</th>
<th>Z39.80</th>
</tr>
<tr>
<td>Title (alternative)</td>
<td>titleInfo/title<br/>titleInfo/PartNum</td>
<td>booktitle<br/>title<br/>chapter<br/>number<br/>pages<br/>volume<br/>series</td>
<td>Analytic Title<br/>
Collective or Series Title<br/>
Monographic Title<br/>
Work Fraction Title<br/>
Location of Conference<br/>
Main Entry<br/>
Name of Conference<br/>
Number of Meeting<br/>
Other Title<br/>
Parallel Title<br/>
Title Abbriviation<br/>
Title of Conference Proceedings<br/>
Translated Title<br/>
Uniform Title<br/>
Abbriviated Translated Title<br/>
Symposium or Session Title<br/>
Collective or Series Edition<br/>
Video/Film Edition<br/>
</td>
</tr>
<tr>
<td>creator</td>
<td>name/namePart</td>
<td>author<br/>creator</td>
<td>Author, Primary<br/>
Corporate Author, Primary<br/>
Abstract Author<br/>
Authorship Statement<br/>
Acknowledged Supporters<br/>
Assignee for Patents<br/>
Chairperson of Conference<br/>
Director of AV Program<br/>
Other Author<br/>
Reviewed Book Author<br/>
Studio<br/>
Sponsor of Conference<br/>
Staff/Cast<br/>
Symposium Chairperson<br/>
Author Address or Affiliation<br/>
Author Country<br/>
Electronic Address of Author<br/>
</td>
</tr>
<tr>
<td>subject</td>
<td>subject/topic</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>Description (abstract | tableOfContents)</td>
<td>abstract<br/>note<br/>tableOfContents</td>
<td>abstract<br/>annotation<br/>note<br/>contents</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Contributer</td>
<td>name</td>
<td>editor?</td>
<td>Book/Report/Volume Editor<br/>
Producer<br/>
Translator<br/>
</td>
</tr>
<tr>
<td>Date (available | created | dateAccepted | dateCopyrighted | dateSubmitted | issued | modified | valid)</td>
<td>originInfo/dateIssued<br/>originInfo/dateCreated<br/>originInfo/dateCaptured<br/>originInfo/dateOther</td>
<td>month<br/>year</td>
<td>Copyright Year<br/>Date-generic<br/>Date of conference<br/>Date of Publication<br/>Date of Update/Revisou/Issuance of Database Record<br/>Former Date<br/>Entry date for Database Record<br/>Database Update<br/>Year of Publication</td>
</tr>
<tr>
<td>Type</td>
<td>typeOfResource<br/>genre</td>
<td>@class<br/>type</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Format (extent | medium)</td>
<td>physicalDescription/internetMediaType<br/>physicalDescription/extent<br/>physicalDescription/form</td>
<td>published</td>
<td>needs mapping</td>
</tr>
<tr>
<td>identifier (bibliographicCitation)</td>
<td>identifier</td>
<td>ISBN<br/>ISSN<br/>LCCN<br/>URL</td>
<td>ISBN<br/>Identifier<br/>Report Identfier<br/>ISSN</td>
</tr>
<tr>
<td>Source</td>
<td>relatedItem</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>language</td>
<td>language</td>
<td>language</td>
<td bgcolor="#cccccc"></td>
</tr>
<tr>
<td>Relation (...)</td>
<td>relatedItem/...</td>
<td>crossRef</td>
<td>needs mapping</td>
</tr>
<tr>
<td>Coverage (spacial | temporal)</td>
<td>subject/temporal<br/>subject/geographic<br/>subject/hierarchicalGeographic<br/>subject/cartographics</td>
<td></td>
<td>needs mapping</td>
</tr>
<tr>
<td bgcolor="#cccccc"></td>
<td>classifications</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td>Rights (accessRights | license)</td>
<td>accessConditions</td>
<td>copyright</td>
<td>needs mapping</td>
</tr>
<tr>
<td>publisher</td>
<td bgcolor="#cccccc"></td>
<td>publisher</td>
<td>Publisher Name<br/>
Place of Publication<br/>
Country of Publication<br/>
Generic Address<br/>
</td>
</tr>
<tr>
<td>audience (educationLevel | mediator)</td>
<td>targetAudience</td>
<td bgcolor="#cccccc"></td>
<td>needs mapping</td>
</tr>
<tr>
<td bgcolor="#999999">accualMethod<br/>accualPeriodicaty<br/>accualPolicy<br/>instrcutionalMethod<br/>provenance<br/>rightsHolder</td>
<td bgcolor="#999999">location<br/>extension<br/>recordInfo</td>
<td bgcolor="#999999">address<br/>afflilication<br/>location<br/>edition<br/>institution<br/>journal<br/>key<br/>keywords<br/>mrnumber<br/>organization<br/>price<br/>school<br/>size</td>
<td bgcolor="#999999">(the following need to be mapped to the above rows or left here as other)<br/><br/>
Database Source<br/>
Databse Record Identifier<br/>
Database Producer Name<br/>
Rights Management<br/>
Subfile<br/>
Other Source Identifier<br/>
Vendor Record Identifier<br/>
Database Vendor Name<br/>
Column Number<br/>
Edition<br/>
Frequency of Publication<br/>
Internet Location for Document<br/>
Supplement/Part/Special number identifer<br/>
Issue Identifier<br/>
Location in Work<br/>
Number of the Chapter<br/>
Number in Series<br/>
Volume Identifier<br/>
Section Indentifier<br/>
</td>
</tr>
</table>

== Dublin Core Metadata ==
[http://dublincore.org/ Dublin Core] metadata uses a small vocabulary to descibe the data.
* contributor
* coverage
* creator
* date
* description
* format
* identifier
* language
* publisher
* relation
* rights
* source
* subject
* title
* type

From those there are specialised types where are just refinments of the previous, for example:

* abstract refines description.
* accessRights refines rights

[http://dublincore.org/documents/dc-citation-guidelines/ Guidelines for Encoding Bibliographic Citation Information in Dublin Core Metadata]

== MODS (Metadata Object Description Schema) ==
This is a format developed for the Libray of Congress for a bibliographic element set that may be used for a variety of purposes, and particularly for library applications.

[http://www.loc.gov/standards/mods/ http://www.loc.gov/standards/mods/]

(the schema is very big, once i devote the proper time to review it, i will post more about the structure -brian)

== XMLResume ==
<pre>
<!ELEMENT pubs (pub+)>
<!ENTITY % pubElements "(artTitle|bookTitle|author|date|pubDate|publisher|pageNums|url)">
<!ELEMENT pub (para | %pubElements;)*>
<!ATTLIST pub id ID #IMPLIED>
<!ELEMENT artTitle (#PCDATA | link)*>
<!ELEMENT bookTitle (#PCDATA | link)*>
<!ELEMENT author (#PCDATA)>
<!ATTLIST author name IDREF #IMPLIED>
<!ELEMENT pubDate (month?, year)> 
<!ELEMENT publisher (#PCDATA | link | url)*>
<!ELEMENT pageNums (#PCDATA)>
</pre>

== BibTeX ==
=== Fields Used by Bibtex ===
<table border="1" width="100%">
<tr>
<td><strong>abstract:</strong></td>
<td>An abstract of the work.</td>
</tr>
<tr>
<td><b>address:</b></td>
<td>Publisher's address. For major publishing houses,
just the city is given. For small publishers, you can
help the reader by giving the complete address.</td>
</tr>
<tr>
<td><strong>affiliation:</strong></td>
<td>The author's affiliation.</td>
</tr>
<tr>
<td><b>annote:</b></td>
<td>An annotation. It is not used by he standard
bibliography styles, but may be used by others that
produce an annotated bibliography.</td>
</tr>
<tr>
<td><b>author:</b></td>
<td>The name(s) of the author(s).</td>
</tr>
<tr>
<td><b>booktitle: </b></td>
<td>Title of a book, part of which is being cited. For
book entries, use the <strong>title</strong> field
instead.</td>
</tr>
<tr>
<td><b>chapter:</b></td>
<td>A chapter (or section) number.</td>
</tr>
<tr>
<td><strong>contents:</strong></td>
<td>A Table of Contents.</td>
</tr>
<tr>
<td><strong>copyright:</strong></td>
<td>Copyright information.</td>
</tr>
<tr>
<td><strong>crossref:</strong></td>
<td>The database key of the entry being cross-referenced.</td>
</tr>
<tr>
<td><b>edition: </b></td>
<td>The edition of a book - for example
"Second". Notice that it is in capitals.</td>
</tr>
<tr>
<td><b>editor: </b></td>
<td>Name(s) of editor(s). If there is also an author
field, then the editor field gives the editor of the book
or collection in which the reference appears.</td>
</tr>
<tr>
<td><b>howpublished:</b></td>
<td>How something strange has been published. The first
word should be capitalized.</td>
</tr>
<tr>
<td><b>institution:</b></td>
<td>The sponsoring institution of a technical report.</td>
</tr>
<tr>
<td><strong>ISBN:</strong></td>
<td>The International Standard Book Number.</td>
</tr>
<tr>
<td><strong>ISSN:</strong></td>
<td>The International Standard Serial Number. Used to
identify a journal.</td>
</tr>
<tr>
<td><b>journal: </b></td>
<td>A journal name. Abbreviations are provided for many
journals.</td>
</tr>
<tr>
<td><b>key: </b></td>
<td>Used for alphabetizing and creating a label when the
author and editor fields are missing. This field should
not be confused with the key that appears at the
beginning of the reference.</td>
</tr>
<tr>
<td><strong>keywords:</strong></td>
<td>Key words used for searching or possibly for
annotation.</td>
</tr>
<tr>
<td><strong>language:</strong></td>
<td>The language the document is written in.</td>
</tr>
<tr>
<td><strong>LCCN:</strong></td>
<td>The Library of Congress Call Number.</td>
</tr>
<tr>
<td><strong>location:</strong></td>
<td>A location associated with the entry, such as the
city in which a conference took place.</td>
</tr>
<tr>
<td><b>month: </b></td>
<td>The month in which the work was published or, for an
unpublished work, in which it was written.</td>
</tr>
<tr>
<td><strong>mrnumber:</strong></td>
<td>The <em>Mathematical Reviews</em> number.</td>
</tr>
<tr>
<td><b>note:</b></td>
<td>Any additional information that can help the reader.
First word should be capitalized.</td>
</tr>
<tr>
<td><b>number: </b></td>
<td>The number of a journal, magazine, technical report,
or of a work in a series. An issue of a journal or
magazine is usually identified by its volume and number;
the organization that issues a technical report usually
gives it a number; and sometimes books are given numbers
in a named series.</td>
</tr>
<tr>
<td><b>organization: </b></td>
<td>The organization that sponsors a conference or
publishes a manual.</td>
</tr>
<tr>
<td><b>pages:</b></td>
<td>One or more page numbers or ranges of number, such as
37--42, or 7,53,82--94.</td>
</tr>
<tr>
<td><strong>price:</strong></td>
<td>The price of the material.</td>
</tr>
<tr>
<td><b>publisher:</b></td>
<td>The publisher's name.</td>
</tr>
<tr>
<td><b>school:</b></td>
<td>The name of the school where a thesis was written.</td>
</tr>
<tr>
<td><b>series:</b></td>
<td>Then name given a series or set of books. When citing
an entire book, the title field gives its title and the
optional series field gives the name of a series in which
the book was published.</td>
</tr>
<tr>
<td><strong>size:</strong></td>
<td>The physical dimensions of the work.</td>
</tr>
<tr>
<td><b>title:</b></td>
<td>The work's title.</td>
</tr>
<tr>
<td><b>type:</b></td>
<td>The type of technical report - for example,
"Research Note".</td>
</tr>
<tr>
<td><strong>url:</strong></td>
<td>The WWW Universal Resource Locator that points to the
item being referenced. Often used for technical reports
to point to the FTP site where it resides.</td>
</tr>
<tr>
<td><b>volume:</b></td>
<td>The volume of a journal or multivolume book.</td>
</tr>
<tr>
<td><b>year:</b></td>
<td>The year of publication or, for an unpublished work,
the year it was written. It should only consist of
numerals, such as 1976.</td>
</tr>
</table>
=== BibTeX citation Types ===
A reference can be to any of a variety of types. Following is a list of types. Each one also explains the fields associated with that type. Any fields not listed as required or optional are considered to be ignored.
<table border="1" width="100%">
<tr>
<td><b>article:</b></td>
<td>An article from a journal or magazine. Required
fields: author, title, journal, year. Optional fields:
volume, number, pages, month, note, key.</td>
</tr>
<tr>
<td><b>book:</b></td>
<td>A book with an explicit publisher. Required fields:
author or editor, title, publisher, year. Optional
fields: volume, series, address, edition, month, note,
key.</td>
</tr>
<tr>
<td><b>booklet: </b></td>
<td>A work that is printed and bound, but without a named
publisher or sponsoring institution. Required fields:
title. Optional fields: author, howpublished, address,
month, year, note, key.</td>
</tr>
<tr>
<td><strong>collection:</strong></td>
<td>A collection of works. Same as <a href="#proceedings">Proceedings</a>.</td>
</tr>
<tr>
<td><b>conference:</b></td>
<td>The same as <a href="#inproceedings">Inproceedings</a>.</td>
</tr>
<tr>
<td><b>inbook:</b></td>
<td>A part of a book, which may be a chapter and/or a
range of pages. Required fields: author or editor, title,
chapter and/or pages, publisher, year. Optional fields:
volumer, series, address, edition, month, note, key.</td>
</tr>
<tr>
<td><b>incollection:</b></td>
<td>A part of a book with its own title. Required fields:
author, title, booktitle, publisher, year. Optional
fields: editor, pages, organization, publisher, address,
month, note, key.</td>
</tr>
<tr>
<td><a name="inproceedings"></a><b>inproceedings:</b></td>
<td>An article in a conference proceedings. Required
fields: author, title, booktitle, year. Optional fields:
editor, pages, organization, publisher, address, month,
note, key.</td>
</tr>
<tr>
<td><b>manual: </b></td>
<td>Technical documentation. Required fields: title.
Optional fields: author, organization, address, edition,
month, year, note.</td>
</tr>
<tr>
<td><b>mastersthesis:</b></td>
<td>A Master's thesis. Required fields: author, title,
school, year. Optional fields: address, month, note, key.</td>
</tr>
<tr>
<td><b>misc:</b></td>
<td>Use this type when nothing else fits. Required
fields: none. Optional fields: author, title,
howpublished, month, year, note, key.</td>
</tr>
<tr>
<td><strong>patent:</strong></td>
<td>A patent.</td>
</tr>
<tr>
<td><b>phdthesis:</b></td>
<td>A Ph.D. thesis. Required fields: author, title,
school, year. Optional fields: address, month, note, key.</td>
</tr>
<tr>
<td><a name="proceedings"></a><b>proceedings:</b></td>
<td>The proceedings of a conference. Required fields:
title, year. Optional fields: editor, publisher,
organization, address, month, note, key.</td>
</tr>
<tr>
<td><b>techreport:</b></td>
<td>A report published by a school or other institution,
usually numbered within a series. Required fields:
author, title, institution, year. Optional fields: type,
number, address, month, note, key.</td>
</tr>
<tr>
<td><b>unpublished:</b></td>
<td>A document with an author and title, but not formally
published. Required fields: author, title, note. Optional
fields: month, year, key.</td>
</tr>
</table>

==== Examples ====
<pre><nowiki>
@book{kn:gnus,

AUTHOR = "Donald E. Knudson",
TITLE = "1966 World Gnus Almanac",
PUBLISHER = {Permafrost Press},
ADDRESS = {Novosibirsk} }

<div class="book" id="kn:gnus">
<div class="author">Donald E. Knudson</div>
<div class="title">1966 World Gnus Almanac</div>
<div class="publisher">Permafrost Press</div>
<div class="address">Novosibirsk</div>
</div>

@article{XAi_HSCheng_1994a,

author = "X. Ai and H. S. Cheng",
title = "Influence of moving dent on point {EHL} contacts",
journal = "Tribol. Trans.",
volume = "37",
year = "1994",
pages = "323--335",
}

<div class="article" id="XAi_HSCheng_1994a">
<div class="author">X. Ai and H. S. Cheng</div>
<div class="title">Influence of moving dent on point {EHL} contacts</div>
<div class="journal">Tribol. Trans.</div>
<div class="volume">37</div>
<div class="year">1994</div>
<div class="pages">323--335</div>
</div>
</nowiki></pre>

== OpenURL ==

OpenURL aka [http://www.niso.org/standards/standard_detail.cfm?std_id=783 Z39.88] defines a standard way of bundling citation data in a URL. It is widely deployed in academic libraries around the world to provide access to licensed content via link resolvers such as [http://www.exlibrisgroup.com/sfx_openurl.htm SFX]. The Context Object in Span ([http://ocoins.info/ COinS]) community standard represents one way to embed OpenURLs in XHTML without including a resolver target.

<pre>
<nowiki>
<span class="Z3988" title="ctx_ver=Z39.88-2004&rft_val_fmt=info:ofi/fmt:kev:mtx:journal&rft.issn=1045-4438"></span>
</nowiki>
</pre>

As you can see this isn't very much like semantic XHTML at all. However significant work has gone into defining the set of Key/Encoded Values (KEVs) that can be used in various [http://alcme.oclc.org/openurl/servlet/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc&set=Core:Metadata+Formats types] of citations: [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:book book], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:dissertation dissertation], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:journal journal], [http://www.openurl.info/registry/docs/mtx/info:ofi/fmt:kev:mtx:patent patent]. It would be possible to simply provide a standard XHTML bundling for these keys as a microformat.

=== Example ===

<pre>
<nowiki>

<div class="openurl-journal">
<span class="aulast">Berners-Lee</span>,
<span class="aufirst">Tim</a>; Hendler, James; Lassila, Ora.</span>
"<span class="atitle">The Semantic Web</span>".
<span class="jtitle">Scientific American</span>
<span class="volume">284</span>(<span class="issue">5</span>), pp.
pp. <span class="pages">34-43</span>.
<span class="issn">0036-8733</span>
</div>

</nowiki>
</pre>

Using OpenURL in this way would enable third party applications that could, say grab citation metadata from a blog, and without much work fire it off at your university's or public libraries openurl resolver to see if the article is available via a licensed databases. The benefits [http://www.infotoday.com/newsbreaks/nb050801-1.shtml have] [http://www.ariadne.ac.uk/issue43/chudnov/ been] [http://www.wallandbinkley.com/quaedam/?p=30 noted] [http://hublog.hubmed.org/archives/001163.html elsewhere].

== Z39.80 ==
I'm not sure the best place for a guide to Z39.80 so please add links as you see fit:

[http://www.niso.org/standards/resources/drft4rev.html http://www.niso.org/standards/resources/drft4rev.html]

== DocBook ==

A sub-set of the DocBook vocabulary is dedicated to representing a bibliography: http://www.docbook.org/tdg/en/html/bibliography.html

citation-examples

2006-01-18T04:39:14Z

MarkRickerby: added extra pre tags for readability

= Example Citation Formats =
The following examples are real world examples that been pulled from places around the web. Please add to this list. The idea is that we get a solid sample of examples and see what commonalities there are amonst them and try to build this microformat so that it can meet 80% of all the possible properties.

== Citation Mark Up in the Wild ==
Mark up examples from reference publisher's websites (online catalogs), including ABC-CLIO, Greenwood Press, Marshall Cavendish, Oxford University Press (USA) and Thomson Gale. Examples are broken down and organized by element.

View complete [[citations in the wild]].

=== Book titles: ===
<pre>
<span id="title" class="producttitle">The 1920's</span>
(ABC-CLIO product detail page)

<div class="title"> <a href="...">The Greenwood Encyclopedia of World Folklore and Folklife</a> </div>
(Greenwood Press homepage)

<span id="lblTitle" class="book_headline block">The Greenwood Encyclopedia of World Folklore and Folklife</span>
(Greenwood Press product detail page)

<td width="35%"><font id="title_catalogue_title_font">Title</font></td>
<td width="65%"><font id="text">The New Terrorism: Anatomy, Trends and Counter-strategies</font></td>
(Marshall Cavendish product detail page)

<h2> <a href="...">The Glorious Cause</a> </h2>
(Oxford Univ. Press, homepage)

<h1>The Glorious Cause</h1>
(OUP, product detail page)

<h2>Contemporary Literary Criticism</h2>
(Thomson Gale, product detail page)

<span id="ctlBookDetailHeader_lblTitle" class="ProdTitle">Talk and Interaction in Social Research Methods</span> (SAGE Publications)
</pre>
Also, many examples where books presented in table format with Title as cell header, or presented "Title: "

=== Book Series Name: ===
<pre>
<span id="serieslbl" class="productsubtitle"><a href="...">Teaching With Documents Series</a></span>
(ABC-CLIO)
</pre>

=== Sub-title: ===
<pre>
<span id="subtitle" class="productsubtitle"></span>
(ABC-CLIO)

<div class="sub_title">[Four Volumes]</div>
(Greenwood, homepage)

<span id="lblSubTitle" class="book_subline">[Four Volumes]</span>
(Greenwood, product page)

<div class="subTitle"> The American Revolution, 1763-1789 </div>
(OUP)
</pre>

=== Author: ===
<pre>
<span id="credit" class="productauthor"></span>
(ABC-CLIO)

<div class="author">William M. Clements</div>
(Greenwood)

<td width="35%"><font id="title_catalogue_title_font">Authors</font></td>
<td width="65%"><font id="text">Andrew Tan & Kumar Ramakrishna (eds)</font></td>
(Marshall Cavendish)

<div class="byline"> Robert Middlekauff </div>
(OUP)
</pre>

=== Publication Date: ===
<pre>
<span id="pubdate" class="productdetailbody">11/2001</span>
(ABC-CLIO -- see table structure)

<div id="pnlPubDate"> <span class="book_options">Publication Date:</span> <span id="lblPubDate">12/30/2005</span> </div>
(Greenwood, detail page)

<span class="publicationDate"> Feb 2005 </span>
(OUP)

<li>Published/Released:<strong> March 1973</strong></li>
(Thomson Gale)
</pre>

=== Volumes: ===
<pre>
<td width="110" class="productdetailhead"><span id="volumeslabel" class="productdetailhead">Volumes</span></td>
<td width="180" class="productdetailbody"><span id="volumes" class="productdetailbody">1</span></td>
(ABC-CLIO)
</pre>

=== ISBN: ===
<pre>
<td class="productdetailhead" width="88"><span id="ISBNLabel">ISBN</span></td>
<td class="productdetailbody">1-57607-785-3</td>
(ABC-CLIO)

<div class="isbn">0-313-32847-1</div>
(Greenwood, homepage)

<div id="pnlIsbn"> <span class="book_options">ISBN:</span> <span id="lblIsbn">0-313-32847-1</span> </div>
(Greenwood, product page)

<td width="35%"><font id="title_catalogue_title_font">ISBN Number</font></td>
<td width="65%"><font id="text">9812102108</font></td>
(Marshall Cavendish)

<span class="isbnNumber">0195162471</span>
(OUP)

<li>ISBN: <strong>0-8103-0100-8</strong></li>
(Thomson Gale)
</pre>

=== Book Edition: ===
<pre>
<div class="edition"> Revised and Expanded Edition </div>
(OUP)
</pre>
Added by [[User:Tim White|Tim]]

== RFC vCard Example ==
<pre><nowiki>
9. References

[ISO 8601] ISO 8601:1988 - Data elements and interchange formats -
Information interchange - Representation of dates and
times - The International Organization for
Standardization, June, 1988.

[ISO 8601 TC] ISO 8601, Technical Corrigendum 1 - Data elements and
interchange formats - Information interchange -
Representation of dates and times - The International
Organization for Standardization, May, 1991.

[ISO 9070] ISO 9070, Information Processing - SGML support
facilities - Registration Procedures for Public Text
Owner Identifiers, April, 1991.

[CCITT E.163] Recommendation E.163 - Numbering Plan for The
International Telephone Service, CCITT Blue Book,
Fascicle II.2, pp. 128-134, November, 1988.

[CCITT X.121] Recommendation X.121 - International Numbering Plan for
Public Data Networks, CCITT Blue Book, Fascicle VIII.3,
pp. 317-332, November, 1988.

[CCITT X.520] Recommendation X.520 - The Directory - Selected
Attribute Types, November 1988.

[CCITT X.521] Recommendation X.521 - The Directory - Selected Object
Classes, November 1988.

[MIME-DIR] Howes, T., Smith, M., and F. Dawson, "A MIME Content-
Type for Directory Information", RFC 2425, September
1998.

[RFC 1738] Berners-Lee, T., Masinter, L., and M. McCahill,
"Uniform Resource Locators (URL)", RFC 1738, December
1994.

[RFC 1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.

[RFC 1872] Levinson, E., "The MIME Multipart/Related Content-
type", RFC 1872, December 1995.

[RFC 2045] Freed, N., and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) - Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.

[RFC 2046] Freed, N., and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) - Part Two: Media Types", RFC
2046, November 1996.

[RFC 2047] Moore, K., "Multipurpose Internet Mail Extensions
(MIME) - Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.

[RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) - Part Four:
Registration Procedures", RFC 2048, January 1997.

[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC 2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[UNICODE] "The Unicode Standard - Version 2.0", The Unicode
Consortium, July 1996.

[VCARD] Internet Mail Consortium, "vCard - The Electronic
Business Card Version 2.1",
http://www.imc.org/pdi/vcard-21.txt, September 18,
1996.
</nowiki></pre>
[http://www.faqs.org/rfcs/rfc2426.html vCard RFC]

== W3C XHTML Spec Example ==
<pre><nowiki>
<h1><a name="refs" id="refs">E.</a> References</h1>

<p><strong>This appendix is informative.</strong></p>

<dl>
<dt><a name="ref-css2" id="ref-css2"><strong>[CSS2]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/1998/REC-CSS2-19980512">Cascading Style Sheets, level 2 (CSS2) Specification</a></cite>", B. Bos, H. W. Lie, C. Lilley, I. Jacobs, 12 May 1998.<br />
<a href="http://www.w3.org/TR/REC-CSS2">Latest version</a> available at: http://www.w3.org/TR/REC-CSS2</dd>

<dt><a name="ref-dom" id="ref-dom"><strong>[DOM]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001">Document Object Model (DOM) Level 1 Specification</a></cite>", Lauren Wood <em lang="lt" xml:lang="lt">et al.</em>, 1 October
1998.<br />
<a href="http://www.w3.org/TR/REC-DOM-Level-1">Latest version</a> available at: http://www.w3.org/TR/REC-DOM-Level-1</dd>

<dt><a name="ref-dom2" id="ref-dom2"><strong>[DOM2]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113">Document Object Model (DOM) Level 2 Core Specification</a></cite>", A. Le Hors, <em lang="lt" xml:lang="lt">et
al.</em>, 13 November 2000.<br />
<a href="http://www.w3.org/TR/DOM-Level-2-Core">Latest version</a> available at: http://www.w3.org/TR/DOM-Level-2-Core</dd>

<dt><a name="ref-html4" id="ref-html4"><strong>[HTML]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</a></cite>", D. Raggett, A. Le Hors, I. Jacobs, 24 December 1999.<br />
<a href="http://www.w3.org/TR/html401">Latest version</a> available at: http://www.w3.org/TR/html401</dd>

<dt><a name="ref-posix.1" id="ref-posix.1"><strong>[POSIX.1]</strong></a></dt>

<dd>"<cite>ISO/IEC 9945-1:1990 Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language]</cite>", Institute of Electrical
and Electronics Engineers, Inc, 1990.</dd>

<dt><a id="ref-rfc2045" name="ref-rfc2045"><strong>[RFC2045]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2045.txt">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a></cite>", N. Freed and N. Borenstein, November
1996. Note that this RFC obsoletes RFC1521, RFC1522, and RFC1590.</dd>

<dt><a name="ref-rfc2046" id="ref-rfc2046"><strong>[RFC2046]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2046.txt">RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a></cite>", N. Freed and N. Borenstein, November 1996.<br />
Available at <a href="http://www.ietf.org/rfc/rfc2046.txt">http://www.ietf.org/rfc/rfc2046.txt</a>. Note that this RFC obsoletes RFC1521, RFC1522, and RFC1590.</dd>

<dt><a name="ref-rfc2119" id="ref-rfc2119"><strong>[RFC2119]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2119.txt">RFC2119: Key words for use in RFCs to Indicate Requirement Levels</a></cite>", S. Bradner, March 1997.<br />
Available at: http://www.ietf.org/rfc/rfc2119.txt</dd>

<dt><a name="ref-rfc2376" id="ref-rfc2376"><strong>[RFC2376]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2376.txt">RFC2376: XML Media Types</a></cite>", E. Whitehead, M. Murata, July 1998.<br />
This document is obsoleted by [<a href="#ref-rfc3023">RFC3023</a>].<br />
Available at: http://www.ietf.org/rfc/rfc2376.txt</dd>

<dt><a name="ref-rfc2396" id="ref-rfc2396"><strong>[RFC2396]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2396.txt">RFC2396: Uniform Resource Identifiers (URI): Generic Syntax</a></cite>", T. Berners-Lee, R. Fielding, L. Masinter, August 1998.<br />
This document updates RFC1738 and RFC1808.<br />
Available at: http://www.ietf.org/rfc/rfc2396.txt</dd>

<dt><a name="ref-rfc2854" id="ref-rfc2854"><strong>[RFC2854]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2854.txt">RFC2854: The text/html Media Type</a></cite>", D. Conolly, L. Masinter, June 2000.<br />
Available at: http://www.ietf.org/rfc/rfc2854.txt</dd>

<dt><a name="ref-rfc3023" id="ref-rfc3023"><strong>[RFC3023]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc3023.txt">RFC3023: XML Media Types</a></cite>", M. Murata, S. St.Laurent, D. Kohn, January 2001.<br />
This document obsoletes [<a href="#ref-rfc2376">RFC2376</a>].<br />
Available at: http://www.ietf.org/rfc/rfc3023.txt</dd>

<dt><a id="ref-rfc3066" name="ref-rfc3066"><strong>[RFC3066]</strong></a></dt>

<dd>"<a href="http://www.ietf.org/rfc/rfc3066.txt">Tags for the Identification of Languages</a>", H. Alvestrand, January 2001.<br />
Available at: http://www.ietf.org/rfc/rfc3066.txt</dd>

<dt><a id="ref-rfc3236" name="ref-rfc3236"><strong>[RFC3236]</strong></a></dt>

<dd>"<a href="http://www.ietf.org/rfc/rfc3236.txt">The 'application/xhtml+xml' Media Type</a>", M. Baker, P. Stark, January 2002.<br />
Available at: http://www.ietf.org/rfc/rfc3236.txt</dd>

<dt><a id="ref-xhtml-mathml" name="ref-xhtml-mathml"><strong>[XHTML+MathML]</strong></a></dt>

<dd><cite>"<a href="http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd">XHTML plus Math 1.1 <abbr title="Document Type Definition">DTD</abbr></a></cite>", "A.2 MathML as a DTD Module", Mathematical
Markup Language (MathML) Version 2.0. Available at: http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd</dd>

<dt><a id="ref-xhtmlmime" name="ref-xhtmlmime"><strong>[XHTMLMIME]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801">XHTML Media Types</a></cite>", Masayasu Ishikawa, 1 August 2002.<br />
<a href="http://www.w3.org/TR/xhtml-media-types">Latest version</a> available at: http://www.w3.org/TR/xhtml-media-types</dd>

<dt><a id="ref-xhtmlmod" name="ref-xhtmlmod"><strong>[XHTMLMOD]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410">Modularization of XHTML</a></cite>", M. Altheim et al., 10 April 2001.<br />
<a href="http://www.w3.org/TR/xhtml-modularization">Latest version</a> available at: http://www.w3.org/TR/xhtml-modularization</dd>

<dt><a name="ref-xml" id="ref-xml"><strong>[XML]</strong></a></dt>

<dd>"<a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible Markup Language (XML) 1.0 Specification (Second Edition)</a>", T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, 6 October
2000.<br />
<a href="http://www.w3.org/TR/REC-xml">Latest version</a> available at: http://www.w3.org/TR/REC-xml</dd>

<dt><a name="ref-xmlns" id="ref-xmlns"><strong>[XMLNS]</strong></a></dt>

<dd>"<a href="http://www.w3.org/TR/1999/REC-xml-names-19990114">Namespaces in XML</a>", T. Bray, D. Hollander, A. Layman, 14 January 1999.<br />
XML namespaces provide a simple method for qualifying names used in XML documents by associating them with namespaces identified by URI.<br />
<a href="http://www.w3.org/TR/REC-xml-names">Latest version</a> available at: http://www.w3.org/TR/REC-xml-names</dd>

<dt><a name="ref-xmlc14n" id="ref-xmlc14n"><strong>[XMLC14N]</strong></a></dt>

<dd>"<a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">Canonical XML Version 1.0</a>", J. Boyer, 15 March 2001.<br />
This document describes a method for generating a physical representation, the canonical form, of an XML document.<br />
<a href="http://www.w3.org/TR/xml-c14n">Latest version</a> available at: http://www.w3.org/TR/xml-c14n</dd>
</dl>
</nowiki></pre>
[http://www.w3.org/TR/xhtml1/#refs XHTML1.0 Spec references]

== CiteProc XHTML Output ==

The XHTML output for CiteProc[http://xbiblio.sourceforge.net/citeproc.html] wasn't designed per se as a microformat, but is probably not a bad place to start. It is desgined to handle a wide range of content. Here is the APA output:

<pre><nowiki>
<div id="bibliography">

<h3>References</h3>

<p id="Brenner2000a" class="bibref">
<span class="creator">Brenner, N.</span>
<span class="date"> (<span class="year">2000</span>) </span>
<span class="title">The Urban Question as a Scale Question: Reflections
on Henri Lefebre, Urban Theory and the Politics of Scale, </span>
<span class="container">
<span class="title" style="font-style: italic">International Journal of
Urban and Regional Research, </span>
<span class="volume">24</span>
<span class="issue">(2)</span>
<span class="locator">, pp. 361–78</span>
</span>.
</p>

<p id="NW2000-0207" class="bibref">
<span class="creator">Newsweek</span>
<span class="date">
(<span class="year">2000a</span>
<span class="month">, February</span>
<span class="day"> 7</span>)
</span>
<span class="title">The Grandmas Pay a Visit, </span>
<span class="container">
<span class="volume">135</span>
<span class="issue">(6)</span>
<span class="locator">, pp. 45</span>
</span>.
</p>

<p id="Veer1996a" class="bibref">
<span class="creator">van der Veer, P.</span>
<span class="date"><span class="year"> (1996) </span></span>
<span class="title">Riots and Rituals: The Construction of Violence
and Public Space in Hindu Nationalism</span>
<span class="container">, In Brass, P.<span class="role"> (Ed.)</span>.
<span class="title" style="font-style: italic">Riots and Pogroms.</span>
<span class="origin"><span class="place">New York</span>
<span class="publisher">: NYU Press</span></span>
<span class="locator">, pp. 154–76</span>
</span>.
</p>
</div>
</nowiki></pre>

= Styles =
This does NOT define a format, but instead shows how the format should be displayed. This is something out of the direct scope of this project. CSS styles will handle the look-and-feel of the text, and the author can put it in any order they choose. These links are mentioned for two reasons, one is informative, the other is so we know at least meet the minimum properties that are used in the styles.

* [http://www.liu.edu/cwis/cwp/library/workshop/citmla.htm MLA Style]
* [http://www.bu.edu/library/guides/citation.html Chicago, MLA, and APA styles]
* [http://www.legalbluebook.com/ Blue Book] for legal citations
* [http://www.columbia.edu/cu/cup/cgos/idx_basic.html Columbia University Citation Style] developed for modern internet citations

citation-examples

2006-01-18T04:35:51Z

MarkRickerby: fixed a typo

= Example Citation Formats =
The following examples are real world examples that been pulled from places around the web. Please add to this list. The idea is that we get a solid sample of examples and see what commonalities there are amonst them and try to build this microformat so that it can meet 80% of all the possible properties.

== Citation Mark Up in the Wild ==
Mark up examples from reference publisher's websites (online catalogs), including ABC-CLIO, Greenwood Press, Marshall Cavendish, Oxford University Press (USA) and Thomson Gale. Examples are broken down and organized by element.

View complete [[citations in the wild]].

=== Book titles: ===

<span id="title" class="producttitle">The 1920's</span>
(ABC-CLIO product detail page)

<div class="title"> <a href="...">The Greenwood Encyclopedia of World Folklore and Folklife</a> </div>
(Greenwood Press homepage)

<span id="lblTitle" class="book_headline block">The Greenwood Encyclopedia of World Folklore and Folklife</span>
(Greenwood Press product detail page)

<td width="35%"><font id="title_catalogue_title_font">Title</font></td>
<td width="65%"><font id="text">The New Terrorism: Anatomy, Trends and Counter-strategies</font></td>
(Marshall Cavendish product detail page)

<h2> <a href="...">The Glorious Cause</a> </h2>
(Oxford Univ. Press, homepage)

<h1>The Glorious Cause</h1>
(OUP, product detail page)

<h2>Contemporary Literary Criticism</h2>
(Thomson Gale, product detail page)

<span id="ctlBookDetailHeader_lblTitle" class="ProdTitle">Talk and Interaction in Social Research Methods</span> (SAGE Publications)

Also, many examples where books presented in table format with Title as cell header, or presented "Title: "

=== Book Series Name: ===

<span id="serieslbl" class="productsubtitle"><a href="...">Teaching With Documents Series</a></span>
(ABC-CLIO)

=== Sub-title: ===

<span id="subtitle" class="productsubtitle"></span>
(ABC-CLIO)

<div class="sub_title">[Four Volumes]</div>
(Greenwood, homepage)

<span id="lblSubTitle" class="book_subline">[Four Volumes]</span>
(Greenwood, product page)

<div class="subTitle"> The American Revolution, 1763-1789 </div>
(OUP)

=== Author: ===

<span id="credit" class="productauthor"></span>
(ABC-CLIO)

<div class="author">William M. Clements</div>
(Greenwood)

<td width="35%"><font id="title_catalogue_title_font">Authors</font></td>
<td width="65%"><font id="text">Andrew Tan & Kumar Ramakrishna (eds)</font></td>
(Marshall Cavendish)

<div class="byline"> Robert Middlekauff </div>
(OUP)

=== Publication Date: ===

<span id="pubdate" class="productdetailbody">11/2001</span>
(ABC-CLIO -- see table structure)

<div id="pnlPubDate"> <span class="book_options">Publication Date:</span> <span id="lblPubDate">12/30/2005</span> </div>
(Greenwood, detail page)

<span class="publicationDate"> Feb 2005 </span>
(OUP)

<li>Published/Released:<strong> March 1973</strong></li>
(Thomson Gale)

=== Volumes: ===

<td width="110" class="productdetailhead"><span id="volumeslabel" class="productdetailhead">Volumes</span></td>
<td width="180" class="productdetailbody"><span id="volumes" class="productdetailbody">1</span></td>
(ABC-CLIO)

=== ISBN: ===

<td class="productdetailhead" width="88"><span id="ISBNLabel">ISBN</span></td>
<td class="productdetailbody">1-57607-785-3</td>
(ABC-CLIO)

<div class="isbn">0-313-32847-1</div>
(Greenwood, homepage)

<div id="pnlIsbn"> <span class="book_options">ISBN:</span> <span id="lblIsbn">0-313-32847-1</span> </div>
(Greenwood, product page)

<td width="35%"><font id="title_catalogue_title_font">ISBN Number</font></td>
<td width="65%"><font id="text">9812102108</font></td>
(Marshall Cavendish)

<span class="isbnNumber">0195162471</span>
(OUP)

<li>ISBN: <strong>0-8103-0100-8</strong></li>
(Thomson Gale)

=== Book Edition: ===

<div class="edition"> Revised and Expanded Edition </div>
(OUP)

Added by [[User:Tim White|Tim]]

== RFC vCard Example ==
<pre><nowiki>
9. References

[ISO 8601] ISO 8601:1988 - Data elements and interchange formats -
Information interchange - Representation of dates and
times - The International Organization for
Standardization, June, 1988.

[ISO 8601 TC] ISO 8601, Technical Corrigendum 1 - Data elements and
interchange formats - Information interchange -
Representation of dates and times - The International
Organization for Standardization, May, 1991.

[ISO 9070] ISO 9070, Information Processing - SGML support
facilities - Registration Procedures for Public Text
Owner Identifiers, April, 1991.

[CCITT E.163] Recommendation E.163 - Numbering Plan for The
International Telephone Service, CCITT Blue Book,
Fascicle II.2, pp. 128-134, November, 1988.

[CCITT X.121] Recommendation X.121 - International Numbering Plan for
Public Data Networks, CCITT Blue Book, Fascicle VIII.3,
pp. 317-332, November, 1988.

[CCITT X.520] Recommendation X.520 - The Directory - Selected
Attribute Types, November 1988.

[CCITT X.521] Recommendation X.521 - The Directory - Selected Object
Classes, November 1988.

[MIME-DIR] Howes, T., Smith, M., and F. Dawson, "A MIME Content-
Type for Directory Information", RFC 2425, September
1998.

[RFC 1738] Berners-Lee, T., Masinter, L., and M. McCahill,
"Uniform Resource Locators (URL)", RFC 1738, December
1994.

[RFC 1766] Alvestrand, H., "Tags for the Identification of
Languages", RFC 1766, March 1995.

[RFC 1872] Levinson, E., "The MIME Multipart/Related Content-
type", RFC 1872, December 1995.

[RFC 2045] Freed, N., and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) - Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.

[RFC 2046] Freed, N., and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) - Part Two: Media Types", RFC
2046, November 1996.

[RFC 2047] Moore, K., "Multipurpose Internet Mail Extensions
(MIME) - Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.

[RFC 2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose
Internet Mail Extensions (MIME) - Part Four:
Registration Procedures", RFC 2048, January 1997.

[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC 2234] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.

[UNICODE] "The Unicode Standard - Version 2.0", The Unicode
Consortium, July 1996.

[VCARD] Internet Mail Consortium, "vCard - The Electronic
Business Card Version 2.1",
http://www.imc.org/pdi/vcard-21.txt, September 18,
1996.
</nowiki></pre>
[http://www.faqs.org/rfcs/rfc2426.html vCard RFC]

== W3C XHTML Spec Example ==
<pre><nowiki>
<h1><a name="refs" id="refs">E.</a> References</h1>

<p><strong>This appendix is informative.</strong></p>

<dl>
<dt><a name="ref-css2" id="ref-css2"><strong>[CSS2]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/1998/REC-CSS2-19980512">Cascading Style Sheets, level 2 (CSS2) Specification</a></cite>", B. Bos, H. W. Lie, C. Lilley, I. Jacobs, 12 May 1998.<br />
<a href="http://www.w3.org/TR/REC-CSS2">Latest version</a> available at: http://www.w3.org/TR/REC-CSS2</dd>

<dt><a name="ref-dom" id="ref-dom"><strong>[DOM]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001">Document Object Model (DOM) Level 1 Specification</a></cite>", Lauren Wood <em lang="lt" xml:lang="lt">et al.</em>, 1 October
1998.<br />
<a href="http://www.w3.org/TR/REC-DOM-Level-1">Latest version</a> available at: http://www.w3.org/TR/REC-DOM-Level-1</dd>

<dt><a name="ref-dom2" id="ref-dom2"><strong>[DOM2]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113">Document Object Model (DOM) Level 2 Core Specification</a></cite>", A. Le Hors, <em lang="lt" xml:lang="lt">et
al.</em>, 13 November 2000.<br />
<a href="http://www.w3.org/TR/DOM-Level-2-Core">Latest version</a> available at: http://www.w3.org/TR/DOM-Level-2-Core</dd>

<dt><a name="ref-html4" id="ref-html4"><strong>[HTML]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/1999/REC-html401-19991224">HTML 4.01 Specification</a></cite>", D. Raggett, A. Le Hors, I. Jacobs, 24 December 1999.<br />
<a href="http://www.w3.org/TR/html401">Latest version</a> available at: http://www.w3.org/TR/html401</dd>

<dt><a name="ref-posix.1" id="ref-posix.1"><strong>[POSIX.1]</strong></a></dt>

<dd>"<cite>ISO/IEC 9945-1:1990 Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language]</cite>", Institute of Electrical
and Electronics Engineers, Inc, 1990.</dd>

<dt><a id="ref-rfc2045" name="ref-rfc2045"><strong>[RFC2045]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2045.txt">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a></cite>", N. Freed and N. Borenstein, November
1996. Note that this RFC obsoletes RFC1521, RFC1522, and RFC1590.</dd>

<dt><a name="ref-rfc2046" id="ref-rfc2046"><strong>[RFC2046]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2046.txt">RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</a></cite>", N. Freed and N. Borenstein, November 1996.<br />
Available at <a href="http://www.ietf.org/rfc/rfc2046.txt">http://www.ietf.org/rfc/rfc2046.txt</a>. Note that this RFC obsoletes RFC1521, RFC1522, and RFC1590.</dd>

<dt><a name="ref-rfc2119" id="ref-rfc2119"><strong>[RFC2119]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2119.txt">RFC2119: Key words for use in RFCs to Indicate Requirement Levels</a></cite>", S. Bradner, March 1997.<br />
Available at: http://www.ietf.org/rfc/rfc2119.txt</dd>

<dt><a name="ref-rfc2376" id="ref-rfc2376"><strong>[RFC2376]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2376.txt">RFC2376: XML Media Types</a></cite>", E. Whitehead, M. Murata, July 1998.<br />
This document is obsoleted by [<a href="#ref-rfc3023">RFC3023</a>].<br />
Available at: http://www.ietf.org/rfc/rfc2376.txt</dd>

<dt><a name="ref-rfc2396" id="ref-rfc2396"><strong>[RFC2396]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2396.txt">RFC2396: Uniform Resource Identifiers (URI): Generic Syntax</a></cite>", T. Berners-Lee, R. Fielding, L. Masinter, August 1998.<br />
This document updates RFC1738 and RFC1808.<br />
Available at: http://www.ietf.org/rfc/rfc2396.txt</dd>

<dt><a name="ref-rfc2854" id="ref-rfc2854"><strong>[RFC2854]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc2854.txt">RFC2854: The text/html Media Type</a></cite>", D. Conolly, L. Masinter, June 2000.<br />
Available at: http://www.ietf.org/rfc/rfc2854.txt</dd>

<dt><a name="ref-rfc3023" id="ref-rfc3023"><strong>[RFC3023]</strong></a></dt>

<dd>"<cite><a href="http://www.ietf.org/rfc/rfc3023.txt">RFC3023: XML Media Types</a></cite>", M. Murata, S. St.Laurent, D. Kohn, January 2001.<br />
This document obsoletes [<a href="#ref-rfc2376">RFC2376</a>].<br />
Available at: http://www.ietf.org/rfc/rfc3023.txt</dd>

<dt><a id="ref-rfc3066" name="ref-rfc3066"><strong>[RFC3066]</strong></a></dt>

<dd>"<a href="http://www.ietf.org/rfc/rfc3066.txt">Tags for the Identification of Languages</a>", H. Alvestrand, January 2001.<br />
Available at: http://www.ietf.org/rfc/rfc3066.txt</dd>

<dt><a id="ref-rfc3236" name="ref-rfc3236"><strong>[RFC3236]</strong></a></dt>

<dd>"<a href="http://www.ietf.org/rfc/rfc3236.txt">The 'application/xhtml+xml' Media Type</a>", M. Baker, P. Stark, January 2002.<br />
Available at: http://www.ietf.org/rfc/rfc3236.txt</dd>

<dt><a id="ref-xhtml-mathml" name="ref-xhtml-mathml"><strong>[XHTML+MathML]</strong></a></dt>

<dd><cite>"<a href="http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd">XHTML plus Math 1.1 <abbr title="Document Type Definition">DTD</abbr></a></cite>", "A.2 MathML as a DTD Module", Mathematical
Markup Language (MathML) Version 2.0. Available at: http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd</dd>

<dt><a id="ref-xhtmlmime" name="ref-xhtmlmime"><strong>[XHTMLMIME]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/2002/NOTE-xhtml-media-types-20020801">XHTML Media Types</a></cite>", Masayasu Ishikawa, 1 August 2002.<br />
<a href="http://www.w3.org/TR/xhtml-media-types">Latest version</a> available at: http://www.w3.org/TR/xhtml-media-types</dd>

<dt><a id="ref-xhtmlmod" name="ref-xhtmlmod"><strong>[XHTMLMOD]</strong></a></dt>

<dd>"<cite><a href="http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410">Modularization of XHTML</a></cite>", M. Altheim et al., 10 April 2001.<br />
<a href="http://www.w3.org/TR/xhtml-modularization">Latest version</a> available at: http://www.w3.org/TR/xhtml-modularization</dd>

<dt><a name="ref-xml" id="ref-xml"><strong>[XML]</strong></a></dt>

<dd>"<a href="http://www.w3.org/TR/2000/REC-xml-20001006">Extensible Markup Language (XML) 1.0 Specification (Second Edition)</a>", T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, 6 October
2000.<br />
<a href="http://www.w3.org/TR/REC-xml">Latest version</a> available at: http://www.w3.org/TR/REC-xml</dd>

<dt><a name="ref-xmlns" id="ref-xmlns"><strong>[XMLNS]</strong></a></dt>

<dd>"<a href="http://www.w3.org/TR/1999/REC-xml-names-19990114">Namespaces in XML</a>", T. Bray, D. Hollander, A. Layman, 14 January 1999.<br />
XML namespaces provide a simple method for qualifying names used in XML documents by associating them with namespaces identified by URI.<br />
<a href="http://www.w3.org/TR/REC-xml-names">Latest version</a> available at: http://www.w3.org/TR/REC-xml-names</dd>

<dt><a name="ref-xmlc14n" id="ref-xmlc14n"><strong>[XMLC14N]</strong></a></dt>

<dd>"<a href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315">Canonical XML Version 1.0</a>", J. Boyer, 15 March 2001.<br />
This document describes a method for generating a physical representation, the canonical form, of an XML document.<br />
<a href="http://www.w3.org/TR/xml-c14n">Latest version</a> available at: http://www.w3.org/TR/xml-c14n</dd>
</dl>
</nowiki></pre>
[http://www.w3.org/TR/xhtml1/#refs XHTML1.0 Spec references]

== CiteProc XHTML Output ==

The XHTML output for CiteProc[http://xbiblio.sourceforge.net/citeproc.html] wasn't designed per se as a microformat, but is probably not a bad place to start. It is desgined to handle a wide range of content. Here is the APA output:

<pre><nowiki>
<div id="bibliography">

<h3>References</h3>

<p id="Brenner2000a" class="bibref">
<span class="creator">Brenner, N.</span>
<span class="date"> (<span class="year">2000</span>) </span>
<span class="title">The Urban Question as a Scale Question: Reflections
on Henri Lefebre, Urban Theory and the Politics of Scale, </span>
<span class="container">
<span class="title" style="font-style: italic">International Journal of
Urban and Regional Research, </span>
<span class="volume">24</span>
<span class="issue">(2)</span>
<span class="locator">, pp. 361–78</span>
</span>.
</p>

<p id="NW2000-0207" class="bibref">
<span class="creator">Newsweek</span>
<span class="date">
(<span class="year">2000a</span>
<span class="month">, February</span>
<span class="day"> 7</span>)
</span>
<span class="title">The Grandmas Pay a Visit, </span>
<span class="container">
<span class="volume">135</span>
<span class="issue">(6)</span>
<span class="locator">, pp. 45</span>
</span>.
</p>

<p id="Veer1996a" class="bibref">
<span class="creator">van der Veer, P.</span>
<span class="date"><span class="year"> (1996) </span></span>
<span class="title">Riots and Rituals: The Construction of Violence
and Public Space in Hindu Nationalism</span>
<span class="container">, In Brass, P.<span class="role"> (Ed.)</span>.
<span class="title" style="font-style: italic">Riots and Pogroms.</span>
<span class="origin"><span class="place">New York</span>
<span class="publisher">: NYU Press</span></span>
<span class="locator">, pp. 154–76</span>
</span>.
</p>
</div>
</nowiki></pre>

= Styles =
This does NOT define a format, but instead shows how the format should be displayed. This is something out of the direct scope of this project. CSS styles will handle the look-and-feel of the text, and the author can put it in any order they choose. These links are mentioned for two reasons, one is informative, the other is so we know at least meet the minimum properties that are used in the styles.

* [http://www.liu.edu/cwis/cwp/library/workshop/citmla.htm MLA Style]
* [http://www.bu.edu/library/guides/citation.html Chicago, MLA, and APA styles]
* [http://www.legalbluebook.com/ Blue Book] for legal citations
* [http://www.columbia.edu/cu/cup/cgos/idx_basic.html Columbia University Citation Style] developed for modern internet citations

rest/datatypes

2006-01-10T06:49:01Z

MarkRickerby:

= Datatypes in HTML =
One of the challenges of using HTML as a data transport is that everything, by default, is a string. This page explores ways to use microformats -- specifically, class names -- to encode data type information, e.g., for use with [[xoxo]] and [[rest/ahah]], in order to allow lossless import/export from various languages. These could also be used with forms to provide [[rest/description]]s of the type of data expected.

== Examples ==

These are the primary datatypes in a range of different languages and formats. Note that we are only concerned with "primitive" datatypes (loosely defined), as structured datatypes (list/array, hash/dictionary) are handled by [[xoxo]].

{| border="1" cellpadding="2"
|+Datatype comparison table
|-
! Language/format !! string !! float !! integer !! boolean !! data || date/time || null
|-
! [http://www.w3.org/TR/xmlschema-2/#built-in-datatypes XML Schema]
| string || float, double || decimal, integer, etc. || boolean || hexBinary, base64Binary || duration, dateTime, date, time || nil
|-
! [http://ws.apache.org/xmlrpc/types.html XML-RPC]
| string || double || i4, int|| boolean || base64 || dateTime.iso8601 || nil
|-
! [http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Concepts/XMLPListsConcept.html Mac OS X plists]
| string || real || integer || true, false || data || date || nil
|-
! [http://www.crockford.com/JSON JSON] (JavaScript)
| string || number || number || true, false || N/A || Date || nil
|-
! [http://yaml.org/spec/current.html#id2503753 YAML] tags
| str || int || float || bool || null (base 64) || N/A || null
|-
! [http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html#table1 SQL (JDBC)]
| char,varchar || float, double, real || decimal, numeric || bit || binary || date, time, timestamp || ?
|-
! [http://www.sysprog.net/ctype.html C]
| char[] || float, double || int, long, short || bool, int || char[] || N/A || (void*)0
|-
! [http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html Java]
| char, String || float, double || int, long, short, byte || boolean || N/A || util.Date || null
|-
! [http://www.zend.com/manual/language.types.php PHP]
| string || float (double)|| integer || boolean || array || N/A || NULL
|-
! [http://search.cpan.org/dist/perl/pod/perldata.pod Perl]
| array || scalar || scalar || scalar || array || N/A
|-
! [http://en.wikibooks.org/wiki/Programming:Python_Numbers Python]
| str || float, complex || int, long || bool || binascii, base64 || time,datetime
|-
! [http://www.rubycentral.com/book/ext_ruby.html Ruby] + [http://www.rubycentral.com/book/lib_standard.html lib]
| String || Float || Fixnum, Bignum || TrueClass,FalseClass || Hash || Date || NilClass
|-
|}

== Analysis ==
The most common set of datatypes appears to be those represented by XML-RPC, which (perhaps fortunately) also has historical precedence on the web:
* string
* double
* int [i4]
* boolean
* base64
* dateTime[.iso8601]

Whlle not perfect, these certainly cover the 80% case, and are reasonably well-defined. That said, there are a number of open questions about how to use them:
# should 'string' also be explicitly specified, or can it be assumed?
# does 'int' always mean 32-bits?
## If so, what should be used for 64-bit integers or cryptographic (256-bit+) numbers?
###Python's 'long' is simple, but ambiguous.
###Ruby's BigNum is clear but much less common.
###XML-Schema has so many types it is hard to say.
###SQL's "decimal", perhaps?
## If not, how should conforming implementations react to longer integers than they can handle?
# Is it worth deviating from the standard to allow "dateTime" as an alias? (the one case where XML Schema is actually simpler)

== Proposals ==
* TBD

== References ==
* [http://en.wikipedia.org/wiki/Datatype Datatypes] in Wikipedia
* Origional [http://microformats.org/discuss/mail/microformats-discuss/2005-September/001020.html datatype] discussion
* Original [http://homepage.mac.com/drernie/plist.html plist] datatype mapping proposal
* Revised [http://opendarwin.org/~drernie/xoxo-datatypes.html xoxo datatype] proposal

rest/datatypes

2006-01-10T06:47:00Z

MarkRickerby: /* Examples */

= Datatypes in HTML =
One of the challenges of using HTML as a data transport is that everything, by default, is a string. This page explores ways to use microformats -- specifically, class names -- to encode data type information, e.g., for use with [[xoxo]] and [[rest/ahah]], in order to allow lossless import/export from various languages. These could also be used with forms to provide [[rest/description]]s of the type of data expected.

== Examples ==

These are the primary datatypes in a range of different languages and formats. Note that we are only concerned with "primitive" datatypes (loosely defined), as structured datatypes (list/array, hash/dictionary) are handled by [[xoxo]].

{| border="1" cellpadding="2"
|+Datatype comparison table
|-
! Language/format !! string !! float !! integer !! boolean !! data || date/time || null
|-
! [http://www.w3.org/TR/xmlschema-2/#built-in-datatypes XML Schema]
| string || float, double || decimal, integer, etc. || boolean || hexBinary, base64Binary || duration, dateTime, date, time || nil
|-
! [http://ws.apache.org/xmlrpc/types.html XML-RPC]
| string || double || i4, int|| boolean || base64 || dateTime.iso8601 || nil
|-
! [http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Concepts/XMLPListsConcept.html Mac OS X plists]
| string || real || integer || true, false || data || date || nil
|-
! [http://www.crockford.com/JSON JSON] (JavaScript)
| string || number || number || true, false || N/A || Date || nil
|-
! [http://yaml.org/spec/current.html#id2503753 YAML] tags
| str || int || float || bool || null (base 64) || N/A || null
|-
! [http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html#table1 SQL (JDBC)]
| char,varchar || float, double, real || decimal, numeric || bit || binary || date, time, timestamp || null
|-
! [http://www.sysprog.net/ctype.html C]
| char[] || float, double || int, long, short || bool, int || char[] || N/A || (void*)0
|-
! [http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html Java]
| char, String || float, double || int, long, short, byte || boolean || N/A || util.Date || ?
|-
! [http://www.zend.com/manual/language.types.php PHP]
| string || float (double)|| integer || boolean || array || N/A || NULL
|-
! [http://search.cpan.org/dist/perl/pod/perldata.pod Perl]
| array || scalar || scalar || scalar || array || N/A
|-
! [http://en.wikibooks.org/wiki/Programming:Python_Numbers Python]
| str || float, complex || int, long || bool || binascii, base64 || time,datetime
|-
! [http://www.rubycentral.com/book/ext_ruby.html Ruby] + [http://www.rubycentral.com/book/lib_standard.html lib]
| String || Float || Fixnum, Bignum || TrueClass,FalseClass || Hash || Date || NilClass
|-
|}

== Analysis ==
The most common set of datatypes appears to be those represented by XML-RPC, which (perhaps fortunately) also has historical precedence on the web:
* string
* double
* int [i4]
* boolean
* base64
* dateTime[.iso8601]

Whlle not perfect, these certainly cover the 80% case, and are reasonably well-defined. That said, there are a number of open questions about how to use them:
# should 'string' also be explicitly specified, or can it be assumed?
# does 'int' always mean 32-bits?
## If so, what should be used for 64-bit integers or cryptographic (256-bit+) numbers?
###Python's 'long' is simple, but ambiguous.
###Ruby's BigNum is clear but much less common.
###XML-Schema has so many types it is hard to say.
###SQL's "decimal", perhaps?
## If not, how should conforming implementations react to longer integers than they can handle?
# Is it worth deviating from the standard to allow "dateTime" as an alias? (the one case where XML Schema is actually simpler)

== Proposals ==
* TBD

== References ==
* [http://en.wikipedia.org/wiki/Datatype Datatypes] in Wikipedia
* Origional [http://microformats.org/discuss/mail/microformats-discuss/2005-September/001020.html datatype] discussion
* Original [http://homepage.mac.com/drernie/plist.html plist] datatype mapping proposal
* Revised [http://opendarwin.org/~drernie/xoxo-datatypes.html xoxo datatype] proposal

rest/datatypes

2006-01-10T06:46:17Z

MarkRickerby: /* Examples */

= Datatypes in HTML =
One of the challenges of using HTML as a data transport is that everything, by default, is a string. This page explores ways to use microformats -- specifically, class names -- to encode data type information, e.g., for use with [[xoxo]] and [[rest/ahah]], in order to allow lossless import/export from various languages. These could also be used with forms to provide [[rest/description]]s of the type of data expected.

== Examples ==

These are the primary datatypes in a range of different languages and formats. Note that we are only concerned with "primitive" datatypes (loosely defined), as structured datatypes (list/array, hash/dictionary) are handled by [[xoxo]].

{| border="1" cellpadding="2"
|+Datatype comparison table
|-
! Language/format !! string !! float !! integer !! boolean !! data || date/time || null
|-
! [http://www.w3.org/TR/xmlschema-2/#built-in-datatypes XML Schema]
| string || float, double || decimal, integer, etc. || boolean || hexBinary, base64Binary || duration, dateTime, date, time || nil
|-
! [http://ws.apache.org/xmlrpc/types.html XML-RPC]
| string || double || i4, int|| boolean || base64 || dateTime.iso8601 || nil
|-
! [http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Concepts/XMLPListsConcept.html Mac OS X plists]
| string || real || integer || true, false || data || date || nil
|-
! [http://www.crockford.com/JSON JSON] (JavaScript)
| string || number || number || true, false || N/A || Date || nil
|-
! [http://yaml.org/spec/current.html#id2503753 YAML] tags
| str || int || float || bool || null (base 64) || N/A || null
|-
! [http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html#table1 SQL (JDBC)]
| char,varchar || float, double, real || decimal, numeric || bit || binary || date, time, timestamp || ?
|-
! [http://www.sysprog.net/ctype.html C]
| char[] || float, double || int, long, short || bool, int || char[] || N/A || (void*)0
|-
! [http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html Java]
| char, String || float, double || int, long, short, byte || boolean || N/A || util.Date || ?
|-
! [http://www.zend.com/manual/language.types.php PHP]
| string || float (double)|| integer || boolean || array || N/A || NULL
|-
! [http://search.cpan.org/dist/perl/pod/perldata.pod Perl]
| array || scalar || scalar || scalar || array || N/A
|-
! [http://en.wikibooks.org/wiki/Programming:Python_Numbers Python]
| str || float, complex || int, long || bool || binascii, base64 || time,datetime
|-
! [http://www.rubycentral.com/book/ext_ruby.html Ruby] + [http://www.rubycentral.com/book/lib_standard.html lib]
| String || Float || Fixnum, Bignum || TrueClass,FalseClass || Hash || Date || NilClass
|-
|}

== Analysis ==
The most common set of datatypes appears to be those represented by XML-RPC, which (perhaps fortunately) also has historical precedence on the web:
* string
* double
* int [i4]
* boolean
* base64
* dateTime[.iso8601]

Whlle not perfect, these certainly cover the 80% case, and are reasonably well-defined. That said, there are a number of open questions about how to use them:
# should 'string' also be explicitly specified, or can it be assumed?
# does 'int' always mean 32-bits?
## If so, what should be used for 64-bit integers or cryptographic (256-bit+) numbers?
###Python's 'long' is simple, but ambiguous.
###Ruby's BigNum is clear but much less common.
###XML-Schema has so many types it is hard to say.
###SQL's "decimal", perhaps?
## If not, how should conforming implementations react to longer integers than they can handle?
# Is it worth deviating from the standard to allow "dateTime" as an alias? (the one case where XML Schema is actually simpler)

== Proposals ==
* TBD

== References ==
* [http://en.wikipedia.org/wiki/Datatype Datatypes] in Wikipedia
* Origional [http://microformats.org/discuss/mail/microformats-discuss/2005-September/001020.html datatype] discussion
* Original [http://homepage.mac.com/drernie/plist.html plist] datatype mapping proposal
* Revised [http://opendarwin.org/~drernie/xoxo-datatypes.html xoxo datatype] proposal

rest/datatypes

2006-01-10T05:40:09Z

MarkRickerby: /* Examples */

= Datatypes in HTML =
One of the challenges of using HTML as a data transport is that everything, by default, is a string. This page explores ways to use microformats -- specifically, class names -- to encode data type information, e.g., for use with [[xoxo]] and [[rest/ahah]], in order to allow lossless import/export from various languages. These could also be used with forms to provide [[rest/description]]s of the type of data expected.

== Examples ==

These are the primary datatypes in a range of different languages and formats. Note that we are only concerned with "primitive" datatypes (loosely defined), as structured datatypes (list/array, hash/dictionary) are handled by [[xoxo]].

{| border="1" cellpadding="2"
|+Datatype comparison table
|-
! Language/format !! string !! float !! integer !! boolean !! data || date/time || null
|-
! [http://www.w3.org/TR/xmlschema-2/#built-in-datatypes XML Schema]
| string || float, double || decimal, integer, etc. || boolean || hexBinary, base64Binary || duration, dateTime, date, time || nil
|-
! [http://ws.apache.org/xmlrpc/types.html XML-RPC]
| string || double || i4, int|| boolean || base64 || dateTime.iso8601 || nil
|-
! [http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Concepts/XMLPListsConcept.html Mac OS X plists]
| string || real || integer || true, false || data || date || nil
|-
! [http://www.crockford.com/JSON JSON] (JavaScript)
| string || number || number || true, false || N/A || Date || nil
|-
! [http://yaml.org/spec/current.html#id2503753 YAML] tags
| str || int || float || bool || null (base 64) || N/A || null
|-
! [http://java.sun.com/j2se/1.3/docs/guide/jdbc/getstart/mapping.html#table1 SQL (JDBC)]
| char,varchar || float, double, real || decimal, numeric || bit || binary || date, time, timestamp || ?
|-
! [http://www.sysprog.net/ctype.html C]
| char[] || float, double || int, long, short || bool, int || char[] || N/A || (void*)0
|-
! [http://java.sun.com/docs/books/tutorial/java/nutsandbolts/datatypes.html Java]
| char, String || float, double || int, long, short, byte || boolean || N/A || util.Date || ?
|-
! [http://www.zend.com/manual/language.types.php PHP]
| string || float (double)|| integer || boolean || array || N/A || NULL
|-
! [http://search.cpan.org/dist/perl/pod/perldata.pod Perl]
| array || scalar || scalar || scalar || array || N/A
|-
! [http://en.wikibooks.org/wiki/Programming:Python_Numbers Python]
| str || float, complex || int, long || bool || binascii, base64 || time,datetime
|-
! [http://www.rubycentral.com/book/ext_ruby.html Ruby] + [http://www.rubycentral.com/book/lib_standard.html lib]
| String || Float || Fixnum, Bignum || TrueClass,FalseClass || Hash || Date
|-
|}

== Analysis ==
The most common set of datatypes appears to be those represented by XML-RPC, which (perhaps fortunately) also has historical precedence on the web:
* string
* double
* int [i4]
* boolean
* base64
* dateTime[.iso8601]

Whlle not perfect, these certainly cover the 80% case, and are reasonably well-defined. That said, there are a number of open questions about how to use them:
# should 'string' also be explicitly specified, or can it be assumed?
# does 'int' always mean 32-bits?
## If so, what should be used for 64-bit integers or cryptographic (256-bit+) numbers?
###Python's 'long' is simple, but ambiguous.
###Ruby's BigNum is clear but much less common.
###XML-Schema has so many types it is hard to say.
###SQL's "decimal", perhaps?
## If not, how should conforming implementations react to longer integers than they can handle?
# Is it worth deviating from the standard to allow "dateTime" as an alias? (the one case where XML Schema is actually simpler)

== Proposals ==
* TBD

== References ==
* [http://en.wikipedia.org/wiki/Datatype Datatypes] in Wikipedia
* Origional [http://microformats.org/discuss/mail/microformats-discuss/2005-September/001020.html datatype] discussion
* Original [http://homepage.mac.com/drernie/plist.html plist] datatype mapping proposal
* Revised [http://opendarwin.org/~drernie/xoxo-datatypes.html xoxo datatype] proposal

hatom-issues

2006-01-06T04:00:46Z

MarkRickerby: /* Feed (atom:feed) */

= Discussion Participants =

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

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

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

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

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

= New Nomenclature =

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

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

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

=== Discussion ===

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

=== Discussion ===

== Entry Title (atom:title) ==
* <code>class="title"</code> (Atom consistency)
* <code>class="entry-title"</code> (Atom consistency, avoid hCard conflict)
* <code>class="heading"</code> (HTML)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (hReview consistency)
* <code>class="headline"</code> what they're called in the News/Journalism industry
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="fn"</code> hReview item consistency

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

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

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

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

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

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

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

BenjaminCarlyle: I have been trying to convince meyself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com describes summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt.

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

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

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

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

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

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

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

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

== Entry Contributor (atom:author) ==
* <code>class="contibutor"</code> (Atom consistency)
: -1 Tantek - recommend postpone from hAtom first version, since the 80% case does not need "contributor". We can always add it later if we need it.

=== Discussion ===

= Questions and Comments =

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

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

== Nomenclature ==

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

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

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

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

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

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

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

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

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

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

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

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

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

* Tantek: agreed.

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

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'

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

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

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

* atom:summary is described as abstract in

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

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

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

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

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

"Pushed back" is the wrong direction here.

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

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

- Tantek

== hCards ==

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

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

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

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

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

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

has an assumed defined mapping to

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

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

== Comparisons ==

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

-- [[Ernie Prabhakar]]

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

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

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

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

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

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

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

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

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

-- BenjaminCarlyle

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

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

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

IMHO yes. -- Tantek

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

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

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

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

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

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

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

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

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

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

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

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

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

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

rel-design-pattern

2006-01-04T23:53:07Z

MarkRickerby: /* Description */

= Rel design pattern =

== Purpose ==
Use the [[rel-design-pattern]] to indicate the meaning of a link (i.e. a href) in an XHTML document

== How to use it ==

* define the semantic meaning of a link (<code>A</code> with <code>href</code>) within a micoformat and give it a name <code>''mf-rel-value''</code>
** this definition may also extend to the value of elements and text enclosed by the link
* add <code>rel="''mf-rel-value''"</code> to hyperlinks that have that semantic meaning within that microformat.
* simple microformats that use only the [[rel-design-pattern]] are typically named after the rel-value

== Examples ==

==== rel="bookmark" ====

The [http://www.w3.org/TR/REC-html40/types.html#h-6.12 HTML4 spec] describes a bookmark as "a link to a key entry point within an extended document". By convention, this entry point also captures the notion of a "permalink".

<pre>
<a href="archive/entry.html" rel="bookmark">A Document Entry</a>
</pre>

==== rel="tag" ====

[[rel-tag]] defines semantic meaning for by the URI and enclosed elements using <code>rel="tag"</code>

<pre>
<a href="http://technorati.com/tag/tech" rel="tag">tech</a>
</pre>

== See Also ==
* [[Main_Page#Design_Patterns|All microformat design patterns]]
* [http://www.w3.org/TR/REC-html40/struct/links.html#edef-A HTML 4.01 definition of the <code>A</code> element]
* [http://www.w3.org/TR/REC-html40/struct/links.html#adef-rel HTML 4.01 definition of the <code>rel</code> attribute]
* Microformats: [[rel-license]], [[rel-nofollow]], [[rel-tag]]
* Proposals: [[rel-directory]], [[rel-enclosure]]

hatom-issues

2006-01-03T19:46:38Z

MarkRickerby: /* Entry (atom:entry) */

= Discussion Participants =

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

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

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

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

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

= New Nomenclature =

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

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

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

=== Discussion ===

== Entry (atom:entry) ==
* <code>class="entry</code> (Atom consistency)
: +1 MarkRickerby
* <code>class="atom-entry</code> (Atom consistency with prefix)
* <code>class="hentry</code> (h* uF consistency)
: +1 DavidJanes

=== Discussion ===

== Entry Title (atom:title) ==
* <code>class="title"</code> (Atom consistency)
* <code>class="entry-title"</code> (Atom consistency, avoid hCard conflict)
* <code>class="heading"</code> (HTML)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (hReview consistency)

=== Discussion ===

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

=== Discussion ===

== Entry Summary (atom:summary) ==
* <code>class="summary"</code> (Atom consistency)
* <code>class="content-summary"</code> (Atom consistency avoiding hCalendar conflict)
* <code>class="partial-description"</code>
* <code>class="excerpt"</code>

=== Discussion ===

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

=== Discussion ===

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

=== Discussion ===

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

=== Discussion ===

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

=== Discussion ===

== Entry Contributor (atom:author) ==
* <code>class="contibutor"</code> (Atom consistency)

=== Discussion ===

= Questions and Comments =

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

* We've deliberately restricted this to being a "blog post" microformat at this point to make the problem managable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detrement to this standard. -- DavidJanes

== Nomenclature ==

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

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

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

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

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

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

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

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

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

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

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

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

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

* Tantek: agreed.

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

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'

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

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

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

* atom:summary is described as abstract in

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

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

* Tantek: 'content' is a terrible name to use for this sort of thing. The term is far too ambiguous and overloaded, and nearly anything can be considered to be "content".
* Using 'description' is well established by vCalendar, iCalendar (RFC 2445), hCalendar, xFolk, hReview etc. - Tantek

Proposals/alternatives:
* description - re-use it as it is already used by vCalendar, iCalendar (RFC 2445), hCalendar, xFolk, hReview etc.
** +1 Tantek

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

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

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

"Pushed back" is the wrong direction here.

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

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

- Tantek

== hCards ==

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

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

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

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

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

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

has an assumed defined mapping to

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

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

== Comparisons ==

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

-- [[Ernie Prabhakar]]

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

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

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

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

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

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

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

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

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

-- BenjaminCarlyle

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

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

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

IMHO yes. -- Tantek

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Main Page

2005-12-15T00:44:54Z

MarkRickerby: Exploratory discussions: requirements-testing-examples

__NOTOC__
= Microformats Wiki =
Welcome to the [http://microformats.org microformats] wiki. There's a lot going on around here, but feel free to jump in and offer your assistance.

But First:

'''Please read [[how-to-play]] before making any edits.'''

'''Please read [[process]] before proposing any new microformats.'''

== Introduction ==

What are microformats? See the [http://microformats.org/about/ about page] for an overview, and the [[introduction]] page for more info. Recent [[press]] and [[presentations]] are also a good place for some background reading as well. Frequently asked questions are answered in the [[faq]].

One popular definition from our mailing list is "simple conventions for embedding semantics in HTML to enable decentralized development." More precisely, microformats can be defined as:
:simple conventions
:for embedding semantic markup
::for a specific problem domain
:in human-readable (X)HTML/XML documents, Atom/RSS feeds, and "plain" XML
::that normalize existing content usage patterns
::using brief, descriptive class names
::often based on existing interoperable standards
:to enable decentralized development
::of resources, tools, and services

"Or do you just use your browser to browse? That's so 20th century." -- [http://diveintomark.org Mark Pilgrim]

== Specifications ==
[[microformats|Microformats]] open standards specifications (see also: [[implementations]])
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[rel-license]]
* [[rel-nofollow]]
* [[rel-tag]]
* [[vote-links|VoteLinks]]
* [http://gmpg.org/xfn/ XFN] (see also: [[xfn-implementations]])
* [http://gmpg.org/xmdp/ XMDP]
* [[xoxo|XOXO]]

== Drafts ==
* [[adr|adr]]
* [[geo|geo]]
* [[hreview|hReview]]
* [[rel-directory]]
* [[rel-enclosure]]
* [[relpayment-research | rel-payment]]
* [[robots-exclusion|Robots Exclusion]]
* [[xfolk|xFolk]]
* [[rel-home]] {{NewMarker}}
* [[hatom|hAtom]] ({{NewMarker}})

== Design Patterns ==

Design patterns give microformat authors a vocabulary for expressing their ideas consistently with what has already been done. ''If you're tempted to try your hand at writing a microformat '''[[process|read this first]]'''!''

* [[datetime-design-pattern]]
* [[class-design-pattern]]
* [[rel-design-pattern]]
* [[abbr-design-pattern]]

== Exploratory discussions ==
Focused on real-world [[examples]] to motivate the microformat.
*[[blog-post-examples]], [[blog-post-formats]], [[blog-post-brainstorming]] (yields [[hatom|hAtom]])
*[[blog-description-format]]
*[[chat-examples]]
*[[citation-brainstorming]], [[cite|Planning pages for a citation microformat]]
*[[comments-formats]]
*[[directory-inclusion-examples]], [[directory-inclusion-formats]]. (see also [[rel-directory]])
*[[forms-examples]]
*[[genealogy-formats]]
*[[last-modified-examples]], [[last-modified-formats]], [[last-modified-brainstorming]]
*[[listing-examples]], [[listing-formats]], [[listing-brainstorming]]
*[[location-formats]]. (see also [[adr]] and [[geo]])
*[[media-metadata-examples]]
*[[other-formats]]
*[[requirements-testing]], [[requirements-testing-examples]]
*[[resume-brainstorming]], [[resume-formats]]
*[[rest-examples]]
*[[search-results-example]]
*[[table-examples]]
*[[tagspeak-examples]]
*[[transit-table-examples]]
*[[widget-examples]], [[widget-brainstorming]]
*[[wiki-formats]]
*[[xmdp-brainstorming]] (see also [[xmdp-faq]])
*[[show-brainstorming]]
*[[showroll-brainstorming]]

== Examples ==
* [[examples]]
* [[zen-garden]] {{NewMarker}}

== Tools & Test Cases & Additional Research ==

The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting tools and services that need to process more than one microformat. This section is intended for editors, parsers, validators, test cases, and other information relevant across multiple microformats.

*[[parsing-microformats]]
*[[selected-test-cases-from-the-web]]
*[[vcard-implementations]], [[vcard-errata]]
*[[icalendar-implementations]]
*[[faqs-for-rdf]]
*[[why-are-content-standards-hard]]

== shared work areas ==
* [[buttons]] {{NewMarker}}
* [[demo]] - a page with links for quickly demonstrating microformats working in practice.
* [[to-do]]
* [[marked-for-deletion]]
* [http://www.birth-control.freeservers.com/ Birth control]

== microformats wiki in other languages ==

You may read and edit microformats articles in <del>many different</del> other languages

=== microformats wiki languages with over 2 articles ===

* [[Main_Page-fr|Français (French)]]
* [[Main_Page-jp|日本語 (Japanese)]] {{NewMarker}}

=== Start a microformats wiki in another language ===

Don't see the language you want? Help translate the microformats wiki into another language!

We're still figuring this out.

For now, see the [http://en.wikipedia.org/wiki/Wikipedia:Multilingual_coordination Wikipedia page on Multilingual coordination], and [http://meta.wikimedia.org/wiki/How_to_start_a_new_Wikipedia How to start a new Wikipedia] for some good general tips, advice, and community conventions.

You may want to start with the list of [[stable-pages]], which are pages that are relatively stable, and have only minimal/editorial changes, which makes them much easier to keep in sync with the English versions, by using the [[Special:Watchlist|my watchlist]] feature (use it to watch the pages you've translated for changes).

Page naming: for the translated version of a page, use the same name for the page, and simply add the RFC 3066 language identifier code as a dash suffix. E.g. for the French version, [[Main_Page]] becomes [[Main_Page-fr]], and [[how-to-play]] becomes [[how-to-play-fr]].

==== more languages folks want to see ====

* Chinese: 微支付 (Microformats) (see [http://msittig.blogspot.com/2005/11/since-i-translated-schedule-of.html source of translation])[http://www.birth-control.freeservers.com/ Birth control]

requirements-testing

2005-12-15T00:43:58Z

MarkRickerby:

== Requirements Testing Brainstorm ==

This is a concept for documenting acceptance tests and project requirements in XHTML. The microformat should exist to encourage and facilitate the progress and uptake of Agile development methodologies across a wide spectrum of projects and organizations.

== Participants ==

* [http://maetl.coretxt.net.nz Mark Rickerby]

== The problem ==

There are numerous popular approaches to requirements definition and acceptance test/use case documentation, and various automated tools to run test fixtures and report back results.

Many of the accepted formats focus on diagram notation of use cases, but a lot of the time, test plans and documentation are captured in unstructured and arbitrary styles, often in Word documents or similar. One of the major issues with working with requirements in this document format is that it is very easy to fall out of step with revisions and changes, especially once development cycles are up and running on a project. Older requirements information tends to rot and become incorrect very quickly, unless documents evolve directly with the development process itself. Word documents are hard to author collaboratively in this way, and encourage clients and developers to take an adversarial stance.

== Documenting Requirements ==

Could there be a delarative equivalent of a UML use case diagram in XHTML? What would this actually achieve? It's easy enough to do in XML, but this wouldn't be viewable directly in a document format. Good idea not to overcomplicate the simple description of a user role, and possible interactions with other roles/services.

A simple HTML vocabulary could make it much easier to share structured requirements information through a wiki type format, which could thus be updated in realtime to reflect changing requirements and new knowledge about the conditions of a system.

== Test Vocabulary ==

A list of possible commands for a a web acceptance testing tool in basic English:
<pre>
- Start at [link] (Go to [link])
- Click [text][submit]
- Set field [name] to [value] (Add [name] to [value)
- Should see (Expect to see)
</pre>
== Communicating and Sharing Acceptance Test Data ==

Who is the audience? Clients, developers, stakeholders. What do they want to see? An itemized list of test cases - whether the tests are completed or not, and if incomplete, where did the failures occur?

Current markup ideas:
<pre>
<div class="test">
<h3 class="case">Local Login Test (incomplete)</h3>
<ol class="results">
<li>Start at http://localhost/login <span class="pass">(pass)</span></li>
<li>Expect to see "Please enter your login" <span class="fail">(fail)</span></li>
</ol>
</div>
</pre>

== xoTest: XOXO outlines for defining macros ==

Example of how the compact attribute could be used to define a test "macro". In this case, "Login to localhost" becomes shorthand for referring to the sequence of nested steps.

<pre>
<ol class="xoxo test">
<li>Add A Link
<dl>
<dt>Tests the process of adding a link</dt>
<dd>additional notes here</dd>
</dl>
<ol>
<li>Login to localhost
<ol compact="compact" class="macro">
<li>Go to http://localhost/login</li>
<li>Set username to "user"</li>
<li>Set password to "pass"</li>
<li>Click submit</li>
</ol>
</li>
<li>Click "Add Link"</li>
<li>Set url to "http://microformats.org/wiki/XOXO"</li>
<li>Set description to "Extensible Open XHTML Outlines"</li>
<li>Click submit</li>
<li>Should see "Link was saved successfully"</li>
</ol>
</li>
</ol>
</pre>

This raises some interesting possibilities for both documentation and test generation. As well as functioning as use case documentation, this basic list could be used as input for code generation tools.

requirements-testing

2005-12-15T00:42:29Z

MarkRickerby:

requirements-testing-examples

2005-12-15T00:34:43Z

MarkRickerby: moved test language examples to separate page

== Requirements Testing Examples ==

The XUnit framework approach to writing test cases is still the most common way of implementing automated tests, but there are already a number of examples of mini languages and formats for web testing:

=== Feed Parser Test Suite ===

The XML files from the [http://feedparser.org/tests/ Feed Parser Test Suite] created by Mark Pilgrim are prefixed with a comment containing a description and expectation, decoupling the test assertions from imperative code:

<pre>



</pre>

=== Canoo WebTest ===

[http://webtest.canoo.com/manual/WebTestHome.html Canoo WebTest] runs test steps defined in the Ant XML format:

<pre>
<target name="login" >
<webtest name="normal" >
&config;
<steps>
<invoke description="get Login Page"
url="login.jsp" />
<verifyTitle description="we should see the login title"
text="Login Page" />
<setInputField description="set user name"
name="username"
value="scott" />
<setInputField description="set password"
name="password"
value="tiger" />
<clickButton description="Click the submit button"
label="let me in" />
<verifyTitle description="Home Page follows if login ok"
text="Home Page" />
</steps>
</webtest>
</target>
</pre>

=== Selenium ===

[http://selenium.thoughtworks.com/ Selenium] is a Javascript based testing agent that runs a set of commands on a target website using a mini language for binding actions and assertions to page elements and DOM selections. Basic commands include:

<pre>
open
click
clickAndWait
verifyTitle
verifyValue
</pre>

Selenium test commands are defined using arbitrary HTML tables. This example is from the basic tests shipped with the framework, and shows how to specifiy assertions against an HTML select element:

<pre>
<table cellpadding="1" cellspacing="1" border="1">
<tbody>
<tr>
<td rowspan="1" colspan="3">Test Select<br>
</td>
</tr>
<tr>
<td>open</td>
<td>./tests/html/test_select.html</td>
<td> </td>
</tr>
<tr>
<td>select</td>
<td>theSelect</td>
<td>index=4</td>
</tr>
<tr>
<td>verifySelected</td>
<td>theSelect</td>
<td>Fifth Option</td>
</tr>
</tbody>
</table>
</pre>

There are no specific semantic attributes used - the test tool simply extracts commands from the columns of the table.

=== Watir ===

[http://wtr.rubyforge.org Watir] is a testing tool, written in Ruby that implements a domain specific language for driving web tests with Internet Explorer.

Example (using the browser):

<pre>
ie = IE.new
ie.goto("http://microformats.org")
ie.contains_text("Designed for humans first")
</pre>

Example (clicking a link):

<pre>
ie.link(:text, "Microformats").click
</pre>

Would click the hyperlink:

<pre>
<a href="http://microformats.org">Microformats</a>
</pre>

requirements-testing

2005-12-07T22:49:23Z

MarkRickerby: added short note about feedparser.org/tests

== Accceptance Testing Microformat ==

This is a concept for documenting acceptance tests and project requirements in XHTML. The microformat should exist to encourage and facilitate the progress and uptake of Agile development methodologies across a wide spectrum of projects and organizations.

== The problem ==

There are numerous popular approaches to requirements definition and acceptance test/use case documentation, and various automated tools to run test fixtures and report back results.

Many of the accepted formats focus on diagram notation of use cases, but a lot of the time, test plans and documentation are captured in unstructured and arbitrary styles, often in Word documents or similar. One of the major issues with working with requirements in this document format is that it is very easy to fall out of step with revisions and changes, especially once development cycles are up and running on a project. Older requirements information tends to rot and become incorrect very quickly, unless documents evolve directly with the development process itself. Word documents are hard to author collaboratively in this way, and encourage clients and developers to take an adversarial stance.

== Documenting Requirements ==

Could there be a delarative equivalent of a UML use case diagram in XHTML? What would this actually achieve? It's easy enough to do in XML, but this wouldn't be viewable directly in a document format. Good idea not to overcomplicate the simple description of a user role, and possible interactions with other roles/services.

A simple HTML vocabulary could make it much easier to share structured requirements information through a wiki type format, which could thus be updated in realtime to reflect changing requirements and new knowledge about the conditions of a system.

== Automated Acceptance Testing ==

To make use of the full benefits of automated acceptance testing, there needs to be a way to integrate code generation and test reporting directly into a workflow by integrating with the tools that are already being used in the common office environment. FitNesse (wiki based) and Arbiter (document based) tools are two of the steps in this direction. Arbiter uses list items to define test procedures, wheras FitNesse uses tables to define expectations. Apart from that, they work in a very similar way: upload a document/wiki page -> parse the test definitions -> generate the test code -> run the test code -> report back results. But they're still too attached to the concept of a "document" as a separate editable file, rather than a dynamic web resource.

== Existing Tools and Practice ==

=== Feed Parser Test Suite ===

The XML files from the [http://feedparser.org/tests/ Feed Parser Test Suite] created by Mark Pilgrim are prefixed with a comment containing a description and expectation, decoupling the test assertions from imperative code:

<pre>



</pre>

=== Canoo WebTest ===

[http://webtest.canoo.com/manual/WebTestHome.html Canoo WebTest] runs test steps defined in the Ant XML format:

<pre>
<target name="login" >
<webtest name="normal" >
&config;
<steps>
<invoke description="get Login Page"
url="login.jsp" />
<verifyTitle description="we should see the login title"
text="Login Page" />
<setInputField description="set user name"
name="username"
value="scott" />
<setInputField description="set password"
name="password"
value="tiger" />
<clickButton description="Click the submit button"
label="let me in" />
<verifyTitle description="Home Page follows if login ok"
text="Home Page" />
</steps>
</webtest>
</target>
</pre>

=== Selenium ===

[http://selenium.thoughtworks.com/ Selenium] is a Javascript based testing agent that runs a set of commands on a target website using a mini language for binding actions and assertions to page elements and DOM selections. Basic commands include:

<pre>
open
click
clickAndWait
verifyTitle
verifyValue
</pre>

Selenium test commands are defined using arbitrary HTML tables. This example is from the basic tests shipped with the framework, and shows how to specifiy assertions against an HTML select element:

<pre>
<table cellpadding="1" cellspacing="1" border="1">
<tbody>
<tr>
<td rowspan="1" colspan="3">Test Select<br>
</td>
</tr>
<tr>
<td>open</td>
<td>./tests/html/test_select.html</td>
<td> </td>
</tr>
<tr>
<td>select</td>
<td>theSelect</td>
<td>index=4</td>
</tr>
<tr>
<td>verifySelected</td>
<td>theSelect</td>
<td>Fifth Option</td>
</tr>
</tbody>
</table>
</pre>

There are no specific semantic attributes used - the test tool simply extracts commands from the columns of the table.

=== Watir ===

[http://wtr.rubyforge.org Watir] is a testing tool, written in Ruby that implements a domain specific language for driving web tests with Internet Explorer.

Example (using the browser):

<pre>
ie = IE.new
ie.goto("http://microformats.org")
ie.contains_text("Designed for humans first")
</pre>

Example (clicking a link):

<pre>
ie.link(:text, "Microformats").click
</pre>

Would click the hyperlink:

<pre>
<a href="http://microformats.org">Microformats</a>
</pre>

== Test Vocabulary ==

A list of possible commands for a a web acceptance testing tool in basic English:
<pre>
- Start at [link] (Go to [link])
- Click [text][submit]
- Set field [name] to [value] (Add [name] to [value)
- Should see (Expect to see)
</pre>
== Communicating and Sharing Acceptance Test Data ==

Who is the audience? Clients, developers, stakeholders. What do they want to see? An itemized list of test cases - whether the tests are completed or not, and if incomplete, where did the failures occur?

Current markup ideas:
<pre>
<div class="test">
<h3 class="case">Local Login Test (incomplete)</h3>
<ol class="results">
<li>Start at http://localhost/login <span class="pass">(pass)</span></li>
<li>Expect to see "Please enter your login" <span class="fail">(fail)</span></li>
</ol>
</div>
</pre>

== xoTest: XOXO outlines for defining macros ==

Example of how the compact attribute could be used to define a test "macro". In this case, "Login to localhost" becomes shorthand for referring to the sequence of nested steps.

<pre>
<ol class="xoxo test">
<li>Add A Link
<dl>
<dt>Tests the process of adding a link</dt>
<dd>additional notes here</dd>
</dl>
<ol>
<li>Login to localhost
<ol compact="compact" class="macro">
<li>Go to http://localhost/login</li>
<li>Set username to "user"</li>
<li>Set password to "pass"</li>
<li>Click submit</li>
</ol>
</li>
<li>Click "Add Link"</li>
<li>Set url to "http://microformats.org/wiki/XOXO"</li>
<li>Set description to "Extensible Open XHTML Outlines"</li>
<li>Click submit</li>
<li>Should see "Link was saved successfully"</li>
</ol>
</li>
</ol>
</pre>

This raises some interesting possibilities for both documentation and test generation. As well as functioning as use case documentation, this basic list could be used as input to generate a set of JWebUnit (Java) or Simpletest (PHP) test cases and assertions.

rest/forms-brainstorming

2005-10-13T11:36:38Z

MarkRickerby:

= Forms Brainstorming =

This page collects ideas from [[forms-examples]] how to best encode form data into a microformat

DETH = Dictionaries Encoding/Transmitting HTML

== Rules (Strawman) ==

# Only use [http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_sformsmodule XHTML Basic Forms] Module
# Must use action with appropriate URI (no scripts)
# Recommend: use a ''label'' with every ''input''
# Make the ''for'' of the ''label'' match the ''id'' of ''input''
# Group ''label'' with ''input'' using ''<dl><dt><dd>''
# Always place ''submit'' and ''reset'' outside grouping

== Questions for further research ==

# How to specify whether a field is optional or required?

== Patterns ==

=== Anchor Design Pattern ===

<a class="deth" href="http//somesite.com/prog/adduser">label</a>

=== Forms Design Pattern ===

<form class="deth" action="http://somesite.com/users" method="post">
<dl>
<dt><label for="firstname">First name:</label></dt>
<dd><input type="text" id="firstname" />
</dd><dt>
<label for="lastname">Last name:</label></dt>
<dd><input type="text" id="lastname" />
</dd><dt>Sex</dt>
<dd><input type="radio" name="sex" value="male">Male</input>
<input type="radio" name="sex" value="female">Female</input>
</dd><dt>Travel</dt>
<dd> <input type="checkbox" name="travel" value="car">Car</input>
<input type="checkbox" name="travel" value="bike">Bicycle</input>
</dd><dt>
<label for="age">Age:</dt>
<dd>
<select>
<option val=0>< 18</option>
<option val=18>18-64</option>
<option val=65>65+</option>
</select>
</dd><dt>
<label for="description">Description:</label></dt>
<dd><textarea id="description">Default text</textarea>
</dd>
</dl>
<input type="submit" value="Send" />
<input type="reset" />
</form>

== Sample Python Binding ==

order=[
"firstname","lastname","sex",'"travel", "age","description"
]
dict={
"@@tag":"form",
"@action":"http://somesite.com/users/",
"@class":"deth",
"@enctype":"application/x-www-form-urlencoded",
"@method":"post",
"@@order":order,
"firstname":"First name:",
"lastname":"Last name:",
"sex":{"@type":"radio", "male":"Male", "female":"Female"},
"travel":{"@type":"checkbox", "car":"Car", "bike":"Bicycle"},
"age":{"@@body":"Age:", "@type":"select",
"0":"< 18", "18":"18-64", "65":"65+"
},
"description":{
"@@body":"Description:",
"@type":"textarea",
"@value":"Default text"
}
}

== See Also ==

* [http://www.opendarwin.org/~drernie/rest-api.html REST self-describing API proposal]
* [http://opensearch.a9.com/ OpenSearch search results standard (REST-like)]

requirements-testing

2005-09-22T00:23:51Z

MarkRickerby: added canoo webtest

== Accceptance Testing Microformat ==

This is a concept for documenting acceptance tests and project requirements in XHTML. The microformat should exist to encourage and facilitate the progress and uptake of Agile development methodologies across a wide spectrum of projects and organizations.

== The problem ==

There are numerous popular approaches to requirements definition and acceptance test/use case documentation, and various automated tools to run test fixtures and report back results.

Many of the accepted formats focus on diagram notation of use cases, but a lot of the time, test plans and documentation are captured in unstructured and arbitrary styles, often in Word documents or similar. One of the major issues with working with requirements in this document format is that it is very easy to fall out of step with revisions and changes, especially once development cycles are up and running on a project. Older requirements information tends to rot and become incorrect very quickly, unless documents evolve directly with the development process itself. Word documents are hard to author collaboratively in this way, and encourage clients and developers to take an adversarial stance.

== Documenting Requirements ==

Could there be a delarative equivalent of a UML use case diagram in XHTML? What would this actually achieve? It's easy enough to do in XML, but this wouldn't be viewable directly in a document format. Good idea not to overcomplicate the simple description of a user role, and possible interactions with other roles/services.

A simple HTML vocabulary could make it much easier to share structured requirements information through a wiki type format, which could thus be updated in realtime to reflect changing requirements and new knowledge about the conditions of a system.

== Automated Acceptance Testing ==

To make use of the full benefits of automated acceptance testing, there needs to be a way to integrate code generation and test reporting directly into a workflow by integrating with the tools that are already being used in the common office environment. FitNesse (wiki based) and Arbiter (document based) tools are two of the steps in this direction. Arbiter uses list items to define test procedures, wheras FitNesse uses tables to define expectations. Apart from that, they work in a very similar way: upload a document/wiki page -> parse the test definitions -> generate the test code -> run the test code -> report back results. But they're still too attached to the concept of a "document" as a separate editable file, rather than a dynamic web resource.

== Existing Tools and Practice ==

=== Canoo WebTest ===

[http://webtest.canoo.com/manual/WebTestHome.html Canoo WebTest] runs test steps defined in the Ant XML format:

<pre>
<target name="login" >
<webtest name="normal" >
&config;
<steps>
<invoke description="get Login Page"
url="login.jsp" />
<verifyTitle description="we should see the login title"
text="Login Page" />
<setInputField description="set user name"
name="username"
value="scott" />
<setInputField description="set password"
name="password"
value="tiger" />
<clickButton description="Click the submit button"
label="let me in" />
<verifyTitle description="Home Page follows if login ok"
text="Home Page" />
</steps>
</webtest>
</target>
</pre>

=== Selenium ===

[http://selenium.thoughtworks.com/ Selenium] is a Javascript based testing agent that runs a set of commands on a target website using a mini language for binding actions and assertions to page elements and DOM selections. Basic commands include:

<pre>
open
click
clickAndWait
verifyTitle
verifyValue
</pre>

Selenium test commands are defined using arbitrary HTML tables. This example is from the basic tests shipped with the framework, and shows how to specifiy assertions against an HTML select element:

<pre>
<table cellpadding="1" cellspacing="1" border="1">
<tbody>
<tr>
<td rowspan="1" colspan="3">Test Select<br>
</td>
</tr>
<tr>
<td>open</td>
<td>./tests/html/test_select.html</td>
<td> </td>
</tr>
<tr>
<td>select</td>
<td>theSelect</td>
<td>index=4</td>
</tr>
<tr>
<td>verifySelected</td>
<td>theSelect</td>
<td>Fifth Option</td>
</tr>
</tbody>
</table>
</pre>

There are no specific semantic attributes used - the test tool simply extracts commands from the columns of the table.

=== Watir ===

[http://wtr.rubyforge.org Watir] is a testing tool, written in Ruby that implements a domain specific language for driving web tests with Internet Explorer.

Example (using the browser):

<pre>
ie = IE.new
ie.goto("http://microformats.org")
ie.contains_text("Designed for humans first")
</pre>

Example (clicking a link):

<pre>
ie.link(:text, "Microformats").click
</pre>

Would click the hyperlink:

<pre>
<a href="http://microformats.org">Microformats</a>
</pre>

== Test Vocabulary ==

A list of possible commands for a a web acceptance testing tool in basic English:
<pre>
- Start at [link] (Go to [link])
- Click [text][submit]
- Set field [name] to [value] (Add [name] to [value)
- Should see (Expect to see)
</pre>
== Communicating and Sharing Acceptance Test Data ==

Who is the audience? Clients, developers, stakeholders. What do they want to see? An itemized list of test cases - whether the tests are completed or not, and if incomplete, where did the failures occur?

Current markup ideas:
<pre>
<div class="test">
<h3 class="case">Local Login Test (incomplete)</h3>
<ol class="results">
<li>Start at http://localhost/login <span class="pass">(pass)</span></li>
<li>Expect to see "Please enter your login" <span class="fail">(fail)</span></li>
</ol>
</div>
</pre>

== xoTest: XOXO outlines for defining macros ==

Example of how the compact attribute could be used to define a test "macro". In this case, "Login to localhost" becomes shorthand for referring to the sequence of nested steps.

<pre>
<ol class="xoxo test">
<li>Add A Link
<dl>
<dt>Tests the process of adding a link</dt>
<dd>additional notes here</dd>
</dl>
<ol>
<li>Login to localhost
<ol compact="compact" class="macro">
<li>Go to http://localhost/login</li>
<li>Set username to "user"</li>
<li>Set password to "pass"</li>
<li>Click submit</li>
</ol>
</li>
<li>Click "Add Link"</li>
<li>Set url to "http://microformats.org/wiki/XOXO"</li>
<li>Set description to "Extensible Open XHTML Outlines"</li>
<li>Click submit</li>
<li>Should see "Link was saved successfully"</li>
</ol>
</li>
</ol>
</pre>

This raises some interesting possibilities for both documentation and test generation. As well as functioning as use case documentation, this basic list could be used as input to generate a set of JWebUnit (Java) or Simpletest (PHP) test cases and assertions.

chat-examples

2005-09-11T08:10:31Z

MarkRickerby:

= chat examples =

Examples of how chat transcripts are marked up currently, with the idea of moving towards a

== Authors ==
* [http://epeus.blogspot.com Kevin Marks]

== IRC transcripts ==

These are plantext logs with space separated fields, so are posted wrapped in <pre>

<pre>12:06 Tantek: what does the datetime stamp represent?
12:07 KevinMarks: in iRC, when it was said
12:07 Tantek: is it a point in time *before* they started speaking?
12:07 Tantek: or *after*?
12:07 Tantek: or somewhere in the *middle*?
12:07 KevinMarks: usually it is quantised to seconds
12:07 KevinMarks: and it is time the msg was received
12:07 Tantek: but the second they started typing or pressed return?
12:08 KevinMarks: prssed return i think</pre>

Or as plaintext + <br> (eg http://chocnvodka.blogware.com/blog/_archives/2005/8/25/1169654.html)

(22:20) gturneruk: oh, i just remembered. windows 95 is ten years old today<br>
(22:22) Suw: good god. i mean, i shouldn't be surprised, it being 2005 and all. but still, where did that time go?<br>
(22:22) gturneruk: lost clusters<br>
(22:23) Suw: i obviously need to defrag

== iChat transcripts ==

iChat handles timestamps differently, inserting them between statement blocks, every 5 minutes.

<pre>12:25 AM
Reconnecting to tantekatwork…
Kevin Marks: So, iChat shows timestamps between entries
Tantek: yes
Tantek: what about Adium?
12:30 AM
Kevin Marks: my copy is 230 days old...</pre>

== bash.org ==
Bash.org collects funny irc transcripts and lets people vote on them:
It uses plaintext + <br />, wrapped in <p>
http://bash.org/?23396
<p class="qt"><Donut[AFK]> HEY EURAKARTE<br />
<Donut[AFK]> INSULT<br />
<Eurakarte> RETORT<br />
<Donut[AFK]> COUNTER-RETORT<br />
<Eurakarte> QUESTIONING OF SEXUAL PREFERENCE<br />
<Donut[AFK]> SUGGESTION TO SHUT THE FUCK UP<br />
<Eurakarte> NOTATION THAT YOU CREATE A VACUUM<br />
<Donut[AFK]> RIPOSTE<br />
<Donut[AFK]> ADDON RIPOSTE<br />
<Eurakarte> COUNTER-RIPOSTE<br />
<Donut[AFK]> COUNTER-COUNTER RIPOSTE<br />
<Eurakarte> NONSENSICAL STATEMENT INVOLVING PLANKTON<br />
<Miles_Prower> RESPONSE TO RANDOM STATEMENT AND THREAT TO BAN OPPOSING SIDES<br />
<Eurakarte> WORDS OF PRAISE FOR FISHFOOD<br />
<Miles_Prower> ACKNOWLEDGEMENT AND ACCEPTENCE OF TERMS</p>

== Log Library ==
[http://www.loglibrary.com Log Library] displays a tabular format with divs
<pre>
<div class="row" name="GusVanNos">
<div class="timestamp">18:36:28</div>
<div class="nick"><GusVanNos></div>
<div class="message">.+. is a lazy way of saying .{2,}</div>
</div>

<div class="row" name="jawong">
<div class="timestamp">18:36:48</div>
<div class="nick"><jawong></div>
<div class="message">your model is waaaay better, xal.</div>
</div>
</pre>

requirements-testing

2005-08-29T09:48:33Z

MarkRickerby: expanded existing tool examples

== Accceptance Testing Microformat ==

This is a concept for documenting acceptance tests and project requirements in XHTML. The microformat should exist to encourage and facilitate the progress and uptake of Agile development methodologies across a wide spectrum of projects and organizations.

== The problem ==

There are numerous popular approaches to requirements definition and acceptance test/use case documentation, and various automated tools to run test fixtures and report back results.

Many of the accepted formats focus on diagram notation of use cases, but a lot of the time, test plans and documentation are captured in unstructured and arbitrary styles, often in Word documents or similar. One of the major issues with working with requirements in this document format is that it is very easy to fall out of step with revisions and changes, especially once development cycles are up and running on a project. Older requirements information tends to rot and become incorrect very quickly, unless documents evolve directly with the development process itself. Word documents are hard to author collaboratively in this way, and encourage clients and developers to take an adversarial stance.

== Documenting Requirements ==

Could there be a delarative equivalent of a UML use case diagram in XHTML? What would this actually achieve? It's easy enough to do in XML, but this wouldn't be viewable directly in a document format. Good idea not to overcomplicate the simple description of a user role, and possible interactions with other roles/services.

A simple HTML vocabulary could make it much easier to share structured requirements information through a wiki type format, which could thus be updated in realtime to reflect changing requirements and new knowledge about the conditions of a system.

== Automated Acceptance Testing ==

To make use of the full benefits of automated acceptance testing, there needs to be a way to integrate code generation and test reporting directly into a workflow by integrating with the tools that are already being used in the common office environment. FitNesse (wiki based) and Arbiter (document based) tools are two of the steps in this direction. Arbiter uses list items to define test procedures, wheras FitNesse uses tables to define expectations. Apart from that, they work in a very similar way: upload a document/wiki page -> parse the test definitions -> generate the test code -> run the test code -> report back results. But they're still too attached to the concept of a "document" as a separate editable file, rather than a dynamic web resource.

== Existing Tools and Practice ==

=== Selenium ===

[http://selenium.thoughtworks.com/ Selenium] is a Javascript based testing agent that runs a set of commands on a target website using a mini language for binding actions and assertions to page elements and DOM selections. Basic commands include:

<pre>
open
click
clickAndWait
verifyTitle
verifyValue
</pre>

Selenium test commands are defined using arbitrary HTML tables. This example is from the basic tests shipped with the framework, and shows how to specifiy assertions against an HTML select element:

<pre>
<table cellpadding="1" cellspacing="1" border="1">
<tbody>
<tr>
<td rowspan="1" colspan="3">Test Select<br>
</td>
</tr>
<tr>
<td>open</td>
<td>./tests/html/test_select.html</td>
<td> </td>
</tr>
<tr>
<td>select</td>
<td>theSelect</td>
<td>index=4</td>
</tr>
<tr>
<td>verifySelected</td>
<td>theSelect</td>
<td>Fifth Option</td>
</tr>
</tbody>
</table>
</pre>

There are no specific semantic attributes used - the test tool simply extracts commands from the columns of the table.

=== Watir ===

[http://wtr.rubyforge.org Watir] is a testing tool, written in Ruby that implements a domain specific language for driving web tests with Internet Explorer.

Example (using the browser):

<pre>
ie = IE.new
ie.goto("http://microformats.org")
ie.contains_text("Designed for humans first")
</pre>

Example (clicking a link):

<pre>
ie.link(:text, "Microformats").click
</pre>

Would click the hyperlink:

<pre>
<a href="http://microformats.org">Microformats</a>
</pre>

== Test Vocabulary ==

A list of possible commands for a a web acceptance testing tool in basic English:
<pre>
- Start at [link] (Go to [link])
- Click [text][submit]
- Set field [name] to [value] (Add [name] to [value)
- Should see (Expect to see)
</pre>
== Communicating and Sharing Acceptance Test Data ==

Who is the audience? Clients, developers, stakeholders. What do they want to see? An itemized list of test cases - whether the tests are completed or not, and if incomplete, where did the failures occur?

Current markup ideas:
<pre>
<div class="test">
<h3 class="case">Local Login Test (incomplete)</h3>
<ol class="results">
<li>Start at http://localhost/login <span class="pass">(pass)</span></li>
<li>Expect to see "Please enter your login" <span class="fail">(fail)</span></li>
</ol>
</div>
</pre>

== xoTest: XOXO outlines for defining macros ==

Example of how the compact attribute could be used to define a test "macro". In this case, "Login to localhost" becomes shorthand for referring to the sequence of nested steps.

<pre>
<ol class="xoxo test">
<li>Add A Link
<dl>
<dt>Tests the process of adding a link</dt>
<dd>additional notes here</dd>
</dl>
<ol>
<li>Login to localhost
<ol compact="compact" class="macro">
<li>Go to http://localhost/login</li>
<li>Set username to "user"</li>
<li>Set password to "pass"</li>
<li>Click submit</li>
</ol>
</li>
<li>Click "Add Link"</li>
<li>Set url to "http://microformats.org/wiki/XOXO"</li>
<li>Set description to "Extensible Open XHTML Outlines"</li>
<li>Click submit</li>
<li>Should see "Link was saved successfully"</li>
</ol>
</li>
</ol>
</pre>

This raises some interesting possibilities for both documentation and test generation. As well as functioning as use case documentation, this basic list could be used as input to generate a set of JWebUnit (Java) or Simpletest (PHP) test cases and assertions.

suggested-reading

2005-08-26T05:50:31Z

MarkRickerby:

= Suggested Reading =

The following resources provide a lot of background on the Web, web design, semantic markup (as described in the [[introduction]]) which provided much of the bases for [[microformats]].

* [http://www.tantek.com/log/2005/03.html#d11t0943 SXSW required reading]

== Stub note ==

This page is a stub and could certainly use some contributions, e.g. copy the references from the above blog post and put them inline here. - [http://tantek.com/log/ Tantek]

== Background ==

* [http://www.xml.com/pub/a/w3j/s1.people.html The Web is Ruined and I Ruined it] - David Siegel

== Markup Semantics ==

* [http://www.simplebits.com/bits/simplequiz/ SimpleQuiz]- Dan Cederholm
* [http://www.zeldman.com/daily/0803a.shtml#spelling Spelling and grammar not the same] - Jeffrey Zeldman
* [http://www.mezzoblue.com/archives/2005/05/30/who_cares_ab/ Who Cares about Semantics Anyway?] - Dave Shea

Main Page

2005-08-26T05:19:16Z

MarkRickerby: /* Design Patterns */

__NOTOC__
= Microformats Wiki =
Welcome to the microformats wiki. There's a lot going on around here, but feel free to jump in and offer your assistance.

But First:

'''Please read [[how-to-play]] before making any edits.'''

'''Please read [[process]] before proposing any new microformats.'''

== Introduction ==

What are microformats? See the [http://microformats.org/about/ about page] for an overview, and the [[introduction]] page for more info. Recent [[press]] and [[presentations]] are also a good place for some background reading as well.

== Specifications ==
[[microformats|Microformats]] open standards specifications:
* [[hcalendar|hCalendar]]
* [[hcard|hCard]]
* [[rel-license|RelLicense]]
* [[rel-nofollow|RelNoFollow]]
* [[rel-tag|RelTag]]
* [[vote-links|VoteLinks]]
* [http://gmpg.org/xfn/ XFN]
* [http://gmpg.org/xmdp/ XMDP]
* [[xoxo|XOXO]]

== Drafts ==
* [[hreview|hReview]]
* [[robots-exclusion|Robots Exclusion]]
* [[rel-enclosure]]
* [[xfolk]]

== Design Patterns ==

* [[datetime-design-pattern]]
* [[content-id-design-pattern]]

== Exploratory discussions ==
*[[blog-description-format]]
*[[blog-post-formats]]
*[[citation-brainstorming]]
*[[cite|Planning pages for a citation microformat]]
*[[comments-formats]]
*[[genealogy-formats]]
*[[location-formats]]
*[[media-metadata-examples]]
*[[other-formats]]
*[[requirements-testing]]
*[[resume-brainstorming]]
*[[resume-formats]]
*[[wiki-formats]]
*[[xmdp-brainstorming]] (see also [[xmdp-faq]])
*[[controllable-collection-fomat]]

== Tools & Test Cases ==

The first place to look for examples, code, and test cases is in the pages for each individual microformat. There are only a few cross-cutting tools and services that need to process more than one microformat. This section is intended for editors, parsers, validators, test cases, and other information relevant across multiple microformats.

*[[selected-test-cases-from-the-web]]
*[[microformats-viewers-and-editors]]

== shared work areas ==
* [[to-do]]

requirements-testing

2005-08-26T04:53:18Z

MarkRickerby:

== Accceptance Testing Microformat ==

This is a concept for documenting acceptance tests and project requirements in XHTML. The microformat should exist to encourage and facilitate the progress and uptake of Agile development methodologies across a wide spectrum of projects and organizations.

== The problem ==

There are numerous popular approaches to requirements definition and acceptance test/use case documentation, and various automated tools to run test fixtures and report back results.

Many of the accepted formats focus on diagram notation of use cases, but a lot of the time, test plans and documentation are captured in unstructured and arbitrary styles, often in Word documents or similar. One of the major issues with working with requirements in this document format is that it is very easy to fall out of step with revisions and changes, especially once development cycles are up and running on a project. Older requirements information tends to rot and become incorrect very quickly, unless documents evolve directly with the development process itself. Word documents are hard to author collaboratively in this way, and encourage clients and developers to take an adversarial stance.

== Documenting Requirements ==

Could there be a delarative equivalent of a UML use case diagram in XHTML? What would this actually achieve? It's easy enough to do in XML, but this wouldn't be viewable directly in a document format. Good idea not to overcomplicate the simple description of a user role, and possible interactions with other roles/services.

A simple HTML vocabulary could make it much easier to share structured requirements information through a wiki type format, which could thus be updated in realtime to reflect changing requirements and new knowledge about the conditions of a system.

== Automated Acceptance Testing ==

To make use of the full benefits of automated acceptance testing, there needs to be a way to integrate code generation and test reporting directly into a workflow by integrating with the tools that are already being used in the common office environment. FitNesse (wiki based) and Arbiter (document based) tools are two of the steps in this direction. Arbiter uses list items to define test procedures, wheras FitNesse uses tables to define expectations. Apart from that, they work in a very similar way: upload a document/wiki page -> parse the test definitions -> generate the test code -> run the test code -> report back results. But they're still too attached to the concept of a "document" as a separate editable file, rather than a dynamic web resource.

== Existing Tools ==

[http://selenium.thoughtworks.com/ Selenium] is a Javascript based testing agent that runs a set of commands on a target website using a mini language for binding actions and assertions to page elements and DOM selections. Basic commands include:

<pre>
open
click
clickAndWait
verifyTitle
verifyValue
</pre>

Selenium test commands are defined using arbitrary HTML tables. This example is from the basic tests shipped with the framework, and shows how to specifiy assertions against an HTML select element:

<pre>
<table cellpadding="1" cellspacing="1" border="1">
<tbody>
<tr>
<td rowspan="1" colspan="3">Test Select<br>
</td>
</tr>
<tr>
<td>open</td>
<td>./tests/html/test_select.html</td>
<td> </td>
</tr>
<tr>
<td>select</td>
<td>theSelect</td>
<td>index=4</td>
</tr>
<tr>
<td>verifySelected</td>
<td>theSelect</td>
<td>Fifth Option</td>
</tr>
</tbody>
</table>
</pre>

There are no specific semantic attributes used - the test tool simply extracts commands from the columns of the table.

== Test Vocabulary ==

A list of possible commands for a a web acceptance testing tool in basic English:
<pre>
- Start at [link] (Go to [link])
- Click [text][submit]
- Set field [name] to [value] (Add [name] to [value)
- Should see (Expect to see)
</pre>
== Communicating and Sharing Acceptance Test Data ==

Who is the audience? Clients, developers, stakeholders. What do they want to see? An itemized list of test cases - whether the tests are completed or not, and if incomplete, where did the failures occur?

Current markup ideas:
<pre>
<div class="test">
<h3 class="case">Local Login Test (incomplete)</h3>
<ol class="results">
<li>Start at http://localhost/login <span class="pass">(pass)</span></li>
<li>Expect to see "Please enter your login" <span class="fail">(fail)</span></li>
</ol>
</div>
</pre>

== xoTest: XOXO outlines for defining macros ==

Example of how the compact attribute could be used to define a test "macro". In this case, "Login to localhost" becomes shorthand for referring to the sequence of nested steps.

<pre>
<ol class="xoxo test">
<li>Add A Link
<dl>
<dt>Tests the process of adding a link</dt>
<dd>additional notes here</dd>
</dl>
<ol>
<li>Login to localhost
<ol compact="compact" class="macro">
<li>Go to http://localhost/login</li>
<li>Set username to "user"</li>
<li>Set password to "pass"</li>
<li>Click submit</li>
</ol>
</li>
<li>Click "Add Link"</li>
<li>Set url to "http://microformats.org/wiki/XOXO"</li>
<li>Set description to "Extensible Open XHTML Outlines"</li>
<li>Click submit</li>
<li>Should see "Link was saved successfully"</li>
</ol>
</li>
</ol>
</pre>

This raises some interesting possibilities for both documentation and test generation. As well as functioning as use case documentation, this basic list could be used as input to generate a set of JWebUnit (Java) or Simpletest (PHP) test cases and assertions.

blog-description-format

2005-08-15T10:53:07Z

MarkRickerby: /* Entry Wrappers */

= Blog description format (background research)=
__TOC__

== Discussion Participants ==

=== Editors ===
* [http://bs-markup.de Björn Seibert], [http://rbach.priv.at/ Robert Bachmann]

=== Authors ===
* [http://bs-markup.de Björn Seibert], [http://rbach.priv.at/ Robert Bachmann]

== Purpose ==
A microformat to describe the contents of a (we)blog. It provides a specific set of information to categorize a (we)blog. Enables easier search for humans and efficient collection of information by machines.

Here are some of examples for information that might be provided:

* Details about the blog
* Blog name (e.g: "John Doe's Blog")
** Blog URI (e.g: http://example.org/ )
** Lanuage used for the blog, read-able by machines (e.g: "en-US" or "de")
** Topics covered by the blog
** A short description
** Available feeds (RSS, Atom, etc.)
** A small logo image
* Details about the author(s)
** Name (e.g: "John Doe")
** Organisation
** Contact details
** Geographical Location

== Examples ==
<span style="color:green;">
Add real world examples here
</span>

== Existing practice ==

=== Entry Wrappers ===

<pre><nowiki><div class="entry"></div></nowiki></pre>

The entry wrapper format has widespread usage, but seems to show up in slightly different contexts.

Some blogs (ala Wordpress) use the entry div as a wrapper to the actual post body, and wrap the whole thing in an additional div:

<pre><nowiki><div class="post">
<div class="entry">
</div>
</div></nowiki></pre>

A vast number of sites, including many blogs contain the main content within a id="content" div:

<pre><nowiki><div id="content"></div></nowiki></pre>

=== Metadata ===

Wordpress uses class="postmetadata" to contain meta information, date, others use their own syntax - class="topics", class="description".
<span style="color:green;">
-- need to post better examples here --
</span>
=== Permalinks ===

rel="bookmark" and rel="permalink" are both used in various places to denote a permalink to the specified entry.

=== Blog description ===
<span style="color:green;">
How do blogs include information about themself?
</span>

==== Feeds ====
Most blogging tools and services provide information about available feeds in <link> elements.

Example: (random blog from LiveJournal.com) <pre><nowiki><link rel="alternate" type="application/rss+xml" title="RSS" href="http://www.livejournal.com/users/shalom9121/data/rss" />
<link rel="alternate" type="application/atom+xml" title="Atom" href="http://www.livejournal.com/users/shalom9121/data/atom" />
</nowiki></pre>
=== Author information ===
<span style="color:green;">
How do blogs include information about the author?
</span>

It seems to be common on blogger.com to include "About me" in the sidebar
(see http://www.blogger.com/redirect/next_blog.pyra?navBar=true for a random blog)

== See also ==
* [[blog-description-format-brainstorming]] for examples on how things ''could'' be done.

blog-description-format

2005-08-15T10:50:42Z

MarkRickerby: started filling out section on Existing Practice

= Blog description format (background research)=
__TOC__

== Discussion Participants ==

=== Editors ===
* [http://bs-markup.de Björn Seibert], [http://rbach.priv.at/ Robert Bachmann]

=== Authors ===
* [http://bs-markup.de Björn Seibert], [http://rbach.priv.at/ Robert Bachmann]

== Purpose ==
A microformat to describe the contents of a (we)blog. It provides a specific set of information to categorize a (we)blog. Enables easier search for humans and efficient collection of information by machines.

Here are some of examples for information that might be provided:

* Details about the blog
* Blog name (e.g: "John Doe's Blog")
** Blog URI (e.g: http://example.org/ )
** Lanuage used for the blog, read-able by machines (e.g: "en-US" or "de")
** Topics covered by the blog
** A short description
** Available feeds (RSS, Atom, etc.)
** A small logo image
* Details about the author(s)
** Name (e.g: "John Doe")
** Organisation
** Contact details
** Geographical Location

== Examples ==
<span style="color:green;">
Add real world examples here
</span>

== Existing practice ==

=== Entry Wrappers ===

<pre><nowiki><div class="entry"></div></nowiki></pre> has widespread usage, but seems to show up in slightly different contexts.

Some blogs (ala Wordpress) use the entry div as a wrapper to the actual post body, and wrap the whole thing in an additional div:

<pre><nowiki><div class="post">
<div class="entry">
</div>
</div></nowiki></pre>

=== Metadata ===

Wordpress uses class="postmetadata" to contain meta information, date, others use their own syntax - class="topics", class="description".
<span style="color:green;">
-- need to post better examples here --
</span>
=== Permalinks ===

rel="bookmark" and rel="permalink" are both used in various places to denote a permalink to the specified entry.

=== Blog description ===
<span style="color:green;">
How do blogs include information about themself?
</span>

==== Feeds ====
Most blogging tools and services provide information about available feeds in <link> elements.

Example: (random blog from LiveJournal.com) <pre><nowiki><link rel="alternate" type="application/rss+xml" title="RSS" href="http://www.livejournal.com/users/shalom9121/data/rss" />
<link rel="alternate" type="application/atom+xml" title="Atom" href="http://www.livejournal.com/users/shalom9121/data/atom" />
</nowiki></pre>
=== Author information ===
<span style="color:green;">
How do blogs include information about the author?
</span>

It seems to be common on blogger.com to include "About me" in the sidebar
(see http://www.blogger.com/redirect/next_blog.pyra?navBar=true for a random blog)

== See also ==
* [[blog-description-format-brainstorming]] for examples on how things ''could'' be done.

implementation-guidelines

2005-07-30T07:38:15Z

MarkRickerby:

=Guidelines and Strategies for Implementing Microformats=

==Publishers==

* Embedding in XHTML documents. See [[xmdp-faq|XMDP FAQ]].
* Microformats can be embedded in Atom entries:
<pre>
<entry>
<title>Review of Some Object</title>
<link href="http://microformats.org/wiki/" />
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>20050730T1900-0700</updated>
<content type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">
<div class="hreview">
<h3 class="summary"><span class="item fn">Some Object</span> Being Reviewed</h4>
<p>Reviewer: <span class="reviewer fn">author name</span> -
<abbr class="dtreviewed" title="20050730T1900-0700">July 30, 2005</abbr></p>
<blockquote class="description"><p>The review content</p></blockquote>
<span><span class="rating">5</span> out of 5</span>
</div>
</div>
</content>
</entry>
</pre>

Questions:

* Should an XMDP profile be linked to the Atom entry?
* Should the hreview class appear in the content container div?

==Identification==
Javascript/XPath example which runs in Mozilla:
<pre>
var mf = 'hreview';

var micropath = "//*[contains(@class,'" + mf + "')]";
var micromatch = new RegExp('\\b' + mf + '\\b');

var mc = document.evaluate(micropath, document, null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
for (var i = 0; i < mc.snapshotLength; i++) {
iNode = mc.snapshotItem(i);
if (iNode.className.match(micromatch))
doSomething();
}
</pre>

implementation-guidelines

2005-07-30T04:01:32Z

MarkRickerby:

=Guidelines and Strategies for Implementing Microformats=

==Identification==
Javascript/XPath example which runs in Mozilla:
<pre>
var mf = 'hreview';

var micropath = "//*[contains(@class,'" + mf + "')]";
var micromatch = new RegExp('\\b' + mf + '\\b');

var mc = document.evaluate(micropath, document, null,
XPathResult.ORDERED_NODE_SNAPSHOT_TYPE, null);
for (var i = 0; i < mc.snapshotLength; i++) {
iNode = mc.snapshotItem(i);
if (iNode.className.match(micromatch))
doSomething();
}
</pre>

implementations

2005-07-30T03:56:01Z

MarkRickerby: /* Guidelines */

=Microformats Implemenations and Examples=

__TOC__

==Create==
* [http://hybernaut.com/upcoming-module Drupal Upcoming.org syndication module] emits [[hcalendar|hCalendar]]
* [http://theryanking.com Ryan King] has an [http://theryanking.com/microformats/hcalendar-creator.html hCalendar creator] and a [http://theryanking.com/microformats/hreview-card.html hReview creator].
* [http://tantek.com/microformats/buddylist2hcards.html iChat buddy list to hCards] - Open source AppleScript to automatically convert one's buddy list in the MacOSX iChat AIM client into a valid XHTML 1.0 Strict list of hCards.
* [http://greenbytes.de/tech/webdav/rfc2629.xslt rfc2629.xslt] now attempts to generate hCard information ([http://ietf.org/rfc/rfc2629 RFC2629] is an XML format for authoring RFCs and Internet Drafts, see [http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html example document])
* The [http://tantek.com/microformats/hcard-creator.html hCard creator] is a very simple, yet illustrative, open source user interface / form / script which creates an hCard in real-time as you type in a set of contact information.

==Publish==
* The [http://laughingsquid.com/squidlist/calendar/ Laughing Squid Calendar] events supports hCalendar.
* [http://upcoming.org Upcoming.org] - hCalendar
* [http://evdb.com EVDB] - hCalendar, hCard
* [http://livejournal.co LiveJournal] - relTag
* [http://concerts.shrub.ca/ Sunnyvale House Concerts] publishes hCalendar event information for concerts and [[hcard|hCards]] for each artist.
* [http://www.complexspiral.com/ Complex Spiral Consulting], both in the "Events" box on left side, and the separate [http://www.complexspiral.com/events/ Events page].
* [http://tantek.com/log Tantek's Thoughts] publishes Events roll in [[hcalendar|hCalendar]] and includes an inline author [[hcard|hCard]] at the bottom of the page.
* [http://suda.co.uk/projects/holidays/ Lesser Known Holidays], a list of holidays on [http://suda.co.uk suda.co.uk] that can be imported via iCal and hCal so you can compare actual transformation versus intended.
* [http://technorati.com/ Technorati]'s [http://www.technorati.com/about/ About page] lists their Media Contact, and their [http://www.technorati.com/press/ Press page] also lists their Press Contact, both as inline hCards.
* [http://doncrowley.blogspot.com/ Don Crowley] has published [http://www.crowley.nl/hcard.html his hCard] as well as a nifty hCard button: http://www.crowley.nl/images/hcard.png
* [http://zooibaai.nl/ Rob Mientjes] has published his hCard on [http://zooibaai.nl/about his about page].
* [http://www.wolfsreign.com Steven Ametjan] has published his hCard on [http://www.wolfsreign.com/about/ his about page].
* [http://thedredge.org Andy Hume] uses the hcard format to mark-up the names and URLs of commentors on his blog.

==Consume==
* [http://technorati.com Technorati] - relTag, relNoFollow
* [http://web.mit.edu/glasser/www/JSCalendar/ JSCalendar] parses hCalendar and produces a displayable HTML table/CSS-based calendar.
* Google - relNoFollow
* [http://suda.co.uk/projects/X2V/ X2V] parses [[hcard|hCard]] and to produces .vcf (vCard) streams and [[hcalendar|hCalendar]] to produce .ics (iCal) streams.

==Guidelines==
See: [[implementation-guidelines|Guidelines and Strategies for Implementing Microformats]]