https://microformats.org/wiki/api.php?action=feedcontributions&user=ScottReynen&feedformat=atomMicroformats Wiki - User contributions [en]2024-03-28T16:47:54ZUser contributionsMediaWiki 1.38.4https://microformats.org/wiki/index.php?title=User:ScottReynen&diff=35368User:ScottReynen2008-12-17T14:18:15Z<p>ScottReynen: </p>
<hr />
<div>email: scott@randomchaos.com<br />
<br />
AIM: imnotscott<br />
<br />
Phone: 303-717-1543<br />
<br />
[http://log.makedatamakesense.com/ Website]<br />
<br />
{{public-domain-release}}</div>ScottReynenhttps://microformats.org/wiki/index.php?title=hcalendar-brainstorming&diff=28476hcalendar-brainstorming2008-07-15T14:14:48Z<p>ScottReynen: Added examples of non-Gregorian date publishing</p>
<hr />
<div><h1> hCalendar Brainstorming </h1><br />
{{TOC-right}}<br />
<br />
[[to-do]]: this page could use just a bit more clean-up and reorganization. - Tantek<br />
<br />
This page is for trying out and documenting ways of using hCalendar which may involve more details than currently in the specification.<br />
<br />
If you have a question, please check the [[hcalendar-faq|hCalendar FAQ]], and ask new questions on the [http://microformats.org/discuss/ mailing lists] first.<br />
<br />
'''[[User:TobyInk]] has put together a [[User:TobyInk/hcalendar-1.1|draft revised hCalendar spec]] using ideas from this brainstorming page, and expanding the spec to cover todo items, freebusy and alarms. Recurrences are documented, as are nested hCards, nested hCalendar items and attachments (using [[rel-enclosure]]).'''<br />
<br />
== Authors ==<br />
* [http://suda.co.uk/ Brian Suda]<br />
* [http://tantek.com/log/ Tantek Çelik]<br />
<br />
== hCalendar authoring best practices ==<br />
=== Tabular event calendars ===<br />
<br />
Many calendars are posted in tabular form, where the headings on the columns and rows have property values that apply to the cells which themselves are events. E.g. many conferences have multiple tracks and post names of rooms (LOCATION) as column headers, and time slots (DTSTART, DTEND) as row headers.<br />
<br />
Here is a description of how to parse such markup into an iCalendar stream. This has been implemented in X2V and deployed. <br />
<br />
'''TO DO: document a "How To" for publishers looking to mark up tabular event listings.'''<br />
<br />
To enable mark these up with [[hcalendar|hCalendar]], we must parse additional semantic attributes from HTML4.<br />
<br />
When parsing, in addition to the special case rules documented in [[hcard-parsing]]:<br />
<br />
* If the element is a table data cell <code>&lt;td&gt;</code>, then:<br />
*# parse its "headers" attribute as a space separated set of local IDs<br />
*# find the <code>&lt;td&gt;</code> and <code>&lt;th&gt;</code> elements referenced by those IDs (call them header cells) and consider them part of the element being parsed as follows:<br />
*## Treat the header cells as children of the element, ordered by the order of ids in its "headers" attribute, immediately following the last child node (text or element) or the element. (The basic idea is that the content from those header cells is used to construct the VEVENT, but secondary to (AFTER) the content in the data cell itself, so that the data cell can customize/override part of the data in the header, e.g. if the header cell included both start time and location, and the event was being held at a different location).<br />
<br />
Real world example in the wild of a tabular event calendar marked up in this fashion: <br />
* See [[hcalendar-examples-in-wild#conference_schedules|hCalendar examples in the wild: conference schedules]].<br />
* Web Essentials 05 Session program (was at <nowiki> http://we05.com/program.cfm </nowiki> but that link went bad sometime in 2006-2007).<br />
<br />
'''Note: We have gained sufficient experience with this that we should formalize this in both [[hcard-parsing]] and [[hcalendar-parsing]] since the table cell headers technique is generic to all class name microformats. The specific use case of how to author a tabular display of events should be documented in [[hcalendar-authoring]]. Tantek'''<br />
<br />
==== rejected use of axis for more class names ====<br />
The following step (which used to be #2 above after the "Treat the header cells..." step has been removed:<br />
<br />
* 2. Parse the "axis" attribute of a header cell as a comma-separated list of categories. These categories must be used in addition to (and before) any class names on that header cell for determining whether it is a property of the VEVENT.<br />
<br />
Reasons for removal:<br />
* The [http://microformats.org/discuss/mail/microformats-discuss/2008-March/011679.html axis attribute is for a human readable label / category], not a class name and thus this would be incorrect usage of the axis attribute.<br />
* No real world tabular event calendar example has ever needed the axis attribute for hCalendar parsing.<br />
* No implementation of tabular event calendar parsing has ever bothered to implement axis parsing (probably due to the lack of any real world examples that needed it).<br />
** This is not the case. It has been implemented by [http://buzzword.org.uk/cognition/ Cognition].<br />
<br />
=== hCard locations ===<br />
<br />
In iCalendar (and thus hCalendar), the LOCATION property is just a text string. In practice however, much event content contains some amount of structure for the location, often a specific venue with name, address etc. Venues are often organizations and are thus conducive to being marked up as [[hcard|hCards]].<br />
<br />
Taking the example from the [[hcalendar|hCalendar]] spec:<br />
<br />
<pre><nowiki><br />
<span class="vevent"><br />
<a class="url" href="http://www.web2con.com/"><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<abbr class="dtstart" title="2005-10-05">October 5</abbr>-<br />
<abbr class="dtend" title="2005-10-08">7</abbr>,<br />
at the <span class="location">Argent Hotel, San Francisco, CA</span><br />
</a><br />
</span><br />
</nowiki></pre><br />
<br />
Clearly the "Argent Hotel" is a venue, and thus could be marked up as an [[hcard|hCard]] itself:<br />
<br />
<pre><nowiki><br />
<span class="location vcard"><br />
<span class="fn org">Argent Hotel</span>, <br />
<span class="adr"><span class="locality">San Francisco</span>, <span class="region">CA</span></span><br />
</span><br />
</nowiki></pre><br />
<br />
Thus in the context of the entire vevent this example would become:<br />
<br />
<pre><nowiki><br />
<span class="vevent"><br />
<a class="url" href="http://www.web2con.com/"><br />
<span class="summary">Web 2.0 Conference</span>: <br />
<abbr class="dtstart" title="2005-10-05">October 5</abbr>-<br />
<abbr class="dtend" title="2005-10-08">7</abbr>,<br />
at the <span class="location vcard"><br />
<span class="fn org">Argent Hotel</span>, <br />
<span class="adr"><span class="locality">San Francisco</span>, <span class="region">CA</span></span><br />
</span><br />
</a><br />
</span><br />
</nowiki></pre><br />
<br />
The advantage of marking up the location with explicit [[hcard|hCard]] semantics is that it enables much better identification and pivoting of locations of events.<br />
<br />
For a real world example of this in practice see Jeremy Keith's excellent SXSW 2006 event page: http://austin.adactio.com/ where all the events contain locations marked up as hCards with [[geo]] properties as well which then aid in locating the precise locations on a map.<br />
<br />
'''Note: We have gained sufficient experience with this that we should formalize this in [[hcalendar-authoring]]. Tantek'''<br />
<br />
=== hCard attendees ===<br />
<br />
In regards to representing '''RFC2445 4.8.4.1 Attendee''' (ATTENDEE property), and '''RFC2445 4.2.16 Participation Role''' (ROLE type), using a real world example to develop a brainstorm proposal for how to use the respective [[hcalendar|hCalendar]] <code>'''attendee'''</code> property and <code>'''role'''</code> subproperty.<br />
<br />
Many online events (e.g. at http://upcoming.org/) indicate who is attending an event, and in fact, who is just "watching" as well in this case. Whereas RFC2445 says to use a "calendar address" (essentially an email address) for the "ATTENDEE" property, it has just enough hooks to make an hCard work instead (DIR for URL to the contact info etc.). Thus hCalendar attendees should be marked up with hCard so that the full semantics are conveyed.<br />
<br />
E.g. for http://upcoming.org/event/152831/<br />
<br />
for the <nowiki><span>s</nowiki> that follow the "Attending" heading on that page<br />
<br />
<pre><nowiki><br />
<span class="attendee vcard"><br />
<a class="dynavatar_link" id="user_48265" href="http://upcoming.org/user/48265/"><br />
<img id="image_cbe16d4252b4b1aab58c787379d130f552994da2" src="http://static.flickr.com/45/buddyicons/86708053%40N00.jpg" align="" valign="" height="12" width="12" border="0" class="avatar logo" style="padding: 2px;" /><br />
</a></span><br />
<span><br />
<a class="friend url nickname" rel="friend" id="user_48265" title="Attending since Feb 15, 2007 02:15 PM" href="http://upcoming.org/user/48265/"><br />
CPERIN</a><br />
</span><br /><br />
</nowiki></pre><br />
<br />
and for the <nowiki><span>s</nowiki> that follow the WATCHING heading<br />
<br />
<nowiki><br />
<span class="attendee vcard"><a class="dynavatar_link" id="user_29960" href="http://upcoming.org/user/29960/"><img id="image_2980a4eb9e608adc0341b318dfea501c5fed6621" src="http://static.flickr.com/16/buddyicons/39472722%40N00.jpg" align="" valign="" height="12" width="12" border="0" class="avatar logo" style="padding: 2px;" /></a></span><span><a class="friend url nickname" rel="friend" id="user_29960" title="Watching since Feb 15, 2007 02:26 PM" href="http://upcoming.org/user/29960/">cee-dub</a><abbr class="role" title="non-participant"></abbr></span><br /><br />
</nowiki><br />
<br />
and I *know* that the <nowiki><abbr class="role" title="non-participant"></abbr></nowiki> is not a best practice because it is hidden metadata, but it is *right next to* the anchor title text that says "Watching" so that is at least *close*.<br />
<br />
and <code>ROLE=NON-PARTICIPANT</code> is the closest semantic in iCalendar RFC2445 to "watching" - "NON-PARTICIPANT" is defined as "Indicates a participant who is copied for information purposes only" which sounds like "watching" to me. [[User:Tantek|Tantek]] 19:34, 23 Feb 2007 (PST)<br />
<br />
==== Role property overlap ====<br />
<br />
Both vCard and iCalendar contain the term ROLE. Their definitions are similar enough to consider collapsing.<br />
<br />
Therefore the following is proposed:<br />
<br />
* The [[hcard|hCard]] "role" property and the [[hcalendar|hCalendar]] "role" subproperty of the "attendee" (and any other applicable) property are considered equivalent. This is essentially an explicit declaration of the status quo and clarification in the context of the above proposal to use hCard to mark up the details of an hCalendar event attendee.<br />
* hCard consuming applications MAY ignore the following "role" property values, as such values most likely apply ''only'' to the context of an hCalendar event attendee, and probably do not indicate the role of the hCard in general. Values are shown in ALL CAPS per convention from RFC2445 but are case-insensitive per hCard/hCalendar conventions for enumerated property values.<br />
** <code>CHAIR</code><br />
** <code>'''REQ-PARTICIPANT'''</code><br />
** <code>OPT-PARTICIPANT</code><br />
** <code>NON-PARTICIPANT</code><br />
* hCalendar authors MUST OMIT the role value "REQ-PARTICIPANT" for the hCard of an attendee of an hCalendar event, because:<br />
*# It is simpler/unnecessary - "REQ-PARTICIPANT" is the default value for the hCalendar "role" subproperty, and thus any conforming hCalendar consuming application would presume that value by default anyway for all "attendee" hCards.<br />
*# It will help avoid polluting existing hCard consuming applications.<br />
* hCalendar consuming applications MUST IGNORE attendee role values that are outside the above list of four values.<br />
<br />
=== Photos and other attachments ===<br />
<br />
To associate a photo or other chunk of content/media (movie, podcast, agenda document, etc.) with an event, use the ATTACH property (defined in RFC2445 section 4.8.1.1 Attachment), e.g. (whitespace added for readabilty)<br />
<br />
<pre><nowiki><br />
<span class="vevent"><br />
<abbr class="dtstart" title="20070215T1900-0800">15 February 2007</abbr>: <br />
<span class="summary">Futurist meetup event</span> to discuss<br />
<a href="http://www.flickr.com/photos/tantek/411545406/"> <br />
<img src="http://farm1.static.flickr.com/183/411545406_c73ca4e613_t.jpg" <br />
class="attach" <br />
alt="this photo" /><br />
</a><br />
</span><br />
</nowiki></pre><br />
<br />
To explicitly indicate the content type of the image, you can instead use the object tag:<br />
<br />
<pre><nowiki><br />
<span class="vevent"><br />
<abbr class="dtstart" title="20070215T1900-0800">15 February 2007</abbr>: <br />
<span class="summary">Futurist meetup event</span> to discuss<br />
<a href="http://www.flickr.com/photos/tantek/411545406/"> <br />
<object data="http://farm1.static.flickr.com/183/411545406_c73ca4e613_t.jpg" <br />
class="attach" <br />
type="image/jpeg"><br />
this photo</object><br />
</a><br />
</span><br />
</nowiki></pre><br />
<br />
<br />
This event might be displayed as:<br />
<br />
<abbr class="dtstart" title="20070215T1900-0800">15 February 2007</abbr>: Futurist meetup event to discuss [http://www.flickr.com/photos/tantek/411545406/ http://farm1.static.flickr.com/183/411545406_c73ca4e613_t.jpg]<br />
<br />
<br />
Note: the above example with object tag should be equivalent to the following iCalendar snippet (BEGIN/END:VCALENDAR omitted):<br />
<pre><nowiki><br />
BEGIN:VEVENT<br />
DTSTART:20070215T1900-0800<br />
SUMMARY:Futurist meetup event<br />
ATTACH;FMTYPE=image/jpeg:http://farm1.static.flickr.com/183/411545406_c73ca4e613_t.jpg<br />
END:VEVENT<br />
</nowiki></pre><br />
<br />
==== Cardinality ====<br />
<br />
The ATTACH property can appear more than once. Though section 4.8.1.1, which defines ATTACH doesn't state how often ATTACH can appear, section 3.5 clearly indicates that the authors intended multiple attachments:<br />
<br />
ATTACHMENTS - - An iCalendar object can include references to Uniform<br />
Resource Locators that can be programmed resources.<br />
<br />
== iCalendar generation best practices ==<br />
<br />
Along with the four base properties, you can define addtional properties through the use of the x-prop property. For best-practices for hCal to iCal transformers, it would be helpful if the transforming application added the following x-* properties:<br />
<br />
=== X-FROM-URL ===<br />
<br />
* X-FROM-URL. The value of this property would be the URL of the page where the iCal representation was generated.<br />
<pre><nowiki><br />
X-FROM-URL:http://example.com/page-containing-hCal-encoding.html<br />
</nowiki></pre><br />
<br />
'''Note: We have gained sufficient experience with this that we should formalize this in [[hcalendar-parsing]]. Tantek'''<br />
<br />
=== X-WR-CALNAME ===<br />
<br />
* X-WR-CALNAME. iCal.app recognizes this property as the "calendar name" for subscribed calendars. Thus transforming applications *should* take the <code>&lt;title&gt;...&lt;/title&gt;</code> from the page being parsed, optionally append " events", and use that value for the X-WR-CALNAME property in the resulting feed. E.g. if the page had <code>&lt;title&gt;Example Home Page&lt;/title&gt;</code> then the .ics output should have as part of the vcalendar object:<br />
<pre><nowiki><br />
X-WR-CALNAME:Example Home Page<br />
</nowiki></pre><br />
<br />
'''Note: We have gained sufficient experience with this that we should formalize this in [[hcalendar-parsing]]. Tantek'''<br />
<br />
: This doesn't seem like a good solution for the case when multiple hCalendars are published on a single HTML page. [[User:TobyInk|TobyInk]] 09:56, 4 Mar 2008 (PST)<br />
<br />
== iCalendar examples in hCalendar ==<br />
<br />
This is a growing example case written in iCal format and transformed to the corresponding XHTML. These conversions are open to community input. See [[hcalendar-examples]] for current work.<br />
<br />
<pre><nowiki><br />
BEGIN:VEVENT<br />
CATEGORIES:foo,bar<br />
SUMMARY: Short Title<br />
DESCRIPTION: Full Description<br />
DTSTART;VALUE=DATE:20040101<br />
DTEND:20040101T235959Z<br />
RRULE:FREQ=YEARLY;UNTIL=20080102T000000Z<br />
URL;WORK:http://example.com<br />
ATTENDEE;ROLE=CHAIR:MAILTO:JohnDoe@example.com<br />
GEO:37.386013;-122.082932<br />
END:VEVENT<br />
</nowiki></pre><br />
<pre><nowiki><br />
<p class="vevent"><br />
<!-- @@ how to deal with Whitespace issues in lists 'foo, bar' --><br />
Categories:<br />
<ul class="categories"><br />
<li>foo</li><br />
<li>bar</li><br />
</ul><br />
<a href="http://example.com" class="summary">Short Title</a><br />
<span class="description">description</span><br />
<span class="geo"><span class="Lat">37.386013</span> <span class="Lon">-122.082932</span></span><br />
<br />
<!-- This currently does not take into consideration the VALUE=DATE --><br />
<!-- The transforming application could attempt to detect the proper format and add params as needed? --><br />
Date: <em class="dtstart">20040101</em> - <em class="dtend">20040101T235959Z</em><br />
<br />
<!-- any thoughts to better encode attendee --><br />
<!-- the ROLE must be of a known type, but one of type is x-name (user-specified) --><br />
<!-- therefore there is no solid way to know "chair" refers to a ROLE parameter --><br />
<a class="attendee chair" href="mailto:JohnDoe@example.com">John Doe</a><br />
<br />
<!-- this messy, but works. Is there a better way? --><br />
<p class="rrule">The event will be held <span class="freq">yearly</span> until <span class=""until">20080102T000000Z</span>.</p><br />
<br />
</p><br />
</nowiki></pre><br />
<br />
@@-need to look at nested tag examples<br />
<pre><nowiki><br />
XHTML<br />
<span class="description"><span class="summary">Short Title</span> to a longer article</span><br />
<br />
vCal<br />
SUMMARY:Short Title<br />
DESCRIPTION:Short Title to a longer article<br />
</nowiki></pre><br />
<br />
<br />
=== Examples from RFC 2445 ===<br />
<br />
* These examples are now all available on [[hcalendar-examples]].<br />
<br />
With the abbr's title attribute being used rather than the node value, the actual data could vary and still represent the same vcalendar.<br />
<br />
<pre><nowiki><br />
BEGIN:VCALENDAR<br />
VERSION:2.0<br />
PRODID:-//hacksw/handcal//NONSGML v1.0//EN<br />
BEGIN:VEVENT<br />
DTSTART:19970714T170000Z<br />
DTEND:19970715T035959Z<br />
SUMMARY:Bastille Day Party<br />
END:VEVENT<br />
END:VCALENDAR<br />
</nowiki></pre><br />
<br />
<pre><nowiki><br />
<span class="vcalendar"><br />
<span class="vevent"><br />
<abbr class="dtstart" title="19970714T170000Z">July 14th</abbr><br />
<abbr class="dtend" title="19970715T035959Z"></abbr><br />
<span class="summary">Bastille Day Party</span><br />
</span><br />
</span><br />
</nowiki></pre><br />
<br />
==== UID handling ====<br />
<br />
The UID in iCal is represented in HTML as the id attribute in these examples. Any valid id in HTML is a valid UID in iCal, but not the contrapositive, a valid UID is NOT a valid HTML id. HTML ids can only start with a letter, not a number.<br />
<br />
<pre><nowiki><br />
BEGIN:VEVENT<br />
UID:19970901T130000Z-123401@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART:19970903T163000Z<br />
DTEND:19970903T190000Z<br />
SUMMARY:Annual Employee Review<br />
CLASS:PRIVATE<br />
CATEGORIES:BUSINESS,HUMAN RESOURCES<br />
END:VEVENT<br />
</nowiki></pre><br />
<br />
<pre><nowiki><br />
<span class="vcalendar"><br />
<span class="vevent" id="19970901T130000Z-123402@host.com"><br />
<abbr class="dtstamp" title="19970901T1300Z"></abbr><br />
<abbr class="dtstart" title="19970903T163000Z">September 3rd, 4:30pm</abbr>-<br />
<abbr class="dtend" title="19970903T190000Z">7:00pm</abbr><br />
<span class="summary">Annual Employee Review</span><br />
<span class="class">private</span><br />
<ul class="categories"><br />
<li>BUSINESS</li><br />
<li>HUMAN RESOURCES</li><br />
</ul><br />
</span><br />
</span><br />
</nowiki></pre><br />
<br />
<pre><nowiki><br />
BEGIN:VCALENDAR<br />
BEGIN:VEVENT<br />
UID:19970901T130000Z-123402@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART:19970401T163000Z<br />
DTEND:19970402T010000Z<br />
SUMMARY:Laurel is in sensitivity awareness class.<br />
CLASS:PUBLIC<br />
CATEGORIES:BUSINESS,HUMAN RESOURCES<br />
TRANSP:TRANSPARENT<br />
END:VEVENT<br />
END:VCALENDAR<br />
</nowiki></pre><br />
<pre><nowiki><br />
<span class="vcalendar"><br />
<span class="vevent" id="19970901T130000Z-123402@host.com"><br />
<abbr class="dtstamp" title="19970901T1300Z"></abbr><br />
<abbr class="dtstart" title="19970401T163000Z">April 1st 4:30pm</abbr>-<br />
<abbr class="dtend" title="19970402T010000Z">1:00am</abbr><br />
<span class="summary">Laurel is in sensitivity awareness class.</span><br />
<span class="class">PUBLIC</span><br />
<ul class="categories"><br />
<li>BUSINESS</li><br />
<li>HUMAN RESOURCES</li><br />
</ul><br />
<span class="transp">Transparent</span><br />
</span><br />
</span><br />
</nowiki></pre><br />
<br />
==== RRULE handling ====<br />
<br />
The way RRULE is encoded should be discussed.<br />
<br />
<pre><nowiki><br />
BEGIN:VEVENT<br />
UID:19970901T130000Z-123403@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART:19971102<br />
SUMMARY:Our Blissful Anniversary<br />
CLASS:CONFIDENTIAL<br />
CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION<br />
RRULE:FREQ=YEARLY<br />
END:VEVENT<br />
</nowiki></pre><br />
<pre><nowiki><br />
<span class="vcalendar"><br />
<span class="vevent" id="19970901T130000Z-123403@host.com"><br />
<abbr class="dtstart" title="19970901T1300Z"></abbr><br />
<abbr class="dtend" title="19971102">November 2nd</abbr><br />
<span class="summary">Our Blissful Anniversary</span><br />
<span class="class">CONFIDENTIAL</span><br />
<ul class="categories"><br />
<li>ANNIVERSARY</li><br />
<li>PERSONAL</li><br />
<li>SPECIAL OCCASION</li><br />
</ul><br />
<span class="rrule"><span class="freq">YEARLY</span></span><br />
</span><br />
</span><br />
</nowiki></pre><br />
<br />
<br />
Is this how re-occuring weekly events (basically, my class teaching list) should be done? Note the use of DTEND and DTSTART to mark ending and starting times for the semester. Using markup from Harry Halpin's homepage http://www.ibiblio.org/hhalpin.<br />
<br />
<pre><nowiki><br />
<span class="vevent"><br />
<div class="rrule"><a<br />
href="http://www.inf.ed.ac.uk/teaching/courses/2007/lsi.html">Language<br />
Semantics and Implementation</a> meet at DHT<br />
7.18 <abbr<br />
class="freq"<br />
title="weekly">every</abbr> <abbr class="BYDAY"<br />
title="FR">F</abbr>ridays <abbr class="dtstart"<br />
title="1206Z1000">10:00</abbr>-<abbr class="dtstart"<br />
title="0409Z1100">11:00</abbr></div><br />
</span><br />
<br />
</nowiki></pre><br />
<br />
:No, because "every" is not an abbreviation of "weekly"; that's an abuse of <code>abbr</code>. If "byday" is not case-sensitive, you could mark up the first two letters of "Friday" with a span (but what if the page was in French or Chinese?). You also have 2x <code>dtstart</code>. [[User:AndyMabbett|Andy Mabbett]] 09:47, 22 Feb 2008 (PST)<br />
<br />
== Examples from real world event sites ==<br />
<br />
=== W3C Meetings ===<br />
<br />
I just got email announcing the dates of another W3C meeting. I don't think it's marked up with hCalendar. I could mark it up myself, like I did for [http://www.w3.org/2005/12/allgroupoverview.html the TP day/week schedule], but it might not stick. Somehow I got [http://www.w3.org/2000/08/w3c-synd/ our syndicated news markup] (precursor to [[hAtom]]) to stick, i.e. to become part of the norm in the W3C comm team. I wonder if I could pull that off for calendars.<br />
<br />
My first thought is authoring tools, but I don't think I can wait that long.<br />
Next thought is instant-feedback checking tools...<br />
X2V is really handy, but can't be used for confidential pages (and many/most calendars I use are not public).<br />
So.. how about some in-browser javascript "yes, you got it right!" or "hmm... that looks like a date; is there an event you didn't mark up?" feedback? I think I saw something like that in hCalendar implementations.<br />
<br />
[[User:DanC|DanC]] 09:00, 3 Feb 2006 (PST)<br />
<br />
=== Laughing Squid ===<br />
<br />
Laughing Squid had the following [http://laughingsquid.com/squidlist/calendar/9584/2005/4/7 multiple occurence event example]:<br />
<br />
Thu, Apr 7 : Tu/Wed: 12-4pm Th/Fr/Sat 12-7pm Sun 12-6pm <br />
<br />
In addition, later on in the description, it says:<br />
<br />
April 7-21, 2005<br />
<br />
This is actually quite a non-trivial example, because the event lasts for different durations on different days (4 hours, 7 hours, 6 hours).<br />
<br />
Because of the differing durations, the specification requires that *each* instance of this recurring event be explicitly specified. <br />
<br />
But first we markup the starting date and time explicitly:<br />
<pre><br />
<abbr class="dtstart" title="20050407T1200-0700">Thu, Apr 7</abbr> : <br />
</pre><br />
Then we put in the quite lengthy explicit specification of every other time the event occurs, marked up around the human readable description.<br />
<pre><br />
<abbr class="rdate" title="20050407T1200-0700/PT7H, 20050408T1200-0700/PT7H, <br />
20050409T1200-0700/PT7H, 20050410T1200-0700/PT6H, 20050412T1200-0700/PT4H, <br />
20050413T1200-0700/PT4H, 200504014T1200-0700/PT7H, 20050415T1200-0700/PT7H, <br />
20050416T1200-0700/PT7H, 20050417T1200-0700/PT6H, 20050419T1200-0700/PT4H, <br />
20050420T1200-0700/PT4H, 20050421T1200-0700/PT7H" ><br />
Tu/Wed: 12-4pm Th/Fr/Sat 12-7pm Sun 12-6pm<br />
</abbr><br />
</pre><br />
<br />
The RDATE "PERIOD" format is fairly straightforward. You simply list *each* occurrence of the event, separated by commas. Each occurrence consists of the ISO8601 datetime of the start of the event, followed by a slash "/", followed by *either* the duration of the event (e.g. 7 hours = PT7H), *or* a complete ISO8601 datetime of the end of the event. I chose to use the duration of the event for this example for reason of brevity.<br />
<br />
Note that "value=period:" is unnecessary in the rdate value since the parser can infer "value=period:" from the presence of a "/" in the title attribute value.<br />
<br />
With simpler repeating events, or perhaps events which only repeat a day or two, their hCalendar markup may be more illustrative of how to do this in a general way.<br />
<br />
== CSS Styles ==<br />
<br />
Since the hCal properties are added in as HTML class names, you can style them with CSS class selectors along with other HTML class names. You are free to style these properties in any fashion you want (see specific notes), but here are a few examples that you can use.<br />
<br />
=== Preserving White-space ===<br />
If you are encoding data that requires tabs, returns, or other white-space to be perserved you can use the following CSS property to do so in HTML.<br />
<pre><nowiki><br />
<span style="white-space: pre"><br />
This white-space<br />
will be<br />
preserved<br />
</span><br />
</nowiki></pre><br />
white-space can take one of three different parameters; normal, pre, and no-wrap.<br />
<br />
=== Not recommended ===<br />
<br />
The following CSS styling techniques are not recommended:<br />
<br />
==== Hiding Data ====<br />
It is possible to encode additional data without it being displayed in the HTML, by using the CSS style property 'display'.<br />
<pre><nowiki><br />
<span style="display:none">Hidden Data</span><br />
</nowiki></pre><br />
This data will be found by any transforming application and will be properly encoded into an iCal file.<br />
<br />
'''You SHOULD NOT do this because it violates the visibility priniciple.'''<br />
<br />
== hCalendar for timelines ==<br />
<br />
<br />
There have been some interesting discussions about how to use [[hcalendar|hCalendar]] for marking up timelines. Here are some pointers:<br />
<br />
* [http://www.foundhistory.org/2006/05/05/calendars-as-timelines/ Calendars as Timelines]<br />
* [http://heml.org/heml-cocoon/ The Historical Event Markup and Linking (HEML) Project]<br />
* [http://v1.clioweb.org/archive/2006/05/04/css-based-timelines/ CSS-Based Timelines]<br />
<br />
See also [[history-microformat]].<br />
<br />
== Other use cases ==<br />
Please add your suggestions!<br />
<br />
hCalendar microformats could be used to:<br />
<br />
*Sequence waypoints for a GPS "track" - see [[geo-waypoint-examples]] for details<br />
*Mark up "last updated" dates on web pages (does anyone have examples of this being done already?).<br />
*Date-time stamp photographs, such as those on Flickr and Wikimedia Commons.<br />
*...<br />
<br />
== grouping events ==<br />
iCalendar has a mechanism: the RELATED-TO property with a RELTYPE attribute of PARENT/CHILD/SIBLING (parent being the default). What are some ways to represent grouped events in hCalendar?<br />
<br />
This comes from the questions previously asked, e.g. from the FAQ:<br />
* [[hcalendar-faq#Is_it_possible_to_represent_groups_of_events|Is it possible to represent groups of events]]<br />
and added here a while ago:<br />
<br />
Q: How do you show an event within an event? ie, how do you show groupings of events, e.g a series of workshops at a conference, where there are parent-child relationships, so that parsers can detect the structure and display/offer different options accordingly?<br />
<br />
A: Currently there is no semantic to express "groupings" of events hierarchically, e.g. parent-child relationships. What you can do is "tag" such related events with the same "category" (using [[rel-tag]]) so that consuming applications can aggregate them together.<br />
<br />
=== grouping options ===<br />
Two general options: <br />
# hierarchical containment (in markup)<br />
# hyperlinks (hyperlinks from related events to each other)<br />
<br />
=== grouping examples ===<br />
Need: real world examples of related events to help drive the design. URLs ''must'' be provided.<br />
<br />
* [[events/2008-03-07-sxsw-interactive|SXSW interactive]] (container event)<br />
** [[events/2008-03-10-sxsw-portability-panel|SXSW panel on social network portability]] (specific event inside that container)<br />
** this example is on two pages, with links between the events, thus the second option, "hyperlinks" seems to make more sense to pursue.<br />
<br />
=== grouping via hierarchical containment ===<br />
Q: Could events eventually be nested? What problems could this cause? e.g <br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<br />
<h1 class="summary">Conference<h1><br />
<abbr class="dtstart" title="2007-08-25t09:00">25 August 2007, 9am</abbr><br />
<br />
<div class="vevent"><br />
<h2 class="summary">Workshop 1</h2><br />
<abbr class="dtstart" title="2007-08-25t09:30">9.30am</abbr><br />
<abbr class="dtend" title="2007-08-25t10:30">10.30am</abbr><br />
</div><br />
<br />
<div class="vevent"><br />
<h2 class="summary">Workshop 2</h2><br />
<abbr class="dtstart" title="2007-08-25t10:30">10.30am</abbr> - <br />
<abbr class="dtend" title="2007-08-25t11:30">11.30am</abbr><br />
</div><br />
<br />
</div><br />
</nowiki></pre><br />
--[[User:GeoffB|GeoffB]] 21:57, 24 Aug 2007 (PDT)<br />
<br />
=== grouping via hyperlink relationships ===<br />
While hierarchical containment may work for some examples, the real world examples found so far seem to indicate that hyperlinking between events will better suit existing event publishing practices.<br />
<br />
In [[iCalendar]] the RELATED-TO property (defined in section 4.8.4.5 Related To) has two pieces:<br />
* its value, which is defined to be the UID of another event (or calendar object)<br />
* the RELTYPE property parameter (defined in section 4.2.15 Relationship Type), which takes values of <code>PARENT</code> (default), <code>CHILD</code>, and <code>SIBLING</code>.<br />
<br />
Best practices for UID on the Web have already been documented for hCard (and thus hCalendar) to be to use an http URL, which are most commonly (as shown in the examples above) published as <code><nowiki><a href></nowiki></code> hyperlinks. Thus we could specify the hCalendar class name "related-to" to map the iCalendar property RELATED-TO, taking the value from the href property of the a element, or whatever is the URL attribute (if any) of an element, similar to the "url" and "photo" properties.<br />
<br />
Such elements also have a <code>rel</code> attribute that can be used to semantically represent the RELTYPE property parameter.<br />
<br />
However we cannot simple re-use the literal RELTYPE values as they collide with existing [[XFN]] [[rel values]]. Thus we must consider some other possibilities.<br />
<br />
=== grouping rel value possibilities ===<br />
rel values that are a 1:1 mapping of the semantics of the RELTYPE values from iCalendar.<br />
* PARENT, CHILD, SIBLING - literal iCalendar values.<br />
<br />
Possible respective rel values.:<br />
* '''superior, subordinate, peer''' - words extracted from RELTYPE prose description in iCalendar.<br />
* '''event-parent, event-child, event-sibling''' - simple adjective prefixing to provide unique rel values for the specific semantic expressed for the respective RELTYPEs in iCalendar.<br />
* '''cal-parent, cal-child, cal-sibling''' - similar, but use of more generic "cal" prefix due to possibly use to relate to other calendar objects (besides events)<br />
* '''ical-parent, ical-child, ical-sibling''' - similar, but slightly more specific use of "ical" prefix to denote semantic definition from the iCalendar spec. Somewhat redundant as the use of the iCalendar spec is already implied by the root class of "vcalendar" or "vevent".<br />
* '''icalendar-parent, icalendar-child, icalendar-sibling''' - similar but longer to precisely refer to name of specification.<br />
* '''vcalendar-parent, vcalendar-child, vcalendar-sibling''' - where "vcalendar" refers back to the root class name for hCalendar rather than the vCalendar spec obsoleted by iCalendar.<br />
* '''component-parent, component-child, component-sibling''' - similar, but use of the word "component" directly from iCalendar section 4.8.4.5 Related To which states: "Purpose: The property is used to represent a relationship or reference between one calendar '''component''' and another." ('''emphasis''' added).<br />
* '''object-parent, object-child, object-sibling''' - similar, but even more generic use of an overloaded computer science term for the sake of strawman analysis.<br />
<br />
Rejected:<br />
* parent, child, sibling - rejected. already defined by [[XFN]] to mean human parent, child, sibling relationships.<br />
<br />
== Open Questions ==<br />
=== Undecided Encodings of Certain Property Attributes ===<br />
There are several attributes that still need to be discussed about how to property encode them into HTML.<br />
<br />
For example the RSVP and ROLE attrbutes:<br />
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO:jsmith@host.com<br />
or<br />
ATTENDEE:CUTYPE=GROUP:MAILTO:john@host.com<br />
<br />
Other attributes include:<br />
* Delegate-To<br />
* Delegate-from<br />
* Sent-By<br />
* Member<br />
* Partstat<br />
* CN<br />
* DIR<br />
<br />
Then all the enumerated possible values for each of these<br />
<br />
=== General Questions ===<br />
'''These should be processed and move to either [[hcalendar-feedback]], [[hcalendar-issues]], or [[hcalendar-faq]].'''<br />
<br />
Q: Should Transforming applications purely extract the information and ignore validity? or should there be some checking, or should this be left to the importing application? (i.e. DTSTART;VALUE=DATE: This-Is-Not-a-proper-date)<br />
<br />
A: The simpler the better. Other than checking for perhaps X(HT)ML validity, it should be a simple translator, because presumably the receiving iCalendar application has to have malformed .ics handling already. Let's avoid duplicating that. -- [http://tantek.com/ Tantek Çelik]<br />
<br />
Q: What about multiple of the instances same vCal entity? (two instances of DTSTART) Is this left up to the importing application, or should the XSLT transformation fail?<br />
<br />
A: Same as previous. Leave it up to the importing application to interpret it per the iCalendar spec, e.g. what does RFC2445 say about two instances of DTSTART? -- [http://tantek.com/ Tantek Çelik]<br />
<br />
From RFC2445:<br />
4.1.2 Multiple Values<br />
Some properties defined in the iCalendar object can have multiple values. The general rule for encoding multi-valued items is to simply create a new content line for each value, including the property name. However, it should be noted that some properties support encoding multiple values in a single property by separating the values with a COMMA character (US-ASCII decimal 44). Individual property definitions should be consulted for determining whether a specific property allows multiple values and in which of these two forms.<br />
<br />
Other than that, it does not mention what to do ABOUT invalid data, or which of the multiple entries takes precedence. The only mention of duplicate instances is in the RRULE and EXDATE rules where events exclusions/inclusions overlap. Then duplicate instances are ignore. If it is explicitly written for those items, but NOT for things like DTSTART, then it is difficult to assume duplicate instances are ignored for them as well.<br />
<br />
Each of the Components (VEVENT, ...) define which properties can exisit and in what quantity. So multiple DTSTART properties are NOT allowed.<br />
-- [http://suda.co.uk Brian Suda]<br />
<br />
Q: Should vCal entitles be represented in XHTML in classes ONLY on block-level element? or should some like VEVENT be block-level and others be of any? does this impact the semantics at all?<br />
<br />
A: I don't think the (X)HTML notion of "block-level" should have any bearing whatsoever on vCal entities. You should be able to say <nowiki><span class="vevent"></nowiki> or <nowiki><div class="vevent"></nowiki> and either should work.<br />
<br />
Q: Should the transforming application add any additional information to the iCalendar representation other than what was encoded in the HTML? (i.e. UID, the unique identifier might not be present in the HTML code, but could be generated by the transforming application and added to the iCal file. Should this be allowed? or should the transforming app ONLY be allowed to add X-PROPERTY properties?) IF it was not explicitly encoded in the HTML should it be left out? What about default values?<br />
<br />
Q: If we are looking at the most semantic way to encoding iCalendar data in HTML then several other attributes should be considered besides just 'class'. There are two other candidated, ID and REL. The ID tag MUST be unique within the XHTML file (this could be used for the UID property). The REL attribute can ONLY be applied to 'a' and 'link' tags, but might be helpful. Are namespaces an option? xml:lang, xml:base, are there any others that might be more semantically correct to encode this data?<br />
<br />
Q: To help distinguish xparam values from other actual CSS styles, should we assume/mandate that all values in a class attribute within an encoded iCal component class attribute (<x class="vevent|vtodo|...">) be considered an xparam?<br />
<br />
A: If you are using other CSS styles (e.g. "center", "bluebox", "greenline", etc.) nested within an iCal component, those should be avoided and the styles applied to the list of iCal properties instead/also?<br />
<br />
<pre><nowiki><br />
.center, .vevent { text-align: center; }<br />
</nowiki></pre><br />
<br />
Q: What about cases where the words "yesterday", "last year", or "last week" was used? How should we represent this? Is this overkill or not appropriate for hcard ? - [[User:B.K._DeLong]]<br />
<br />
A: I took a stab at "yesterday" and just added a dtstart of the previous day. Not sure how to represent a single year or whole week - [[User:B.K._DeLong]]<br />
<br />
<pre><nowiki><br />
<abbr class="dtstart" title="20050114">Yesterday's</abbr><br />
</nowiki></pre><br />
<br />
<br />
=== Recurring Events ===<br />
<br />
Recurring events are tricky. First, there's the question of whether to follow ''For types with multiple components, use nested elements with class names equivalent to the names of the components'' a la<br />
<pre><br />
<nowiki><div class="rrule">every <em class="interval">1</em><br />
<em class="freq">WEEKLY</em> on <em class="byday">TU</em><br />
until <em class="until">2004-11-01</em></div></nowiki><br />
</pre><br />
... or ...<br />
<pre><br />
<nowiki><abbr class="rrule" title="FREQ=WEEKLY;COUNT=17;INTERVAL=2;BYDAY=TH"> every other<br />
Thursday for 34 weeks</abbr></nowiki><br />
</pre><br />
... as in [http://microformats.org/discuss/mail/microformats-discuss/2005-August/000516.html Tantek's 1 Aug msg].<br />
<br />
[http://www.w3.org/People/Connolly/ DanC] has been experimenting with representing his PDA calendar in hCalendar:<br />
<br />
* in [http://dev.w3.org/cvsweb/2001/palmagent/ palmagent], there's dangerSync.py which uses the XMLRPC interface and spits out RDF data. Then asHCal.xsl converts that to hCalendar<br />
* then in [http://www.w3.org/2002/12/cal/ the RDF Calendar workspace], there's [http://www.w3.org/2002/12/cal/glean-hcal.xsl glean-hcal.xsl] that turns hCalendar into RDF Calendar, and finally,<br />
* in [http://www.w3.org/2000/10/swap/ SWAP] there's [http://www.w3.org/2000/10/swap/pim/toIcal.py toIcal.py] that turns RDF Calendar to .ics format.<br />
<br />
So I can go from my sidekick to .ics with one Makefile.<br />
<br />
[http://dev.w3.org/cvsweb/2001/palmagent/event-test.html events-test.html] is a test file that has all the constructs from my PDA data, in hCalendar. In particular, it uses the nested element representation of recurring events. glean-hcal.xsl would be much less fun to write if it had to parse <nowiki>title="FREQ=WEEKLY;COUNT=17;INTERVAL=2;BYDAY=TH"</nowiki>.<br />
<br />
Then there's the question of "every tuesday afternoon at 2pm Chicago time". This isn't expressible using [[datetime-design-pattern]]. There are some good reasons for that, but it leaves a rather large and uncomfortable gap in hCalendar.<br />
<br />
=== Encoding Questions ===<br />
The way dates are encoded is not always the most user friendly. If i want to encode january 1st, 2005, that is <code><span class="dtstart">20050101</span></code>, which is displayed as 20050101. If we are marking-up comma seperated values, like FN, with each sub-element inside their own tag, then the date should be allowed the same.<br />
<br />
(However, FN is in the RFC2426 spec and vCard schema, these individual date terms are not, therefore the reasoning in the last sentence is incorrect. -[http://tantek.com/log/ Tantek])<br />
<br />
<pre><nowiki><br />
20050101<br />
<span class="dtstart"><span class="Year">2005</span><span class="Month">01</span><span class="Day">01</span></span><br />
</nowiki></pre><br />
With this encoding, then YYYYMMDD schema can be rearranged for different cultures, DD-MM-YYYY for UK, MM-DD-YYYY for US, etc.<br />
<pre><nowiki><br />
02-01-2005<br />
<span class="dtstart"><span class="Month">02</span>-<span class="Day">01</span>-<span class="Year">2005</span></span><br />
01-02-2005<br />
<span class="dtstart"><span class="Day" title="first">01</span>-<span class="Month" title="Feb">02</span>-<span class="Year">2005</span></span><br />
</nowiki></pre><br />
Both of the above encodings are equal, the '-' seperator is ignored by the transforming application. -- [http://suda.co.uk Brian Suda]<br />
<br />
Agreed that the way dates are encoded is not always the most user friendly, but there is an easier solution to this, once you think of what is actually going on in the difference between ISO8601 dates, and dates the way humans use them. Humans typically use an abbrevation or shorthand for a date, like "tomorrow", or "Tuesday", or "the 4th", or perhaps "July 4th". Thus it makes sense to permit this in hCalendar, using the <code>&lt;abbr&gt;</code> tag which provides the ability to markup the human-familiar short form of some data or language, while preserving the long form in the 'title' attribute.<br />
<br />
E.g. for the above example of a start date of January 1st, 2005, you could use this markup:<br />
<br />
<pre><nowiki><br />
<abbr class="dtstart" title="20050101">January 1st, 2005</abbr><br />
</nowiki></pre><br />
<br />
Which would display as <code>January 1st, 2005</code> but would provide the respective ISO8601 date in the title attribute. - [http://tantek.com/log Tantek]<br />
<br />
== TO DO ==<br />
=== XMDP Profile ===<br />
* hCalendar XMDP profile ([[hcalendar-profile]]) needs to be created.<br />
<br />
=== Applications ===<br />
A simple implementation of transforming/extracting vCal data from an XHTML file is available for testing. A bookmarklet is also available. The code will be updated as the spec is finalised.<br />
http://suda.co.uk/projects/X2V/ . You may also use http://feeds.technorati.com/events/ for parsing hCalendar events and returning an iCalendar stream.<br />
<br />
<br />
=== Parsing ===<br />
<br />
Need to write up an [[hcalendar-parsing]] document, similar to [[hcard-parsing]].<br />
<br />
== Relationships with other microformats ==<br />
<br />
In a [http://www.technologyreview.com/articles/04/10/frauenfelder1004.asp Technology Review interview], TBL said "It would have the relationships between the event and the various people chairing it.".<br />
<br />
We should have examples of how hCalendar events can indicate such relationships, both in the format and in the presentation.<br />
<br />
E.g.:<br />
* Would it just link to URLs for the various people? (e.g. to their homepages/blogs etc.)<br />
* Would it include hCards for the various people? <br />
* Would it link to hCards for various people?<br />
* Perhaps allow all the above?<br />
<br />
== Mime-Type ==<br />
<br />
According to RFC2445, the proposed media type value is 'text/calendar'.<br />
<br />
A standard vCalendar file has an extension of .vcs and MIME type of text/x-vCalendar. If you use iCalendar, the MIME type is "text/Calendar" and the extension is .ics.<br />
<br />
Text/X-vCalendar Content Type<br />
<br />
The vCalendar object can also be passed as a non-standard MIME media type. This would be useful in order to clearly identify the vCalendar object in an electronic mail message body part. A non-standard, vCalendar object should be identified as the MIME type/subtype "text/x-vCalendar".<br />
<br />
@@ - i have to do some more investigation, but (i think) vCalendar is a subset of iCalendar, so many of the same encodings will work for both, but this document is dealing with iCalendar RFC2445 representation!<br />
<br />
== Button ==<br />
<br />
We need to come up with a nice <code>[ hCal | friendly ]</code> button to indicate that event info on a page/site is using hCalendar. - [http://tantek.com/log/ Tantek].<br />
<br />
Possibilities:<br />
* <code>[ hCal | friendly ]</code><br />
* <code>[ hCal | aware ]</code><br />
* <code>[ hCal | inside ]</code><br />
* <code>[ Valid | hCalendar ]</code> - though that would require writing an hCalendar validator which people could link to.<br />
* <code>[ <icon> | hCalendar ]</code> where <icon> could be some generic calendar looking thing, or it could be a PHP generated image with the actual date in the icon, kind of like how the Apple iCal icon updates in the dock automatically.<br />
<br />
And then we have to pick colors and all that stuff - [http://tantek.com/log/ Tantek].<br />
<br />
Other ideas:<br />
* <code>[ hCal | enabled ]</code><br />
* <code>[ hCal | available ]</code> - kind of an off-hand reference to being available for meetings, etc.<br />
<br />
- [http://meyerweb.com/ Eric]<br />
<br />
== Including More of iCalendar ==<br />
<br />
=== Free/Busy information ===<br />
<br />
See [http://www.ifreebusy.com/cyclical/blog/ Neil Jensen]'s [http://www.ifreebusy.com/cyclical/blog/calendar/3 analysis of how to represent the iCalendar VFREEBUSY object in hCalendar].<br />
<br />
In order to show free/busy information, we could either use the existing vevent class (with empty location, summary, etc. properties) or create a new vfreebusy class. We should create a new vfreebusy class because it is consistent with the XHTML design principles, particularly point #4, "Use class names based on names from the original schema...". <br />
<br />
In the iCalendar standard, the vfreebusy calendar component frequently has more than one freebusy property, and also may have a number of other properties such as organizer. For example:<br />
<br />
<pre><nowiki><br />
BEGIN:VFREEBUSY <br />
ORGANIZER:jsmith@host.com <br />
DTSTART:19980313T141711Z <br />
DTEND:19980410T141711Z <br />
FREEBUSY:19980314T233000Z/19980315T003000Z <br />
FREEBUSY:19980316T153000Z/19980316T163000Z <br />
FREEBUSY:19980318T030000Z/19980318T040000Z <br />
URL:http://www.host.com/calendar/busytime/jsmith.ifb <br />
END:VFREEBUSY<br />
</nowiki></pre><br />
<br />
So, our hCalendar representation should include separate elements for the vfreebusy calendar component (defined once) and the freebusy property (possibly defined many times):<br />
<br />
<pre><nowiki><br />
<span class="vfreebusy"> <br />
<span class="freebusy"> <br />
<abbr class="dtstart" title="20050721T1000-0800"> <br />
July 21, 2005 - 10:00 <br />
</abbr> - <br />
<abbr class="dtend" title="20050721T1100-0800"> <br />
11:00 <br />
</abbr> <br />
</span><br/> <br />
<span class="freebusy"> <br />
<abbr class="dtstart" title="20050722T1000-0800"> <br />
July 22, 2005 - 10:00 <br />
</abbr> - <br />
<abbr class="dtend" title="20050722T1100-0800"> <br />
11:00 <br />
</abbr> <br />
</span><br/> <br />
</span><br />
</nowiki></pre><br />
<br />
According to RFC2445 section 4.8.4.3, "When publishing a "VFREEBUSY" calendar component, the <nowiki>[ORGANIZER]</nowiki> property is used to specify the calendar that the published busy time came from." The organizer property type is CAL-ADDRESS, and can include "non-standard, language, common name and directory entry reference" property parameters. CAL-ADDRESS is "...a URI as defined by [RFC 1738] or any other IANA registered form...".<br />
<br />
From what I've seen, Microsoft Outlook typically populates this property with the email address of the calendar owner, which initially made me think of using hCard to specify the organizer. However, given that the property refers to the calendar and not necessarily the person who owns or has published it, I think we should use a new organizer element, as shown below: <br />
<br />
<pre><nowiki><br />
BEGIN:VFREEBUSY <br />
ORGANIZER:jsmith@host.com <br />
FREEBUSY:20050314T133000Z/20050314T163000Z <br />
END:VFREEBUSY<br />
</nowiki></pre><br />
<br />
becomes<br />
<br />
<pre><nowiki><br />
<span class="vfreebusy"> <br />
organizer: <span class="organizer">jsmith@host.com</span> <br />
<span class="freebusy"> <br />
<abbr class="dtstart" title="20050314T133000Z"> <br />
March 14, 2005 - 13:30 <br />
</abbr> - <br />
<abbr class="dtend" title="20050314T163000Z"> <br />
16:30 <br />
</abbr> <br />
</span><br/> <br />
</span> <br />
</nowiki></pre><br />
<br />
Hmmm, this looks a little funny when the organizer is so obviously an email address, but at least it is semantically correct. The other problem that I can now see occurring is when the organizer property has parameters, for example (from the iCalendar spec):<br />
<br />
<pre><nowiki><br />
ORGANIZER;CN=JohnSmith;DIR="ldap://host.com:6666/o=3DDC%20Associ <br />
ates,c=3DUS??(cn=3DJohn%20Smith)":MAILTO:jsmith@host1.com<br />
</nowiki></pre><br />
<br />
Perhaps it's best to use the same approach described in "Human vs. ISO8601 dates problem solved"; use the abbr element like so:<br />
<br />
<pre><nowiki><br />
<span class="vfreebusy"> <br />
<span class="freebusy"> <br />
organizer: <abbr class="organizer" title="CN=JohnSmith;DIR=ldap://host.com:6666/o=3DDC%20Associ <br />
ates,c=3DUS??(cn=3DJohn%20Smith):MAILTO:jsmith@host1.com">jsmith@host1.com</abbr> <br />
<abbr class="dtstart" title="20050314T133000Z"> <br />
March 14, 2005 - 13:30 <br />
</abbr> - <br />
<abbr class="dtend" title="20050314T163000Z"> <br />
16:30 <br />
</abbr> <br />
</span> <br />
</span><br />
</nowiki></pre><br />
<br />
A different reading, particularly of section 4.6.4 "Free/Busy Component", is that the organizer property refers to a calendar user, not the calendar itself. In that section we find this: "When used to publish busy time, the "ORGANIZER" property specifies the calendar user associated with the published busy time".<br />
<br />
Under this reading, an hCard might be appropriate. But if for some reason a simpler representation is wanted, using an &lt;a&gt; tag instead of &lt;span&gt; or &lt;abbr&gt; is closer semantically, more consistent with expected web presentation of uri-type data, and easily handles the ORGANIZER examples in the RFC. For example:<br />
<br />
<pre><nowiki><br />
ORGANIZER;CN="John Smith":MAILTO:jsmith@host.com<br />
</nowiki></pre><br />
becomes<br />
<pre><nowiki><br />
<a class="organizer" href="mailto:jsmith@host.com">John Smith</a><br />
</nowiki></pre><br />
and<br />
<pre><nowiki><br />
ORGANIZER;CN=JohnSmith;DIR="ldap://host.com:6666/o=3DDC%20Associ <br />
ates,c=3DUS??(cn=3DJohn%20Smith)":MAILTO:jsmith@host1.com<br />
</nowiki></pre><br />
becomes<br />
<pre><nowiki><br />
<a class="organizer" href="mailto:jsmith@host.com" <br />
title="DIR=ldap://host.com:6666/o=3DDC%20Associates,c=3DUS??(cn=3DJohn%20Smith)">John Smith</a><br />
</nowiki></pre><br />
<br />
=== To-Do information ===<br />
<br />
The [http://www.policyawareweb.org/2005/ftf2/paw-mtg Policy Aware Web (PAW) Project Meeting - 23 Aug 2005] uses class="vtodo" to capture action items. Clearly recording action items from a meeting and publishing them as minutes is a good practical example use of the VTODO object on the web. <br />
<br />
What's the scenario for usage though?<br />
<br />
What kind of indexer/aggregator application would find these VTODO items and what would it do with them? <br />
<br />
Perhaps with some way of figuring out who the to-do item is assigned to ("ATTENDEE"), who assigned it ("DELEGATED-FROM"), and a whitelisting of who, perhaps the "ORGANIZER" property, (and their domains/URLs) that a user would accept assignments from, a user could aggregate to-do items assigned from other folks. Then question remains how to update the status ("STATUS") (RFC 2445 4.8.1.11 Status) on that to-do item when it is (a) completed ("COMPLETED"), (b) abandoned/cut/rejected ("CANCELLED"), (c) some progress is made ("IN-PROCESS") etc. There certainly seems to be sufficient expressiveness in VTODO and its properties to do a decentralized to-do list / task distribution system. Could be very interesting for helping open source projects and other distributed teams do project management using the Web.<br />
<br />
== Non-Gregorian Calendars ==<br />
<br />
=== Japanese Calendar ===<br />
<br />
* [http://home.yomiuri.co.jp/wnews/20080711hg03.htm yomiuri] - newspaper<br />
* [http://urakoma.com/bbs.html urakoma.com] - form input<br />
<br />
=== Umm al-Qura (Saudi Arabia) Calendar ===<br />
<br />
* [http://www.sama.gov.sa/ Sama] - Government site<br />
<br />
== References ==<br />
=== Normative References ===<br />
* [http://www.ietf.org/rfc/rfc2445.txt RFC 2445]<br />
* [http://gmpg.org/xmdp/ XMDP]<br />
<br />
=== Informative References ===<br />
* [http://wiki.oreillynet.com/foocamp04/index.cgi?HTMLForCalendars HTMLForCalendars (FOO camp)] - presented just a few days before this, hopefully these efforts can be combine<br />
<br />
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]<br />
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]<br />
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]<br />
* [http://www.ietf.org/rfc/rfc2446.txt iTIP RFC2446]<br />
* [http://www.ietf.org/rfc/rfc2447.txt iMIP RFC2447]<br />
* [http://www.ietf.org/rfc/rfc3283.txt Guide to Internet Calendaring RFC3283]<br />
<br />
== Other Implementations/Ideas ==<br />
* [http://www.nehmer.net/~bergie/openpsa-calendar-horizontal.jpg OpenPSA calendar screenshot]<br />
* [http://www.w3.org/2002/12/cal/ RDF Calendar Workspace] - some older work done with RDF, not really applicable to the simple XHTML case, but perhaps worthy of analysis for when and why they may have diverged from established iCalendar schemas.<br />
* [http://planb.nicecupoftea.org/archives/000072.html 2003 RDF icalendar work, xCal references]<br />
* [http://tools.ietf.org/html/draft-norris-ical-venue-00 vVenue (proposal to add vCard-adr like properties to iCalendar)]<br />
<br />
== Blogs About Calendaring ==<br />
* http://staff.washington.edu/oren/weblog2/<br />
<br />
==Simplification of date-end==<br />
<br />
If ever there is an "hCalendar 2" standard, thought should be given to changing the way dtend is handled, where no hour is specified. Currently, we use:<br />
<br />
:<code><nowiki><abbr class="dtend" title="2007-02-01">31 January 2007</abbr></nowiki></code><br />
<br />
which is counter-intuitive for publishers (as past evidence on [[hcalendar-examples-in-wild|examples in the wild]] and elsewhere [http://rbach.priv.at/Microformats-IRC/2007-03-29#T183612] has shown). In the interests of ''ease of authoring'', we should consider, perhaps with a new property name for clarity, using:<br />
<br />
:<code><nowiki><abbr class="enddate" title="2007-01-31">31 January 2007</abbr></nowiki></code><br />
<br />
and making ''parsers'' responsible for converting to "2007-02-01" when exporting as a vCard. [[User:AndyMabbett|Andy Mabbett]] 05:28, 29 Mar 2007 (PDT)<br />
<br />
== Related Pages ==<br />
{{hcalendar-related-pages}}</div>ScottReynenhttps://microformats.org/wiki/index.php?title=hatom-parsing&diff=31816hatom-parsing2008-04-04T20:26:51Z<p>ScottReynen: added link to parsing</p>
<hr />
<div><h1>hAtom parsing</h1><br />
<br />
'''Work in progress!'''<br />
__TOC__<br />
<br />
<h2>Editor/Author</h2><br />
* [http://theryanking.com/ Ryan King]<br />
<br />
= URL handling =<br />
<br />
An hAtom parser may begin with a URL to retrieve.<br />
<br />
If the URL lacks a fragment identifier, then the parser should parse the entire retrieved resource for hAtom feeds and hAtom entries.<br />
<br />
If the URL has a fragment identifier, then the parser should parse ''only'' the node indicated by the fragment identifier and its descendants, looking for hAtom feeds and hAtom entries, starting with the indicated node, which may itself be a hAtom feed/entry.<br />
<br />
= Finding hAtom feeds/entries =<br />
<br />
* hAtom feeds are identified with the classname <code>hfeed</code><br />
* hAtom entries are identified by the classname <code>hentry</code><br />
* if the document does not contain an element with the class name <code>hfeed</code>, but does contain an element with the classname <code>hentry</code>, the entire document should be treated as a feed<br />
<br />
= Extracting feed elements =<br />
<br />
== Feed &lt;category&gt; ==<br />
<br />
See [[hatom#Feed_Category | hAtom: Feed Category]]<br />
<br />
= Extracting entry elements =<br />
== Entry &lt;link&gt; == <br />
<br />
Use the first [[rel-bookmark]] in the entry.<br />
<br />
== Entry &lt;id&gt; ==<br />
<br />
Use the same value as the [[hatom-parsing#Entry_.3Clink.3E | entry link]].<br />
<br />
== Entry &lt;title&gt; ==<br />
<br />
See [[hatom#Entry_Title | hAtom: Entry Title]]<br />
<br />
== Entry &lt;updated&gt; ==<br />
<br />
See [[hatom#Entry_Updated | hAtom: Entry Updated]]<br />
<br />
== Entry &lt;published&gt; ==<br />
<br />
See [[hatom#Entry_Published | hAtom: Entry Published]]<br />
<br />
<br />
= Extracting tags =<br />
<br />
See [[rel-tag-parsing]] and [[hatom#Entry_Category | hAtom: Entry Category]].<br />
<br />
See [[hatom#Entry_Category | hAtom: Entry Category]].<br />
<br />
= References =<br />
== Normative References ==<br />
* [[hatom|hAtom]]<br />
* [http://w3.org/TR/XHTML1 XHTML 1.0 Recommendation]<br />
* [http://w3.org/TR/html401 HTML 4.01 Recommendation]<br />
<br />
== Informative References ==<br />
* [http://hg.microformats.org/tests test suite] - work in progress!<br />
* [http://microformats.org/wiki/parsing parsing] - general microformat parsing</div>ScottReynenhttps://microformats.org/wiki/index.php?title=User:ScottReynen&diff=21659User:ScottReynen2007-07-14T20:03:59Z<p>ScottReynen: added public domain release</p>
<hr />
<div>email: scott@randomchaos.com<br />
<br />
AIM: imnotscott<br />
<br />
Phone: 515-710-2725<br />
<br />
[http://log.makedatamakesense.com/ Website]<br />
<br />
{{public-domain-release}}</div>ScottReynenhttps://microformats.org/wiki/index.php?title=hcard-brainstorming&diff=18357hcard-brainstorming2007-07-13T15:10:06Z<p>ScottReynen: /* INPUT element handling */ added proposed markup examples</p>
<hr />
<div><h1> hCard Brainstorming </h1><br />
This page is for brainstorming about various uses and details of [[hcard|hCard]].<br />
<br />
__TOC__<br />
<br />
== Authors ==<br />
* [http://suda.co.uk/ Brian Suda]<br />
* [http://tantek.com/log/ Tantek Çelik], [http://technorati.com Technorati, Inc]<br />
<br />
== Contributors ==<br />
* [[User:Atamido|Atamido]]<br />
* [[User:ChrisMessina|ChrisMessina]]<br />
* [[User:DimitriGlazkov|DimitriGlazkov]]<br />
* ...<br />
* ... and many others<br />
<br />
== Problems Being Solved ==<br />
<br />
Some of the problems that [[hcard|hCard]] helps to solve:<br />
<br />
* having to enter business cards that go out of date (subscribe to someone's syndicated [[hcard|hCard]] instead).<br />
* annoying "update your contact info" email from various centralized contact info services<br />
<br />
== FN Nickname semantic ==<br />
<br />
There are many sites (e.g. [http://flickr.com Flickr], [http://consumating.com/ Consumating]) which permit the user to '''both''' have a multi-word login/handle/alias, '''and''' not show their ''real'' name (fn, n, given-name, family-name etc.).<br />
<br />
For the people represented by the profile pages of these sites, the best we can do is mark-up their login/handle/alias as their "nickname". Originally, we had thought that such handles etc. were single words only, and thus we created the [[hcard#Implied_.22nickname.22_Optimization|Implied nickname optimization]] accordingly, where you can markup the handle as an "fn", and have it automatically set a "nickname" property value, and empty values for all the "n" sub-values.<br />
<br />
In order to deal with multi-word handles, similar to the [[hcard#Organization_Contact_Info|hCard Organization contact info]] method, the following is proposed:<br />
<br />
=== "fn" and "nickname" combination ===<br />
<br />
Due to the use of potentially multi-word nicknames/handles/usernames in content published on the Web, (e.g. on sites like [http://flickr.com Flickr] and [http://consumating.com/ Consumating]), hCard has a mechanism for specifying a multi-word "fn" that is also a "nickname" without affecting any "n" sub-properties that are otherwise specified, and explicitly implying empty defaults for "n" sub-properties.<br />
<br />
Similar to the [[hcard#Implied_.22nickname.22_Optimization|implied "nickname" optimization]], if the "fn" property and a "nickname" property have the exact same value (typically because they are set on the same element, e.g. <code>class="fn nickname"</code>), then<br />
<br />
# The content of the "fn" is treated as a "nickname" property value.<br />
# Parsers should handle the missing "n" property by implying empty values for all the "n" sub-properties.<br />
<br />
== Examples ==<br />
<br />
* See [[hcard-examples]], which provides several illustrative instructive examples, as well as 1:1 hCard examples for each example in [http://www.ietf.org/rfc/rfc2426.txt RFC 2426].<br />
<br />
=== Using RFC2806 with hCard ===<br />
<br />
[http://www.ietf.org/rfc/rfc2806.txt RFC 2806] defines the telephone scheme "tel:", "fax:" and "modem:" to handle phone communications with URIs in the same way, "mailto:" is defined for email. It's part of the list or registered schemes by IANA : [http://www.iana.org/assignments/uri-schemes Uniform Resource Identifier (URI) SCHEMES]<br />
<br />
<pre><nowiki><br />
tel telephone [RFC2806]<br />
fax fax [RFC2806]<br />
modem modem [RFC2806]<br />
</nowiki></pre><br />
<br />
It is practical to write your tel number like this.<br />
<br />
<pre><nowiki><br />
<a class="tel" href="tel:+1-919-555-7878">+1-919-555-7878</a><br />
</nowiki></pre><br />
<br />
or even<br />
<br />
<pre><nowiki><br />
<a class="tel" href="tel:+1-919-555-7878">Mr Smith's phone</a><br />
</nowiki></pre><br />
<br />
You can add support for "tel:" to your desktop and to your browser<br />
<br />
* For Gnome, edit ~/.gnome/Gnome and add something to the URL Handlers section. (Dan Connolly uses this to get galeon to launch telnum from [http://dev.w3.org/cvsweb/2001/telagent/ telagent sources] for tel URIs)<br />
* In Mozilla, [http://dizzy.mozdev.org/ Dizzy]<br />
* In Internet Explorer, [http://msdn.microsoft.com/workshop/networking/pluggable/overview/overview.asp Asynchronous Pluggable Protocols]<br />
<br />
On the CSS front… You could for example add automagically an icon. I have put the property !important for those who wants to add it to their own stylesheet in their browsers, so they know type of links when browsing.<br />
<br />
<pre><nowiki><br />
a[href^="tel:"]:before {<br />
content: '\260f ' !important;<br />
padding-left: 20px !important; }<br />
<br />
a[href^="mailto:"]:before {<br />
content: '\2709 ' !important;<br />
padding-left: 20px !important; }<br />
</nowiki></pre><br />
<br />
<br />
<br />
<br />
== Encoding "modern" attributes ==<br />
<br />
Since vCard was first established, various interactive communication technologies and addressing schemes have been widely adopted. Although there aren't specific properties for these technologies / addressing schemes, they can be captured as URLs or email addresses.<br />
<br />
This has now been written up for the most part. See:<br />
<br />
http://microformats.org/wiki/hcard-examples#New_Types_of_Contact_Info<br />
<br />
Still to be addressed:<br />
<br />
* iChat mac.com addresses, simply store "@mac.com" email addresses, e.g.<br />
** <code><nowiki>&lt;a class="email" href="mailto:steve@mac.com"&gt;...</nowiki></code><br />
* MSN Instant Messenger, you can simple store "@hotmail.com" or "@msn.com" or "@passport.com" email addresses.<br />
* Internet Relay Chat (IRC), use "irc:" URLs.<br />
<br />
== Auto-Discovery ==<br />
<br />
=== Representative hCard discovery ===<br />
Ways to auto discover the representative hCard for a page, that is the hCard that means the person/owner of the page. <br />
<br />
Applications for auto-discovery of the representative hCard for the page<br />
* vCard auto extraction from the page<br />
* profile icon discovery (e.g. what people use gravatar for and have proposed pavatar for).<br />
<br />
The preferred option is to use only visible semantic HTML ([[POSH]]). <br />
<br />
Here is a scenario that outlines the proposed auto-discovery process:<br />
<br />
# I (as user) give the URL of my homepage or hCard or other profile URL, to a site that wants a profile icon<br />
# That site goes and gets it (e.g. using hKit), and then:<br />
## checks to see if there is an <nowiki><address></nowiki> hCard, and uses it if it finds it<br />
## otherwise uses the first hCard it finds (which in cases of profile URLs which have a single hCard like on [http://flickr.com Flickr], [http://zooomr.com Zooomr], and [http://technorati.com/ Technorati], will work as expected).<br />
# The site looks in the hCard for a "logo" property and uses the first one if it finds any.<br />
# Otherwise it looks for a "photo" property and uses the first one if it finds any.<br />
# Otherwise the site uses a default icon, but subscribes to the URL with the hCard and checks it for a "logo" or "photo", say, once a day.<br />
<br />
=== vCard link rel auto-discovery ===<br />
<br />
A similar possibility is an auto discovery link in the head of the document could point to a URL (perhaps with transform) to a vCard version of the representative hCard.<br />
<br />
On the page with the hCard encoding, the best link would be as follows:<br />
<code><nowiki> <link rel="alternate" type="text/directory" href="..." /> </nowiki></code><br />
this HTML page is an alternate view of the vCard. <br />
<br />
The [http://www.iana.org/assignments/media-types/text/ registered and appropriate type] for vCard entities is “text/directory”, as defined in Internet RFC 2425, “[http://www.rfc-editor.org/rfc/rfc2425.txt A MIME Content-Type for Directory Information]”. RFC 2426, “[http://www.rfc-editor.org/rfc/rfc2425.txt vCard MIME Directory Profile]”, specifies the vCard profile for “text/directory” entities, which profile the MIME/HTTP header field “Content-Type” would indicate with a “profile” parameter whose value is “VCARD”. <br />
<br />
It is unclear whether the HTML/XHTML “type” attribute allows values with parameters. On 2004-05-23, [http://bjoern.hoehrmann.de/ Björn Höhrmann] sent to the [http://www.w3.org/2002/05/html/charter HTML Working Group] a [http://www.w3.org/mid/40ccdc4d.97400945@smtp.bjoern.hoehrmann.de request for clarification] on the issue.<br />
<br />
When on a different page, referencing that encoded page in the href would ''not'' be an alternate view of the current page. Therefore rel="alternate" may not be appropriate. The problem of what rel value to use is bigger than links to vCards.<br />
<br />
=== hCard to hCard relationships ===<br />
<br />
There are several types of hCard to hCard relationships, that is, one hCard hyperlinking to another hCard which would beneift from the explicit rel values that described the specific relationship.<br />
<br />
==== mini hCard to expanded hCard ====<br />
<br />
Perhaps the most common type of hCard to hCard link is a mini hCard, e.g. from a personal home page or blog to the person's contact/about page, perhaps consisting of only a name and URL, that links to an expanded hCard. Examples in the wild:<br />
<br />
In this instance, possible rel values might include:<br />
* rel="expanded"<br />
* rel="definitive" - the problem with this is that the expanded hCard is not necessarily a definitive version.<br />
* rel="canonical" - similarly, the expanded hCard is not necessarily at a canonical URL. It may simply be *an* expanded version, not *the* expanded version.<br />
<br />
The following rel values have been suggested, but are not really a good idea due to the fact that they imply a dependence to add a new rel value for any new microformat which might have a mini-version linking to a more expanded version: <br />
* rel="author"<br />
* rel='contact'<br />
* rel="contactinfo"<br />
* rel='hcard'<br />
* rel='person'<br />
<br />
Here are some more generic values that have been suggested which perhaps make even less sense:<br />
* rel='microformat' - this doesn't make any sense when you imagine a world where nearly every web page contains microformats.<br />
* rel='about' - what does "about" have to do with a person or even authorship?<br />
* rel="profile" - should be reserved for meaning here is an [[xmdp|XMDP]] profile for the current page.<br />
* rel='PIM' - not sure about how this makes any sense either.<br />
<br />
==== mini hCard to remote site ====<br />
Per the instructions in [[hcard-examples]] for [[hcard-examples#References_to_People_in_Blogrolls|marking up people in blogrolls]], you might have an hCard of your site for another person which then links to that other person's website. Should there be a rel value that indicates this "mini-hCard" to "person" relationship?<br />
<br />
==== mini hCards and nearby expanded hCard links ====<br />
Some authors include mini-hCards on their pages of themselves (e.g. in their blog posts), and yet those mini-hCards don't actually point to more expanded versions. However, sometimes they have a separate but nearby link on the same page like "about" or "contact" that does link to an expanded hCard.<br />
<br />
E.g. on [http://factoryjoe.com/blog/ FactoryCity], blog posts have mini-hCards for "published by", e.g. (white space added for readability):<br />
<pre><nowiki><br />
Published by <br />
<span class="vcard author"><br />
<a href="http://factoryjoe.com/blog/author/factoryjoe/" class="url fn"><br />
Chris Messina<br />
</a><br />
</span><br />
</nowiki></pre><br />
<br />
On those same blog pages, there is a link labeled "Contact Information" that links to http://factoryjoe.com/blog/hcard/ which has an hCard with more information like phone number, birthday etc.<br />
<br />
<br />
=== Auto-Discovery for XFN ===<br />
<br />
An author will typically their XFN information on a specific page, rather than all pages. In particular, a specific page separate from the home page of their blog, and thus it would be useful to have an explicit rel value to assist in auto-discovery of XFN information.<br />
<br />
This was suggested by Jens Alfke on 20050606 at the WWDC blogger's dinner.<br />
<br />
== geo improvements ==<br />
''See [[geo-brainstorming]]''<br />
<br />
== Other use cases ==<br />
*calculate and display the subject's age "as of today".<br />
*calculate and display the subject's age at death (if a Date of Death is available)<br />
*Generate an recurring iCal for a living subject's birthday<br />
*Generate an recurring iCal for a dead subject's "anniversary of birth" (if a Date of Death is available)<br />
<br />
== Issues with vCard Applications ==<br />
See [[vcard-implementations]].<br />
<br />
== Open Questions ==<br />
<br />
Q: since many of the components would be using CSS classes for encoding data, it is possible to MIX two different profiles. (e.g. hCard and XFN) There are no real constraints on where/how to enforce class names, these are based on the html profile, since it is difficult to associate the text within the attribute to a specific profile. <br />
<br />
<pre><nowiki><br />
...<br />
<a href="mailto:joe.smith@example.com" class="fn" rel="met">Joe Smith</a><br />
...<br />
</nowiki></pre><br />
<br />
-- [http://suda.co.uk/ Brian Suda]<br />
<br />
Q: Preserving White space? Should the transforming applications preserve extra white space characters? For example:<br />
<pre><nowiki><br />
<a href="http://mywebsite.com/" class="fn n"><br />
<span class="given-name">John</span><br />
<span class="other-names">Q.</span><br />
<span class="family-name">Public</span><br />
</a><br />
</nowiki></pre><br />
<br />
When transformed into a vCard, the N property will pick apart the span tags and create the value for N correctly seperated by colons. The FN property will take a string and simply display it. There are two possible renderings for FN:<br />
<pre><nowiki><br />
John Q. Public<br />
<br />
John<br />
Q.<br />
Public<br />
</nowiki></pre><br />
<br />
Either the white-space is preserved or it is not. Which should the transforming applications render?<br />
<br />
-- [http://suda.co.uk/ Brian Suda]<br />
<br />
A: The parsing application should follow the white space collapsing rules of the mime type it retrieves. I.e. if it retrieves a "text/html" document, it should do HTML white space collapsing.<br />
<br />
-- [http://tantek.com/log/ Tantek]<br />
<br />
Many of the Questions and Answers are relevant to both ["hCal"] and hCard.<br />
<br />
Q: Would it be appropriate to wrap the name of the vCard owner with <dfn/>? This may give the hCard some added semantic value in the XHTML document.<br />
<pre><nowiki><br />
<span class="agent"> <br />
<span class="vcard"><br />
<span class="email"><br />
<a class="internet" href="mailto:jfriday@host.com"><br />
<dfn><br />
<span class="fn">Joe Friday</span><br />
</dfn><br />
</a><br />
</span><br />
<span class="tel">+1-919-555-7878</span><br />
<span class="title">Area Administrator, Assistant</span><br />
</span><br />
</span><br />
</nowiki></pre><br />
-- [http://www.ben-ward.co.uk/ Ben Ward]<br />
<br />
== Applications ==<br />
Applications that are hCard aware or can convert hCard to vCard formats.<br />
<br />
=== Copy hCards favelet(s) ===<br />
* I think a Favelet would work nicely here. When you find a page that is hCard friendly, you click the favlet and you get yourself a vCard. This is done! See X2V in the implementations section of the [[hcard|hCard]] spec.<br />
<br />
=== Distributed Commentor Icons ===<br />
<br />
* See [http://thedredge.org/2005/06/using-hcards-in-your-blog/ using hCards in your blog] for an example of hCards used for comment authors (commentors). The system used there, "Gravatars", is a centralized site that serves commentor icons that requires login etc. <br />
<br />
What if we gave each commentor the option of hosting their own icon?<br />
<br />
A distributed commentor icon implementation could work like this:<br />
<br />
# Given the URL of a commentor, look for an <code><address></code> element with classname of "vcard" at the commentor's URL. The <code><address></code> element is supposed to be the contact information for the page (see [[hcard-faq|hCard FAQ]] for more info), so this makes sense.<br />
# Next, look for the first element inside that hcard that has a classname of "logo".<br />
# Hopefully that element is an <code><img></code>, and if so, use its src to get the commentor's icon.<br />
# Presto. You've got distributed commentor icons!<br />
<br />
== Spam prevention ==<br />
hCard uses <code>mailto:</code> links, and therefore<br />
it automatically "inherits" the disadvantage of <code>mailto:</code> links:<br />
These links can be easily detected by emails spiders (used by spammers).<br />
<br />
Email addresses are picked up like any other link crawled by a search engine and trustworthy crawlers may be deterred from adding emphasis while indexing these links by including rel="nofollow" (See [[rel-nofollow]]). However, email addresses used for spam are crawled by email spiders which will likely ignore this attribute.<br />
<br />
There are ways to prevent email address detection by simple email spiders, while<br />
still retaining full compatibility with (X)HTML applications.<br />
One common way is to "encode" the the "m" of "mail" and "@" with character entities, yet it's unwise to follow a convention of only encoding specific characters because the email spiders can pick up on this too:<br />
<br />
Example of the original link:<br />
<pre><nowiki><br />
<a class="email" href="mailto:john.smith@example.com">john.smith@example.com</a> <br />
</nowiki></pre><br />
<br />
Example of the "encoded" link (with rel-nofollow added):<br />
<pre><nowiki><br />
<a class="e&amp;#109;ail" rel="nofollow" href="&amp;#109;ailto:john.smith&amp;#064;example.com">john.smith&amp;#064;example.com</a><br />
</nowiki></pre><br />
<br />
Simple email spiders which do not do character entity decoding will therefore not be able to find your email address.<br />
<br />
''Note:'' Perhaps there are or will be email spiders which can decode entities, so the this technique will only help with some (cheap) email spiders.<br />
(See also: http://rbach.priv.at/Misc/2005/EmailSpiderTest)<br />
<br />
=== Other prevention methods to consider ===<br />
* Using server-side code to implement character entities randomly<br />
* Displaying the address in a way thought to be only human readable (thus breaking the link):<br />
** Using an image instead of text (could still be machine readable using OCR)<br />
** Using human readable text that conveys the need for editing before use (eg PLEASE-NO-SPAM_name@example_NO-SPAM.com)<br />
* Using javascript for client-side decryption of an encrypted address (requires javascript to be enabled)<br />
* Pointing to an email form or other URL instead of an email address<br />
<br />
== Tutorials ==<br />
* How to hCard encode entries in Popular blog software.<br />
* Good reasons to publish your hCard<br />
** as a business, get people to put you in their address book so they'll find you later<br />
** as a business with an email list, get people to add you (with email address) to their address book so that your email list works via whitelisting via the address book.<br />
<br />
== Parsing ==<br />
See separate [[hcard-parsing|hCard parsing]] page for current hCard parsing rules.<br />
<br />
Add thoughts/proposals to improve/add to hCard parsing here in this section in hCard brainstorming, and be sure to include URLs to examples of hCards in the wild which could benefit from parsing rule changes.<br />
<br />
* Multiple Type parsing / Type Optimization: The spec allows for, and the [[hcard-authoring#Phone_Numbers|hcard-authoring]] demonstrate the use of multiple type designations for a single value of tel. The syntax used in the authoring examples where each seems like it could become cumbersome. As these type designations are all single 'word' strings it may be possible to implement additional parsing rules to allow for multiple types inside the same HTML element. Handling delimiters may be an issue [space, comma, etc?], and some in-the-wild usage of multiple types would need to be located and examined before considering additional parsing rules along these lines [ [[User:ChrisCasciano|ChrisCasciano]] 10:21, 16 Apr 2007 (PDT) ]<br />
*Parsers could calculate the current age of hCard subjects, from the DoB. [[User:AndyMabbett|Andy Mabbett]] 07:47, 20 Apr 2007 (PDT)<br />
*for hCards with DoB, parsers could generate and export a recurring hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:06, 20 Apr 2007 (PDT)<br />
**If/ when date-of-death is added to hCard, parsers could instead generate a recurring "death-anniversary" hCalendar. [[User:AndyMabbett|Andy Mabbett]] 08:08, 20 Apr 2007 (PDT)<br />
* ...<br />
<br />
=== fax and modem hyperlink parsing ===<br />
For the "tel" property in particular, when the element is:<br />
* <code>&lt;a href="fax:..."&gt;</code> OR <code>&lt;area href="fax:..."&gt;</code> : parse the value of the 'href' attribute, omitting the "fax:" prefix and any "?" query suffix (if present), in the attribute. For details on the "fax:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "fax" in addition to any explicit subproperty type specified on the 'tel' property.<br />
* <code>&lt;a href="modem:..."&gt;</code> OR <code>&lt;area href="modem:..."&gt;</code> : parse the value of the 'href' attribute, omitting the "modem:" prefix and any "?" query suffix (if present), in the attribute. For details on the "modem:" URL scheme, see RFC 2806. In addition, treat this 'tel' property instance as having subproperty type "modem" in addition to any explicit subproperty type specified on the 'tel' property.<br />
<br />
== Post vCard additions ==<br />
<br />
Keeping hCard properties and values as a 1:1 representation of vCard properties and values has numerous benefits such as simplicity, stability, interoperability with the vast number of existing vCard applications etc.<br />
<br />
However some have found vCard to be limiting in terms of the data/properties/fields they want to express in contact information. Some implementations use vCard extensions to express such information [citation needed].<br />
<br />
This section is for documentation of such suggested additions. Empirical evidence of actual *real world* examples on the Web of people publishing this information would be a good step towards considering any such additions/extensions.<br />
<br />
* '''altitude'''. From [[hcard-issues]].<br />
** Used by Wikipedia e.g. [http://en.wikipedia.org/wiki/Avers Avers]; [http://en.wikipedia.org/wiki/List_of_volcanoes_in_Argentina volcanoes in Argentina]<br />
**Used (as "height") by PoI66 in GPS tracks, e.g [http://www.poi66.com/maps/show_earth.php?album=wip&lat=35.58756&lon=27.06803&extent=0.1&title=Beach%20van%20Lefkos%20]<br />
**Used by Great Circle Mapper, e.g [http://gc.kls2.com/airport/BHX BHX]<br />
**Used by UK Govt. Met Office (as "AMSL" = height Above Mean Sea Level) e.g. [http://www.metoffice.gov.uk/climate/uk/averages/19611990/sites/penkridge.html Penkridge Weather station]<br />
**See also [[geo-elevation-examples]]<br />
* '''vat-number''' : for VAT numbers of companies, which are used a lot in Europe and they need to be published on Belgian publications (including websites).<br />
* '''gender''' <br />
**most social network sites (see [[profile-examples]]) publish the gender of the individual<br />
**Many pages publish implicit gender information, not easily machine parsable - using names (Andrew, Andrea), titles (Mr, Mrs, Miss), relationships (husband, brother), pronouns (he, she), etc. See also [[genealogy-brainstorming]]<br />
* '''date-of-death'''<br />
**Used by Wikipedia e.g. [http://en.wikipedia.org/wiki/John_Bonham John Bonham]<br />
**Used in obituaries, e.g [http://www.westmidlandbirdclub.com/obituaries/norris.htm Tony Norris (WMBC)]; [http://www.guardian.co.uk/obituaries/story/0,,1725211,00.html Ivor Cutler (Guardian)]; [http://www.britarch.ac.uk/BA/ba8/ba8obit.html Grahame Clark (British Archaeology)]<br />
**Used in grave indices e.g. [http://www.findagrave.com/cgi-bin/fg.cgi?page=gr&GRid=676 Chico Marx]<br />
**Used on war memorial pages [http://tinyurl.com/2ddlvq Captain Ronald Wilkinson]<br />
**Used in biographies e.g. [http://www.oxforddnb.com/public/lotw/6.html Oxford National Dictionary of Biography]<br />
Of course if vCard were extended itself, that may provide impetus to add such extensions to hCard in order to maintain the 1:1 representation of properties/values.<br />
<br />
Thus see (and add to): [[vcard-suggestions]]<br />
<br />
Another path to consider is the development of another microformat which includes an hCard and then extends it with additional properties for a particular domain. In many ways [[hresume|hResume]] has already done this. Other related efforts:<br />
* [[genealogy]]<br />
* [[profile]]<br />
<br />
Using hCard as a stable building block for additional microformats may seem more desirable than incrementally growing hCard itself.<br />
<br />
==Wikipedia's Persondata==<br />
Wikipedia's [http://en.wikipedia.org/wiki/Wikipedia:Persondata Persondata] aligns very closely with hCard, but has additional date and place of birth & death fields. [[User:AndyMabbett|Andy Mabbett]] 13:02, 28 Jan 2007 (PST)<br />
<br />
== TODO ==<br />
<br />
* The [[hcard-profile]] needs verification and perhaps a URL for retrieving the actual XMDP, rather than as &lt;pre&gt; text on a wiki page.<br />
* Complete translating the examples from the vCard spec into hCard, and place them on a separate hCard examples page.<br />
* Create a "rich" but realistic hCard example, say for example for a salesperson, who wants to put a whole bunch of contact information on their website in order to be found/contacted easily.<br />
* Provide examples of how to encode instant messaging (IM) accounts. Figure out what would the mailto: or aim: URL in hCard look like in vCard. And take a look at what vCard applications do today with IM addresses.<br />
<br />
<br />
== CSS Styles ==<br />
Not only can you create semantics with the hCard values, but you can add CSS styles to them as well. You are free to style the terms in any way you want, but here we can list a few ideas for how to style terms.<br />
<br />
If you want to encode hCard data, but do NOT want to display it in the HTML code (WARNING: This is very much recommended AGAINST, and in general against the microformat principle of marking up visible data), then you can hide that tag in CSS with the following code:<br />
<pre><nowiki><br />
<span style="display: none">Hidden Data</span><br />
</nowiki></pre><br />
Transforming applications will still find the data and use it when converting hCards to vCards.<br />
<br />
<br />
== Other Implementations/Ideas ==<br />
* [http://www.w3.org/TR/2001/NOTE-vcard-rdf-20010222/ Representing vCard Objects in RDF/XML] This could allow conversion of vCard data from XHTML to RDF and from RDF to XHTML<br />
* It would also be possible to convert XFN and hCard to FoaF.<br />
<br />
== Additional Parsing Improvements ==<br />
=== Ambiguous name components ===<br />
<br />
When automatically publishing hCards from pre-existing data, it's not necessarily possible to tell which words in a name map to which hCard properties. When the structure of a name is unknown, it is hard to ensure an automatically published hCard remains valid.<br />
<br />
There's currently no easy answer to this.<br />
<br />
One implementation suggestion is a 'best-guess' algorithm, something along the lines of:<br />
<br />
# If the name is one word, attempt [[hcard#Implied_.22nickname.22_Optimization|implied nickname optimization]]<br />
# If the name is two words, attempt [[hcard#Implied_.22n.22_Optimization|implied n optimization]]<br />
# For three or more words<br />
## Perform a lookup against known sub-name combinations (e.g. 'Sarah Jane', 'Vander Wal')<br />
## Apply the grammar "given-name additional-name(s) family-name"<br />
<br />
The principal behind this suggestion is that it's better to make a good guess and potentially miscategorize an ambiguous name component than to generate an invalid hCard.<br />
<br />
===ADR with no children===<br />
Parsers (Operator, Tails, Almost Universal Microformat Parser) currently expect <code>adr</code> to have one or more sub-properties. It is not clear from the hCard spec that that's mandatory (though the vCard RFC requires it); nor is it always possible for an address field in a templated (or CMS) web site to be defined with such granularity. <br />
<br />
Consider Wikipedia, whose templates often have a "locale" or "place" field, used, for example, on these articles about railway stations:<br />
<br />
*[http://en.wikipedia.org/wiki/Old_Street_station Old Street]<br />
**"Place" ("locale" in the template) is a '''street'''<br />
*[http://en.wikipedia.org/wiki/Hamstead_railway_station Hamstead]<br />
**"Place" is a '''local district'''<br />
*[http://en.wikipedia.org/wiki/Inverness_railway_station Inverness]<br />
**"Place" is a '''city'''<br />
<br />
Likewise, the Wikipedia template for organisations, in which a "headquarters" address (for a business, for example) may contain a full or partial postal address, or just a city/county or city/country pair: <br />
<br />
*[http://en.wikipedia.org/wiki/Tesco Tesco]<br />
*[http://en.wikipedia.org/wiki/BP BP]<br />
*[http://en.wikipedia.org/wiki/Google Google]<br />
*[http://en.wikipedia.org/wiki/Blue_Coat_Systems Blue Coat Systems]<br />
<br />
I propose that, where <code>adr</code> has content, but no explicit sub-properties, there should be a default sub-property to which that content is allocated, in order that it is captured by user agents, and can later be manually tweaked (in, say, an address book programme) by users if so desired. This would satisfy the vCard requirement for child-of-adr, and adhere to the general principle to "[[be-strict|be strict in what you send but generous in what you receive]]". <br />
*Note that there may be other reasons to consider this suggestion, such as "ease of authoring". Another way of looking at this suggestion is as a "adr/extended-address shorthand". [[User:Tantek|Tantek]] 08:28, 26 Mar 2007 (PDT)<br />
<br />
* there is also a LABEL property which is NOT structured data, but purely a text string to be used when labeling. LABEL purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents. [[User:Brian|Brian]] 13:18, 30 Mar 2007 (UTC)<br />
**On re-reading this, it seems that none of the adressess given in my examples meet the criteria of being "''formatted text corresponding to delivery address''". [[User:AndyMabbett|Andy Mabbett]] 03:35, 17 Apr 2007 (PDT)<br />
<br />
Of the available sub-property options:<br />
<br />
*street-address<br />
*extended-address<br />
*region<br />
*locality<br />
<br />
I suggest that "extended-address" is the most sensible sub-property to use, for this purpose. [[User:AndyMabbett|Andy Mabbett]] 03:57, 26 Mar 2007 (PDT)<br />
<br />
=== INPUT element handling ===<br />
<br />
In [[hcard-parsing]], I've defined special-case handling for several elements according to [[hcard-parsing#more_semantic_exceptions|more semantic exceptions]], e.g. textual properties on the IMG element use the 'alt' attribute.<br />
<br />
One element I forgot at the time was the INPUT element, specifically, <nowiki><input type="text"></nowiki>.<br />
<br />
The simple suggestion is to add the following to [[hcard-parsing]], specifically to the [[hcard-parsing#all_properties|all properties]] sub-section:<br />
<br />
* <code>&lt;input type="text" value="..."&gt;</code>: use the value of the 'value' attribute. If there is no 'value' attribute then treat the value as empty.<br />
<br />
[[User:Tantek|Tantek]]<br />
<br />
==== Background discussion: ====<br />
<br />
Key threads:<br />
* http://microformats.org/discuss/mail/microformats-discuss/2006-September/005951.html<br />
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006132.html<br />
* http://microformats.org/discuss/mail/microformats-discuss/2007-January/008312.html<br />
<br />
<br />
Somewhat related:<br />
* http://microformats.org/wiki/rest/forms-brainstorming <br />
* http://microformats.org/wiki/rest/forms-examples<br />
<br />
One key summary:<br />
* http://microformats.org/discuss/mail/microformats-discuss/2006-October/006172.html <br />
<br />
The options discussed in a hypothetical hCard input system so far appear to be:<br />
<br />
1) create a new root class other than vcard to indicate a form that's<br />
fillable with hCard data.<br />
<br />
Proposed markup:<br />
<br />
<pre><nowiki><br />
<form class="vcard-input" ...><br />
<fieldset class="fn"><br />
<input type="text" class="given-name" name="first_name" /><br />
<input type="text" class="family-name" name="last_name" /><br />
</fieldset><br />
...<br />
</form><br />
</nowiki></pre><br />
<br />
Benefits:<br />
Doesn't overcomplicate hCard with new parsing rules,<br />
doesn't require rewrite of existing parsers to ignore 'unparsable' data.<br />
Drawbacks:<br />
Requires completely new parsers to be written.<br />
Existing parsers would ignore data even if a valid hCard could be extracted.<br />
<br />
2) extend hCard's parsing rules to cover form elements and relying on<br />
the FORM/INPUT semantics to indicate that stuff is inputtable.<br />
<br />
Proposed markup:<br />
<br />
<pre><nowiki><br />
<form class="vcard" ...><br />
<fieldset class="fn"><br />
<input type="text" class="given-name" name="first_name" /><br />
<input type="text" class="family-name" name="last_name" /><br />
</fieldset><br />
...<br />
</form><br />
</nowiki></pre><br />
<br />
Benefits:<br />
Small addition to existing format rather than new one.<br />
Semantics of an input form and the eventual display format are the same.<br />
Drawbacks:<br />
Existing parsers would/could parse forms as invalid hCards, would need re-writing.<br />
<br />
<br />
Broader question:<br />
* http://microformats.org/discuss/mail/microformats-discuss/2005-September/001059.html<br />
Should this be extended beyond just hCard?<br />
<br />
<br />
==== Key Issues/discussion points ====<br />
* Extending parsing rules to extract value attributes from <input type="text|hidden"> fields<br />
- ''Negative'' : this require re-coding the existing parsers<br />
- ''Positive'' : this could help to enable uf based auto form filling<br />
- ''Negative'' : this could help to enable uf based auto form filling (e.g. spam automation)<br />
* Existing server side and client side scripts use non-hCard field names so class is the most seamless extension point<br />
- ''Positive'' : this is in line with the current parsing model<br />
* Many parsers (e.g. operator) parse the loaded html not the dynamic DOM<br />
- ''Negative'' : parser doesn't pickup any updated form data after the page has loaded<br />
- e.g. even though textarea appears to parse ok - it's only ever the initially loaded value that can be exported<br />
* Forms may contain more than one hCard so using <FORM class="vcard"> should not be required<br />
- ''Positive'' : this minimises the changes to current parsing rules<br />
* Empty values should be ignored when extracting hCards<br />
* hCards with all empty values should be ignored when listing/extracting hCards<br />
* Which form elements should be supported beyond input fields<br />
- ''Examples''<br />
- title select that lists mr/mrs/ms/dr/etc.<br />
- checkboxes to choose which addresses to use<br />
- ''Option'' : simplify extension to only support input fields and recommend that select's, radio buttons and checkboxes update related hidden input fields with simple javascript (e.g. onChange/Click="this.form.elements[this.className].value = this.value")<br />
- ''Positive'' : this would simplify parsing and server side form processing as only single input fields for each value need to be used/validated<br />
- ''Negative'' : hCard forms then require javascript if they use form elements other than basic <input type="text|hidden"><br />
- ''Comment'' : either way any auto form filling will be more complex beyond simple <input type="text|hidden"> fields<br />
<br />
<br />
<br />
[[User:RobManson|RobManson]]<br />
<br />
== Accepted Suggestions ==<br />
<br />
=== Encoding Company data as a Business Card (proposal) ===<br />
<br />
( Accepted: http://microformats.org/wiki/hcard#Organization_Contact_Info )<br />
<br />
In the wild there are several hCards that do not currently validate because they are businesses that have omitted the "fn" property in favor of the "org" property.<br />
<br />
Proposal: hCards representing a business or organization MUST set fn AND org to the same value. Parsers may then use this equivalence, if detected, to treat an hCard as the contact info for a business or organization rather than an individual.<br />
<br />
Note that [http://microformats.org/wiki/vcard-implementations#organization_vs._individual Apple Address Book supports this semantic when importing vCards].<br />
<br />
See the [http://technorati.com/about/contact.html Technorati Contact Info] for an example.<br />
<br />
=== Implied "FN and N" Optimization (proposal) ===<br />
<br />
Right now a parser first looks for an "n" element.<br />
<br />
And then if no "n" is present, look for an "fn" element to use to imply an "n" element per the "implied n property" rules in the spec.<br />
<br />
BACKGROUND:<br />
<br />
Due to the prevalence of the use of "nicknames" or "handles" on the Web, in actual content published on the Web (e.g. authors of reviews), there has been a discussion about adding a "fn" shortcut to the "n" shortcut that used the "nickname" as a fallback.<br />
<br />
PROPOSAL:<br />
<br />
We should consider adding one more implied optimization after the steps documented above and that is:<br />
<br />
If no "fn" is present either, then look for a "nickname" element to use to imply both the "fn", and the "n/given-name", leaving the "n/family-name" as empty.<br />
<br />
This would enable "nickname" only hCards for denoting and individual on a website, which is quite common on blogs and reviews published on the Web.<br />
* +1 [[User:Atamido|Atamido]]<br />
* +1 [[User:ChrisMessina|ChrisMessina]] - note: multiple alternate nicknames should also be allowed<br />
* +1 [[User:DimitriGlazkov|DimitriGlazkov]]<br />
<br />
<br />
== Rejected Suggestions ==<br />
<br />
Suggestion: ''The use of class="url" on an <a> tag to represent an hCard URL property is redundant. By virtue of the <a> tag you know this is a URL.''<br />
<br />
Rejected. This is a bad suggestion because although it appears to reduce redunancy and keep things cleaner, it also creates a few problems. Without explicitly noting that this is a URL then any <a> tags within a 'vcard' would be considered a URL, for example:<br />
<pre><nowiki><br />
<span class="vcard"><br />
...<br />
<ul class="categories"><br />
<li><a href="http://w3c.org">W3C</a></li><br />
</ul><br />
...<br />
</span><br />
</nowiki></pre><br />
<br />
There is no way to "turn-off" the encoding of the W3C URL, whereas if "url" needed to be explicitly listed in the class attribute list, then by NOT listing it you could effectively turn it off.<br />
<br />
== References ==<br />
=== Normative References ===<br />
* [http://www.ietf.org/rfc/rfc2426.txt RFC 2426] vCard RFC<br />
* [http://www.ietf.org/rfc/rfc2397 RFC 2397] data URI RFC<br />
* [http://gmpg.org/xmdp/ XMDP]<br />
=== Informative References ===<br />
* [http://www.imc.org/pdi/ Personal Data Interchange (PDI) at the Internet Mail Consortium]<br />
* [http://tantek.com/log/2004/07.html#d27t1049 Markup language design notes]<br />
* [http://tantek.com/log/2002/12.html#L20021216t2238 A Touch of Class]<br />
* [http://www.icao.int/mrtd/download/technical.cfm ICAO - Machine Readable Travel Documents format]<br />
<br />
== Related Pages ==<br />
{{hcard-related-pages}}</div>ScottReynenhttps://microformats.org/wiki/index.php?title=definition-feedback-fr&diff=31866definition-feedback-fr2007-07-09T21:00:29Z<p>ScottReynen: Reverting SPAM</p>
<hr />
<div><h1>réactions sur les définitions</h1><br />
<br />
Réactions, questions, commentaires et critiques des définitions des microformats, à la fois sur le [http://microformats.org/ site web] et sur la page wiki [[what-are-microformats-fr|que sont les microformats]].<br />
<br />
== Joe Andrieu ==<br />
<blockquote style="font-size:larger;"><p>Conçus d'abord pour les humains et ensuite pour les machines, les microformats sont un ensemble de formats de données simples et ouverts construits sur (X)HTML et CSS.</p><br />
<br />
<p>L'argumentaire actuel me laisse penser "Mais <strong>que</strong> sont-ils ?". Je me souviens de cette impression de la première lecture dans le wiki des microformats. La [http://microformateurs.org/about page A propos] continue à partir de l'argumentaire d'ouverture pour déclarer ce que sont les microformats, ce que les microformats ne sont pas et les principes des microformats.</p><br />
<br />
<p>Toutes des descriptions géniales... A cette heure qui me laisse penser au niveau le plus basique de concrétisation : <strong>Que sont-ils ?</strong> Des librairies Javascript ? Un vocabulaire XML ? des outils PHP ? Le langage le plus spécifique est "format de donnée standard." Est-ce comme HTML ? Est-ce simplement une RFC pour le prochain truc web ?</p><br />
<br />
<p>Bien sûr, je connais les réponses désormais. Mais cela m'a pris un moment pour y parvenir.</p><br />
<br />
<p>Cette suggestion tente de concrétiser les "standards existants et largement adoptés". C'est un peu plus court et à mes yeux un peu plus clair et plus puissant.</p><br />
</blockquote><br />
<br />
== Extrait du Wiki ==<br />
Il existe quelques fautes perturbantes avec les définitions et les explications données. Les écrits semblent être un cri de ralliement pour les partisans - tournures intelligentes, groupes nominaux impressionnants. Mais cela n'explique rien à ceux qui ne sont pas familiers avec les microformats. Imaginez donner ce type d'explication à l'oral : "Un Microformat ? Que voulez-vous dire ?" vous demande t'on. "Bien," l'autre répond pendant qu'il bondit sur la table la plus proche, sa voix excitée et explosive, une foule se rassemblant autour de lui : <br />
<br />
<blockquote style="font-style:italic"><br />
Conçus tout d'abord pour les humains et ensuite pour les machines, les microformats sont un ensemble de formats de données simples et ouverts construits sur des standards existants et massivement adoptés. Au lieu de jeter ce qui fonctionne aujourd'hui, les microformats ont pour intention à résoudre en priorité les problèmes les plus simples en s'adaptant aux comportements humains et aux modèles d'utilisation (par ex. XHTML, blog). [...]<br />
</blockquote><br />
<br />
Ah, je vois maintenant. Ainsi, c'est quelque chose à utiliser pour les personnes. Quelque chose de simple et intutif, comme un volant. Quelque chose d'ouvert, facilement modifiable par quiconque, comme un wiki ou linux. Un format de donnée, comme rtf, xml, ou pdf. Cela obéit à des standards non spécifiés, mais c'est tellement plus ! C'est basé sur quelque chose qui fonctionne déjà. Cela n'essaye pas de résoudre tout ce qui n'a pas besoin de l'être. Cela change dynamiquement pour s'adapter à la façon dont je me comporte en ce moment... Oui. Oui ! C'est ce dont j'ai besoin ! Mon interface-utilisateur/machine en texte vivante fondée sur un flux DOM ne sera jamais la même, maintenant que j'ai les microformats ! Je me trompe... non ?<br />
<br />
<blockquote style="font-size:larger;"><br />
Les Microformats sont des conventions pour baliser des données couramment rencontrées (comme des liens, de l'information de contact et des événements calendaires) dans des langages établis comme le HTML. En utilisant des structures standardisées, des noms de classes et des valeurs d'attribut, l'information devient plus accessible et plus utile tant pour les humains que les ordinateurs.<br />
</blockquote><br />
<br />
J'apprécierais si quelqu'un copiait cela sur la liste de diffusion, parce que je ne souhaite pas m'enregistrer, mais j'aimerais que cela puisse être remédié. [[User:M|M]] 23:52, 23 août 2006 (PDT)<br />
<br />
<br />
== Richard Quick ==<br />
Ceci n'est pas une définition des microformats, c'est plus une explication...<br />
<br />
<blockquote style="font-size:larger;">Chaque page web contient de l'information. La plupart des sites web ont une page contact, avec un numéro de téléphone, une adresse email et probablement une adresse avec la rue. D'autres ont des critiques de produits, de livres ou de CDs.</blockquote><br />
<br />
<blockquote style="font-size:larger;">Les microformats sont une manière d'étiqueter certaines informations, comme les détails du contact ou les critiques, de façon que cela puisse être facilement extrait de votre page web par un programme informatique adapté ou une application basée sur le web.</blockquote><br />
<br />
<blockquote style="font-size:larger;">Bien que les microformats existent pour faciliter aux ordinateurs l'extraction d'informations provenant de pages web, ils ont été conçus pour être faciles à utiliser par les personnes. Par exemple, beaucoup de microformats impliquent simplement l'ajout de certains noms de classes à une balise HTML (d'autres par exemple utilisent les attributs rel).</blockquote><br />
<br />
<blockquote style="font-size:larger;">Si une page web utilise le HTML à part, il est très difficile (voire même impossible dans certains cas) d'écrire une programme informatique qui puisse examiner la page web, déterminer quel type d'information est sur la page et extraire cette information.</blockquote><br />
<br />
<blockquote style="font-size:larger;">Par exemple, regardez l'adresse qui suit :<br />
<br />
<pre>Jean Dupont<br />
1 Seaview Lane,<br />
Mousehole,<br />
Cornwall,<br />
UK.</pre></blockquote><br />
<br />
<blockquote style="font-size:larger;">Comment un programme informatique détermine quel type d'inforamtion est le mot "[http://en.wikipedia.org/wiki/Mousehole Mousehole]" ? Est-ce une ville ? Est-ce un pays ? Est-ce le trou où vit Jean ?</blockquote><br />
<br />
<blockquote style="font-size:larger;">Evidemment, ça va être vraiment difficile. Néanmoins en utilisant le microformat '''[[hcard-fr|hCard]]''', vous pouvez étiqueter chaque morceau d'information de façon à ce qu'il soit évident pour un ordinateur de déterminer quel type d'information est ce mot "Mousehole".<br />
<br />
<pre><div class="vcard"><br />
<span class="fn">Jean Dupont</span>,<br />
<div class="adr"><br />
<div class="street-address">1 Seaview Lane</div>,<br />
<span class="locality">Mousehole</span>, <br />
<span class="region">Cornwall</span>,<br />
<span class="country-name">UK</span><br />
</div><br />
</div></pre></blockquote><br />
<br />
<blockquote style="font-size:larger;">Ainsi, c'est tout ce que sont les microformats ? Un groupe de noms de classes (et d'autres attributs similaires faciles à utiliser ) ?</blockquote><br />
<br />
<blockquote style="font-size:larger;">Oui, c'est fondamentalement tout ça.</blockquote><br />
<br />
<blockquote style="font-size:larger;">La clé est que tout le monde puisse utiliser les mêmes noms de classes (et atures attributs). Dans l'exemple au-dessus, vous pouvez voir que la div autour du mot "Moushole", comporte "locality" dans son nom de classe. Bien sûr, "city", "town" ou "village" auraient été tous des noms de classes aussi bien adaptés pour l'utilisation, néanmoins en standardisant un nom de classe spécifique, cela facilite l'écriture d'un programme informatique qui peut examiner une page web, vérifier l'existence de microformats et puis extraire l'information provenant de cette page.</blockquote><br />
<br />
<blockquote style="font-size:larger;">Aussi, dans l'exemple ci-dessus, vous pourriez avoir remarqué le code suivant : <br />
<br />
<pre><div class="vcard"></pre><br />
<br />
Pourquoi avons-nous utilisé "vcard" alors que le nom du microformat est hCard ?</blockquote><br />
<br />
<blockquote style="font-size:larger;">Oui, une autre fonctionnalité importante des microformats est qu'ils n'essayent pas de réinventer la roue. </blockquote><br />
<br />
<blockquote style="font-size:larger;">Il existait déjà un standard existant pour étiqueter les détails de contacts sur les ordinateurs de bureau, la [http://fr.wikipedia.org/wiki/Vcard V Card]. Les V Cards sont de petits fichiers contenant votre information de contact, que vous pouvez envoyer aux personnes que vous connaissez. Ils peuvent ensuite importer ces détails de contacts à l'intérieur de n'importe quel morceau de logiciel qui supporte le format V Card, par exemple Outlook Express.</blockquote><br />
<br />
<blockquote style="font-size:larger;">Plutôt que de sortir une toute nouvelle façon d'étiqueter l'information de contact, le microformat hCard utilise la même structure que les V Cards. (le "h" dans hCard veut symplement dire hypertexte, soit dit en passant).</blockquote><br />
<br />
<blockquote style="font-size:larger;">Et c'est à peu près tout. Les microformats sont un moyen d'étiqueter l'information sur des pages web, de façon à ce qu'elle puisse extraite par un programme informatique ou une application web. Ils sont conçus pour être faciles à utiliser par les personnes, et si possible, ils sont basés sur des standards existants utilisés ailleurs.</blockquote><br />
<br />
[[User:RichQuick|Richard Quick]]. Note : Ce texte (avec des altérations mineures) apparaît désormais dans [http://ineasysteps.com/books/details/?1840783141 Web Design in easy steps]<br />
* Superbe intro en langage clair ! [[User:AndyMabbett|AndyMabbett]] 01:02, 26 Oct 2006 (PDT)</div>ScottReynenhttps://microformats.org/wiki/index.php?title=digital-signatures&diff=32752digital-signatures2007-07-09T20:52:08Z<p>ScottReynen: Reverted edit of Od7Wck, changed back to last version by HenrichPoehls</p>
<hr />
<div><h1>Digital Signatures</h1><br />
<br />
This page documents a discussion about digitally signed Microformatted data.<br />
<br />
__TOC__<br />
<br />
== Introduction ==<br />
<br />
Defined Microformats such as [[hCard]], [[hCalendar]] or [[hReview]] can be formatted to include a digital signature. This document is a definition of a proposed format for the digital signing of Microformatted data. As this format is content agnostic it can be used to build compound signed Microformats from all existing and future Microformats.<br />
<br />
In a broad sense, this format (sometimes referred to as hSig) aims to protect the authenticity and authority of content that has been made machine-readable through the use of semantic annotations (e.g. Microformatted data).<br />
<br />
== Format ==<br />
<br />
The structure and names are chosen in the style of the W3C Recommendation for XML-Signature Syntax and Processing [http://www.w3.org/TR/xmldsig-core/], the existing XML structure for digital signatures. <br />
<br />
<pre><nowiki><br />
// Proposed format with example values<br />
....<br />
<div class="hsig"><br />
<a class="canonicalizationmethod url"<br />
href="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"><br />
</a><br />
Signed using <span class="signaturemethod">RSA</span>.<br />
Hashed using <span class="digestmethod">SHA1</span>.<br />
<abbr class="manifest" title="vcard:fn,vcard:email"><br />
Name and eMail signed.<br />
</abbr><br />
<abbr class="digestvalue" title="57c8105e6d944[...]a14c4cea7f53"><br />
The Hash.<br />
</abbr><br />
<abbr class="signaturevalue" title="7m6NS6ANCa[...]Kl42Rr+Pfw=="><br />
The signature.<br />
</abbr><br />
<abbr class="keyinfo" title="X509"><br />
I have an X509 certified key.<br />
</abbr><br />
<abbr class="keyvalue" title="-----BEGIN CERTIFICATE----- E693c4[...]<br />
[...]MIICIzCCAc2gAgANB-----END CERTIFICATE-----" ><br />
My X509 certificate containing my public-key.<br />
</abbr>.<br />
</div><br />
...<br />
</nowiki></pre><br />
<br />
There are several differences between this format and the original XML Signature structure:<br />
* Most notably, the proposed Microformat is less nested. For example, instead of placing digestmethod and digestvalue into a sub-container called reference, the structure was flattened. <br />
* Fields were added which allow more room for capturing different signature formats. For example, in addition to flattening keyinfo keyvalue was added, which stores information about the key.<br />
<br />
== Integration of signature ==<br />
<br />
To bind the signature to existing Microformatted content, there are three possibilities (again conforming to the use of XML Signatures).<br />
<br />
=== Enveloping signature ===<br />
For an enveloping signature the hsig container contains the Microformatted content that is signed. The content's sub-properties are referenced in the manifest using the Microformat's name followed by the sub-property, separated by a colon (e.g. vcard:fn).<br />
=== Enveloped signature ===<br />
In the case of an enveloped signature the hsig container is contained within the Microformatted micro content that is signed. Again the micro content's sub-properties are referenced in the manifest using the Microformat's name followed by the sub-property, separated by a colon (e.g. vcard:fn ). Figure 2 shows this case.<br />
=== Detached signature ===<br />
This case is needed when a signature shall cover more than one micro content from that page. The micro contents that are part of the signature are then referenced using an <object> or <a> HTML element inside the hsig -section. In this case the micro content needs an id, which is then used for reference instead of the Microformat's name. This case is the most complex one and is not further elaborated for brevity.<br />
<br />
<pre><nowiki><br />
// Signed content using an enveloped hsig<br />
<br />
<div class="vcard"><br />
<h1 class="fn">SVS - Office</h1><br />
<a href="mailto:svs-office@informatik.uni-hamburg.de" class="email">Email us.</a><br/><br />
Tel.: <span class="tel">+49 40 42883 - 2510</span><br/><br />
Fax: +49 40 42883 - 2086 <br/><br />
Room: F-631 <br><br />
<div class="hsig"><br />
<abbr class="manifest" title="vcard:fn, vcard:tel, vcard:email"><br />
This<br />
</abbr><br />
<abbr class="digestvalue" title="57c8105e6dd944[...]a14c4cea7f53"><br />
content<br />
</abbr><br />
<abbr class="signaturevalue title="7m6NS6NCa[...]Kl42Rr+Pfw=="><br />
is signed.<br />
</abbr><br />
<abbr class="digestmethod" title="SHA1">It was hashed using SHA1.</abbr><br />
<abbr class="signaturemethod" title="RSA">And signed using RSA.</abbr><br />
<abbr class="keyvalue" title="-----BEGIN CERTIFICATE----- [....]<br />
[...] CIzCCAc2gAgA-----END CERTIFICATE-----" ><br />
My <span class="keyinfo">X509</span> public-key certificate.<br />
</abbr>.<br />
</div><br />
</div><br />
</nowiki><br />
</pre><br />
<br />
== Manifest and sig generation details ==<br />
<br />
In our prototype, the manifest is stored under the class name manifest (see above). The manifest is also embedded into the signature this aids security. The manifest first identifies for which Microformat structure the signature has been generated. <br />
<br />
After the Microformat identifier, the sub-properties are expressed using their class names (e.g. vcard:fn). Hashes are computed over each sub-property in the manifest and the manifest itself. The hahses are then concatenated in the order they appear in the manifest with the manifest's hash first. This concatenation of hashes is hashed again and stored in digestvalue. <br />
<br />
Finally, it is digitally signed using a digital signature algorithm (specified in signaturemethod) and the value is stored in signaturevalue. To allow for an easier verification of the signature and to aid authentication of the signer, the key can be added to hSig as keyvalue. The key could be anything ranging from a PGP Key to an X509 Certificate from a CA. Exactly what key information is appended should be specified in keyinfo even if it might be deductable from the values of the key itself or the signing method used.<br />
<br />
== References ==<br />
=== Normative References ===<br />
* [[hcard]]<br />
* [[hCalendar]]<br />
<br />
=== Informative References ===<br />
* [http://www.informatik.uni-hamburg.de/SVS/personnel/henrich/hsig.php A Microformat for Digital Signatures]<br />
<br />
=== Related pages ===<br />
* [[digitalsignature-brainstorming]]<br />
* [[digitalsignature-examples]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=mfo-examples&diff=31661mfo-examples2007-07-03T12:23:15Z<p>ScottReynen: /* hCard in hReview */ Formatting</p>
<hr />
<div>= MFO examples =<br />
<br />
Microformat Object or Microformat Opacity or Microformat Opaque<br />
<br />
== Contributors ==<br />
<br />
* Tantek Çelik<br />
<br />
== The Problem ==<br />
<br />
Both recent discussions around hAtom, and earlier discussions from June of 2005 have indicated that there may be a need for a generic microformat to indicate that a specific element is a wrapper, container, or layer of abstraction, that should be opaque to something parsing the microformats that may be further up the hierarchy.<br />
<br />
E.g. you might put a <code>&lt;span class="vcard mfo"&gt;</code> deep inside a <code>&lt;span class="vevent"&gt;</code>, and not want the categories/tags of the [[hcard|hCard]] accidentally parsed into the hCalendar event.<br />
<br />
Note: the use of "mfo" is only for the purpose of illustration is by no means a proposed name for this microformat. We expect research/discussion to reveal a much better name. We use "mfo" only as a temporary name for the sake of discussion and example illustration. We may even want to commit to deliberately using a class name different from "mfo" just to make this clear in the end.<br />
<br />
== Forward Compatibility for Parsers ==<br />
<br />
Part of the point of this is to help with forward compatibility for parsers.<br />
<br />
Thus an hCalendar parser might need not know about hCard (even though in practice they probably will). As the number of microformats grows, the chances that a new microformat may confuse an old parser due to the scenario outlined above increases. Thus we are considering making it explicit when a new "root" microformat is established.<br />
<br />
== To Do ==<br />
<br />
In order:<br />
<br />
# fill out the real world examples below<br />
# create [[mfo-formats]] page for researching/describing how other data formats indicate this kind of "abstraction", including the various terms they use like "object", "container", etc.<br />
# create [[mfo-brainstorming]] page where we discuss how this should work, and candidate names. Some candidate names that have been offered to date: u, uf, object, container, root, mfo...<br />
<br />
== Examples ==<br />
<br />
Here are some real world examples where folks have encountered the need to explicitly indicate that an embedded microformat does not introduce properties to its container.<br />
<br />
=== hCard in hCalendar ===<br />
<br />
[[http://playinghere.com/ PlayingHere.com]] includes thousands of hCalendar events with embedded hCard contacts. The contacts have URLs, the events do not, and these contact URLs are treated as event URLs, which is not what the author intended. An example of the markup:<br />
<br />
<pre><nowiki><br />
<body class="vevent"><br />
[...]<br />
<h1 class="vcard organizer"><span class="summary">June 19th, 2007 at <span class="fn org">Varsity Theatre</span></span></h1><br />
[...]<br />
<h3><br />
<span class="attendee vcard"><a href="http://playinghere.com/band/armyofme/" class="fn url">ARMY OF ME</a></span><br />
at <abbr class="dtstart" title="2007-06-19T17:00:00-07:00">5:00 pm</abbr><br />
</h3><br />
[...]<br />
</body><br />
</nowiki></pre><br />
<br />
[[http://eventful.com/ Eventful]] includes tens of thousands (hundreds of thousands?) of hCalendar events with embedded hCard contacts. The contacts and events both have URLs. Because the contact URLs come first, they take precedence over the event URLs (at least in X2V) when the event data is exported. As a result, the real event URL is replaced with a less useful URL, which is not what the author intended. An example of the markup:<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
[...]<br />
<h1 class="summary">Brown Bag Music Series</h1><br />
[...]<br />
<h2>When</h2><br />
<p><br />
<abbr class="dtstart" title="20070619T120000">Tuesday, June 19, 2007 12:00 PM</abbr><br />
</p><br />
[...]<br />
<h2>Where</h2><br />
<div class="location vcard"><br />
<a rel="bookmark" class="url uid fn org" href="/venues/V0-001-000395941-4">Denver Public Library - Central Branch</a><br />
[...]<br />
</div><br />
[...]<br />
<a class="url" href="/r/http://www.denver365.com/index.php?app=eventDetail&amp;id=73358">Event details at www.denver365.com</a><br />
[...]<br />
</div><br />
</nowiki></pre><br />
<br />
=== hCard in hReview ===<br />
<br />
[[http://www.bbc.co.uk/music/ BBC Music]] includes thousands of hCard contacts embedded within hReview reviews. The contacts have URLs, but the reviews do not. These contact URLs are interpretted as review URLs, which is not what the publisher intended. [[http://microformats.org/discuss/mail/microformats-discuss/2007-July/010136.html See email discussion]]. An example of the markup:<br />
<br />
<pre><nowiki><br />
<div class="hreview"><br />
[...]<br />
<dl><br />
<dt>Artist:</dt><br />
<dd><span class="vcard"><br />
<a href="/music/artist/m6qv/" class="fn url">The Beatles</a><br />
</span></dd><br />
[...]<br />
</dl><br />
[...]<br />
</div><br />
</nowiki></pre><br />
<br />
=== hAtom ===<br />
<br />
Container microformats use context in a similar way to that of conventional XML. When an Atom document includes the element <author> it is context that determines whether the author of a feed or the author of an entry is being specified. However, contrary to convetional XML microformats support forwards compatibility with must-ignore semantics for intervening elements between the context and data. This introduces a problem of identifying contexts that may have been ignored in parsing. If hAtom finds an author element belonging a new microformat that it does not recognise, it may incorrectly summise that the author element belongs to it and refers to it. In fact, it refers to the unknown microformat. Any other inference is invalid.<br />
<br />
Elements that have different meanings in different microformats also pose a problem. [[hcard|hCard]] includes a title element meaning approximately "a person's job title". Atom and various other specifications use title to mean "the title of this document or sub-document". [[hreview|hReview]] avoided the use of title by re-using "summary" from [[hcalendar|hCalendar]] element, however this also clashes with the atom namespace. hReview uses summary to mean "review title", while atom uses summary to mean "abbreviated content, both longer than title and shorter than content".<br />
<br />
[[hatom|hAtom]] currently attempts to resolve both the context problem and the nomenclature problem by explicitly naming child elements as opaque. Currently "content" and "summary" (will likely change) are considered completely opaque, while "author" and "contributor" are only scanned for [[hcard|hCard]] content. This may be an incomplete solution if hCards or other context microformats are included outside of these nodes.<br />
<br />
=== hAtom and other microformats ===<br />
<br />
One might say that if a parser understands hAtom, then there's no need for explicitly <br />
marking opaque elements as opaque.<br />
<br />
This is true, for [[hatom|hAtom]] parsers, and I (Tantek) made the same argument originally for [[hcard|hCard]], and [[hcalendar|hCalendar]], and [[hreview|hReview]], e.g. if a parser understands hCard, then there's no need for explicitly marking opaque elements as opaque.<br />
<br />
However, what happens when an hReview parser, which was written before hAtom was conceived, encounters mixed hReview + hAtom content?<br />
<br />
The whole need for marking opaque elements explicitly as opaque is to enable *current/old* microformat parsers to NOT be confused by new microformats which happen to reuse vocabulary.<br />
<br />
Another way of looking at this is that by agreeing on a neutral opacity class name, we avoid the need for every microformat parser to have to know about every microformat. I'm sure you can imagine how much of a burden that might become over time.<br />
<br />
=== hAtom and hReview - an example of overlay ===<br />
<br />
It could be said that certain microformats, e.g. hAtom, hReview, [[xfolk|xFolk]], can be "overlayed" (different from "composited").<br />
<br />
In particular you can do do this:<br />
<pre><nowiki><br />
<div class="hatom hreview"><br />
...<br />
</div><br />
</nowiki></pre><br />
<br />
and have the expected right thing happen.<br />
<br />
In fact, hReview is a perfect example of a microformat that sometimes you will want to make opaque, and sometimes you will want to overlay. Or perhaps you will want to overlay *most* of an hReview, and mark part of it (such as the "reviewer") as opaque.<br />
<br />
Thus we actually cannot assume an hReview either whole or in part is either opaque or transparent. We actually need another "bit" of information to indicate that aspect of opacity on the hReview as a whole, or in parts of it..<br />
<br />
== Similar or Related Problems ==<br />
<br />
=== Microformat Property ===<br />
<br />
Just as using the class name "mfo" could be used to identify the existence of an arbitrary "microformat object" which by its very nature of being an object, should be opaque to any containing microformat (as described above), it may also be worth considering the use of a general purpose class name like "mfp" to indicate that an element represents a microformat property. This would allow auto-recognition of properties of an arbitrary new microformat without having to read the profile for that microformat explicitly.<br />
<br />
==== Challenges ====<br />
<br />
Since there are type specific markup and parsing interpretations, there may need to be several such classes to indicate types of microformat properties that require special parsing (see [[hcard-parsing]] for details for [[hcard|hCard]] in particular). E.g.: datetime (must prefer 'title' attribute to element contents), url (must prefer href/data/src attributes on a/object/img elements over element contents), email (similar to URL but "mailto:" is pruned). Some questions<br />
* Would there simply be separate class names like "mfdt", "mfu", "mfe"? <br />
* How useful would this be without knowing more about the specific microformat? <br />
* Is that set of types fixed or would we need to add more in the future? <br />
* Do we thus reserve all class names that start with "mf"?<br />
* Is this walking too much down the path of coming up with answers to generic / general-purpose questions which violate our [[microformats]] principles?<br />
* Is this a solution looking for a problem?<br />
<br />
== Related Pages ==<br />
<br />
* [[mfo-brainstorming]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=mfo-examples&diff=18102mfo-examples2007-07-03T12:22:06Z<p>ScottReynen: Oops - formatting</p>
<hr />
<div>= MFO examples =<br />
<br />
Microformat Object or Microformat Opacity or Microformat Opaque<br />
<br />
== Contributors ==<br />
<br />
* Tantek Çelik<br />
<br />
== The Problem ==<br />
<br />
Both recent discussions around hAtom, and earlier discussions from June of 2005 have indicated that there may be a need for a generic microformat to indicate that a specific element is a wrapper, container, or layer of abstraction, that should be opaque to something parsing the microformats that may be further up the hierarchy.<br />
<br />
E.g. you might put a <code>&lt;span class="vcard mfo"&gt;</code> deep inside a <code>&lt;span class="vevent"&gt;</code>, and not want the categories/tags of the [[hcard|hCard]] accidentally parsed into the hCalendar event.<br />
<br />
Note: the use of "mfo" is only for the purpose of illustration is by no means a proposed name for this microformat. We expect research/discussion to reveal a much better name. We use "mfo" only as a temporary name for the sake of discussion and example illustration. We may even want to commit to deliberately using a class name different from "mfo" just to make this clear in the end.<br />
<br />
== Forward Compatibility for Parsers ==<br />
<br />
Part of the point of this is to help with forward compatibility for parsers.<br />
<br />
Thus an hCalendar parser might need not know about hCard (even though in practice they probably will). As the number of microformats grows, the chances that a new microformat may confuse an old parser due to the scenario outlined above increases. Thus we are considering making it explicit when a new "root" microformat is established.<br />
<br />
== To Do ==<br />
<br />
In order:<br />
<br />
# fill out the real world examples below<br />
# create [[mfo-formats]] page for researching/describing how other data formats indicate this kind of "abstraction", including the various terms they use like "object", "container", etc.<br />
# create [[mfo-brainstorming]] page where we discuss how this should work, and candidate names. Some candidate names that have been offered to date: u, uf, object, container, root, mfo...<br />
<br />
== Examples ==<br />
<br />
Here are some real world examples where folks have encountered the need to explicitly indicate that an embedded microformat does not introduce properties to its container.<br />
<br />
=== hCard in hCalendar ===<br />
<br />
[[http://playinghere.com/ PlayingHere.com]] includes thousands of hCalendar events with embedded hCard contacts. The contacts have URLs, the events do not, and these contact URLs are treated as event URLs, which is not what the author intended. An example of the markup:<br />
<br />
<pre><nowiki><br />
<body class="vevent"><br />
[...]<br />
<h1 class="vcard organizer"><span class="summary">June 19th, 2007 at <span class="fn org">Varsity Theatre</span></span></h1><br />
[...]<br />
<h3><br />
<span class="attendee vcard"><a href="http://playinghere.com/band/armyofme/" class="fn url">ARMY OF ME</a></span><br />
at <abbr class="dtstart" title="2007-06-19T17:00:00-07:00">5:00 pm</abbr><br />
</h3><br />
[...]<br />
</body><br />
</nowiki></pre><br />
<br />
[[http://eventful.com/ Eventful]] includes tens of thousands (hundreds of thousands?) of hCalendar events with embedded hCard contacts. The contacts and events both have URLs. Because the contact URLs come first, they take precedence over the event URLs (at least in X2V) when the event data is exported. As a result, the real event URL is replaced with a less useful URL, which is not what the author intended. An example of the markup:<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
[...]<br />
<h1 class="summary">Brown Bag Music Series</h1><br />
[...]<br />
<h2>When</h2><br />
<p><br />
<abbr class="dtstart" title="20070619T120000">Tuesday, June 19, 2007 12:00 PM</abbr><br />
</p><br />
[...]<br />
<h2>Where</h2><br />
<div class="location vcard"><br />
<a rel="bookmark" class="url uid fn org" href="/venues/V0-001-000395941-4">Denver Public Library - Central Branch</a><br />
[...]<br />
</div><br />
[...]<br />
<a class="url" href="/r/http://www.denver365.com/index.php?app=eventDetail&amp;id=73358">Event details at www.denver365.com</a><br />
[...]<br />
</div><br />
</nowiki></pre><br />
<br />
=== hCard in hReview ===<br />
<br />
[[http://www.bbc.co.uk/music/|BBC Music]] includes thousands of hCard contacts embedded within hReview reviews. The contacts have URLs, but the reviews do not. These contact URLs are interpretted as review URLs, which is not what the publisher intended. [[http://microformats.org/discuss/mail/microformats-discuss/2007-July/010136.html|See email discussion]]. An example of the markup:<br />
<br />
<pre><nowiki><br />
<div class="hreview"><br />
[...]<br />
<dl><br />
<dt>Artist:</dt><br />
<dd><span class="vcard"><br />
<a href="/music/artist/m6qv/" class="fn url">The Beatles</a><br />
</span></dd><br />
[...]<br />
</dl><br />
[...]<br />
</div><br />
</nowiki></pre><br />
<br />
=== hAtom ===<br />
<br />
Container microformats use context in a similar way to that of conventional XML. When an Atom document includes the element <author> it is context that determines whether the author of a feed or the author of an entry is being specified. However, contrary to convetional XML microformats support forwards compatibility with must-ignore semantics for intervening elements between the context and data. This introduces a problem of identifying contexts that may have been ignored in parsing. If hAtom finds an author element belonging a new microformat that it does not recognise, it may incorrectly summise that the author element belongs to it and refers to it. In fact, it refers to the unknown microformat. Any other inference is invalid.<br />
<br />
Elements that have different meanings in different microformats also pose a problem. [[hcard|hCard]] includes a title element meaning approximately "a person's job title". Atom and various other specifications use title to mean "the title of this document or sub-document". [[hreview|hReview]] avoided the use of title by re-using "summary" from [[hcalendar|hCalendar]] element, however this also clashes with the atom namespace. hReview uses summary to mean "review title", while atom uses summary to mean "abbreviated content, both longer than title and shorter than content".<br />
<br />
[[hatom|hAtom]] currently attempts to resolve both the context problem and the nomenclature problem by explicitly naming child elements as opaque. Currently "content" and "summary" (will likely change) are considered completely opaque, while "author" and "contributor" are only scanned for [[hcard|hCard]] content. This may be an incomplete solution if hCards or other context microformats are included outside of these nodes.<br />
<br />
=== hAtom and other microformats ===<br />
<br />
One might say that if a parser understands hAtom, then there's no need for explicitly <br />
marking opaque elements as opaque.<br />
<br />
This is true, for [[hatom|hAtom]] parsers, and I (Tantek) made the same argument originally for [[hcard|hCard]], and [[hcalendar|hCalendar]], and [[hreview|hReview]], e.g. if a parser understands hCard, then there's no need for explicitly marking opaque elements as opaque.<br />
<br />
However, what happens when an hReview parser, which was written before hAtom was conceived, encounters mixed hReview + hAtom content?<br />
<br />
The whole need for marking opaque elements explicitly as opaque is to enable *current/old* microformat parsers to NOT be confused by new microformats which happen to reuse vocabulary.<br />
<br />
Another way of looking at this is that by agreeing on a neutral opacity class name, we avoid the need for every microformat parser to have to know about every microformat. I'm sure you can imagine how much of a burden that might become over time.<br />
<br />
=== hAtom and hReview - an example of overlay ===<br />
<br />
It could be said that certain microformats, e.g. hAtom, hReview, [[xfolk|xFolk]], can be "overlayed" (different from "composited").<br />
<br />
In particular you can do do this:<br />
<pre><nowiki><br />
<div class="hatom hreview"><br />
...<br />
</div><br />
</nowiki></pre><br />
<br />
and have the expected right thing happen.<br />
<br />
In fact, hReview is a perfect example of a microformat that sometimes you will want to make opaque, and sometimes you will want to overlay. Or perhaps you will want to overlay *most* of an hReview, and mark part of it (such as the "reviewer") as opaque.<br />
<br />
Thus we actually cannot assume an hReview either whole or in part is either opaque or transparent. We actually need another "bit" of information to indicate that aspect of opacity on the hReview as a whole, or in parts of it..<br />
<br />
== Similar or Related Problems ==<br />
<br />
=== Microformat Property ===<br />
<br />
Just as using the class name "mfo" could be used to identify the existence of an arbitrary "microformat object" which by its very nature of being an object, should be opaque to any containing microformat (as described above), it may also be worth considering the use of a general purpose class name like "mfp" to indicate that an element represents a microformat property. This would allow auto-recognition of properties of an arbitrary new microformat without having to read the profile for that microformat explicitly.<br />
<br />
==== Challenges ====<br />
<br />
Since there are type specific markup and parsing interpretations, there may need to be several such classes to indicate types of microformat properties that require special parsing (see [[hcard-parsing]] for details for [[hcard|hCard]] in particular). E.g.: datetime (must prefer 'title' attribute to element contents), url (must prefer href/data/src attributes on a/object/img elements over element contents), email (similar to URL but "mailto:" is pruned). Some questions<br />
* Would there simply be separate class names like "mfdt", "mfu", "mfe"? <br />
* How useful would this be without knowing more about the specific microformat? <br />
* Is that set of types fixed or would we need to add more in the future? <br />
* Do we thus reserve all class names that start with "mf"?<br />
* Is this walking too much down the path of coming up with answers to generic / general-purpose questions which violate our [[microformats]] principles?<br />
* Is this a solution looking for a problem?<br />
<br />
== Related Pages ==<br />
<br />
* [[mfo-brainstorming]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=mfo-examples&diff=18101mfo-examples2007-07-03T12:21:42Z<p>ScottReynen: /* Examples */ Added BBC Music</p>
<hr />
<div>= MFO examples =<br />
<br />
Microformat Object or Microformat Opacity or Microformat Opaque<br />
<br />
== Contributors ==<br />
<br />
* Tantek Çelik<br />
<br />
== The Problem ==<br />
<br />
Both recent discussions around hAtom, and earlier discussions from June of 2005 have indicated that there may be a need for a generic microformat to indicate that a specific element is a wrapper, container, or layer of abstraction, that should be opaque to something parsing the microformats that may be further up the hierarchy.<br />
<br />
E.g. you might put a <code>&lt;span class="vcard mfo"&gt;</code> deep inside a <code>&lt;span class="vevent"&gt;</code>, and not want the categories/tags of the [[hcard|hCard]] accidentally parsed into the hCalendar event.<br />
<br />
Note: the use of "mfo" is only for the purpose of illustration is by no means a proposed name for this microformat. We expect research/discussion to reveal a much better name. We use "mfo" only as a temporary name for the sake of discussion and example illustration. We may even want to commit to deliberately using a class name different from "mfo" just to make this clear in the end.<br />
<br />
== Forward Compatibility for Parsers ==<br />
<br />
Part of the point of this is to help with forward compatibility for parsers.<br />
<br />
Thus an hCalendar parser might need not know about hCard (even though in practice they probably will). As the number of microformats grows, the chances that a new microformat may confuse an old parser due to the scenario outlined above increases. Thus we are considering making it explicit when a new "root" microformat is established.<br />
<br />
== To Do ==<br />
<br />
In order:<br />
<br />
# fill out the real world examples below<br />
# create [[mfo-formats]] page for researching/describing how other data formats indicate this kind of "abstraction", including the various terms they use like "object", "container", etc.<br />
# create [[mfo-brainstorming]] page where we discuss how this should work, and candidate names. Some candidate names that have been offered to date: u, uf, object, container, root, mfo...<br />
<br />
== Examples ==<br />
<br />
Here are some real world examples where folks have encountered the need to explicitly indicate that an embedded microformat does not introduce properties to its container.<br />
<br />
=== hCard in hCalendar ===<br />
<br />
[[http://playinghere.com/ PlayingHere.com]] includes thousands of hCalendar events with embedded hCard contacts. The contacts have URLs, the events do not, and these contact URLs are treated as event URLs, which is not what the author intended. An example of the markup:<br />
<br />
<pre><nowiki><br />
<body class="vevent"><br />
[...]<br />
<h1 class="vcard organizer"><span class="summary">June 19th, 2007 at <span class="fn org">Varsity Theatre</span></span></h1><br />
[...]<br />
<h3><br />
<span class="attendee vcard"><a href="http://playinghere.com/band/armyofme/" class="fn url">ARMY OF ME</a></span><br />
at <abbr class="dtstart" title="2007-06-19T17:00:00-07:00">5:00 pm</abbr><br />
</h3><br />
[...]<br />
</body><br />
</nowiki></pre><br />
<br />
[[http://eventful.com/ Eventful]] includes tens of thousands (hundreds of thousands?) of hCalendar events with embedded hCard contacts. The contacts and events both have URLs. Because the contact URLs come first, they take precedence over the event URLs (at least in X2V) when the event data is exported. As a result, the real event URL is replaced with a less useful URL, which is not what the author intended. An example of the markup:<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
[...]<br />
<h1 class="summary">Brown Bag Music Series</h1><br />
[...]<br />
<h2>When</h2><br />
<p><br />
<abbr class="dtstart" title="20070619T120000">Tuesday, June 19, 2007 12:00 PM</abbr><br />
</p><br />
[...]<br />
<h2>Where</h2><br />
<div class="location vcard"><br />
<a rel="bookmark" class="url uid fn org" href="/venues/V0-001-000395941-4">Denver Public Library - Central Branch</a><br />
[...]<br />
</div><br />
[...]<br />
<a class="url" href="/r/http://www.denver365.com/index.php?app=eventDetail&amp;id=73358">Event details at www.denver365.com</a><br />
[...]<br />
</div><br />
</nowiki></pre><br />
<br />
=== hCard in hReview<br />
<br />
[[http://www.bbc.co.uk/music/|BBC Music]] includes thousands of hCard contacts embedded within hReview reviews. The contacts have URLs, but the reviews do not. These contact URLs are interpretted as review URLs, which is not what the publisher intended. [[http://microformats.org/discuss/mail/microformats-discuss/2007-July/010136.html|See email discussion]]. An example of the markup:<br />
<br />
<pre><nowiki><br />
<div class="hreview"><br />
[...]<br />
<dl><br />
<dt>Artist:</dt><br />
<dd><span class="vcard"><br />
<a href="/music/artist/m6qv/" class="fn url">The Beatles</a><br />
</span></dd><br />
[...]<br />
</dl><br />
[...]<br />
</div><br />
</nowiki></pre><br />
<br />
=== hAtom ===<br />
<br />
Container microformats use context in a similar way to that of conventional XML. When an Atom document includes the element <author> it is context that determines whether the author of a feed or the author of an entry is being specified. However, contrary to convetional XML microformats support forwards compatibility with must-ignore semantics for intervening elements between the context and data. This introduces a problem of identifying contexts that may have been ignored in parsing. If hAtom finds an author element belonging a new microformat that it does not recognise, it may incorrectly summise that the author element belongs to it and refers to it. In fact, it refers to the unknown microformat. Any other inference is invalid.<br />
<br />
Elements that have different meanings in different microformats also pose a problem. [[hcard|hCard]] includes a title element meaning approximately "a person's job title". Atom and various other specifications use title to mean "the title of this document or sub-document". [[hreview|hReview]] avoided the use of title by re-using "summary" from [[hcalendar|hCalendar]] element, however this also clashes with the atom namespace. hReview uses summary to mean "review title", while atom uses summary to mean "abbreviated content, both longer than title and shorter than content".<br />
<br />
[[hatom|hAtom]] currently attempts to resolve both the context problem and the nomenclature problem by explicitly naming child elements as opaque. Currently "content" and "summary" (will likely change) are considered completely opaque, while "author" and "contributor" are only scanned for [[hcard|hCard]] content. This may be an incomplete solution if hCards or other context microformats are included outside of these nodes.<br />
<br />
=== hAtom and other microformats ===<br />
<br />
One might say that if a parser understands hAtom, then there's no need for explicitly <br />
marking opaque elements as opaque.<br />
<br />
This is true, for [[hatom|hAtom]] parsers, and I (Tantek) made the same argument originally for [[hcard|hCard]], and [[hcalendar|hCalendar]], and [[hreview|hReview]], e.g. if a parser understands hCard, then there's no need for explicitly marking opaque elements as opaque.<br />
<br />
However, what happens when an hReview parser, which was written before hAtom was conceived, encounters mixed hReview + hAtom content?<br />
<br />
The whole need for marking opaque elements explicitly as opaque is to enable *current/old* microformat parsers to NOT be confused by new microformats which happen to reuse vocabulary.<br />
<br />
Another way of looking at this is that by agreeing on a neutral opacity class name, we avoid the need for every microformat parser to have to know about every microformat. I'm sure you can imagine how much of a burden that might become over time.<br />
<br />
=== hAtom and hReview - an example of overlay ===<br />
<br />
It could be said that certain microformats, e.g. hAtom, hReview, [[xfolk|xFolk]], can be "overlayed" (different from "composited").<br />
<br />
In particular you can do do this:<br />
<pre><nowiki><br />
<div class="hatom hreview"><br />
...<br />
</div><br />
</nowiki></pre><br />
<br />
and have the expected right thing happen.<br />
<br />
In fact, hReview is a perfect example of a microformat that sometimes you will want to make opaque, and sometimes you will want to overlay. Or perhaps you will want to overlay *most* of an hReview, and mark part of it (such as the "reviewer") as opaque.<br />
<br />
Thus we actually cannot assume an hReview either whole or in part is either opaque or transparent. We actually need another "bit" of information to indicate that aspect of opacity on the hReview as a whole, or in parts of it..<br />
<br />
== Similar or Related Problems ==<br />
<br />
=== Microformat Property ===<br />
<br />
Just as using the class name "mfo" could be used to identify the existence of an arbitrary "microformat object" which by its very nature of being an object, should be opaque to any containing microformat (as described above), it may also be worth considering the use of a general purpose class name like "mfp" to indicate that an element represents a microformat property. This would allow auto-recognition of properties of an arbitrary new microformat without having to read the profile for that microformat explicitly.<br />
<br />
==== Challenges ====<br />
<br />
Since there are type specific markup and parsing interpretations, there may need to be several such classes to indicate types of microformat properties that require special parsing (see [[hcard-parsing]] for details for [[hcard|hCard]] in particular). E.g.: datetime (must prefer 'title' attribute to element contents), url (must prefer href/data/src attributes on a/object/img elements over element contents), email (similar to URL but "mailto:" is pruned). Some questions<br />
* Would there simply be separate class names like "mfdt", "mfu", "mfe"? <br />
* How useful would this be without knowing more about the specific microformat? <br />
* Is that set of types fixed or would we need to add more in the future? <br />
* Do we thus reserve all class names that start with "mf"?<br />
* Is this walking too much down the path of coming up with answers to generic / general-purpose questions which violate our [[microformats]] principles?<br />
* Is this a solution looking for a problem?<br />
<br />
== Related Pages ==<br />
<br />
* [[mfo-brainstorming]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=hatom-hints&diff=17695hatom-hints2007-06-20T13:34:48Z<p>ScottReynen: Reverted edit of LasX5m, changed back to last version by Tantek</p>
<hr />
<div>= hAtom Hints =<br />
<br />
[[hAtom]] is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. This page gives hints on how to use, implement and embed hAtom, backgrounders and other information closely related to the hAtom spec but that doesn't strictly belong on the main page.<br />
<br />
If there's a conflict between this page and the spec, the spec is correct.<br />
<br />
{{out-of-date}}<br />
<br />
__TOC__<br />
<br />
== Schema Notes ==<br />
==== Nomenclature ====<br />
<br />
'''Note:''' Please see the [[hatom-issues]] document for discussion on property names.<br />
<br />
{| width="100%" border="1" cellspacing="0" <br />
|-<br />
! width="150" | Concept<br />
! Atom Identifier<br />
! hAtom Microformat Usage<br />
|-<br />
| Feed<br />
| <code>atom:feed</code><br />
| Add class name <code>"hfeed"</code><br />
|-<br />
| Entry<br />
| <code>atom:entry</code><br />
| Add class name <code>hentry</code>; if practical, also define <code>id="unique-identifier"</code> to the Entry.<br />
|-<br />
| Entry Title<br />
| <code>atom:title</code><br />
| Add class name <code>headline</code>. Using <code>&lt;h#></code> also is encouraged.<br />
|-<br />
| Entry Content<br />
| <code>atom:content</code><br />
| Add class name <code>content</code> to all appropriate blocks. Multiple Entry Content blocks are logically considered one concatenated <code>atom:content</code> equivalent.<br />
|-<br />
| Entry Summary<br />
| <code>atom:summary</code><br />
| Add class name <code>excerpt</code> to all appropriate blocks. Multiple Entry Summary blocks are logically considered one concatenated <code>atom:summary</code> equivalent.<br />
|-<br />
| Entry Permalink<br />
| <code>atom:link</code><br />
| Add a rel value of <code>bookmark</code>.<br />
|-<br />
| Entry Published<br />
| <code>atom:published</code><br />
| Use class name <code>published</code>, optionally with the [[datetime-design-pattern]].<br />
|-<br />
| Entry Updated<br />
| <code>atom:updated</code><br />
| Use class name<code>updated</code>, with an ISO8601 absolute datetime, optionally with the [[datetime-design-pattern]].<br />
|-<br />
| Entry Author<br />
| <code>atom:author</code><br />
| Add class name <code>"author</code>. Using an <code>address</code> element is recommended. A [[hcard|hCard]] SHOULD be added.<br />
|}<br />
<br />
==== Nesting Rules ====<br />
<br />
{| width="100%" border="1" cellspacing="0" <br />
|-<br />
! Concept<br />
! Nests In<br />
! hAtom Opaque<br />
! Cardinality<br />
! Logical Cardinality<br /><i>Informative</i><br />
|-<br />
| Feed<br />
| HTML document<br />
| No<br />
| 1-N<br />
| 1-N<br />
|-<br />
| Entry<br />
| Feed<br />
| No<br />
| 0-N<br />
| 0-N<br />
|-<br />
| Entry Title<br />
| Entry<br />Entry Permalink<br />
| No<br />
| 0-N<br />
| 0-1<br />
|-<br />
| Entry Content<br />
| Entry<br />
| Yes<br />
| 0-N<br />
| 0-1<br />
|-<br />
| Entry Summary<br />
| Entry<br />
| Yes<br />
| 0-N<br />
| 0-1<br />
|-<br />
| Entry Permalink<br />
| Entry<br />Entry Title<br />Entry Published<br />
| No<br />
| 0-N<br />
| 1<br />
|-<br />
| Entry Published<br />
| Entry<br />Entry Permalink<br />
| No<br />
| 0-N<br />
| 0-1<br />
|-<br />
| Entry Updated<br />
| Entry<br />Entry Permalink<br />
| No<br />
| 0-N<br />
| 1<br />
|-<br />
| Entry Author<br />
| Entry<br />
| Yes<br />
| 0-N<br />
| 1-N<br />
|}<br />
<br />
===== hAtom Opaque =====<br />
<br />
"hAtom Opaque" specifies whether a hAtom parser should not "look inside" the element for further hAtom content. If there are multiple rules applied to the same element take the OR of the two (i.e. "Yes/Opaque" always wins)<br />
<br />
: ''hAtom Opaque is designed to make parsing rules less ambiguous. In particular, it allows "quoted" hAtom elements (from another blog being blockquoted, for example) ti be ignored. It also allows 'embedded' hAtom to be potentially delivered within hAtom itself, and to prevent accidental 'leaking' of other microformat information up into the hAtom container. A general concept of opaqueness (<b>need link</b>) has also been proposed but it will complement, not replace this.''<br />
<br />
===== Cardinality =====<br />
<br />
How many times can an element of the given type appear in it's nesting/parent element.<br />
<br />
===== Logical Cardinality =====<br />
<br />
''This column is informative -- Atom has a number of rules for deciding what is required depending on the context and other elements, many which aren't strictly applicable to here.''<br />
<br />
From a modeling/logical perspective, the number of times can an element appear.<br />
<br />
: ''This is all rule dependent, see below. For example, an Entry Permalink may appear 6 times, but each one must be the same value; an Entry Content element may appear 3 times, but they are all concatenated together to make a single logical element.''<br />
<br />
<br />
=== Element notes ===<br />
===== Feed =====<br />
<br />
* you could have multiple feeds on news pages, or weblogs with "mini-blogs" on the sidebar.<br />
* class="hfeed hentry" is OK for feeds with a single entry.<br />
<br />
===== Entry Permalink =====<br />
* Entry Permalinks SHOULD be the same as the <code>atom:link</code> (or <code>rss:link</code>) used in syndication feeds<br />
: ''The intention of the previous two rules to gently force people to use strings that can be byte compared for equivalence. In general, the canonical URI should be the link used in an Atom entry.''<br />
* if an Entry has multiple elements marked as the Entry Permalink, they MUST have exactly the same URI<br />
<br />
==See Also==<br />
* [[hatom|hAtom]] - the draft proposal<br />
* [[hatom-hints|hAtom Hints]] - help for implementors<br />
* [[hatom-issues]] - problems? complaints? ideas? Put them here<br />
* [[hatom-faq]] - knowledge base<br />
* [[blog-post-brainstorming]]<br />
* [[blog-post-formats]]<br />
* [[blog-post-examples]]<br />
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)</div>ScottReynenhttps://microformats.org/wiki/index.php?title=citation-irc-meetup&diff=17685citation-irc-meetup2007-06-20T13:32:50Z<p>ScottReynen: Reverted edit of KciBfq, changed back to last version by Brian</p>
<hr />
<div>There has been an explosion of messages to the mailing list about the citation format. I think it would be best for everyone interested in contributing to try and set aside 30-60 minutes so we can all meet in the IRC room and hammer out alot of the simple things and get a road map for the larger pictures.<br />
<br />
I would like to try to get the first meeting within the next 10 days, so please put your name with a time that works best for you. REMEMBER we span different timezone, so maybe a weekend is best?<br />
<br />
== Attendees ==<br />
* [http://suda.co.uk/ Brian Suda] (-0600) TZ, Any day after 19:00 (7pm) or weekends<br />
* [http://michael-mccracken.net/ Michael McCracken] (-0800) TZ, Any day after 4pm or weekends, starting Tuesday, Apr. 4. (Except April 7th, 8th & 9th)<br />
* [http://tjameswhite.com/ Tim White] (-0500)TZ, Weekends best (except April 7-8), or after 7pm (no Tuesdays)<br />
* [http://www.inkdroid.org/ Ed Summers] (-0600)TZ, 9AM-10PM.<br />
* [http://dilettantes.code4lib.org/ Ross Singer] (-0500)TZ Monday April 3rd or Sunday the 9th... 9-5 either day.<br />
* [http://netapps.muohio.edu/blogs/darcusb/darcusb/ Bruce D'Arcus] (-0500)TZ 9-5 in general, weekend probably best.<br />
<br />
== things to discuss ==<br />
* Difference between inline citation and a Bibliography<br />
* Minimum information needed to be considered a citation?<br />
* Citation Typing (should types such as Book, Journal, Photo, Art be explicitly stated?)<br />
* Can the citation properties be used to describe the Page Article itself and/or the references?<br />
<br />
== meet-up date/time ==<br />
SUNDAY April 9th, 2006<br />
2pm Central/3pm Eastern</div>ScottReynenhttps://microformats.org/wiki/index.php?title=mfo-examples&diff=17806mfo-examples2007-06-20T01:37:34Z<p>ScottReynen: </p>
<hr />
<div>= MFO examples =<br />
<br />
Microformat Object or Microformat Opacity or Microformat Opaque<br />
<br />
== Contributors ==<br />
<br />
* Tantek Çelik<br />
<br />
== The Problem ==<br />
<br />
Both recent discussions around hAtom, and earlier discussions from June of 2005 have indicated that there may be a need for a generic microformat to indicate that a specific element is a wrapper, container, or layer of abstraction, that should be opaque to something parsing the microformats that may be further up the hierarchy.<br />
<br />
E.g. you might put a <code>&lt;span class="vcard mfo"&gt;</code> deep inside a <code>&lt;span class="vevent"&gt;</code>, and not want the categories/tags of the [[hcard|hCard]] accidentally parsed into the hCalendar event.<br />
<br />
Note: the use of "mfo" is only for the purpose of illustration is by no means a proposed name for this microformat. We expect research/discussion to reveal a much better name. We use "mfo" only as a temporary name for the sake of discussion and example illustration. We may even want to commit to deliberately using a class name different from "mfo" just to make this clear in the end.<br />
<br />
== Forward Compatibility for Parsers ==<br />
<br />
Part of the point of this is to help with forward compatibility for parsers.<br />
<br />
Thus an hCalendar parser might need not know about hCard (even though in practice they probably will). As the number of microformats grows, the chances that a new microformat may confuse an old parser due to the scenario outlined above increases. Thus we are considering making it explicit when a new "root" microformat is established.<br />
<br />
== To Do ==<br />
<br />
In order:<br />
<br />
# fill out the real world examples below<br />
# create [[mfo-formats]] page for researching/describing how other data formats indicate this kind of "abstraction", including the various terms they use like "object", "container", etc.<br />
# create [[mfo-brainstorming]] page where we discuss how this should work, and candidate names. Some candidate names that have been offered to date: u, uf, object, container, root, mfo...<br />
<br />
== Examples ==<br />
<br />
Here are some real world examples where folks have encountered the need to explicitly indicate that an embedded microformat does not introduce properties to its container.<br />
<br />
=== hCard in hCalendar ===<br />
<br />
[[http://playinghere.com/ PlayingHere.com]] includes thousands of hCalendar events with embedded hCard contacts. The contacts have URLs, the events do not, and these contact URLs are treated as event URLs, which is not what the author intended. An example of the markup:<br />
<br />
<pre><nowiki><br />
<body class="vevent"><br />
[...]<br />
<h1 class="vcard organizer"><span class="summary">June 19th, 2007 at <span class="fn org">Varsity Theatre</span></span></h1><br />
[...]<br />
<h3><br />
<span class="attendee vcard"><a href="http://playinghere.com/band/armyofme/" class="fn url">ARMY OF ME</a></span><br />
at <abbr class="dtstart" title="2007-06-19T17:00:00-07:00">5:00 pm</abbr><br />
</h3><br />
[...]<br />
</body><br />
</nowiki></pre><br />
<br />
[[http://eventful.com/ Eventful]] includes tens of thousands (hundreds of thousands?) of hCalendar events with embedded hCard contacts. The contacts and events both have URLs. Because the contact URLs come first, they take precedence over the event URLs (at least in X2V) when the event data is exported. As a result, the real event URL is replaced with a less useful URL, which is not what the author intended. And example of the markup:<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
[...]<br />
<h1 class="summary">Brown Bag Music Series</h1><br />
[...]<br />
<h2>When</h2><br />
<p><br />
<abbr class="dtstart" title="20070619T120000">Tuesday, June 19, 2007 12:00 PM</abbr><br />
</p><br />
[...]<br />
<h2>Where</h2><br />
<div class="location vcard"><br />
<a rel="bookmark" class="url uid fn org" href="/venues/V0-001-000395941-4">Denver Public Library - Central Branch</a><br />
[...]<br />
</div><br />
[...]<br />
<a class="url" href="/r/http://www.denver365.com/index.php?app=eventDetail&amp;id=73358">Event details at www.denver365.com</a><br />
[...]<br />
</div><br />
</nowiki></pre><br />
<br />
=== hAtom ===<br />
<br />
Container microformats use context in a similar way to that of conventional XML. When an Atom document includes the element <author> it is context that determines whether the author of a feed or the author of an entry is being specified. However, contrary to convetional XML microformats support forwards compatibility with must-ignore semantics for intervening elements between the context and data. This introduces a problem of identifying contexts that may have been ignored in parsing. If hAtom finds an author element belonging a new microformat that it does not recognise, it may incorrectly summise that the author element belongs to it and refers to it. In fact, it refers to the unknown microformat. Any other inference is invalid.<br />
<br />
Elements that have different meanings in different microformats also pose a problem. [[hcard|hCard]] includes a title element meaning approximately "a person's job title". Atom and various other specifications use title to mean "the title of this document or sub-document". [[hreview|hReview]] avoided the use of title by re-using "summary" from [[hcalendar|hCalendar]] element, however this also clashes with the atom namespace. hReview uses summary to mean "review title", while atom uses summary to mean "abbreviated content, both longer than title and shorter than content".<br />
<br />
[[hatom|hAtom]] currently attempts to resolve both the context problem and the nomenclature problem by explicitly naming child elements as opaque. Currently "content" and "summary" (will likely change) are considered completely opaque, while "author" and "contributor" are only scanned for [[hcard|hCard]] content. This may be an incomplete solution if hCards or other context microformats are included outside of these nodes.<br />
<br />
=== hAtom and other microformats ===<br />
<br />
One might say that if a parser understands hAtom, then there's no need for explicitly <br />
marking opaque elements as opaque.<br />
<br />
This is true, for [[hatom|hAtom]] parsers, and I (Tantek) made the same argument originally for [[hcard|hCard]], and [[hcalendar|hCalendar]], and [[hreview|hReview]], e.g. if a parser understands hCard, then there's no need for explicitly marking opaque elements as opaque.<br />
<br />
However, what happens when an hReview parser, which was written before hAtom was conceived, encounters mixed hReview + hAtom content?<br />
<br />
The whole need for marking opaque elements explicitly as opaque is to enable *current/old* microformat parsers to NOT be confused by new microformats which happen to reuse vocabulary.<br />
<br />
Another way of looking at this is that by agreeing on a neutral opacity class name, we avoid the need for every microformat parser to have to know about every microformat. I'm sure you can imagine how much of a burden that might become over time.<br />
<br />
=== hAtom and hReview - an example of overlay ===<br />
<br />
It could be said that certain microformats, e.g. hAtom, hReview, [[xfolk|xFolk]], can be "overlayed" (different from "composited").<br />
<br />
In particular you can do do this:<br />
<pre><nowiki><br />
<div class="hatom hreview"><br />
...<br />
</div><br />
</nowiki></pre><br />
<br />
and have the expected right thing happen.<br />
<br />
In fact, hReview is a perfect example of a microformat that sometimes you will want to make opaque, and sometimes you will want to overlay. Or perhaps you will want to overlay *most* of an hReview, and mark part of it (such as the "reviewer") as opaque.<br />
<br />
Thus we actually cannot assume an hReview either whole or in part is either opaque or transparent. We actually need another "bit" of information to indicate that aspect of opacity on the hReview as a whole, or in parts of it..<br />
<br />
== Similar or Related Problems ==<br />
<br />
=== Microformat Property ===<br />
<br />
Just as using the class name "mfo" could be used to identify the existence of an arbitrary "microformat object" which by its very nature of being an object, should be opaque to any containing microformat (as described above), it may also be worth considering the use of a general purpose class name like "mfp" to indicate that an element represents a microformat property. This would allow auto-recognition of properties of an arbitrary new microformat without having to read the profile for that microformat explicitly.<br />
<br />
==== Challenges ====<br />
<br />
Since there are type specific markup and parsing interpretations, there may need to be several such classes to indicate types of microformat properties that require special parsing (see [[hcard-parsing]] for details for [[hcard|hCard]] in particular). E.g.: datetime (must prefer 'title' attribute to element contents), url (must prefer href/data/src attributes on a/object/img elements over element contents), email (similar to URL but "mailto:" is pruned). Some questions<br />
* Would there simply be separate class names like "mfdt", "mfu", "mfe"? <br />
* How useful would this be without knowing more about the specific microformat? <br />
* Is that set of types fixed or would we need to add more in the future? <br />
* Do we thus reserve all class names that start with "mf"?<br />
* Is this walking too much down the path of coming up with answers to generic / general-purpose questions which violate our [[microformats]] principles?<br />
* Is this a solution looking for a problem?<br />
<br />
== Related Pages ==<br />
<br />
* [[mfo-brainstorming]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=mfo-examples&diff=17674mfo-examples2007-06-20T01:11:07Z<p>ScottReynen: /* Examples */</p>
<hr />
<div>= MFO examples =<br />
<br />
Microformat Object or Microformat Opacity or Microformat Opaque<br />
<br />
== Contributors ==<br />
<br />
* Tantek Çelik<br />
<br />
== The Problem ==<br />
<br />
Both recent discussions around hAtom, and earlier discussions from June of 2005 have indicated that there may be a need for a generic microformat to indicate that a specific element is a wrapper, container, or layer of abstraction, that should be opaque to something parsing the microformats that may be further up the hierarchy.<br />
<br />
E.g. you might put a <code>&lt;span class="vcard mfo"&gt;</code> deep inside a <code>&lt;span class="vevent"&gt;</code>, and not want the categories/tags of the [[hcard|hCard]] accidentally parsed into the hCalendar event.<br />
<br />
Note: the use of "mfo" is only for the purpose of illustration is by no means a proposed name for this microformat. We expect research/discussion to reveal a much better name. We use "mfo" only as a temporary name for the sake of discussion and example illustration. We may even want to commit to deliberately using a class name different from "mfo" just to make this clear in the end.<br />
<br />
== Forward Compatibility for Parsers ==<br />
<br />
Part of the point of this is to help with forward compatibility for parsers.<br />
<br />
Thus an hCalendar parser might need not know about hCard (even though in practice they probably will). As the number of microformats grows, the chances that a new microformat may confuse an old parser due to the scenario outlined above increases. Thus we are considering making it explicit when a new "root" microformat is established.<br />
<br />
== To Do ==<br />
<br />
In order:<br />
<br />
# fill out the real world examples below<br />
# create [[mfo-formats]] page for researching/describing how other data formats indicate this kind of "abstraction", including the various terms they use like "object", "container", etc.<br />
# create [[mfo-brainstorming]] page where we discuss how this should work, and candidate names. Some candidate names that have been offered to date: u, uf, object, container, root, mfo...<br />
<br />
== Examples ==<br />
<br />
Here are some real world examples where folks have encountered the need to explicitly indicate that an embedded microformat does not introduce properties to its container.<br />
<br />
=== hCard in hCalendar ===<br />
<br />
[[http://playinghere.com/ PlayingHere.com]] includes thousands of hCalendar events with embedded hCard contacts. The contacts have URLs, the events do not, and these contact URLs are treated as event URLs, which is not what the author intended. And example of the markup:<br />
<br />
<pre><nowiki><br />
<body class="vevent"><br />
[...]<br />
<h1 class="vcard organizer"><span class="summary">June 19th, 2007 at <span class="fn org">Varsity Theatre</span></span></h1><br />
[...]<br />
<h3><br />
<span class="attendee vcard"><a href="http://playinghere.com/band/armyofme/" class="fn url">ARMY OF ME</a></span><br />
at <abbr class="dtstart" title="2007-06-19T17:00:00-07:00">5:00 pm</abbr><br />
</h3><br />
[...]<br />
</body><br />
</nowiki></pre><br />
<br />
=== hAtom ===<br />
<br />
Container microformats use context in a similar way to that of conventional XML. When an Atom document includes the element <author> it is context that determines whether the author of a feed or the author of an entry is being specified. However, contrary to convetional XML microformats support forwards compatibility with must-ignore semantics for intervening elements between the context and data. This introduces a problem of identifying contexts that may have been ignored in parsing. If hAtom finds an author element belonging a new microformat that it does not recognise, it may incorrectly summise that the author element belongs to it and refers to it. In fact, it refers to the unknown microformat. Any other inference is invalid.<br />
<br />
Elements that have different meanings in different microformats also pose a problem. [[hcard|hCard]] includes a title element meaning approximately "a person's job title". Atom and various other specifications use title to mean "the title of this document or sub-document". [[hreview|hReview]] avoided the use of title by re-using "summary" from [[hcalendar|hCalendar]] element, however this also clashes with the atom namespace. hReview uses summary to mean "review title", while atom uses summary to mean "abbreviated content, both longer than title and shorter than content".<br />
<br />
[[hatom|hAtom]] currently attempts to resolve both the context problem and the nomenclature problem by explicitly naming child elements as opaque. Currently "content" and "summary" (will likely change) are considered completely opaque, while "author" and "contributor" are only scanned for [[hcard|hCard]] content. This may be an incomplete solution if hCards or other context microformats are included outside of these nodes.<br />
<br />
=== hAtom and other microformats ===<br />
<br />
One might say that if a parser understands hAtom, then there's no need for explicitly <br />
marking opaque elements as opaque.<br />
<br />
This is true, for [[hatom|hAtom]] parsers, and I (Tantek) made the same argument originally for [[hcard|hCard]], and [[hcalendar|hCalendar]], and [[hreview|hReview]], e.g. if a parser understands hCard, then there's no need for explicitly marking opaque elements as opaque.<br />
<br />
However, what happens when an hReview parser, which was written before hAtom was conceived, encounters mixed hReview + hAtom content?<br />
<br />
The whole need for marking opaque elements explicitly as opaque is to enable *current/old* microformat parsers to NOT be confused by new microformats which happen to reuse vocabulary.<br />
<br />
Another way of looking at this is that by agreeing on a neutral opacity class name, we avoid the need for every microformat parser to have to know about every microformat. I'm sure you can imagine how much of a burden that might become over time.<br />
<br />
=== hAtom and hReview - an example of overlay ===<br />
<br />
It could be said that certain microformats, e.g. hAtom, hReview, [[xfolk|xFolk]], can be "overlayed" (different from "composited").<br />
<br />
In particular you can do do this:<br />
<pre><nowiki><br />
<div class="hatom hreview"><br />
...<br />
</div><br />
</nowiki></pre><br />
<br />
and have the expected right thing happen.<br />
<br />
In fact, hReview is a perfect example of a microformat that sometimes you will want to make opaque, and sometimes you will want to overlay. Or perhaps you will want to overlay *most* of an hReview, and mark part of it (such as the "reviewer") as opaque.<br />
<br />
Thus we actually cannot assume an hReview either whole or in part is either opaque or transparent. We actually need another "bit" of information to indicate that aspect of opacity on the hReview as a whole, or in parts of it..<br />
<br />
== Similar or Related Problems ==<br />
<br />
=== Microformat Property ===<br />
<br />
Just as using the class name "mfo" could be used to identify the existence of an arbitrary "microformat object" which by its very nature of being an object, should be opaque to any containing microformat (as described above), it may also be worth considering the use of a general purpose class name like "mfp" to indicate that an element represents a microformat property. This would allow auto-recognition of properties of an arbitrary new microformat without having to read the profile for that microformat explicitly.<br />
<br />
==== Challenges ====<br />
<br />
Since there are type specific markup and parsing interpretations, there may need to be several such classes to indicate types of microformat properties that require special parsing (see [[hcard-parsing]] for details for [[hcard|hCard]] in particular). E.g.: datetime (must prefer 'title' attribute to element contents), url (must prefer href/data/src attributes on a/object/img elements over element contents), email (similar to URL but "mailto:" is pruned). Some questions<br />
* Would there simply be separate class names like "mfdt", "mfu", "mfe"? <br />
* How useful would this be without knowing more about the specific microformat? <br />
* Is that set of types fixed or would we need to add more in the future? <br />
* Do we thus reserve all class names that start with "mf"?<br />
* Is this walking too much down the path of coming up with answers to generic / general-purpose questions which violate our [[microformats]] principles?<br />
* Is this a solution looking for a problem?<br />
<br />
== Related Pages ==<br />
<br />
* [[mfo-brainstorming]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=mfo-examples&diff=17673mfo-examples2007-06-20T01:04:15Z<p>ScottReynen: </p>
<hr />
<div>= MFO examples =<br />
<br />
Microformat Object or Microformat Opacity or Microformat Opaque<br />
<br />
== Contributors ==<br />
<br />
* Tantek Çelik<br />
<br />
== The Problem ==<br />
<br />
Both recent discussions around hAtom, and earlier discussions from June of 2005 have indicated that there may be a need for a generic microformat to indicate that a specific element is a wrapper, container, or layer of abstraction, that should be opaque to something parsing the microformats that may be further up the hierarchy.<br />
<br />
E.g. you might put a <code>&lt;span class="vcard mfo"&gt;</code> deep inside a <code>&lt;span class="vevent"&gt;</code>, and not want the categories/tags of the [[hcard|hCard]] accidentally parsed into the hCalendar event.<br />
<br />
Note: the use of "mfo" is only for the purpose of illustration is by no means a proposed name for this microformat. We expect research/discussion to reveal a much better name. We use "mfo" only as a temporary name for the sake of discussion and example illustration. We may even want to commit to deliberately using a class name different from "mfo" just to make this clear in the end.<br />
<br />
== Forward Compatibility for Parsers ==<br />
<br />
Part of the point of this is to help with forward compatibility for parsers.<br />
<br />
Thus an hCalendar parser might need not know about hCard (even though in practice they probably will). As the number of microformats grows, the chances that a new microformat may confuse an old parser due to the scenario outlined above increases. Thus we are considering making it explicit when a new "root" microformat is established.<br />
<br />
== To Do ==<br />
<br />
In order:<br />
<br />
# fill out the real world examples below<br />
# create [[mfo-formats]] page for researching/describing how other data formats indicate this kind of "abstraction", including the various terms they use like "object", "container", etc.<br />
# create [[mfo-brainstorming]] page where we discuss how this should work, and candidate names. Some candidate names that have been offered to date: u, uf, object, container, root, mfo...<br />
<br />
== Examples ==<br />
<br />
Here are some real world examples where folks have encountered the need to explicitly indicate that an embedded microformat does not introduce properties to its container.<br />
<br />
=== hAtom ===<br />
<br />
Container microformats use context in a similar way to that of conventional XML. When an Atom document includes the element <author> it is context that determines whether the author of a feed or the author of an entry is being specified. However, contrary to convetional XML microformats support forwards compatibility with must-ignore semantics for intervening elements between the context and data. This introduces a problem of identifying contexts that may have been ignored in parsing. If hAtom finds an author element belonging a new microformat that it does not recognise, it may incorrectly summise that the author element belongs to it and refers to it. In fact, it refers to the unknown microformat. Any other inference is invalid.<br />
<br />
Elements that have different meanings in different microformats also pose a problem. [[hcard|hCard]] includes a title element meaning approximately "a person's job title". Atom and various other specifications use title to mean "the title of this document or sub-document". [[hreview|hReview]] avoided the use of title by re-using "summary" from [[hcalendar|hCalendar]] element, however this also clashes with the atom namespace. hReview uses summary to mean "review title", while atom uses summary to mean "abbreviated content, both longer than title and shorter than content".<br />
<br />
[[hatom|hAtom]] currently attempts to resolve both the context problem and the nomenclature problem by explicitly naming child elements as opaque. Currently "content" and "summary" (will likely change) are considered completely opaque, while "author" and "contributor" are only scanned for [[hcard|hCard]] content. This may be an incomplete solution if hCards or other context microformats are included outside of these nodes.<br />
<br />
=== hAtom and other microformats ===<br />
<br />
One might say that if a parser understands hAtom, then there's no need for explicitly <br />
marking opaque elements as opaque.<br />
<br />
This is true, for [[hatom|hAtom]] parsers, and I (Tantek) made the same argument originally for [[hcard|hCard]], and [[hcalendar|hCalendar]], and [[hreview|hReview]], e.g. if a parser understands hCard, then there's no need for explicitly marking opaque elements as opaque.<br />
<br />
However, what happens when an hReview parser, which was written before hAtom was conceived, encounters mixed hReview + hAtom content?<br />
<br />
The whole need for marking opaque elements explicitly as opaque is to enable *current/old* microformat parsers to NOT be confused by new microformats which happen to reuse vocabulary.<br />
<br />
Another way of looking at this is that by agreeing on a neutral opacity class name, we avoid the need for every microformat parser to have to know about every microformat. I'm sure you can imagine how much of a burden that might become over time.<br />
<br />
=== hAtom and hReview - an example of overlay ===<br />
<br />
It could be said that certain microformats, e.g. hAtom, hReview, [[xfolk|xFolk]], can be "overlayed" (different from "composited").<br />
<br />
In particular you can do do this:<br />
<pre><nowiki><br />
<div class="hatom hreview"><br />
...<br />
</div><br />
</nowiki></pre><br />
<br />
and have the expected right thing happen.<br />
<br />
In fact, hReview is a perfect example of a microformat that sometimes you will want to make opaque, and sometimes you will want to overlay. Or perhaps you will want to overlay *most* of an hReview, and mark part of it (such as the "reviewer") as opaque.<br />
<br />
Thus we actually cannot assume an hReview either whole or in part is either opaque or transparent. We actually need another "bit" of information to indicate that aspect of opacity on the hReview as a whole, or in parts of it..<br />
<br />
== Similar or Related Problems ==<br />
<br />
=== Microformat Property ===<br />
<br />
Just as using the class name "mfo" could be used to identify the existence of an arbitrary "microformat object" which by its very nature of being an object, should be opaque to any containing microformat (as described above), it may also be worth considering the use of a general purpose class name like "mfp" to indicate that an element represents a microformat property. This would allow auto-recognition of properties of an arbitrary new microformat without having to read the profile for that microformat explicitly.<br />
<br />
==== Challenges ====<br />
<br />
Since there are type specific markup and parsing interpretations, there may need to be several such classes to indicate types of microformat properties that require special parsing (see [[hcard-parsing]] for details for [[hcard|hCard]] in particular). E.g.: datetime (must prefer 'title' attribute to element contents), url (must prefer href/data/src attributes on a/object/img elements over element contents), email (similar to URL but "mailto:" is pruned). Some questions<br />
* Would there simply be separate class names like "mfdt", "mfu", "mfe"? <br />
* How useful would this be without knowing more about the specific microformat? <br />
* Is that set of types fixed or would we need to add more in the future? <br />
* Do we thus reserve all class names that start with "mf"?<br />
* Is this walking too much down the path of coming up with answers to generic / general-purpose questions which violate our [[microformats]] principles?<br />
* Is this a solution looking for a problem?<br />
<br />
== Related Pages ==<br />
<br />
* [[mfo-brainstorming]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=mfo-examples&diff=17672mfo-examples2007-06-20T01:03:43Z<p>ScottReynen: </p>
<hr />
<div>= MFO examples =<br />
<br />
Microformat Object or Microformat Opacity or Microformat Opaque<br />
<br />
== Contributors ==<br />
<br />
* Tantek Çelik<br />
<br />
== The Problem ==<br />
<br />
Both recent discussions around hAtom, and earlier discussions from June of 2005 have indicated that there may be a need for a generic microformat to indicate that a specific element is a wrapper, container, or layer of abstraction, that should be opaque to something parsing the microformats that may be further up the hierarchy.<br />
<br />
E.g. you might put a <code>&lt;span class="vcard mfo"&gt;</code> deep inside a <code>&lt;span class="vevent"&gt;</code>, and not want the categories/tags of the [[hcard|hCard]] accidentally parsed into the hCalendar event.<br />
<br />
Note: the use of "mfo" is only for the purpose of illustration is by no means a proposed name for this microformat. We expect research/discussion to reveal a much better name. We use "mfo" only as a temporary name for the sake of discussion and example illustration. We may even want to commit to deliberately using a class name different from "mfo" just to make this clear in the end.<br />
<br />
== Forward Compatibility for Parsers ==<br />
<br />
Part of the point of this is to help with forward compatibility for parsers.<br />
<br />
Thus an hCalendar parser might need not know about hCard (even though in practice they probably will). As the number of microformats grows, the chances that a new microformat may confuse an old parser due to the scenario outlined above increases. Thus we are considering making it explicit when a new "root" microformat is established.<br />
<br />
== To Do ==<br />
<br />
In order:<br />
<br />
# fill out the real world examples below<br />
# create [[mfo-formats]] page for researching/describing how other data formats indicate this kind of "abstraction", including the various terms they use like "object", "container", etc.<br />
# create [[mfo-brainstorming]] page where we discuss how this should work, and candidate names. Some candidate names that have been offered to date: u, uf, object, container, root, mfo...<br />
<br />
== Examples ==<br />
<br />
Here are some real world examples where folks have encountered the need to explicitly indicate that an embedded microformat does not introduce properties to its container.<br />
<br />
=== hAtom ===<br />
<br />
Container microformats use context in a similar way to that of conventional XML. When an Atom document includes the element <author> it is context that determines whether the author of a feed or the author of an entry is being specified. However, contrary to convetional XML microformats support forwards compatibility with must-ignore semantics for intervening elements between the context and data. This introduces a problem of identifying contexts that may have been ignored in parsing. If hAtom finds an author element belonging a new microformat that it does not recognise, it may incorrectly summise that the author element belongs to it and refers to it. In fact, it refers to the unknown microformat. Any other inference is invalid.<br />
<br />
Elements that have different meanings in different microformats also pose a problem. [[hcard|hCard]] includes a title element meaning approximately "a person's job title". Atom and various other specifications use title to mean "the title of this document or sub-document". [[hreview|hReview]] avoided the use of title by re-using "summary" from [[hcalendar|hCalendar]] element, however this also clashes with the atom namespace. hReview uses summary to mean "review title", while atom uses summary to mean "abbreviated content, both longer than title and shorter than content".<br />
<br />
[[hatom|hAtom]] currently attempts to resolve both the context problem and the nomenclature problem by explicitly naming child elements as opaque. Currently "content" and "summary" (will likely change) are considered completely opaque, while "author" and "contributor" are only scanned for [[hcard|hCard]] content. This may be an incomplete solution if hCards or other context microformats are included outside of these nodes.<br />
<br />
=== hAtom and other microformats ===<br />
<br />
One might say that if a parser understands hAtom, then there's no need for explicitly <br />
marking opaque elements as opaque.<br />
<br />
This is true, for [[hatom|hAtom]] parsers, and I (Tantek) made the same argument originally for [[hcard|hCard]], and [[hcalendar|hCalendar]], and [[hreview|hReview]], e.g. if a parser understands hCard, then there's no need for explicitly marking opaque elements as opaque.<br />
<br />
However, what happens when an hReview parser, which was written before hAtom was conceived, encounters mixed hReview + hAtom content?<br />
<br />
The whole need for marking opaque elements explicitly as opaque is to enable *current/old* microformat parsers to NOT be confused by new microformats which happen to reuse vocabulary.<br />
<br />
Another way of looking at this is that by agreeing on a neutral opacity class name, we avoid the need for every microformat parser to have to know about every microformat. I'm sure you can imagine how much of a burden that might become over time.<br />
<br />
=== hAtom and hReview - an example of overlay ===<br />
<br />
It could be said that certain microformats, e.g. hAtom, hReview, [[xfolk|xFolk]], can be "overlayed" (different from "composited").<br />
<br />
In particular you can do do this:<br />
<pre><nowiki><br />
<div class="hatom hreview"><br />
...<br />
</div><br />
</nowiki></pre><br />
<br />
and have the expected right thing happen.<br />
<br />
In fact, hReview is a perfect example of a microformat that sometimes you will want to make opaque, and sometimes you will want to overlay. Or perhaps you will want to overlay *most* of an hReview, and mark part of it (such as the "reviewer") as opaque.<br />
<br />
Thus we actually cannot assume an hReview either whole or in part is either opaque or transparent. We actually need another "bit" of information to indicate that aspect of opacity on the hReview as a whole, or in parts of it..<br />
<br />
== Similar or Related Problems ==<br />
<br />
=== Microformat Property ===<br />
<br />
Just as using the class name "mfo" could be used to identify the existence of an arbitrary "microformat object" which by its very nature of being an object, should be opaque to any containing microformat (as described above), it may also be worth considering the use of a general purpose class name like "mfp" to indicate that an element represents a microformat property. This would allow auto-recognition of properties of an arbitrary new microformat without having to read the profile for that microformat explicitly.<br />
<br />
==== Challenges ====<br />
<br />
Since there are type specific markup and parsing interpretations, there may need to be several such classes to indicate types of microformat properties that require special parsing (see [[hcard-parsing]] for details for [[hcard|hCard]] in particular). E.g.: datetime (must prefer 'title' attribute to element contents), url (must prefer href/data/src attributes on a/object/img elements over element contents), email (similar to URL but "mailto:" is pruned). Some questions<br />
* Would there simply be separate class names like "mfdt", "mfu", "mfe"? <br />
* How useful would this be without knowing more about the specific microformat? <br />
* Is that set of types fixed or would we need to add more in the future? <br />
* Do we thus reserve all class names that start with "mf"?<br />
* Is this walking too much down the path of coming up with answers to generic / general-purpose questions which violate our [[microformats]] principles?<br />
* Is this a solution looking for a problem?<br />
<br />
== Related Pages ==<br />
<br />
* [[mfo-brainstorming]]<br />
* [[mfo-examples]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=mfo-examples&diff=17671mfo-examples2007-06-20T01:03:00Z<p>ScottReynen: </p>
<hr />
<div>= MFO examples =<br />
<br />
Microformat Object or Microformat Opacity or Microformat Opaque<br />
<br />
== Contributors ==<br />
<br />
* Tantek Çelik<br />
<br />
== The Problem ==<br />
<br />
Both recent discussions around hAtom, and earlier discussions from June of 2005 have indicated that there may be a need for a generic microformat to indicate that a specific element is a wrapper, container, or layer of abstraction, that should be opaque to something parsing the microformats that may be further up the hierarchy.<br />
<br />
E.g. you might put a <code>&lt;span class="vcard mfo"&gt;</code> deep inside a <code>&lt;span class="vevent"&gt;</code>, and not want the categories/tags of the [[hcard|hCard]] accidentally parsed into the hCalendar event.<br />
<br />
Note: the use of "mfo" is only for the purpose of illustration is by no means a proposed name for this microformat. We expect research/discussion to reveal a much better name. We use "mfo" only as a temporary name for the sake of discussion and example illustration. We may even want to commit to deliberately using a class name different from "mfo" just to make this clear in the end.<br />
<br />
== Forward Compatibility for Parsers ==<br />
<br />
Part of the point of this is to help with forward compatibility for parsers.<br />
<br />
Thus an hCalendar parser might need not know about hCard (even though in practice they probably will). As the number of microformats grows, the chances that a new microformat may confuse an old parser due to the scenario outlined above increases. Thus we are considering making it explicit when a new "root" microformat is established.<br />
<br />
== To Do ==<br />
<br />
In order:<br />
<br />
# fill out the real world examples below<br />
# create [[mfo-formats]] page for researching/describing how other data formats indicate this kind of "abstraction", including the various terms they use like "object", "container", etc.<br />
# create [[mfo-brainstorming]] page where we discuss how this should work, and candidate names. Some candidate names that have been offered to date: u, uf, object, container, root, mfo...<br />
<br />
== Examples ==<br />
<br />
Here are some real world examples where folks have encountered the need to explicitly indicate that an embedded microformat does not introduce properties to its container.<br />
<br />
=== hAtom ===<br />
<br />
Container microformats use context in a similar way to that of conventional XML. When an Atom document includes the element <author> it is context that determines whether the author of a feed or the author of an entry is being specified. However, contrary to convetional XML microformats support forwards compatibility with must-ignore semantics for intervening elements between the context and data. This introduces a problem of identifying contexts that may have been ignored in parsing. If hAtom finds an author element belonging a new microformat that it does not recognise, it may incorrectly summise that the author element belongs to it and refers to it. In fact, it refers to the unknown microformat. Any other inference is invalid.<br />
<br />
Elements that have different meanings in different microformats also pose a problem. [[hcard|hCard]] includes a title element meaning approximately "a person's job title". Atom and various other specifications use title to mean "the title of this document or sub-document". [[hreview|hReview]] avoided the use of title by re-using "summary" from [[hcalendar|hCalendar]] element, however this also clashes with the atom namespace. hReview uses summary to mean "review title", while atom uses summary to mean "abbreviated content, both longer than title and shorter than content".<br />
<br />
[[hatom|hAtom]] currently attempts to resolve both the context problem and the nomenclature problem by explicitly naming child elements as opaque. Currently "content" and "summary" (will likely change) are considered completely opaque, while "author" and "contributor" are only scanned for [[hcard|hCard]] content. This may be an incomplete solution if hCards or other context microformats are included outside of these nodes.<br />
<br />
=== hAtom and other microformats ===<br />
<br />
One might say that if a parser understands hAtom, then there's no need for explicitly <br />
marking opaque elements as opaque.<br />
<br />
This is true, for [[hatom|hAtom]] parsers, and I (Tantek) made the same argument originally for [[hcard|hCard]], and [[hcalendar|hCalendar]], and [[hreview|hReview]], e.g. if a parser understands hCard, then there's no need for explicitly marking opaque elements as opaque.<br />
<br />
However, what happens when an hReview parser, which was written before hAtom was conceived, encounters mixed hReview + hAtom content?<br />
<br />
The whole need for marking opaque elements explicitly as opaque is to enable *current/old* microformat parsers to NOT be confused by new microformats which happen to reuse vocabulary.<br />
<br />
Another way of looking at this is that by agreeing on a neutral opacity class name, we avoid the need for every microformat parser to have to know about every microformat. I'm sure you can imagine how much of a burden that might become over time.<br />
<br />
=== hAtom and hReview - an example of overlay ===<br />
<br />
It could be said that certain microformats, e.g. hAtom, hReview, [[xfolk|xFolk]], can be "overlayed" (different from "composited").<br />
<br />
In particular you can do do this:<br />
<pre><nowiki><br />
<div class="hatom hreview"><br />
...<br />
</div><br />
</nowiki></pre><br />
<br />
and have the expected right thing happen.<br />
<br />
In fact, hReview is a perfect example of a microformat that sometimes you will want to make opaque, and sometimes you will want to overlay. Or perhaps you will want to overlay *most* of an hReview, and mark part of it (such as the "reviewer") as opaque.<br />
<br />
Thus we actually cannot assume an hReview either whole or in part is either opaque or transparent. We actually need another "bit" of information to indicate that aspect of opacity on the hReview as a whole, or in parts of it..<br />
<br />
== Similar or Related Problems ==<br />
<br />
=== Microformat Property ===<br />
<br />
Just as using the class name "mfo" could be used to identify the existence of an arbitrary "microformat object" which by its very nature of being an object, should be opaque to any containing microformat (as described above), it may also be worth considering the use of a general purpose class name like "mfp" to indicate that an element represents a microformat property. This would allow auto-recognition of properties of an arbitrary new microformat without having to read the profile for that microformat explicitly.<br />
<br />
==== Challenges ====<br />
<br />
Since there are type specific markup and parsing interpretations, there may need to be several such classes to indicate types of microformat properties that require special parsing (see [[hcard-parsing]] for details for [[hcard|hCard]] in particular). E.g.: datetime (must prefer 'title' attribute to element contents), url (must prefer href/data/src attributes on a/object/img elements over element contents), email (similar to URL but "mailto:" is pruned). Some questions<br />
* Would there simply be separate class names like "mfdt", "mfu", "mfe"? <br />
* How useful would this be without knowing more about the specific microformat? <br />
* Is that set of types fixed or would we need to add more in the future? <br />
* Do we thus reserve all class names that start with "mf"?<br />
* Is this walking too much down the path of coming up with answers to generic / general-purpose questions which violate our [[microformats]] principles?<br />
* Is this a solution looking for a problem?<br />
<br />
== Related Pages ==<br />
<br />
[[mfo-brainstorming]]<br />
[[mfo-examples]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=Main_Page-pt-br&diff=17644Main Page-pt-br2007-06-19T01:36:01Z<p>ScottReynen: Reverted edit of BnvQmr, changed back to last version by Tantek</p>
<hr />
<div>__NOTOC__<br />
<br />
= Microformatos Wiki =<br />
<br />
<br />
'''Olá!''' Bem vindo ao microformatos wiki. Se esta é sua primeira visita, por favor veja a página de [[introduction-pt-br|introdução]].<br />
<br />
Por favor, leia [[how-to-play-pt-br|o que fazer]] antes de fazer qualquer edição.<br />
<br />
Por favor, leia o [[process-pt-br|procedimento]] antes de propor qualquer novo microformato.<br />
<br />
__TOC__<br />
<br />
==Guia Rápido==<br />
<br />
[[what-are-microformats|O que são microformatos]]? [[what-can-you-do-with-microformats|O que você pode fazer com eles]]? <br />
<br />
A [http://microformats.org/about/ página about], e mais recente [[press]], [[presentations]], [[podcasts]], and [[screencasts]] são bom locais para informações a fundo. <br />
<br />
As perguntas feitas com mais frequência sobre o wiki e microformatos em geral são respondidas no [[faq]].<br />
<br />
Quer aprender mais pessoalmente? Verifique os [[events|eventos]].<br />
<br />
==Definição==<br />
<br />
Uma definição popular da nossa [http://microformats.org/discuss/ lista de discussão] (ver também: [[mailing-lists]]) é "convenções simples para combinar semântica em HTML para permitir o desenvolvimento decentralizado." Mais precisamente, microformatos podem ser definidos como:<br />
:convenções simples<br />
:para combinar com marcação semântica<br />
::for a specific problem domain<br />
:para ser legível aos humanos, documentos (X)HTML/XML, feeds Atom/RSS, e XML "plano"<br />
::que padroniza existente conteúdo com uso de padrões.<br />
::usando brief, descritivas nomes de classes<br />
::baseada frequentemente nos existentes padrões de interoperabilidade<br />
:para permitir desenvolvimento decentralizado<br />
::de recursos, ferramentas, e serviços<br />
<br />
Simplesmente coloque: "Microformatos são uma codificação de convenção." -- [http://easy-reader.net Aaron Gustafson]<br />
<br />
"Ou você só usa seu browser para navegar? Então isto é o século 20." -- [http://diveintomark.org Mark Pilgrim]<br />
<br />
== Como contribuir ==<br />
<br />
Você quer ajudar a levar microformatos ao próximo nível? Você pode:<br />
<br />
*Verificar as coisas em aberto [[to-do-pt-br|lista do que fazer]] para ajudar a concluir.<br />
*Ingressar na [http://microformats.org/discuss lista de emails] e [[irc|Canal de IRC]] para aprender como ajudar a responder perguntas sobre microformatos.<br />
*[[advocacy|Advocacia]] o uso de microformatos.<br />
*Ajudar a [[Main_Page#microformats_wiki_in_other_languages|traduza o microformatos wiki para outras linguagens]] e tornar microformatos globalmente acessível.<br />
<br />
== Especificações ==<br />
[[microformats-pt-br|Microformatos]] especificações de padrões abertos (ver também: [[implementations-pt-br|implementações]])<br />
* [[hcalendar-pt-br|hCalendar]] - [http://microformats.org/code/hcalendar/creator hcalendar creator]<br />
* [[hcard-pt-br|hCard]] - [http://microformats.org/code/hcard/creator hcard creator]<br />
* [[rel-license-pt-br|rel-license]]<br />
* [[rel-nofollow-pt-br|rel-nofollow]]<br />
* [[rel-tag-pt-br|rel-tag]]<br />
* [[vote-links-pt-br|VoteLinks]]<br />
* [http://gmpg.org/xfn/ XFN] (ver também: [[xfn-implementations]])<br />
* [http://gmpg.org/xmdp/ XMDP]<br />
* [[xoxo-pt-br|XOXO]]<br />
<br />
== Esboços ==<br />
* [[adr|adr]]<br />
* [[geo|geo]]<br />
* [[hatom|hAtom]] {{NewMarker-pt-br}}<br />
* [[hresume|hResume]] {{NewMarker-pt-br}}<br />
* [[hreview|hReview]] - [http://microformats.org/code/hreview/creator hreview creator]<br />
* [[rel-directory]]<br />
* [[rel-enclosure]]<br />
* [[rel-home]]<br />
* [[relpayment-research | rel-payment]]<br />
* [[robots-exclusion|Robots Exclusion]]<br />
* [[xfolk-pt-br|xFolk]]<br />
<br />
== Padrões do projeto ==<br />
<br />
{{design_patterns}} <!-- this can be edited in /wiki/Template:design_patterns --><br />
<br />
== Discussões exploratória ==<br />
Pesquisa e análises do mundo real [[examples|exemplos]], formatos existentes e idéias para motivar o microformatos.<br />
*alternates [[alternates-brainstorming]], [[alternates-examples]]<br />
*[[attention]]<br />
* blog description [[blog-description-examples|examplos]]<br />
* blog info [[blog-info-examples|exemplos]]<br />
* blog post [[blog-post-examples|exemplos]], [[blog-post-formats|formatos]], e [[blog-post-brainstorming|brainstorming]] (yielded the [[hatom|hAtom]] draft)<br />
* book [[book-examples|exemplos]], [[book-formats|formatos]], e [[book-brainstorming|brainstorming]]<br />
* chat [[chat-examples|exemplos]], [[chat-formats|formatos]], e [[chat-brainstorming|brainstorming]]<br />
* citation [[citation|effort]], [[citation-examples|examples]], [[citation-formats|formatos]], [[citation-brainstorming|brainstorming]], e [[citation-faq|FAQ]]<br />
* comment [[comment-problem|problem]], [[comment-examples|examples]], e [[comments-formats|formatos]] (Alguma coisa precisa ser extraída de [[comments-formats]])<br />
* [[currency]]; [[currency-examples]]; [[currency-brainstorming]] {{NewMarker}}<br />
* directions [[directions-examples|examplos]] {{NewMarker}}<br />
* directory inclusion [[directory-inclusion-examples|examples]], [[directory-inclusion-formats|formatos]]. (see also [[rel-directory]])<br />
* distributed conversation [[distributed-conversation|overview]], [[distributed-conversation-brainstorming|brainstorming]], [[distributed-conversation-examples|examplos]], and [[distributed-conversation-formats|formatos]]<br />
* forms [[forms-examples|exemplos]]<br />
* genealogy [[genealogy-formats|exemplos]]<br />
* group [[group-brainstorming|brainstorming]] and [[group-examples|examplos]]<br />
* hash [[hash-examples|examples]]<br />
* job listing [[job-listing-examples|exemplos]] e [[job-listing-brainstorming|brainstorming]]<br />
* last modified [[last-modified-examples|exemplos]], [[last-modified-formats|formatos]], and [[last-modified-brainstorming|brainstorming]]<br />
* hListing [[hlisting-proposal|proposal]], e [[hlisting-feedback|feedback]] {{NewMarker}}<br />
** Also, listing [[listing-examples|exemplos]], [[listing-formats|formatos]], and [[listing-brainstorming|brainstorming]]<br />
* location [[location-formats|formatos]]. (ver também [[adr]] e [[geo]])<br />
* [[luna]] ([[geo]]-like co-ordinates, for places on The Moon) {{NewMarker}}<br />
* [[mars]] ([[geo]]-like co-ordinates, for places on the planet Mars) {{NewMarker}}<br />
* measures and measurement units [[measure]]<br />
* [[media-info]] ([[media-info-examples|exemplos]], [[media-info-formats|formatos]], [[media-info-brainstorming|brainstorming]]) <br />
* meeting minutes [[meeting-minutes-examples|exemplos]], [[meeting-minutes-formats|formatos]], e [[meeting-minutes-brainstorming|brainstorming]]<br />
* metalink [[metalink-examples|exemplos]] {{NewMarker}}<br />
* microsummary [[microsummary-brainstorming|brainstorming]] {{NewMarker}}<br />
* [[mfo-examples|MFO examples]]<br />
* music [[music-examples|exemplos]]<br />
* photo note [[photo-note-examples|exemplos]]<br />
* recipe [[recipe-examples|exemplos]]<br />
* rel-product [[rel-product-brainstorming|brainstorming]]<br />
* requirements testing [[requirements-testing|overview]], e [[requirements-testing-examples|examplos]]<br />
* [[rest-examples|REST examples]]<br />
* resume [[resume-brainstorming|brainstorming]], e [[resume-formats|formatos]]<br />
* review [[review-examples|examples]], e [[review-formats|formatosformatos]] (yielded the [[hreview|hReview]] draft)<br />
* search results [[search-results-example|exemplos]]<br />
* show [[show-brainstorming|brainstorming]]<br />
* showroll [[showroll-brainstorming|brainstorming]]<br />
* [[species]] - para a remarcação de nomes científicos de coisas vivas: [[species-examples]]; [[species-brainstorming]] {{NewMarker}}<br />
* table [[table-examples|exemplos]]<br />
* tagspeak [[tagspeak-examples|exemplos]]<br />
* tagcloud [[tagcloud-examples|exemplos]], e [[tagcloud-brainstorming | brainstorming]]. {{NewMarker}}<br />
* transit table [[transit-table-examples|exemplos]]<br />
* [[uid]]<br />
* widget [[widget-examples|exemplos]], e [[widget-brainstorming|brainstorming]]<br />
* [[wiki-formats|wiki formatos]]<br />
* work of art [[work-of-art|overview]], [[workofart-examples|examples]], [[workofart-formats|formatos]], e [[workofart-brainstorming|brainstorming]] {{NewMarker}}<br />
*[[xmdp-brainstorming|XMDP brainstorming]] (ver também [[xmdp-faq]])<br />
<br />
== Exemplos ==<br />
* [[examples]]<br />
* [[zen-garden]]<br />
<br />
<br />
== Ferramentas & Casos Prova & Pesquisa Adicional ==<br />
<br />
O primeira lugar a procurar por exemplos, códigos, e casos é nas páginas de cada microformato indivídual. Há poucas ferramentas de atalho e serviços que precisam processar mais que um microformato. Esta sessão é destinada a editores, analisadores, validadores, testadores de casos e a outras informações relevantes através de microformatos multíplos.<br />
<br />
*[[accessibility|acessibilidade]]<br />
*[[faqs-for-rdf]]<br />
*[[icalendar-implementations]]<br />
*[[parsing-microformats]]<br />
*[[selected-test-cases-from-the-web]]<br />
*[http://hg.microformats.org/ Source code repository] -- [[mercurial-quick-start|HowTo: Download code from the repository]]<br />
*[[vcard-implementations]], [[vcard-errata]]<br />
*[[why-are-content-standards-hard]]<br />
<br />
== Areas de trabalho compartilhado ==<br />
* [[buttons]]<br />
* [[spread-microformats]] {{NewMarker-pt-br}}<br />
* [[demo]] - uma página com links para rapidamente demostrar microformatos funcionando na prática.<br />
* [[events|eventos]] {{NewMarker-pt-br}}<br />
* [[to-do-pt-br|o que fazer]]<br />
* [[user-interface]]<br />
* [[marked-for-deletion]]<br />
<br />
== wiki em outras linguagens==<br />
<br />
Você pode ler e editar artigos microformatos em qualquer língua:<br />
<br />
* linguagens com mais de 50 artigos<br />
** [[Main_Page-fr|Français (French)]] {{NewMarker-fr}}<br />
* linguagens com mais de 20 artigos<br />
** [[Main_Page-pt-br|Português (Brazilian Portuguese)]]<br />
* linguagens com mais de 2 artgos<br />
** [[Main_Page-ja|日本語 (Japanese)]]<br />
** [[Main_Page-es|Español (Spanish)]]<br />
* linguagens com 2 artigos<br />
** [[Main_Page-de|Deutsch (German)]]<br />
<br />
==== tradução de microformatos dos outros ====<br />
Há outras páginas/sites externas com traduções sobre microformatos. Se você está trabalhando em uma dessas, por favor, considere como tradução o principal site de microformatos!<br />
* [http://mikroformate.pbwiki.com/ Deutsch (German) mikroformate.pbwiki.com] {{NewMarker}}<br />
<br />
=== Iniciar um microformatos wiki em outras línguas ===<br />
<br />
Não vê a tradução que gostaria? Ajuda a traduzir a wiki para sua língua!<br />
<br />
Estamos trabalhando na melhoria das páginas em outra linguagem.<br />
<br />
Enquanto isso, veja [http://en.wikipedia.org/wiki/Wikipedia:Multilingual_coordination Página em coordenadas Multi-língua], e [http://meta.wikimedia.org/wiki/How_to_start_a_new_Wikipedia Como iniciar um novo Wikipedia] para algumas dicas, conselhos, e convenções de comunidade.<br />
<br />
Para começar, você pode acessar as [[stable-pages|páginas estáveis]], que são páginas que são relativamente estáveis e tem apenas pequenas mudanças editoriais, que as tornam muito fácil mantê-las em sincronia com a versão em inglês, pelo uso do recurso [[Special:Watchlist|my watchlist]] (use-o para monitorar as páginas que você traduziu).<br />
<br />
Nome do artigo: a versão traduzida de uma página, coloque o mesmo nome para a página e simplesmente adicione o código de identificador de linguagem RFC 3066 como um traço no sulfixo do nome original. <br />
Ex. para a versão em Francês, [[Main_Page]] torna-se [[Main_Page-fr]], e [[how-to-play]] torna-se [[how-to-play-fr]].</div>ScottReynenhttps://microformats.org/wiki/index.php?title=currency-proposal&diff=25626currency-proposal2007-06-18T16:18:35Z<p>ScottReynen: Reverted edit of XtfG6g, changed back to last version by Tantek</p>
<hr />
<div>= Currency =<br />
<br />
'''currency''' is a simple microformat for marking up money amounts, such as prices of products/services or financial facts.<br />
<br />
== Introduction ==<br />
<br />
Money amounts are one of the most widespread content found on the Web, but the lack of unambiguous representation of the currency they are expressed in, or the date that they relate to, makes comparison and matching of offerings online difficult.<br />
<br />
== Acknowledgments ==<br />
<br />
This proposal was written based on the contributions of several members of the community. Original brainstorming ideas and strawman proposal can be viewed at [[currency-brainstorming]] and [[currency-brainstorming#Andy_Mabbett]]<br />
<br />
== Scope ==<br />
<br />
This proposal limits its scope to:<br />
* money amounts expressed in one officially issued coins and notes. This means it currently does not support money amounts expressed in terms of commodities or other liquefiable asset.<br />
* money amounts expressed in one unit. This means that it currently does not support composite amounts such as "39 U.S. Dollars and 99 Cents".<br />
<br />
== Features ==<br />
<br />
* Reuse of widely used ISO 4217 for unambiguous encoding of currency types: ensures interoperability with many existing and emerging industry standards such as [http://www.ifxforum.org IFX], [http://www.acord.org ACORD], [http://www.xbrl.org XBRL] or [http://docs.oasis-open.org/ubl/cd-UBL-1.0/ UBL].<br />
* Define currency once, use anywhere: allows currency units to be defined once and then referred to, instead of locally defined for each money amount, resulting in ease of readability for both human users and their user agents.<br />
* Timestamping: money amounts have an optional date that allows user agents to translate a historical figure to an equivalent present amount.<br />
<br />
=== Root Class Name ===<br />
<br />
The root class name for a money amount is <code>money</code>.<br />
<br />
=== Property List ===<br />
<br />
* Required <code>amount</code>: can mark up a machine-readable numerical value with a <code>span</code>element or a string value with a <code>abbr</code> whose <code>title</code> attribute contains the machine-readable numerical value (See [[abbr-design-pattern]]).<br />
* Optional <code>currency</code>, or reference to a currency (See [[include-pattern]]). Must markup a ISO 4217 compliant code or use the [[abbr-design-pattern]] to provide the equivalent ISO 4217 machine readable value to the marked up human-readable value.<br />
* Optional <code>unit</code>, or reference to a unit of the currency (See [[include-pattern]]), for instance a "dollar" or "cent". This proposal does not specify how the unit must be marked up. This is the focus of the [[measure]] microformats. When not present, the unit is assumed to be the default unit for the given currency. For instance, "Dollar" for the U.S. currency.<br />
* Optional <code>date</code> following the [[datetime-design-pattern]], specifies the date that must be used to evaluate the value of the currency unit used.<br />
<br />
=== Examples ===<br />
<br />
Simple in-line example with local definition of the currency unit: <span class="money"><abbr class="currency" title="USD">$</abbr><span class="amount">39.99</span></span><br />
<br />
<pre><br />
<span class="money"><abbr class="currency" title="USD">$</abbr><span class="amount">39.99</span></span><br />
</pre><br />
<br />
Text representation of the amount: <span class="money"><abbr class="amount">Thirty-nine</abbr> <abbr class="currency" title="USD">Dollars</abbr></span><br />
<br />
<pre><br />
<span class="money"><abbr class="amount" title="39">Thirty-nine</abbr> <abbr class="currency" title="USD">Dollars</abbr></span><br />
</pre><br />
<br />
Example using the <code>unit</code> class: <span class="money"><span class="amount">99</span><abbr class="unit">&cent;</abbr><abbr class="currency" title="USD"></abbr></span><br />
<br />
<pre><br />
<span class="money"><span class="amount">99</span><abbr class="unit">&cent;</abbr><abbr class="currency" title="USD"></abbr></span><br />
</pre><br />
<br />
Table example with global definition of the currency:<br />
<br />
<pre><br />
<table><br />
<tr><th>Price in <abbr id="u1" class="currency" title="USD">US$</abbr></th></tr><br />
<tr><td><div class="money">39.99<a href="#u1" class="include"></a></div></td></tr><br />
</table><br />
</pre><br />
<br />
== Issues ==<br />
<br />
Discussion of this proposal by specific problems on [[currency-issues]].<br />
<br />
==Related pages==<br />
{{currency-related-pages}}</div>ScottReynenhttps://microformats.org/wiki/index.php?title=buttons-fr&diff=17648buttons-fr2007-06-18T16:18:15Z<p>ScottReynen: Reverted edit of XceY1k, changed back to last version by ChristopheDucamp</p>
<hr />
<div><h1> Boutons Microformats </h1><br />
<br />
Il y a eu quelques demandes pour des boutons destinés à différents microformats. Soit des badges ou des boutons qui font quelque chose avec les microformats spécifiques. Cette page maintient une liste de boutons tout comme des requêtes. - [http://tantek.com/log/ Tantek]<br />
<br />
Ajouté des boutons hébergés pour tous les micro-formats, y compris les brouillons, tout comme les instructions pour savoir comment fabriquer vos propres boutons. (14 mai 2006) - [http://www.wackomenace.co.uk/ Ruben]<br />
<br />
<br />
==Licences==<br />
<br />
Si vous ajoutez des liens vers des boutons que vous avez conçus, '''incluez aussi une déclaration''' que vous suivez une des règles suivantes : <br />
* publiez-les dans le domaine public<br />
* détenez le copyright, mais publiez les droits d'utilisation<br />
* licenciez-les sous une licence spécifiée libre, par exemple imaginez utiliser une licence [http://creativecommons.org/ Creative Commons] telle que la [http://creativecommons.org/licenses/by/3.0 cc-by-3.0].<br />
<br />
Merci.<br />
<br />
* Les images ci-dessous hébergées par boogdesign.com sont disponibles sous [http://creativecommons.org/licenses/by/2.0/ licence CC Attribution 2.0], voir [http://www.boogdesign.com/buttons.html ma page boutons] pour les fichiers Photoshop si vous en avez besoin. - Rob Crowther<br />
* Les images ci-dessous hébergées chez rbach.priv.at sont disponibles sous licence [http://creativecommons.org/licenses/by/3.0 cc-by-3.0]. - [[User:RobertBachmann|Robert Bachmann]]<br />
* Les images ci-dessous hébergées chez synaesthetic.net sont disponibles sous la licence [http://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. -- [[User:Kwilson|Kenn Wilson]]<br />
<br />
__TOC__<br />
<br />
== Boutons ==<br />
=== Bouton Microformat ===<br />
J'ai produit un bouton pour les microformats. Parce qu'il existe beaucoup de microformats et encore plus à venir, indiquer simplement le support / utilisation des microformats pourrait être une bonne approche. L'image est libre d'utilisation. SVP copiez-là chez votre hébergeur et ne faites pas de liens vers elle.<br />
<br />
http://www.crowley.nl/images/microformats.png<br />
<br />
J'ai déjà un "J'utilise les <br />
http://www.crowley.nl/images/microformats.png" sur mon blog: http://doncrowley.blogspot.com/<br />
<br />
- Don Crowley<br />
<br />
* http://www.boogdesign.com/images/buttons/microformat.png<br />
* http://www.boogdesign.com/images/buttons/microformat_enabled.png<br />
* http://www.boogdesign.com/images/buttons/emf_green.png<br />
* http://www.boogdesign.com/images/buttons/mfe_green.png<br />
* http://www.boogdesign.com/images/buttons/mwmf_green.png<br />
* http://www.boogdesign.com/images/buttons/smf_green.png<br />
* http://www.boogdesign.com/images/buttons/emf_white.png<br />
* http://www.boogdesign.com/images/buttons/mfe_white.png<br />
* http://www.boogdesign.com/images/buttons/mwmf_white.png<br />
* http://www.boogdesign.com/images/buttons/smf_white.png<br />
<br />
<br />
=== [[hcalendar|hCalendar]] ===<br />
* http://rbach.priv.at/2006/buttons/hcal.png<br />
* http://www.boogdesign.com/images/buttons/microformat_hcalendar.png<br />
* bouton CSS-powered tiré de [http://www.midgard-project.org/community/events/ calendrier événement Midgard CMS] : <br />
<br />
<span class="badge" style="float: left; font: 9px Geneva, Verdana, sans-serif; padding: 0 1em 1px 0; border: 1px solid #000; background: #D1940C; color: #fff; text-decoration: none; text-align: center;"><span style="background: #000; border-right: 1px solid #000; color: #fff; padding: 1px 0.75em; margin-right: 0.1em;">&#8250;&#8250;&#8250;</span> hCalendar</span><br />
<br />
<br />
Code (espace blanc ajouté pour la lisibilité) :<br />
<br />
<pre><nowiki><br />
<span class="badge" <br />
style="float: left; font: 9px Geneva, Verdana, sans-serif; padding: 0 1em 1px 0;<br />
border: 1px solid #000; background: #D1940C; color: #fff; text-decoration: none;<br />
text-align: center;"><br />
<span style="background: #000; border-right: 1px solid #000; color: #fff; padding: 1px 0.75em; <br />
margin-right: 0.1em;"><br />
&amp;#8250;&amp;#8250;&amp;#8250;<br />
</span> <br />
hCalendar<br />
</span><br />
</nowiki></pre><br />
<br />
=== [[hcard|hCard]] ===<br />
* http://www.crowley.nl/images/hcard.png (miroir : http://www.davidjanes.com/images/mf_hcard.png )* http://rbach.priv.at/2006/buttons/hcard.png<br />
* bouton CSS-powered comme mis en évidence [http://re-run.com/about/microformat-badges microformat badges @ re-run]<br />
* http://www.boogdesign.com/images/buttons/microformat_hcard.png<br />
<br />
=== [[rel-license-fr|rel-license]] ===<br />
* http://rbach.priv.at/2006/buttons/license.png<br />
* http://www.boogdesign.com/images/buttons/microformat_rellicense.png<br />
<br />
=== [[rel-nofollow-fr|rel-nofollow]] ===<br />
* http://rbach.priv.at/2006/buttons/nofollow.png<br />
* http://www.boogdesign.com/images/buttons/microformat_relnofollow.png<br />
<br />
=== [[rel-tag-fr|rel-tag]] ===<br />
* http://rbach.priv.at/2006/buttons/rel-tag.png<br />
* http://rbach.priv.at/2006/buttons/tag.png<br />
* http://www.boogdesign.com/images/buttons/microformat_reltag.png<br />
<br />
=== [[vote-links-fr|VoteLinks]] ===<br />
* http://rbach.priv.at/2006/buttons/votelinks.png<br />
* http://www.boogdesign.com/images/buttons/microformat_votelinks.png<br />
<br />
=== [http://gmpg.org/xfn/ XFN] ===<br />
* http://rbach.priv.at/2006/buttons/xfn.png<br />
* http://www.boogdesign.com/images/buttons/microformat_xfn.png<br />
<br />
=== [http://gmpg.org/xmdp/ XMDP] ===<br />
* http://rbach.priv.at/2006/buttons/xmdp.png<br />
* http://www.boogdesign.com/images/buttons/microformat_xmdp.png<br />
<br />
=== [[xoxo-fr|XOXO]] ===<br />
* http://rbach.priv.at/2006/buttons/xoxo.png<br />
* http://www.boogdesign.com/images/buttons/microformat_xoxo.png<br />
<br />
<br />
<br />
=== Styles CSS pour microformats===<br />
Je ne suis pas certain si ceci peut être sous les boutons, mais ne sais pas où le poser ailleurs. Ceci est une feuille de style contenant des styles pour la plupart des microformats. Et c'est automatique. Je l'ai publiée sous la cc by-sa. Notez svp que je suis nouveau sur les microformats et que si vous pouvez l'améliorer, faites-le svp. [[User:Mac Lover|Mac Lover]] 13:25, 13 Apr 2007 (PDT)<br />
<br />
[http://creativecommons.org/licenses/by-sa/3.0/us/ Licence]<br />
[http://alyosha.bendebury.net/microformat-css.zip Zip]<br />
<br />
<br />
== Boutons pour les formats brouillons ==<br />
<br />
Ceux-ci peuvent être sujets à modifications si les noms des formats changent quand ils seront publiés.<br />
<br />
=== [[adr-fr|adr]] ===<br />
* http://rbach.priv.at/2006/buttons/adr.png<br />
<br />
=== [[geo-fr|geo]] ===<br />
* http://rbach.priv.at/2006/buttons/geo.png<br />
<br />
=== [[hatom-fr|hAtom]] ===<br />
* http://rbach.priv.at/2006/buttons/hatom.png<br />
<br />
=== [[hresume-fr|hResume]] ===<br />
* http://rbach.priv.at/2006/buttons/hresume.png<br />
* http://www.boogdesign.com/images/buttons/microformat_hresume.png<br />
<br />
=== [[hreview-fr|hReview]] ===<br />
* http://rbach.priv.at/2006/buttons/hreview.png<br />
<br />
=== [[rel-directory-fr|rel-directory]] ===<br />
* http://rbach.priv.at/2006/buttons/directory.png<br />
<br />
=== [[rel-enclosure-fr|rel-enclosure]] ===<br />
* http://rbach.priv.at/2006/buttons/enclosure.png<br />
<br />
=== [[rel-home-fr|rel-home]] ===<br />
* http://rbach.priv.at/2006/buttons/rel-home.png<br />
* http://rbach.priv.at/2006/buttons/home.png<br />
<br />
=== [[relpayment-research-fr|rel-payment]] ===<br />
* http://rbach.priv.at/2006/buttons/payment.png<br />
<br />
=== [[robots-exclusion-fr|Robots Exclusion]] ===<br />
* http://rbach.priv.at/2006/buttons/robots.png<br />
<br />
=== [[xfolk-fr|xFolk]] ===<br />
* http://rbach.priv.at/2006/buttons/xfolk.png<br />
<br />
== Faites vos propres boutons ==<br />
=== Style 1 ===<br />
Exemple : http://www.crowley.nl/images/hcard.png <br />
<br />
Utilisez le [http://kalsey.com/tools/buttonmaker/ Kalsey Button Maker] avec les réglages suivants :<br />
* Outer border: #666666<br />
* Inner border: #ffffff<br />
* Bar position: 25 pixels from the left<br />
* Left box text: &gt;&gt;&gt;<br />
* Left box background: #000000<br />
* Left box text colour: #ffffff<br />
* Left box text start: 7 pixels from the left<br />
* Right box text: (The name of the microformat goes here)<br />
* Right box background: #31757b<br />
* Right box text colour: #ffffff<br />
* Right box text start: 3 pixels from the bar<br />
<br />
=== Style 2 ===<br />
<br />
Exemple : http://rbach.priv.at/2006/buttons/hcal.png<br />
<br />
# Téléchargez le [http://www.kottke.org/plus/type/silkscreen/ Silkscreen] de fonte<br />
# Installez [http://www.imagemagick.org/ ImageMagick]<br />
# Recevez l'icône blanche (http://rbach.priv.at/2006/buttons/blank.png)<br />
# Ouvrez la ligne de commande de votre machine (DOS ou autre) et saisissez : <br />
<pre>convert blank.png <br />
-fill white <br />
-font Silkscreen <br />
-pointsize 8 <br />
+antialias <br />
-draw "text 28,10 'étiquette-bouton'" <br />
output.png<br />
</pre><br />
<br />
=== Style 3 ===<br />
<br />
Exemple : http://files.synaesthetic.net/common/images/buttons/hatom.png<br />
<br />
# Obtenez la police [http://www.kottke.org/plus/type/silkscreen/ Silkscreen]<br />
# Installez [http://www.imagemagick.org/ ImageMagick]<br />
# Obtenez l'icône blanche (http://files.synaesthetic.net/microformats/button2-blank.png)<br />
# Saisissez : <br />
<pre>convert button2-blank.png <br />
-fill white <br />
-font Silkscreen <br />
-pointsize 8 <br />
+antialias <br />
-draw "text 20,10 'button label'" <br />
output.png<br />
</pre><br />
<br />
<br />
= Microformats Logos =<br />
Rohit est un très pauvre hacker CSS, mais il lui a donné son meilleur shot. Il [http://labs.commerce.net/~rohit/µf-logo.html l'a aussi restitué en 72 et 18 points.] <br />
<br />
http://microformats.org/img/logo.gif<br />
<br />
<div style="position: relative; top:-46px; left:180px"><br />
<div style="background-color:#679A06; width:30px; height: 30px; left:1px; top:10px; position:absolute; -moz-border-radius:5pt;"></div><br />
<br />
<div style="background-color:#85BC07; width:22px; height: 22px; left:11.5px; top:6px; position:absolute; border-left: 2px solid white;border-bottom: 2px solid white; -moz-border-radius:4pt;"></div><br />
<br />
<div style="background-color:#AEE219; width:14px; height: 14px; left:22.5px; top:4px; position:absolute; border-left: 2px solid white;border-bottom: 2px solid white;-moz-border-radius:2pt;"></div><br />
<br />
<div style="font-family:Arial Narrow,Arial,sans-serif;font-size:17.5pt;letter-spacing:0px;color:#676767; position: absolute; left:44px; top: -6px"><br />
<span style="padding-left:9;color:#111111;vertical-align:40%">micro</span><span style="vertical-align:40%;padding-left:1pt">formats</span><br />
</div><br />
</div><br />
<br />
Le logo en-dessous sous PNG transparent (lié ici à partir de mon propre serveur ; si vous l'utilisez, copiez svp pour vous-même) : <br />
<br />
http://files.synaesthetic.net/public/microformats/microformats1.png <br />
<br />
<br />
==Palette==<br />
<br />
<div style="background-color:#AEE219; width:8em; height: 4ex;">#AEE219</div><br />
<br />
<div style="background-color:#85BC07; width:8em; height: 4ex;">#85BC07</div><br />
<br />
<div style="background-color:#679A06; width:8em; height: 4ex;">#679A06</div><br />
<br />
=Wiki boutons= <br />
Pour utilisation sur ce wiki. <br />
*{{NewMarker-fr}} - <nowiki>{{NewMarker-fr}}</nowiki> <br />
*{{SuccessMarker-fr}} - <nowiki>{{SuccessMarker-fr}}</nowiki> <br />
*{{UpdateMarker-fr}} - <nowiki>{{UpdateMarker-fr}}</nowiki> <br />
<br />
<br />
= Demandes =<br />
<br />
* Logos pour tous les microformats</div>ScottReynenhttps://microformats.org/wiki/index.php?title=hcalendar-examples-fr&diff=17630hcalendar-examples-fr2007-06-18T16:17:50Z<p>ScottReynen: Reverted edit of Tf6Eu5, changed back to last version by ScottReynen</p>
<hr />
<div>= exemples de hCalendar =<br />
<br />
Exemples de [[hcalendar-fr|hCalendars]].<br />
== Auteurs ==<br />
* [http://diveintomark.org/ Mark Pilgrim]<br />
* [http://theryanking.com/ Ryan King]<br />
* [http://tantek.com/log/ Tantek Çelik]<br />
<br />
* Traduction fr en cours : [[Christophe Ducamp]]<br />
== exemples RFC 2445 dans hCalendar ==<br />
Ce sont des exemples hCalendar 1:1 pour chaque exemple dans la RFC 2445.<br />
<br />
Les errata sont appliqués à partir d'[http://www.rfc-editor.org/cgi-bin/errata.pl#rfc2445 ici].<br />
<br />
'''Ces exemples sont de stricts copier-coller tirés de la RFC, ils ne devraient pas être édités.'''<br />
<br />
=== 4.6.1 Composant Event ===<br />
Ci-après un exemple du composant de calendrier "VEVENT" utilisé pour représenter une réunion qui sera aussi opaque pour les recherches du temps occupé : <br />
<br />
<pre><nowiki><br />
BEGIN:VEVENT<br />
UID:19970901T130000Z-123401@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART:19970903T163000Z<br />
DTEND:19970903T190000Z<br />
SUMMARY:Annual Employee Review<br />
CLASS:PRIVATE<br />
CATEGORIES:BUSINESS,HUMAN RESOURCES<br />
END:VEVENT<br />
</nowiki></pre><br />
<br />
Cet event iCalendar comme un hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<h5 class="summary">Annual Employee Review</h5><br />
<div>posted on <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div><br />
<div>UID: <span class="uid">19970901T130000Z-123401@host.com</span></div><br />
<div>Dates: <abbr class="dtstart" title="19970903T163000Z">Septempter 3, 1997, 16:30</abbr> -<br />
<abbr class="dtend" title="19970903T190000Z">19:00 UTC</abbr></div><br />
<div>This meeting is <strong class="class">private</strong>.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Business</li><br />
<li class="category">Human Resources</li><br />
</ul><br />
</div><br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme : <br />
<div class="vevent"><br />
<br />
<h5 class="summary">Annual Employee Review</h5><br />
<div>posted on <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div><br />
<div>UID: <span class="uid">19970901T130000Z-123401@host.com</span></div><br />
<div>Dates: <abbr class="dtstart" title="19970903T163000Z">Septempter 3, 1997, 16:30</abbr> - <abbr class="dtend" title="19970903T190000Z">19:00 UTC</abbr></div><br />
<div>This meeting is <strong class="class">Private</strong>.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Business</li><br />
<li class="category">Human Resources</li><br />
</ul><br />
</div><br />
<br />
==== Exemple 2 ====<br />
Ce qui suit est un exemple du composant calendrier "VEVENT" utilisé pour représenter un aide-mémoire qui ne sera pas opaque, mais plutôt transparent aux recherches sur le temps occupé : <br />
<br />
<pre><nowiki><br />
BEGIN:VEVENT<br />
UID:19970901T130000Z-123402@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART:19970401T163000Z<br />
DTEND:19970402T010000Z<br />
SUMMARY:Laurel is in sensitivity awareness class.<br />
CLASS:PUBLIC<br />
CATEGORIES:BUSINESS,HUMAN RESOURCES<br />
TRANSP:TRANSPARENT<br />
END:VEVENT<br />
</nowiki></pre><br />
<br />
Cet event iCalendar en tant que fragment hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<h5 class="summary">Laurel is in sensitivity awareness class.</h5><br />
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div><br />
<div class="uid">19970901T130000Z-123402@host.com</div><br />
<div>Dates: <abbr class="dtstart" title="19970401T163000Z">April 1, 1997, 16:30 UTC</abbr>-<br />
<abbr class="dtend" title="19970402T010000Z">April 2, 1997 01:00 UTC</abbr></div><br />
<div>This event is <span class="class">public</span> and <span class="transp">transparent</span> to free/busy scheduling.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Business</li><br />
<li class="category">Human Resources</li><br />
</ul><br />
</div><br />
</nowiki></pre><br />
<br />
Cet hCalendar pourrait être affiché comme : <br />
<br />
<div class="vevent"><br />
<h5 class="summary">Laurel is in sensitivity awareness class.</h5><br />
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div><br />
<div class="uid">19970901T130000Z-123402@host.com</div><br />
<div>Dates: <abbr class="dtstart" title="19970401T163000Z">April 1, 1997, 16:30 UTC</abbr>-<abbr class="dtend" title="19970402T010000Z">April 2, 1997 01:00 UTC</abbr></div><br />
<div>This event is <span class="class">public</span> and <span class="transp">transparent</span> to free/busy scheduling.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Business</li><br />
<li class="category">Human Resources</li><br />
</ul><br />
</div><br />
<br />
<br />
==== Exemple 3 ====<br />
<br />
Ce qui suit est un exemple du composant calendrier "VEVENT" utilisé pour représenter un anniversaire qui arrivera chaque année. Parce que cela ne prend pas de temps, il n'apparaîtra pas comme opaque dans une recherche sur le temps occupé ; peu importe ce qu'indique la valeur de la propriété "TRANSP" :<br />
<br />
<pre><nowiki><br />
BEGIN:VEVENT<br />
UID:19970901T130000Z-123403@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART:19971102<br />
SUMMARY:Our Blissful Anniversary<br />
CLASS:CONFIDENTIAL<br />
CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION<br />
RRULE:FREQ=YEARLY<br />
END:VEVENT<br />
</nowiki></pre><br />
<br />
Cet event iCalendar comme un fragment hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<h5 class="summary">Our Blissful Anniversary</h5><br />
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div><br />
<div class="uid">19970901T130000Z-123403@host.com</div><br />
<div>Date: <abbr class="dtstart" title="19971102">November 2, 1997</abbr></div><br />
<div>This event is <strong class="class">confidential</strong>.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Anniversary</li><br />
<li class="category">Personal</li><br />
<li class="category">Special Occassion</li><br />
</ul><br />
<div class="rrule">Repeat <span class="freq">yearly</span>.</div><br />
</div><br />
</nowiki></pre><br />
<br />
PROBLEMATIQUES :<br />
* Nous avons eu une plus grande discussion à propos de RRULE qui a besoin d'être résolue, ces exemples aideront en cela, je l'espère. --RyanKing<br />
<br />
Ce hCalendar pourrait s'afficher comme : <br />
<br />
<div class="vevent"><br />
<h5 class="summary">Our Blissful Anniversary</h5><br />
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div><br />
<div class="uid">19970901T130000Z-123403@host.com</div><br />
<div>Date: <abbr class="dtstart" title="19971102">November 2, 1997</abbr></div><br />
<div>This event is <span class="class">confidential</span>.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Anniversary</li><br />
<li class="category">Personal</li><br />
<li class="category">Special Occassion</li><br />
</ul><br />
<div class="rrule">Repeat <span class="freq">yearly</span></div><br />
</div><br />
<br />
=== 4.6.2 A faire : Composant ===<br />
<br />
Exemple : Ce qui suit est un exemple d'un composant calendrier "VTODO" :<br />
<br />
<pre><nowiki><br />
BEGIN:VTODO<br />
UID:19970901T130000Z-123404@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART:19970415T133000Z<br />
DUE:19970416T045959Z<br />
SUMMARY:1996 Income Tax Preparation<br />
CLASS:CONFIDENTIAL<br />
CATEGORIES:FAMILY,FINANCE<br />
PRIORITY:1<br />
STATUS:NEEDS-ACTION<br />
END:VTODO<br />
</nowiki></pre><br />
<br />
Ce fragment iCalendar sous hCalendar:<br />
<br />
<pre><nowiki><br />
@TODO<br />
</nowiki></pre><br />
<br />
=== 4.6.3 Composant Journal ===<br />
<br />
Exemple : Ce qui suit est un exemple du composant calendrier "VJOURNAL" :<br />
<br />
BEGIN:VJOURNAL<br />
UID:19970901T130000Z-123405@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART;VALUE=DATE:19970317<br />
SUMMARY:Staff meeting minutes<br />
DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa<br />
and Bob. Aurora project plans were reviewed. There is currently<br />
no budget reserves for this project. Lisa will escalate to<br />
management. Next meeting on Tuesday.\n<br />
2. Telephone Conference: ABC Corp. sales representative called<br />
to discuss new printer. Promised to get us a demo by Friday.\n<br />
3. Henry Miller (Handsoff Insurance): Car was totaled by tree.<br />
Is looking into a loaner car. 654-2323 (tel).<br />
END:VJOURNAL<br />
<br />
Ce fragment iCalendar comme hCalendar : <br />
<br />
<pre><nowiki><br />
@TODO<br />
</nowiki></pre><br />
<br />
=== 4.6.4. Composant Free/Busy ===<br />
<br />
Exemple : Ce qui suit est une exemple d'un composant calendrier "VFREEBUSY" utilisé pour requêter une information sur le temps libre ou occupé :<br />
<br />
<pre><nowiki><br />
BEGIN:VFREEBUSY<br />
ORGANIZER:MAILTO:jane_doe@host1.com<br />
ATTENDEE:MAILTO:john_public@host2.com<br />
DTSTART:19971015T050000Z<br />
DTEND:19971016T050000Z<br />
DTSTAMP:19970901T083000Z<br />
END:VFREEBUSY<br />
</nowiki></pre><br />
<br />
Ce fragment iCalendar sous hCalendar :<br />
<br />
<pre><nowiki><br />
@TODO<br />
</nowiki></pre><br />
<br />
Ce qui suit est un exemple d'un composant calendrier "VFREEBUSY" utilisé pour répondre à la requête avec l'information sur le temps occupé :<br />
<br />
<pre><nowiki><br />
BEGIN:VFREEBUSY<br />
ORGANIZER:MAILTO:jane_doe@host1.com<br />
ATTENDEE:MAILTO:john_public@host2.com<br />
DTSTAMP:19970901T100000Z<br />
FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M,<br />
19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M<br />
URL:http://host2.com/pub/busy/jpublic-01.ifb<br />
COMMENT:This iCalendar file contains busy time information for<br />
the next three months.<br />
END:VFREEBUSY<br />
</nowiki></pre><br />
<br />
<br />
Ce fragment iCalendar sous hCalendar :<br />
<br />
<pre><nowiki><br />
@TODO<br />
</nowiki></pre><br />
<br />
Ce qui suit est un exemple d'un composant calendrier "VFREEBUSY" utilisé pour publier l'information sur le temps occupé.<br />
<br />
<pre><nowiki><br />
BEGIN:VFREEBUSY<br />
ORGANIZER:jsmith@host.com<br />
DTSTART:19980313T141711Z<br />
DTEND:19980410T141711Z<br />
FREEBUSY:19980314T233000Z/19980315T003000Z<br />
FREEBUSY:19980316T153000Z/19980316T163000Z<br />
FREEBUSY:19980318T030000Z/19980318T040000Z<br />
URL:http://www.host.com/calendar/busytime/jsmith.ifb<br />
END:VFREEBUSY<br />
</nowiki></pre><br />
<br />
Ce fragment iCalendar sous hCalendar :<br />
<br />
<pre><nowiki><br />
@TODO<br />
</nowiki></pre><br />
<br />
<br />
=== 5. Exemples Objet iCalendar ===<br />
<br />
L'exemple suivant spécifie une conférence de trois jours qui démarrer le 18 septembre 1996 à 8:00 AM EDT, et se termine à 6:00 PM EDT le 20 septembre 1996.<br />
<br />
<pre><nowiki><br />
BEGIN:VEVENT<br />
DTSTAMP:19960704T120000Z<br />
UID:uid1@host.com<br />
ORGANIZER:MAILTO:jsmith@host.com<br />
DTSTART:19960918T143000Z<br />
DTEND:19960920T220000Z<br />
STATUS:CONFIRMED<br />
CATEGORIES:CONFERENCE <br />
SUMMARY:Networld+Interop Conference<br />
DESCRIPTION:Networld+Interop Conference and Exhibit\nAtlanta World Congress Center\nAtlant\, Georgia<br />
END:VEVENT<br />
</nowiki></pre><br />
<br />
Cet événement iCalendar sous un fragment hCalendar : ''la syntaxe des participants semble incomplète''<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<h5 class="summary">Networld+Interop Conference</h5><br />
<div class="description">Networld+Interop Conference and Exhibit Atlanta World Congress<br />
Center Atlanta, Georgia</div><br />
<div>Posted on: <abbr class="dtstamp" title="19960704T120000Z">July 4, 1996</abbr></div><br />
<div class="uid">uid1@host.com</div><br />
<div>Organized by: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></div><br />
<div>Dates: <abbr class="dtstart" title="19960918T143000Z">September 18, 1996, 14:30 UTC</abbr> -<br />
<abbr class="dtend" title="19960920T220000Z">September 20, 1996, 22:00 UTC</abbr></div><br />
<div>Status: <span class="status">CONFIRMED</span></div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Conference</li><br />
</ul><br />
</div><br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme :<br />
<br />
<div class="vevent"><br />
<h5 class="summary">Networld+Interop Conference</h5><br />
<div class="description">Networld+Interop Conference and Exhibit Atlanta World Congress<br />
Center Atlanta, Georgia</div><br />
<div>Posted on: <abbr class="dtstamp" title="19960704T120000Z">July 4, 1996</abbr></div><br />
<div class="uid">uid1@host.com</div><br />
<div>Organized by: [mailto:jsmith@host.com jsmith@host.com]</div><br />
<div>Dates: <abbr class="dtstart" title="19960918T143000Z">September 18, 1996, 14:30 UTC</abbr> -<br />
<abbr class="dtend" title="19960920T220000Z">September 20, 1996, 22:00 UTC</abbr></div><br />
<div>Status: <span class="status">confirmed</span></div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Conference</li><br />
</ul><br />
</div><br />
<br />
<br />
==== Exemple 2 ====<br />
L'exemple suivant spécifie une réunion programmée d'un groupe qui démarre le 12 mars 1998 à 8:30 AM EST et se termine à 9:30 AM EST le 12 mars 1998. L'"Organizer" a programmé la réunion avec un ou plusieurs calendriers utilisateurs dans un groupe. Une spécification de "time zone" pour l'Est des Etats Unis a été spécifiée.<br />
<br />
<pre><nowiki><br />
BEGIN:VCALENDAR<br />
PRODID:-//RDU Software//NONSGML HandCal//EN<br />
VERSION:2.0<br />
BEGIN:VTIMEZONE<br />
TZID:US-Eastern<br />
BEGIN:STANDARD<br />
DTSTART:19981025T020000<br />
RDATE:19981025T020000<br />
TZOFFSETFROM:-0400<br />
TZOFFSETTO:-0500<br />
TZNAME:EST<br />
END:STANDARD<br />
BEGIN:DAYLIGHT<br />
DTSTART:19990404T020000<br />
RDATE:19990404T020000<br />
TZOFFSETFROM:-0500<br />
TZOFFSETTO:-0400<br />
TZNAME:EDT<br />
END:DAYLIGHT<br />
END:VTIMEZONE<br />
BEGIN:VEVENT<br />
DTSTAMP:19980309T231000Z<br />
UID:guid-1.host1.com<br />
ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com<br />
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:MAILTO:employee-A@host.com<br />
DESCRIPTION:Project XYZ Review Meeting<br />
CATEGORIES:MEETING<br />
CLASS:PUBLIC<br />
CREATED:19980309T130000Z<br />
SUMMARY:XYZ Project Review<br />
DTSTART;TZID=US-Eastern:19980312T083000<br />
DTEND;TZID=US-Eastern:19980312T093000<br />
LOCATION:1CP Conference Room 4350<br />
END:VEVENT<br />
END:VCALENDAR<br />
</nowiki></pre><br />
<br />
Ce iCalendar sous un hCalendar :<br />
<br />
<pre><nowiki><br />
@TODO<br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme :<br />
<br />
@TODO<br />
<br />
==== Exemple 3 ====<br />
<pre><nowiki><br />
BEGIN:VCALENDAR<br />
METHOD:xyz<br />
VERSION:2.0<br />
PRODID:-//ABC Corporation//NONSGML My Product//EN<br />
BEGIN:VEVENT<br />
DTSTAMP:19970324T1200Z<br />
SEQUENCE:0<br />
UID:uid3@host1.com<br />
ORGANIZER:MAILTO:jdoe@host1.com<br />
ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com<br />
DTSTART:19970324T123000Z<br />
DTEND:19970324T210000Z<br />
CATEGORIES:MEETING,PROJECT<br />
CLASS:PUBLIC<br />
SUMMARY:Calendaring Interoperability Planning Meeting<br />
DESCRIPTION:Discuss how we can test c&s interoperability\nusing iCalendar and other IETF standards.<br />
LOCATION:LDB Lobby<br />
ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/conf/bkgrnd.ps<br />
END:VEVENT<br />
END:VCALENDAR<br />
</nowiki></pre><br />
<br />
Ce iCalendar sous un hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vcalendar"><br />
<div>Method: <span class="method">xyz</span></div><br />
<div class="vevent"><br />
<div>Posted at: <span class="dtstamp">19970324T1200Z</span></div><br />
<div>Sequence: <span class="sequence">0</span></div><br />
<div>UID: <span class="uid">uid3@host1.com</span></div><br />
<div>Organzied by: <a class="organizer" href="mailto:jdoe@host1.com">jdoe@host1.com</a></div><br />
<div>Attending: <span class="attendee"><a class="value" href="mailto:jsmith@host1.com">jsmith@host1.com</a> RSVPed? <span class="rsvp">TRUE</span></span></div><br />
<div>Start Time: <abbr class="dtstart" title="19970324T123000Z">March 24, 1997 12:30 UTC</abbr></div><br />
<div>End Time: <abbr class="dtend" title="19970324T210000Z">March 24, 1997, 21:00 UTC</abbr></div><br />
<ul><br />
<li class="category">Meeting</li><br />
<li class="category">Project</li><br />
</ul><br />
<div>This event is <strong class="class">Public</strong></div><br />
<div class="summary">Calendaring Interoperability Planning Meeting</div><br />
<div class="description">Discuss how we can test c&s interoperability using iCalendar and other IETF standards.</div><br />
<div class="location">LDB Lobby</div><br />
<div>Attachment: <a class="attach" type="application/postscript" href="ftp://xyzCorp.com/pub/conf/bkgrnd.ps">ftp://xyzCorp.com/pub/conf/bkgrnd.ps</a></div><br />
</div><br />
</div><br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme :<br />
<br />
<div class="vcalendar"><br />
<div>Method: <span class="method">xyz</span></div><br />
<div class="vevent"><br />
<div>Posted at: <span class="dtstamp">19970324T1200Z</span></div><br />
<div>Sequence: <span class="sequence">0</span></div><br />
<div>UID: <span class="uid">uid3@host1.com</span></div><br />
<div>Organzied by: [mailto:jdoe@host1.com jdoe@host1.com]</div><br />
<div>Attending: <span class="attendee">[mailto:jsmith@host1.com jsmith@host1.com], RSVPed? <span class="rsvp">TRUE></span></span></div><br />
<div>Start Time: <abbr class="dtstart" title="19970324T123000Z">March 24, 1997 12:30 UTC</abbr></div><br />
<div>End Time: <abbr class="dtend" title="19970324T210000Z">March 24, 1997, 21:00 UTC</abbr></div><br />
<ul><br />
<li class="category">Meeting</li><br />
<li class="category">Project</li><br />
</ul><br />
<div>This event is <strong class="class">Public</strong></div><br />
<div class="summary">Calendaring Interoperability Planning Meeting</div><br />
<div class="description">Discuss how we can test c&s interoperability using iCalendar and other IETF standards.</div><br />
<div class="location">LDB Lobby</div><br />
<div>Attachment: [ftp://xyzCorp.com/pub/conf/bkgrnd.ps ftp://xyzCorp.com/pub/conf/bkgrnd.ps]</div><br />
</div><br />
</div><br />
<br />
<br />
==== Exemple 4 ====<br />
<br />
Ce qui suit est un exemple d'une to-do pour le 15 avril 1998. Une alarme audio a été spécifiée pour faire rappeler le calendrier utilisateur, le jour précédent la todo est attendu à être complété et répété toutes les heurs, à quatre reprise. La définition de la to-do a été modifiée deux fois depuis qu'elle a été initialement créée.<br />
<br />
<pre><nowiki><br />
BEGIN:VCALENDAR<br />
VERSION:2.0<br />
PRODID:-//ABC Corporation//NONSGML My Product//EN<br />
BEGIN:VTODO<br />
DTSTAMP:19980130T134500Z<br />
SEQUENCE:2<br />
UID:uid4@host1.com<br />
ORGANIZER:MAILTO:unclesam@us.gov<br />
ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com<br />
DUE:19980415T235959<br />
STATUS:NEEDS-ACTION<br />
SUMMARY:Submit Income Taxes<br />
BEGIN:VALARM<br />
ACTION:AUDIO<br />
TRIGGER:19980403T120000<br />
ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-files/ssbanner.aud<br />
REPEAT:4<br />
DURATION:PT1H<br />
END:VALARM<br />
END:VTODO<br />
END:VCALENDAR<br />
</nowiki></pre><br />
<br />
Ce iCalendar sous un hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vcalendar"><br />
<div class="vtodo"><br />
<div>Posted at: <span class="dtstamp">19980130T134500Z</span></div><br />
<div>Sequence <span class="sequence">2</span></div><br />
<div>UID: <span class="uid">uid4@host1.com</span></div><br />
<div>Organizer: [mailto:unclesam@us.gov unclesam@us.gov]</div><br />
<div>Attending: [mailto:jqpublic@host.com jqpublic@host.com], <span class="partstat">ACCEPTED</span></span></div><br />
<div>Due: <abbr class="due" title="19980415T235959">one minute before midnight on April 15, 1998</abbr></div><br />
<div>Status: <span class="status">needs-action</span></div><br />
<div class="summary">Submit Income Taxes</div><br />
<div class="valarm"><br />
<div>Action: <span class="action">AUDIO</span></div><br />
<div>Trigger: <span class="trigger">19980403T120000</span></div><br />
<div>Attachment: <a class="attach" type="audio/basic" href="http://host.com/pub/audio-files/ssbanner.aud">http://host.com/pub/audio-files/ssbanner.aud</a></div><br />
<div>Repeat: <span class="repeat">4</span></div><br />
<div>Duration: <span class="duration">PT1H</span></div><br />
</div><br />
</div><br />
</div><br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme :<br />
<br />
<div class="vcalendar"><br />
<div class="vtodo"><br />
<div>Posted at: <span class="dtstamp">19980130T134500Z</span></div><br />
<div>Sequence <span class="sequence">2</span></div><br />
<div>UID: <span class="uid">uid4@host1.com</span></div><br />
<div>Organizer: [mailto:unclesam@us.gov unclesam@us.gov]</div><br />
<div>Attending: [mailto:jqpublic@host.com jqpublic@host.com], <span class="partstat">ACCEPTED</span></span></div><br />
<div>Due: <abbr class="due" title="19980415T235959">one minute before midnight on April 15, 1998</abbr></div><br />
<div>Status: <span class="status">needs-action</span></div><br />
<div class="summary">Submit Income Taxes</div><br />
<div class="valarm"><br />
<div>Action: <span class="action">AUDIO</span></div><br />
<div>Trigger: <span class="trigger">19980403T120000</span></div><br />
<div>Attachment: [http://host.com/pub/audio-files/ssbanner.aud http://host.com/pub/audio-files/ssbanner.aud]</div><br />
<div>Repeat: <span class="repeat">4</span></div><br />
<div>Duration: <span class="duration">PT1H</span></div><br />
</div><br />
</div><br />
</div><br />
<br />
==== Exemple 5 : entrée de journal ====<br />
Ce qui suit est un exemple d'entrée de journa : <br />
<br />
<pre><nowiki><br />
BEGIN:VCALENDAR<br />
VERSION:2.0<br />
PRODID:-//ABC Corporation//NONSGML My Product//EN<br />
BEGIN:VJOURNAL<br />
DTSTAMP:19970324T120000Z<br />
UID:uid5@host1.com<br />
ORGANIZER:MAILTO:jsmith@host.com<br />
STATUS:DRAFT<br />
CLASS:PUBLIC<br />
CATEGORY:Project Report, XYZ, Weekly Meeting<br />
DESCRIPTION:Project xyz Review Meeting Minutes\nAgenda\n<br />
1. Review of project version 1.0 requirements.\n<br />
2. Definition of project processes.\n<br />
3. Review of project schedule.\nParticipants: John Smith, Jane Doe, Jim Dandy\n<br />
-It was decided that the requirements need to be signed off by product marketing.\n<br />
-Project processes were accepted.\n<br />
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.\n<br />
-New schedule will be distributed by Friday.\n<br />
-Next weeks meeting is cancelled. No meeting until 3/23.<br />
END:VJOURNAL<br />
END:VCALENDAR<br />
</nowiki></pre><br />
<br />
(*note* : les sauts de ligne ont été ajoutés dans la description, en réalité, ce devrait être en une ligne)<br />
<br />
Ce fragment iCalendar sous hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vcalendar"><br />
<div class="vjournal"><br />
<div>Posted at: <abbr class="dtstamp" title="19970324T120000Z">March 24, 1997, 12:00 UTC</abbr></div><br />
<div class="uid">uid5@host1.com</div><br />
<div>Organizer: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></div><br />
<div>Status: <span class="status">Draft</span></div><br />
<div>This journal is<span class="class">Public</span>.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Project Report</li><br />
<li class="category">xyz</li><br />
<li class="category">Weekly Meeting</li><br />
</ul><br />
<div class="description">Project xyz Review Meeting Minutes<br /><br />
Agenda<br /><br />
1. Review of project version 1.0 requirements.<br /><br />
2. Definition of project processes.<br /><br />
3. Review of project schedule.<br /><br />
Participants: John Smith, Jane Doe, Jim Dandy<br /><br />
-It was decided that the requirements need to be signed off by product marketing.<br /><br />
-Project processes were accepted.<br /><br />
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.<br /><br />
-New schedule will be distributed by Friday.<br /><br />
-Next weeks meeting is cancelled. No meeting until 3/23.<br />
</div><br />
</div><br />
</div><br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme :<br />
<br />
<div class="vcalendar"><br />
<div class="vjournal"><br />
<div>Posted at: <abbr class="dtstamp" title="19970324T120000Z">March 24, 1997, 12:00 UTC</abbr></div><br />
<div class="uid">uid5@host1.com</div><br />
<div>Organizer: [mailto:jsmith@host.com jsmith@host.com]</div><br />
<div>Status: <span class="status">Draft</span></div><br />
<div>This journal is<span class="class">Public</span>.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Project Report</li><br />
<li class="category">xyz</li><br />
<li class="category">Weekly Meeting</li><br />
</ul><br />
<div class="description">Project xyz Review Meeting Minutes<br /><br />
Agenda<br /><br />
1. Review of project version 1.0 requirements.<br /><br />
2. Definition of project processes.<br /><br />
3. Review of project schedule.<br /><br />
Participants: John Smith, Jane Doe, Jim Dandy<br /><br />
-It was decided that the requirements need to be signed off by product marketing.<br /><br />
-Project processes were accepted.<br /><br />
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.<br /><br />
-New schedule will be distributed by Friday.<br /><br />
-Next weeks meeting is cancelled. No meeting until 3/23.<br />
</div><br />
</div><br />
</div><br />
<br />
==== Exemple 6. temps Free/Busy ====<br />
<br />
Ce qui suit est un exmple d'information publiée sur le temps occupé. L'objet iCalendar pourrait être placé dans la ressource réseau www.host.com/calendar/busytime/jsmith.ifb.<br />
<br />
<pre><nowiki><br />
BEGIN:VCALENDAR<br />
VERSION:2.0<br />
PRODID:-//RDU Software//NONSGML HandCal//EN<br />
BEGIN:VFREEBUSY<br />
ORGANIZER:MAILTO:jsmith@host.com<br />
DTSTART:19980313T141711Z<br />
DTEND:19980410T141711Z<br />
FREEBUSY:19980314T233000Z/19980315T003000Z<br />
FREEBUSY:19980316T153000Z/19980316T163000Z<br />
FREEBUSY:19980318T030000Z/19980318T040000Z<br />
URL:http://www.host.com/calendar/busytime/jsmith.ifb<br />
END:VFREEBUSY<br />
END:VCALENDAR<br />
</nowiki></pre><br />
<br />
Ce fragment iCalendar sous hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vcalendar"><br />
<div>Version: <span class="version">2.0</span></div><br />
<div>ProdID:<span class="prodid">-//RDU Software//NONSGML HandCal//EN</span></div><br />
<div class="vfreebusy"><br />
<div>Organizer: <span class="organizer">MAILTO:jsmith@host.com</span></div><br />
<div>Start Time: <abbr class="dtstart" title="19980313T141711Z">March 13, 1998 14:17:11 UTC</abbr></div><br />
<div>End time: <abbr class="dtend" title="19980410T141711Z">April 10, 1998 14:17:11 UTC</abbr></div><br />
<p>Busy times:</p> <!-- note that the default is BUSY --><br />
<ol><br />
<li class="freebusy"><abbr class="dtstart" title="19980314T233000Z">1998-03-14 23:30:00 UTC</abbr> - <abbr class="dtend" title="19980315T003000Z">1998-03-15- 00:30:00 UTC</abbr></li><br />
<li class="freebusy"><abbr class="dtstart" title="19980316T153000Z">1998-03-16 15:30:00 UTC</abbr> - <abbr class="dtend" title="19980316T163000Z">1998-03-16 16:30:00 UTC</abbr></li><br />
<li class="freebusy"><abbr class="dtstart" title="19980318T030000Z">1998-03-18 03:00:00 UTC</abbr> - <abbr class="dtend" title="19980318T040000Z">1998-03-18 04:00:00 UTC</abbr></li><br />
</ol><br />
<div>URL <a class="url" href="http://www.host.com/calendar/busytime/jsmith.ifb">http://www.host.com/calendar/busytime/jsmith.ifb</a></div><br />
</div><br />
</div><br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme :<br />
<br />
@TODO<br />
<br />
== Autres ==<br />
<br />
* voir [[hcalendar-brainstorming]] pour plus d'exemples (qui peuvent éventuellement être migrés ici) et des analyses.</div>ScottReynenhttps://microformats.org/wiki/index.php?title=xoxo-fr&diff=18221xoxo-fr2007-06-18T16:17:35Z<p>ScottReynen: Reverted edit of By6Twl, changed back to last version by Tantek</p>
<hr />
<div><h1> XOXO 1.0 : eXtensible Open XHTML Outlines </h1><br />
<br />
XOXO est un simple format ouvert d'outline écrit en XHTML standard et adaptable pour embarquement dans (X)HTML, Atom, RSS et le XML arbitraire. <br />
XOXO est l'un des nombreux [[microformats-fr|microformats]] standards ouverts . <br />
<br />
__TOC__<br />
<br />
== Spécification Brouillon du 01-Octobre-2004 ==<br />
<br />
=== Editeur ===<br />
[http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc]<br />
<br />
=== Auteurs ===<br />
* [http://epeus.blogspot.com/ Kevin Marks], [http://technorati.com Technorati, Inc]<br />
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc] (formerly of [http://microsoft.com/ Microsoft Corporation])<br />
* [http://diveintomark.org/ Mark Pilgrim], [http://ibm.com IBM]<br />
* [http://www.blogologue.com/ Morten W. Petersen]<br />
<br />
=== Traducteur(s) ===<br />
* [[Christophe Ducamp]]<br />
<br />
<br />
=== Copyright ===<br />
{{MicroFormatCopyrightStatement2003-fr}}<br />
<br />
=== Brevets ===<br />
{{MicroFormatPatentStatement-fr}}<br />
<br />
== Préambule ==<br />
Quand nous avons discuté d'[http://developers.technorati.com/wiki/attentionxml Attention.xml], Tantek faisait remarquer que XHTML a tout ce qui est nécessaire pour exprimer sémantiquement des outlines et des abonnements comme des blogrolls dans un format XML qui soit à la fois restituable interactivement par des navigateurs et parsable par des moteurs XML strict. Cette page est ici pour disctuer de cette idée.<br />
<br />
=== Nom ===<br />
XOXO veut dire eXtensible Open XHTML Outlines, et se prononce selon 'icks oh icks oh', 'zho-zho', ou 'cho-cho'.<br />
<br />
== Abstract ==<br />
XOXO est l'un des nombreux [[microformats-fr|microformats]]. Cette spécification définit un nouveau type de document XHTML basé sur le squelette module et les modules définis dans Modularisation du XHTML ([http://www.w3.org/TR/xhtml-modularization XHTMLMOD]). Le but du type de document XOXO est de servir de base pour des outlines XHTML faciles qui puissent être traités par les moteurs XML et pour une restitution interactive facile par les navigateurs.<br />
<br />
== Le type de Document XOXO ==<br />
Le type de document XOXO est construit sur les modules suivants XHTML. <br />
Les éléments, attributs et modèles de contenu minimal associés avec ces modules sont définis dans "Modularization of XHTML" ([http://www.w3.org/TR/xhtml-modularization XHTMLMOD]). <br />
Les éléments sont listés ici à des fins d'information, mais les définitions dans "Modularization of XHTML" devraient être considérées comme définitives. Dans la version en ligne de ce document, les noms de modules dans la liste en-dessous pointent dans les définitions des modules dans la version actuelle de "Modularization of XHTML".<br />
<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_structuremodule Structure Module]<br />
body, head, html, title<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_hypertextmodule Hypertext Module]<br />
a<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_listmodule List Module]<br />
dl, dt, dd, ol, ul, li<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_metamodule Metainformation Module]<br />
meta<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_stylemodule Stylesheet Module]<br />
style element<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_styleattributemodule Style Attribute Module]<br />
style attribute<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_linkmodule Link Module]<br />
link<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_legacymodule Legacy Module]<br />
Attribute compact on ol and ul<br />
<br />
=== Le Profil XOXO ===<br />
<br />
Voir [[xoxo-profile-fr|xoxo-profile]] pour le profil [http://gmpg.org/xmdp XMDP] de XOXO qui définit les valeurs XOXO pour l'attribut class.<br />
<br />
== Fragment Simple XOXO ==<br />
<br />
=== Balisage ===<br />
<br />
<pre><nowiki><ol class='xoxo'><br />
<li>Sujet 1<br />
<ol><br />
<li>souspoint a</li><br />
<li>souspoint b</li><br />
</ol><br />
</li><br />
<li>Sujet 2<br />
<ol compact="compact"><br />
<li>souspoint c</li><br />
<li>souspoint d</li><br />
</ol><br />
</li><br />
<li>Sujet 3<br />
<ol><br />
<li>souspoint e</li><br />
</ol><br />
</li><br />
</ol><br />
</nowiki></pre><br />
<br />
=== Restitution Echantillon ===<br />
<pre><nowiki><br />
1. Sujet 1<br />
a. souspoint a<br />
b. souspoint b<br />
2. Sujet 2<br />
3. Sujet 3<br />
a. souspoint e<br />
</nowiki></pre><br />
=== Usage de l'attribut 'compact' ===<br />
<br />
Notez l'utilisation de l'attribut 'compact' pour indiquer que les sous-points du titre "Sujet 2" <br />
ne sont pas dans un état déployé. L'absence de l'attribut 'compact' ailleurs indique que les autres titres <br />
sont en état déployé.<br />
<br />
=== Règles de Style par Défaut pour une Restitution Echantillon ===<br />
<br />
<pre><nowiki><br />
ol.xoxo { list-style:decimal; }<br />
ol.xoxo ol { list-style:lower-latin; }<br />
ol[compact="compact"] { display:none; }<br />
</nowiki></pre><br />
<br />
<br />
== Plus d'Exemples Simples ==<br />
<br />
MarkP a un ensemble d'exemples qui démontrent à la fois la simplicité du balisage et la richesse de présentation qui est possible : <br />
<br />
* [http://diveintomark.org/public/2004/01/xo-flat.xo fichier simple XO qui peut être directement embarqué à l'intérieur d'une page XHTML]<br />
* [http://diveintomark.org/public/2004/01/xo-embeddable.xo XO avec groupes imbriqués, aussi directement embarquable dans le XHTML]<br />
* [http://diveintomark.org/public/2004/01/xo-standalone.xo XO comme page XHTML autonome] ([http://validator.w3.org/check?uri=http%3A%2F%2Fdiveintomark.org%2Fpublic%2F2004%2F01%2Fxo-standalone.xo XHTML valide])<br />
* [http://diveintomark.org/public/2004/01/xo-with-style.xo XO comme page XHTML autonome, mise en forme avec CSS] ([http://validator.w3.org/check?uri=http%3A%2F%2Fdiveintomark.org%2Fpublic%2F2004%2F01%2Fxo-with-style.xo aussi valide XHTML])<br />
* [http://homepage.mac.com/ctholland/thelab/outlines/ Chris Holland Outline Helper] : tordu l'un des exemples au-dessus, yanked CSS pour la simplicity, ajouté référence vers [http://homepage.mac.com/ctholland/thelab/outlines/outlines.css outlines.css] et [http://homepage.mac.com/ctholland/thelab/outlines/outlines.js outlines.js], copié quelques combinaisons différentes de ul/ol/li avec l'attribut compact.<br />
** en essayant de rester compatible avec les principes de l'attribut "compact" pour les éléments ol et ul est ce qui conduit à l'état d'affichage. <br />
Via la programmation, je suis en train d'installer des classes sur l'élément conteneur li pour une flexibilité ajouté de style, même si les gourous CSS pourraient être capables de remplacer "li.expanded" dans outlines.css avec quelque autre sélecteur CSS qui dise "sélectionnez un noeud li qui contient un noeud ol avvec un réglage d'attribut sur 'compact' ".<br />
<br />
== Propriétés des Items Outline ==<br />
Outlines consiste généralement en une hiérarchie de points et sous-points. <br />
Chacun de ces points (items outlines) peut avoir lui-même quelques propriétés (comme des attributs ou des méta-données) qui ont besoin d'être représentées. Peut-être que la propriété supplémentaire la plus commune sur les items d'outline est en pratique l'URL comme cela est démontré dans les exemples de Mark Pilgrim au-dessus. Même le texte label/title d'un item outline pourrait être considéré comme une propriété commmune. Quelques propriétés communes :<br />
* text<br />
* description<br />
* url (souvent appelé xmlurl ou htmlurl ; parfois appelé permalink)<br />
* title<br />
* type (truc du MIME type de la ressource indiqué par l'URL)<br />
<br />
En général, les propriétés d'un item outline <code><nowiki><li></nowiki></code> sont représentées par une liste de définitions imbriquées <code><nowiki><dl></nowiki></code>. A strictement parler, c'est le premier <code><nowiki><dl></nowiki></code> à l'intérieur du <code><nowiki><li></nowiki></code> et avant tout <code><nowiki><ol></nowiki></code>, <code><nowiki>&lt;ul&gt;</nowiki></code>, ou <code>&lt;li&gt;</code> suivant, par ex. voici un item "item 1" avec une propriété de description (les sous-points sont là purement comme un point de référence vers un exemple antérieur).<br />
<br />
<pre><nowiki><br />
<ol class='xoxo'><br />
<li>item 1<br />
<dl><br />
<dt>description</dt><br />
<dd>cet item représente le point principal que nous essayons de produire.</dd><br />
</dl><br />
<ol><br />
<li>souspoint a</li><br />
<li>souspoint b</li><br />
</ol><br />
</li><br />
</nowiki></pre><br />
<br />
=== Propriétés Spéciales ===<br />
Il existe un paquet de propriétés spéciales que nous pouvons représenter plus directement <br />
et de façon commode avec les blocs de construction du XHTML sémantique que nous avons inclus, au lieu de termes dans une liste de définition. La plupart sont extraits de la liste au-dessus des propriétés communes, ce sont : <br />
* text, url, title, type, et rel (raccourci de relationship)<br />
<br />
Si nous devions les représenter simplement comme des termes de définition (y compris la propriété "description" tirée du précédent exemple), cela pourrait ressembler à quelque chose comme ça : <br />
<br />
Exemple pour recherche de discussion seulement / pas un exemple canonique XOXO :<br />
<br />
<pre><nowiki><br />
<ol class='xoxo'><br />
<li><br />
<dl><br />
<dt>text</dt><br />
<dd>item 1</dd><br />
<dt>description</dt><br />
<dd> Cet item représente le point principal que nous essayons de produire.</dd><br />
<dt>url</dt><br />
<dd>http://exemple.com/plus.xoxo</dd><br />
<dt>title</dt><br />
<dd>titre de item 1</dd><br />
<dt>type</dt><br />
<dd>text/xml</dd><br />
<dt>rel</dt><br />
<dd>aide</dd><br />
</dl><br />
</li><br />
</nowiki></pre><br />
<br />
Néanmoins, en tirant profit de l'élément sémantique <code><a href></code>, nous pouvons dramatiquement simplifier les cases communes qui utilisent ces propriétés. Du point de vue d'un parseur, ceci s'applique au premier élément <code><a href></code> diretement dans le <code><nowiki>&lt;li&gt;</nowiki></code>.<br />
<br />
Exemple véritable XOXO :<br />
<br />
<pre><nowiki><br />
<ol class='xoxo'><br />
<li><a href="http://exemple.com/more.xoxo"<br />
title="titre item 1"<br />
type="text/xml"<br />
rel="help">item 1</a> <br />
<!-- notez comme la propriété "text" est simplement les contenus de l'élément <a> --><br />
<dl><br />
<dt>description</dt><br />
<dd>Cet item présente le point principal que nous essayons de produire.</dd><br />
</dl><br />
</li><br />
</nowiki></pre><br />
<br />
Toutes les autres propriétés sont simplement ajoutées à la liste de définition <br />
de la même façon que la propriété "description".<br />
<br />
== Publier XOXO ==<br />
<br />
XOXO peut être pubié sous deux formes, XHTML valide, et XML simple et bien formé.<br />
<br />
=== XOXO XHTML Valide ===<br />
<br />
Une page XOXO XHTML Valide est un document XHTML complet.<br />
<br />
<pre><nowiki><br />
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"<br />
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><br />
<html xmlns="http://www.w3.org/1999/xhtml"><br />
<head><br />
<meta http-equiv="content-type" content="text/html; charset=utf-8" /><br />
<title>XOXO page</title><br />
</head><br />
<body><br />
<ol class="xoxo"><br />
<li><a href="URL-un">TEXT-un</a></li><br />
<li><a href="URL-deux">TEXT-deux</a></li><br />
...<br />
</ol><br />
</body><br />
</html><br />
</nowiki></pre><br />
<br />
==== Content-Type ====<br />
<br />
Le XOXO XHTML Valide DEVRAIT être servi avec cet en-tête Content-Type pour une compatibilité navigateur maximale.<br />
<br />
<pre><nowiki><br />
Content-Type: text/html; charset=utf-8<br />
</nowiki></pre><br />
<br />
Il DOIT être servi avec l'un de ces en-têtes de Content-Type :<br />
<br />
<pre><nowiki><br />
Content-Type: text/html; charset=utf-8<br />
Content-Type: application/xhtml+xml<br />
</nowiki></pre><br />
<br />
=== XOXO XML Simple bien-formé ===<br />
<br />
L'élément racine d'une page XOXO XML simple bien formé est soit un <code>ol</code> ou <code>ul</code> avec le nom de classe de "xoxo". Cette variante est idéale pour la syndication et la transclusion à l'intérieur de pages (X)HTML avec [[rest/ahah|AHAH]].<br />
<br />
<pre><nowiki><br />
<ol class="xoxo"><br />
<li><a href="URL-un">TEXTE-un</a></li><br />
<li><a href="URL-deux">TEXTE-deux</a></li><br />
...<br />
</ol><br />
</nowiki></pre><br />
<br />
==== Content-Type ====<br />
<br />
Le XML Simple bien formé XOXO DEVRAIT être servi avec cet en-tête Content-Type :<br />
<pre><nowiki><br />
Content-Type: text/xml; charset=utf-8<br />
</nowiki></pre><br />
<br />
Il DOIT être servi avec l'un de ces en-têtes Content-Type :<br />
<br />
<pre><nowiki><br />
Content-Type: text/xml; charset=utf-8<br />
Content-Type: application/xml<br />
Content-Type: application/xml; charset=utf-8<br />
</nowiki></pre><br />
<br />
== Exemples dans la Jungle ==<br />
Cette section est '''informative'''.<br />
<br />
Trop nombreux pour documenter exhaustivement. Presque chaque blogroll sur le web peut être parsée sous XOXO, parce qu'elles sont généralement sous formes de listes non ordonnées d'items de listes d'hyperliens, ce qui est dans le profil XOXO.<br />
<br />
== Implémentations ==<br />
Cette section est '''informative'''.<br />
<br />
* [http://chneukirchen.org/blog/ Christian Neukirchen] a [http://chneukirchen.org/blog/archive/2006/01/xoxo-rb-0-1-released.html écrit un xoxo.rb, un parseur XOXO et un générateur pour Ruby]<br />
* [http://odeo.com Odeo] publie les liste d'abonnements utilisateurs dans XOXO. Voir la liste de Ryan King [http://odeo.com/profile/RyanKing/xoxo ici].<br />
* [http://www.decafbad.com/blog/ Les Orchard] a [http://www.decafbad.com/blog/2005/07/12/xoxo_outliner_experiment écrit] un [http://www.decafbad.com/2005/07/map-test/tree2.html bel éditeur XOXO en javascript].<br />
* http://homepage.mac.com/ctholland/thelab/outlines/ est une démonstration géniale du XOXO dynamique et interactif avec l'utilisation de "compact" et du DHTML pour déployer/replier.<br />
* http://tool-man.org/examples/sorting.html est une démonstration géniale de listes XOXO "glisser déposer" triables avec javascript and CSS.<br />
* http://www.joshpeek.com/projects/opmltoxoxo est un convertisseur extensible de OPML vers XOXO.<br />
* http://www.opendarwin.org/~drernie/xoxo-datatypes.html Mapper XOXO en [http://developer.apple.com/documentation/Cocoa/Conceptual/PropertyLists/Concepts/XMLPListsConcept.html listes de propriétés Mac OS X]<br />
* [http://weblog.techno-weenie.net/2005/9/30/if_i_had_a_tumblelog ligne unique de rails pour convertir XOXO en HTML]<br />
<br />
<br />
=== Code échantillon ===<br />
<br />
* Voir la page [[xoxo-sample-code-fr|xoxo-code-échantillon]] pour un code échantillon open source afin de lire et écrire des fichiers XOXO.<br />
* Voir aussi la page [[xoxo-compact-sample-fr|xoxo-échantillon-compact]] avec la source pour le CSS et JS qui altère le "look and feel" de quelque XOXO pour avoir des triangles dépliables dans les listes imbriquées qui respectent aussi l'attribut compact.<br />
<br />
== Schémas XOXO ==<br />
Cette section est "informative".<br />
<br />
Note : ces liens peuvent être démodés et ont besoin d'être mis à jour pour refléter l'utilisation de &lt;dl&gt; pour l'annotation d'items XOXO avec des propriétés arbitraires.<br />
* [[DTDs]]<br />
* [http://www.nidelven-it.no/projects/XOXO/xoxo-0.1.tgz Schemas (Relax NG and DTDs)]<br />
<br />
<br />
== Références ==<br />
=== Références "Normatives" ===<br />
* [http://www.w3.org/TR/xhtml1 XHTML 1.0]<br />
* [http://www.w3.org/TR/xhtml-modularization XHTMLMOD]<br />
* [http://gmpg.org/xmdp/ XMDP]<br />
* [http://gmpg.org/xfn/ XFN]<br />
<br />
=== Références "Informatives" ===<br />
Cette section est '''informative'''.<br />
* [http://developers.technorati.com/wiki/attentionxml Attention.xml]<br />
* [[vote-links-fr|VoteLinks]]<br />
* [http://www.w3.org/TR/xhtml11 XHTML 1.1]<br />
* [http://opml.scripting.com/spec OPML 1.0]<br />
* Contribution provenant de http://developers.technorati.com/wiki/XOXO<br />
<br />
=== Travaux similaires ===<br />
* [http://dannyayers.com/archives/001961.html XHTML Outlines] - DannyAyers a sorti indépendamment l'idée en octobre 2003 (juste un mois ou deux avant que Kevin et Tantek se sortent indépendamment XOXO) d'utiliser un simple profil XHTML <br />
pour représenter sémantiquement les outlines en utilisant des blocs de constrution existant provenant du XHTML.<br />
* [http://semtext.org/2004-02/ XOW] - les rend éditables, produisant des listes de RDF et bookmark à partir d'eux (DannyAyers)<br />
<br />
=== Lecture en Rapport ===<br />
* [http://patricklogan.blogspot.com/2005/08/lists-really-can-we-expect-better.html Patrick Logan sur pourquoi OPML et une extension Microsoft Lists sont tous deux non nécessaires].<br />
* [http://raybenchen.blogspot.com/2005/11/is-crappy-format-worth-saving.html Dr. Tao Chen sur pourquoi il est mieux d'utiliser XOXO que de continuer à avancer sur OPML]<br />
<br />
=== Lecture sans aucun rapport ===<br />
* [http://www.questionablecontent.net/view.php?comic=493 Questionable Content comic #493] - apparemment le personnage Faye est un fan of XOXO.<br />
<br />
=== Contenus Promotionnels / Schwag ===<br />
* Il existe toute une ligne de vêtements et d'accessoires en ligne. [http://www.xoxo.com/home.php Buy XOXO stuff online].<br />
<br />
== Discussions ==<br />
Cette spécification est un chantier en cours. Au fur et à mesure que des aspects supplémentaires sont discutés, compris et écrits, ils seront ajoutés. Il existe un document séparé où nous gardons traces de nos brainstorms et autres explorations en rapport avec XOXO :<br />
<br />
* Voir [[xoxo-brainstorming-fr]] pour des idées supplémentaires sur la façon d'utiliser XOXO pour des usages spécifiques.<br />
* Voir aussi [http://www.technorati.com/cosmos/referer.html les blogs qui discutent de cette page].<br />
** [http://blogxoxo.blogspot.com/ XOXO Blog]<br />
<br />
=== Q&R ===<br />
* Si vous avez quelque question à propos de XOXO, regardez les [[xoxo-faq-fr|xoxo-faq]], et si vous ne trouvez pas de réponses, ajoutez vos questions !<br />
<br />
=== Problématiques ===<br />
* ajoutez svp toute problématique sur la spécification à la page document séparée [[xoxo-issues-fr|problématiques xoxo]].</div>ScottReynenhttps://microformats.org/wiki/index.php?title=blog-description-format-brainstorming&diff=17627blog-description-format-brainstorming2007-06-18T16:16:54Z<p>ScottReynen: Reverted edit of MvmHhj, changed back to last version by Brian</p>
<hr />
<div>= Blog description format (brainstorming)=<br />
__TOC__<br />
<br />
== Discussion Participants ==<br />
<br />
=== Editors ===<br />
* [http://bs-markup.de Bj&ouml;rn Seibert], [http://rbach.priv.at/ Robert Bachmann]<br />
<br />
=== Authors ===<br />
* [http://bs-markup.de Bj&ouml;rn Seibert], [http://rbach.priv.at/ Robert Bachmann]<br />
<br />
== Purpose ==<br />
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.<br />
<br />
Here are some of examples for information that might be provided:<br />
<br />
* Details about the blog<br />
* Blog name (e.g: "John Doe's Blog")<br />
** Blog URI (e.g: http://example.org/ )<br />
** Lanuage used for the blog, read-able by machines (e.g: "en-US" or "de")<br />
** Topics covered by the blog<br />
** A short description<br />
** Available feeds (RSS, Atom, etc.)<br />
** A small logo image<br />
* Details about the author(s)<br />
** Name (e.g: "John Doe")<br />
** Organisation<br />
** Contact details <br />
** Geographical Location<br />
<br />
== Theoretical examples ==<br />
<br />
<pre><nowiki><br />
<div class="blogformat" xml:lang="en"><br />
<p><img class="logo" alt="" src="http://rbach.priv.at/Misc/2005/Smiley.gif" /><br />
<a class="author" href="http://example.org/jdoe">My</a> <br />
<a class="bookmark" href="http://example.org/blog" title="John Doe's Blog">blog</a><br />
about <br />
<span class="description"><br />
<a rel="tag" href="http://technorati.com/tags/web+standards">Web standards</a>,<br />
<a rel="tag" href="http://technorati.com/tags/css">CSS</a>,<br />
<a rel="tag" href="http://technorati.com/tags/xhtml">XHTML</a><br />
and topics releated to web development.</span></p><br />
<p>There are <br />
<a rel="alternate" type="application/atom+xml" href="http://example.org/feeds/atom">Atom</a> and <br />
<a rel="alternate" type="application/rss+xml" href="http://example.org/feeds/rss">RSS 2.0</a><br />
feeds available.</p><br />
</div><br />
</nowiki></pre><br />
<br />
See [http://rbach.priv.at/Misc/2005/BlogDescriptionMicroformat/ExamplesForBrainstorming.html#example2 here] or [http://www.bs-markup.de/info.php there] for a rendered version of this example.<br />
<br />
== Strawman proposal ==<br />
<br />
Text in ''italics'' is used as reference to the comments below.<br />
<br />
=== Blog information container ===<br />
<br />
The blog information container element contains all other elements of the blog description.<br />
<br />
It '''must''' have a class attribute which includes the value <code>blogformat</code>.<br />
<br />
=== Language ===<br />
<br />
The blog information container element or an ancestor element ''(langanc)'' of it '''must''' include <br />
a language code using the <code>xml:lang</code> attribute to indicate the language used for the blog.<br />
<br />
If the document type used by the author allows the usage of the <code>lang</code> <br />
attribute, it must be used to specify the language code. <br />
The value '''must''' be equal to the one used for <code>xml:lang</code>. ''(langequ)''<br />
<br />
Example 1:<br />
<pre><nowiki><br />
<!-- A blog written in English as spoken in the US --><br />
<div class="blogformat" lang="en-US" xml:lang="en-US"><br />
<!-- child elements --><br />
</div><br />
</nowiki></pre><br />
<br />
Example 2:<br />
<pre><nowiki><br />
<!-- A blog written in French --><br />
<div class="blogformat" lang="fr" xml:lang="fr"><br />
<!-- child elements --><br />
</div><br />
</nowiki></pre><br />
<br />
=== Blog URI ===<br />
<br />
The blog URI element '''must''' be an <code>&lt;a&gt;</code> element and '''must''' contain a <code>rel</code> attribute which includes the value <code>bookmark</code>. <br />
<br />
It must link to the blog's mainpage using an absolute URI ''(absuri)''.<br />
<br />
This element '''should''' provide the name of the blog in its <code>title</code> attribute. <br />
<br />
If no <code>title</code> attribute is provided agents ''(agents)'' '''must''' use the text value of the blog URI element ''(meta)''.<br />
<br />
=== Blog description and topics ===<br />
<br />
It contains the main categories covered by the blog.<br />
<br />
The categories are marked up within anchors ''(cat)'' that (may) refer to technorati-tags.<br />
<br />
Example:<br />
<pre><nowiki><a rel="tag" href="http://technorati.com/tags/xhtml">XHTML</a></nowiki></pre><br />
<br />
In addition authors can write up a short introduction.<br />
<br />
=== Author information ===<br />
<br />
Information about the author '''should''' be provided.<br />
<br />
The author information element '''must''' have a class attribute which includes the value <code>author</code>. This element '''should''' provide the name of the author <br />
in its <code>title</code> attribute. <br />
<br />
Example:<br />
<pre><nowiki><span class="author" title="John Doe">John's</span> Blog.</nowiki></pre><br />
<br />
If no <code>title</code> attribute is provided agents ''(agents)'' '''must''' use the text value of the author information element ''(meta'').<br />
<br />
The author information element may be an <code>&lt;a&gt;</code> element which links<br />
to the author's page using an absolute URI ''(absuri)'' or may be some other element containing<br />
an [[hcard]].<br />
<br />
Example:<br />
<pre><nowiki><br />
<a class="author" title="John Doe"<br />
href="http://example.org/~johnd/">John's</a> Blog.<br />
</nowiki></pre><br />
<br />
=== Feeds ===<br />
<br />
''To be done.''<br />
<br />
Perhaps using <br />
<a rel="alternate" type="application/atom+xml" href="http://example.org/feeds/atom">Atom</a> <br />
<a rel="alternate" type="application/rss+xml" href="http://example.org/feeds/rss">RSS 2.0</a><br />
<br />
(Maybe the already used <br />
<link rel="alternate" type="application/rss+xml" href="http://example.org/feeds/rss" title="RSS 2.0" /><br />
is enough? --RobertBachmann<br />
)<br />
=== Image ===<br />
<br />
''To be done.''<br />
<br />
=== Comments ===<br />
* (langanc): There are XHTML documents which already have their language specified in the &lt;html&gt; tag. In this case it would be redundant to require having it twice. --[[User:RobertBachman |RobertBachmann]]<br />
<br />
* (langequ): See http://microformats.org/discuss/mail/microformats-discuss/2005-July/000440.html. --[[User:RobertBachman |RobertBachmann]]<br />
<br />
* (absuri): As long as we are parsing blog information from the original URI, handling relative URIs isn't a big problem. I think we should recommend the use of absolute URIs ("absolute URIs '''should''' be used") but I'm not sure if we should require them. --[[User:RobertBachman |RobertBachmann]]<br />
<br />
* (agent): Is agent the right term? --[[User:RobertBachman |RobertBachmann]]<br />
<br />
* (meta): Perhaps agent would want to extract information from <code>&lt;head&gt;</code> if no information can be found within "blogformat"<br />
**<code>&lt;link rel="author" href="http://example.org/~jdoe" /&gt;</code><br />
**<code>&lt;meta name="author" value="John Doe" /&gt;</code><br />
**<code>&lt;title&gt;John Doe's Blog&lt;/title&gt;</code><br />
--[[User:RobertBachman |RobertBachmann]]<br />
<br />
* (cat): '''May''', '''should''' or '''must''' they be within anchors. What are the options where they can point to? --[[User:BjoernSeibert |BjoernSeibert]]<br />
<br />
<br />
<br />
== See also ==<br />
* [[blog-description-format]] (background research)</div>ScottReynenhttps://microformats.org/wiki/index.php?title=hcalendar-examples-fr&diff=17611hcalendar-examples-fr2007-06-17T22:05:35Z<p>ScottReynen: Reverted edit of Wu4Dhl, changed back to last version by ChristopheDucamp</p>
<hr />
<div>= exemples de hCalendar =<br />
<br />
Exemples de [[hcalendar-fr|hCalendars]].<br />
== Auteurs ==<br />
* [http://diveintomark.org/ Mark Pilgrim]<br />
* [http://theryanking.com/ Ryan King]<br />
* [http://tantek.com/log/ Tantek Çelik]<br />
<br />
* Traduction fr en cours : [[Christophe Ducamp]]<br />
== exemples RFC 2445 dans hCalendar ==<br />
Ce sont des exemples hCalendar 1:1 pour chaque exemple dans la RFC 2445.<br />
<br />
Les errata sont appliqués à partir d'[http://www.rfc-editor.org/cgi-bin/errata.pl#rfc2445 ici].<br />
<br />
'''Ces exemples sont de stricts copier-coller tirés de la RFC, ils ne devraient pas être édités.'''<br />
<br />
=== 4.6.1 Composant Event ===<br />
Ci-après un exemple du composant de calendrier "VEVENT" utilisé pour représenter une réunion qui sera aussi opaque pour les recherches du temps occupé : <br />
<br />
<pre><nowiki><br />
BEGIN:VEVENT<br />
UID:19970901T130000Z-123401@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART:19970903T163000Z<br />
DTEND:19970903T190000Z<br />
SUMMARY:Annual Employee Review<br />
CLASS:PRIVATE<br />
CATEGORIES:BUSINESS,HUMAN RESOURCES<br />
END:VEVENT<br />
</nowiki></pre><br />
<br />
Cet event iCalendar comme un hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<h5 class="summary">Annual Employee Review</h5><br />
<div>posted on <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div><br />
<div>UID: <span class="uid">19970901T130000Z-123401@host.com</span></div><br />
<div>Dates: <abbr class="dtstart" title="19970903T163000Z">Septempter 3, 1997, 16:30</abbr> -<br />
<abbr class="dtend" title="19970903T190000Z">19:00 UTC</abbr></div><br />
<div>This meeting is <strong class="class">private</strong>.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Business</li><br />
<li class="category">Human Resources</li><br />
</ul><br />
</div><br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme : <br />
<div class="vevent"><br />
<br />
<h5 class="summary">Annual Employee Review</h5><br />
<div>posted on <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div><br />
<div>UID: <span class="uid">19970901T130000Z-123401@host.com</span></div><br />
<div>Dates: <abbr class="dtstart" title="19970903T163000Z">Septempter 3, 1997, 16:30</abbr> - <abbr class="dtend" title="19970903T190000Z">19:00 UTC</abbr></div><br />
<div>This meeting is <strong class="class">Private</strong>.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Business</li><br />
<li class="category">Human Resources</li><br />
</ul><br />
</div><br />
<br />
==== Exemple 2 ====<br />
Ce qui suit est un exemple du composant calendrier "VEVENT" utilisé pour représenter un aide-mémoire qui ne sera pas opaque, mais plutôt transparent aux recherches sur le temps occupé : <br />
<br />
<pre><nowiki><br />
BEGIN:VEVENT<br />
UID:19970901T130000Z-123402@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART:19970401T163000Z<br />
DTEND:19970402T010000Z<br />
SUMMARY:Laurel is in sensitivity awareness class.<br />
CLASS:PUBLIC<br />
CATEGORIES:BUSINESS,HUMAN RESOURCES<br />
TRANSP:TRANSPARENT<br />
END:VEVENT<br />
</nowiki></pre><br />
<br />
Cet event iCalendar en tant que fragment hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<h5 class="summary">Laurel is in sensitivity awareness class.</h5><br />
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div><br />
<div class="uid">19970901T130000Z-123402@host.com</div><br />
<div>Dates: <abbr class="dtstart" title="19970401T163000Z">April 1, 1997, 16:30 UTC</abbr>-<br />
<abbr class="dtend" title="19970402T010000Z">April 2, 1997 01:00 UTC</abbr></div><br />
<div>This event is <span class="class">public</span> and <span class="transp">transparent</span> to free/busy scheduling.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Business</li><br />
<li class="category">Human Resources</li><br />
</ul><br />
</div><br />
</nowiki></pre><br />
<br />
Cet hCalendar pourrait être affiché comme : <br />
<br />
<div class="vevent"><br />
<h5 class="summary">Laurel is in sensitivity awareness class.</h5><br />
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div><br />
<div class="uid">19970901T130000Z-123402@host.com</div><br />
<div>Dates: <abbr class="dtstart" title="19970401T163000Z">April 1, 1997, 16:30 UTC</abbr>-<abbr class="dtend" title="19970402T010000Z">April 2, 1997 01:00 UTC</abbr></div><br />
<div>This event is <span class="class">public</span> and <span class="transp">transparent</span> to free/busy scheduling.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Business</li><br />
<li class="category">Human Resources</li><br />
</ul><br />
</div><br />
<br />
<br />
==== Exemple 3 ====<br />
<br />
Ce qui suit est un exemple du composant calendrier "VEVENT" utilisé pour représenter un anniversaire qui arrivera chaque année. Parce que cela ne prend pas de temps, il n'apparaîtra pas comme opaque dans une recherche sur le temps occupé ; peu importe ce qu'indique la valeur de la propriété "TRANSP" :<br />
<br />
<pre><nowiki><br />
BEGIN:VEVENT<br />
UID:19970901T130000Z-123403@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART:19971102<br />
SUMMARY:Our Blissful Anniversary<br />
CLASS:CONFIDENTIAL<br />
CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION<br />
RRULE:FREQ=YEARLY<br />
END:VEVENT<br />
</nowiki></pre><br />
<br />
Cet event iCalendar comme un fragment hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<h5 class="summary">Our Blissful Anniversary</h5><br />
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div><br />
<div class="uid">19970901T130000Z-123403@host.com</div><br />
<div>Date: <abbr class="dtstart" title="19971102">November 2, 1997</abbr></div><br />
<div>This event is <strong class="class">confidential</strong>.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Anniversary</li><br />
<li class="category">Personal</li><br />
<li class="category">Special Occassion</li><br />
</ul><br />
<div class="rrule">Repeat <span class="freq">yearly</span>.</div><br />
</div><br />
</nowiki></pre><br />
<br />
PROBLEMATIQUES :<br />
* Nous avons eu une plus grande discussion à propos de RRULE qui a besoin d'être résolue, ces exemples aideront en cela, je l'espère. --RyanKing<br />
<br />
Ce hCalendar pourrait s'afficher comme : <br />
<br />
<div class="vevent"><br />
<h5 class="summary">Our Blissful Anniversary</h5><br />
<div>Posted on: <abbr class="dtstamp" title="19970901T1300Z">September 1, 1997</abbr></div><br />
<div class="uid">19970901T130000Z-123403@host.com</div><br />
<div>Date: <abbr class="dtstart" title="19971102">November 2, 1997</abbr></div><br />
<div>This event is <span class="class">confidential</span>.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Anniversary</li><br />
<li class="category">Personal</li><br />
<li class="category">Special Occassion</li><br />
</ul><br />
<div class="rrule">Repeat <span class="freq">yearly</span></div><br />
</div><br />
<br />
=== 4.6.2 A faire : Composant ===<br />
<br />
Exemple : Ce qui suit est un exemple d'un composant calendrier "VTODO" :<br />
<br />
<pre><nowiki><br />
BEGIN:VTODO<br />
UID:19970901T130000Z-123404@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART:19970415T133000Z<br />
DUE:19970416T045959Z<br />
SUMMARY:1996 Income Tax Preparation<br />
CLASS:CONFIDENTIAL<br />
CATEGORIES:FAMILY,FINANCE<br />
PRIORITY:1<br />
STATUS:NEEDS-ACTION<br />
END:VTODO<br />
</nowiki></pre><br />
<br />
Ce fragment iCalendar sous hCalendar:<br />
<br />
<pre><nowiki><br />
@TODO<br />
</nowiki></pre><br />
<br />
=== 4.6.3 Composant Journal ===<br />
<br />
Exemple : Ce qui suit est un exemple du composant calendrier "VJOURNAL" :<br />
<br />
BEGIN:VJOURNAL<br />
UID:19970901T130000Z-123405@host.com<br />
DTSTAMP:19970901T1300Z<br />
DTSTART;VALUE=DATE:19970317<br />
SUMMARY:Staff meeting minutes<br />
DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa<br />
and Bob. Aurora project plans were reviewed. There is currently<br />
no budget reserves for this project. Lisa will escalate to<br />
management. Next meeting on Tuesday.\n<br />
2. Telephone Conference: ABC Corp. sales representative called<br />
to discuss new printer. Promised to get us a demo by Friday.\n<br />
3. Henry Miller (Handsoff Insurance): Car was totaled by tree.<br />
Is looking into a loaner car. 654-2323 (tel).<br />
END:VJOURNAL<br />
<br />
Ce fragment iCalendar comme hCalendar : <br />
<br />
<pre><nowiki><br />
@TODO<br />
</nowiki></pre><br />
<br />
=== 4.6.4. Composant Free/Busy ===<br />
<br />
Exemple : Ce qui suit est une exemple d'un composant calendrier "VFREEBUSY" utilisé pour requêter une information sur le temps libre ou occupé :<br />
<br />
<pre><nowiki><br />
BEGIN:VFREEBUSY<br />
ORGANIZER:MAILTO:jane_doe@host1.com<br />
ATTENDEE:MAILTO:john_public@host2.com<br />
DTSTART:19971015T050000Z<br />
DTEND:19971016T050000Z<br />
DTSTAMP:19970901T083000Z<br />
END:VFREEBUSY<br />
</nowiki></pre><br />
<br />
Ce fragment iCalendar sous hCalendar :<br />
<br />
<pre><nowiki><br />
@TODO<br />
</nowiki></pre><br />
<br />
Ce qui suit est un exemple d'un composant calendrier "VFREEBUSY" utilisé pour répondre à la requête avec l'information sur le temps occupé :<br />
<br />
<pre><nowiki><br />
BEGIN:VFREEBUSY<br />
ORGANIZER:MAILTO:jane_doe@host1.com<br />
ATTENDEE:MAILTO:john_public@host2.com<br />
DTSTAMP:19970901T100000Z<br />
FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M,<br />
19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M<br />
URL:http://host2.com/pub/busy/jpublic-01.ifb<br />
COMMENT:This iCalendar file contains busy time information for<br />
the next three months.<br />
END:VFREEBUSY<br />
</nowiki></pre><br />
<br />
<br />
Ce fragment iCalendar sous hCalendar :<br />
<br />
<pre><nowiki><br />
@TODO<br />
</nowiki></pre><br />
<br />
Ce qui suit est un exemple d'un composant calendrier "VFREEBUSY" utilisé pour publier l'information sur le temps occupé.<br />
<br />
<pre><nowiki><br />
BEGIN:VFREEBUSY<br />
ORGANIZER:jsmith@host.com<br />
DTSTART:19980313T141711Z<br />
DTEND:19980410T141711Z<br />
FREEBUSY:19980314T233000Z/19980315T003000Z<br />
FREEBUSY:19980316T153000Z/19980316T163000Z<br />
FREEBUSY:19980318T030000Z/19980318T040000Z<br />
URL:http://www.host.com/calendar/busytime/jsmith.ifb<br />
END:VFREEBUSY<br />
</nowiki></pre><br />
<br />
Ce fragment iCalendar sous hCalendar :<br />
<br />
<pre><nowiki><br />
@TODO<br />
</nowiki></pre><br />
<br />
<br />
=== 5. Exemples Objet iCalendar ===<br />
<br />
L'exemple suivant spécifie une conférence de trois jours qui démarrer le 18 septembre 1996 à 8:00 AM EDT, et se termine à 6:00 PM EDT le 20 septembre 1996.<br />
<br />
<pre><nowiki><br />
BEGIN:VEVENT<br />
DTSTAMP:19960704T120000Z<br />
UID:uid1@host.com<br />
ORGANIZER:MAILTO:jsmith@host.com<br />
DTSTART:19960918T143000Z<br />
DTEND:19960920T220000Z<br />
STATUS:CONFIRMED<br />
CATEGORIES:CONFERENCE <br />
SUMMARY:Networld+Interop Conference<br />
DESCRIPTION:Networld+Interop Conference and Exhibit\nAtlanta World Congress Center\nAtlant\, Georgia<br />
END:VEVENT<br />
</nowiki></pre><br />
<br />
Cet événement iCalendar sous un fragment hCalendar : ''la syntaxe des participants semble incomplète''<br />
<br />
<pre><nowiki><br />
<div class="vevent"><br />
<h5 class="summary">Networld+Interop Conference</h5><br />
<div class="description">Networld+Interop Conference and Exhibit Atlanta World Congress<br />
Center Atlanta, Georgia</div><br />
<div>Posted on: <abbr class="dtstamp" title="19960704T120000Z">July 4, 1996</abbr></div><br />
<div class="uid">uid1@host.com</div><br />
<div>Organized by: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></div><br />
<div>Dates: <abbr class="dtstart" title="19960918T143000Z">September 18, 1996, 14:30 UTC</abbr> -<br />
<abbr class="dtend" title="19960920T220000Z">September 20, 1996, 22:00 UTC</abbr></div><br />
<div>Status: <span class="status">CONFIRMED</span></div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Conference</li><br />
</ul><br />
</div><br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme :<br />
<br />
<div class="vevent"><br />
<h5 class="summary">Networld+Interop Conference</h5><br />
<div class="description">Networld+Interop Conference and Exhibit Atlanta World Congress<br />
Center Atlanta, Georgia</div><br />
<div>Posted on: <abbr class="dtstamp" title="19960704T120000Z">July 4, 1996</abbr></div><br />
<div class="uid">uid1@host.com</div><br />
<div>Organized by: [mailto:jsmith@host.com jsmith@host.com]</div><br />
<div>Dates: <abbr class="dtstart" title="19960918T143000Z">September 18, 1996, 14:30 UTC</abbr> -<br />
<abbr class="dtend" title="19960920T220000Z">September 20, 1996, 22:00 UTC</abbr></div><br />
<div>Status: <span class="status">confirmed</span></div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Conference</li><br />
</ul><br />
</div><br />
<br />
<br />
==== Exemple 2 ====<br />
L'exemple suivant spécifie une réunion programmée d'un groupe qui démarre le 12 mars 1998 à 8:30 AM EST et se termine à 9:30 AM EST le 12 mars 1998. L'"Organizer" a programmé la réunion avec un ou plusieurs calendriers utilisateurs dans un groupe. Une spécification de "time zone" pour l'Est des Etats Unis a été spécifiée.<br />
<br />
<pre><nowiki><br />
BEGIN:VCALENDAR<br />
PRODID:-//RDU Software//NONSGML HandCal//EN<br />
VERSION:2.0<br />
BEGIN:VTIMEZONE<br />
TZID:US-Eastern<br />
BEGIN:STANDARD<br />
DTSTART:19981025T020000<br />
RDATE:19981025T020000<br />
TZOFFSETFROM:-0400<br />
TZOFFSETTO:-0500<br />
TZNAME:EST<br />
END:STANDARD<br />
BEGIN:DAYLIGHT<br />
DTSTART:19990404T020000<br />
RDATE:19990404T020000<br />
TZOFFSETFROM:-0500<br />
TZOFFSETTO:-0400<br />
TZNAME:EDT<br />
END:DAYLIGHT<br />
END:VTIMEZONE<br />
BEGIN:VEVENT<br />
DTSTAMP:19980309T231000Z<br />
UID:guid-1.host1.com<br />
ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com<br />
ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:MAILTO:employee-A@host.com<br />
DESCRIPTION:Project XYZ Review Meeting<br />
CATEGORIES:MEETING<br />
CLASS:PUBLIC<br />
CREATED:19980309T130000Z<br />
SUMMARY:XYZ Project Review<br />
DTSTART;TZID=US-Eastern:19980312T083000<br />
DTEND;TZID=US-Eastern:19980312T093000<br />
LOCATION:1CP Conference Room 4350<br />
END:VEVENT<br />
END:VCALENDAR<br />
</nowiki></pre><br />
<br />
Ce iCalendar sous un hCalendar :<br />
<br />
<pre><nowiki><br />
@TODO<br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme :<br />
<br />
@TODO<br />
<br />
==== Exemple 3 ====<br />
<pre><nowiki><br />
BEGIN:VCALENDAR<br />
METHOD:xyz<br />
VERSION:2.0<br />
PRODID:-//ABC Corporation//NONSGML My Product//EN<br />
BEGIN:VEVENT<br />
DTSTAMP:19970324T1200Z<br />
SEQUENCE:0<br />
UID:uid3@host1.com<br />
ORGANIZER:MAILTO:jdoe@host1.com<br />
ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com<br />
DTSTART:19970324T123000Z<br />
DTEND:19970324T210000Z<br />
CATEGORIES:MEETING,PROJECT<br />
CLASS:PUBLIC<br />
SUMMARY:Calendaring Interoperability Planning Meeting<br />
DESCRIPTION:Discuss how we can test c&s interoperability\nusing iCalendar and other IETF standards.<br />
LOCATION:LDB Lobby<br />
ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/conf/bkgrnd.ps<br />
END:VEVENT<br />
END:VCALENDAR<br />
</nowiki></pre><br />
<br />
Ce iCalendar sous un hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vcalendar"><br />
<div>Method: <span class="method">xyz</span></div><br />
<div class="vevent"><br />
<div>Posted at: <span class="dtstamp">19970324T1200Z</span></div><br />
<div>Sequence: <span class="sequence">0</span></div><br />
<div>UID: <span class="uid">uid3@host1.com</span></div><br />
<div>Organzied by: <a class="organizer" href="mailto:jdoe@host1.com">jdoe@host1.com</a></div><br />
<div>Attending: <span class="attendee"><a class="value" href="mailto:jsmith@host1.com">jsmith@host1.com</a> RSVPed? <span class="rsvp">TRUE</span></span></div><br />
<div>Start Time: <abbr class="dtstart" title="19970324T123000Z">March 24, 1997 12:30 UTC</abbr></div><br />
<div>End Time: <abbr class="dtend" title="19970324T210000Z">March 24, 1997, 21:00 UTC</abbr></div><br />
<ul><br />
<li class="category">Meeting</li><br />
<li class="category">Project</li><br />
</ul><br />
<div>This event is <strong class="class">Public</strong></div><br />
<div class="summary">Calendaring Interoperability Planning Meeting</div><br />
<div class="description">Discuss how we can test c&s interoperability using iCalendar and other IETF standards.</div><br />
<div class="location">LDB Lobby</div><br />
<div>Attachment: <a class="attach" type="application/postscript" href="ftp://xyzCorp.com/pub/conf/bkgrnd.ps">ftp://xyzCorp.com/pub/conf/bkgrnd.ps</a></div><br />
</div><br />
</div><br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme :<br />
<br />
<div class="vcalendar"><br />
<div>Method: <span class="method">xyz</span></div><br />
<div class="vevent"><br />
<div>Posted at: <span class="dtstamp">19970324T1200Z</span></div><br />
<div>Sequence: <span class="sequence">0</span></div><br />
<div>UID: <span class="uid">uid3@host1.com</span></div><br />
<div>Organzied by: [mailto:jdoe@host1.com jdoe@host1.com]</div><br />
<div>Attending: <span class="attendee">[mailto:jsmith@host1.com jsmith@host1.com], RSVPed? <span class="rsvp">TRUE></span></span></div><br />
<div>Start Time: <abbr class="dtstart" title="19970324T123000Z">March 24, 1997 12:30 UTC</abbr></div><br />
<div>End Time: <abbr class="dtend" title="19970324T210000Z">March 24, 1997, 21:00 UTC</abbr></div><br />
<ul><br />
<li class="category">Meeting</li><br />
<li class="category">Project</li><br />
</ul><br />
<div>This event is <strong class="class">Public</strong></div><br />
<div class="summary">Calendaring Interoperability Planning Meeting</div><br />
<div class="description">Discuss how we can test c&s interoperability using iCalendar and other IETF standards.</div><br />
<div class="location">LDB Lobby</div><br />
<div>Attachment: [ftp://xyzCorp.com/pub/conf/bkgrnd.ps ftp://xyzCorp.com/pub/conf/bkgrnd.ps]</div><br />
</div><br />
</div><br />
<br />
<br />
==== Exemple 4 ====<br />
<br />
Ce qui suit est un exemple d'une to-do pour le 15 avril 1998. Une alarme audio a été spécifiée pour faire rappeler le calendrier utilisateur, le jour précédent la todo est attendu à être complété et répété toutes les heurs, à quatre reprise. La définition de la to-do a été modifiée deux fois depuis qu'elle a été initialement créée.<br />
<br />
<pre><nowiki><br />
BEGIN:VCALENDAR<br />
VERSION:2.0<br />
PRODID:-//ABC Corporation//NONSGML My Product//EN<br />
BEGIN:VTODO<br />
DTSTAMP:19980130T134500Z<br />
SEQUENCE:2<br />
UID:uid4@host1.com<br />
ORGANIZER:MAILTO:unclesam@us.gov<br />
ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com<br />
DUE:19980415T235959<br />
STATUS:NEEDS-ACTION<br />
SUMMARY:Submit Income Taxes<br />
BEGIN:VALARM<br />
ACTION:AUDIO<br />
TRIGGER:19980403T120000<br />
ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-files/ssbanner.aud<br />
REPEAT:4<br />
DURATION:PT1H<br />
END:VALARM<br />
END:VTODO<br />
END:VCALENDAR<br />
</nowiki></pre><br />
<br />
Ce iCalendar sous un hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vcalendar"><br />
<div class="vtodo"><br />
<div>Posted at: <span class="dtstamp">19980130T134500Z</span></div><br />
<div>Sequence <span class="sequence">2</span></div><br />
<div>UID: <span class="uid">uid4@host1.com</span></div><br />
<div>Organizer: [mailto:unclesam@us.gov unclesam@us.gov]</div><br />
<div>Attending: [mailto:jqpublic@host.com jqpublic@host.com], <span class="partstat">ACCEPTED</span></span></div><br />
<div>Due: <abbr class="due" title="19980415T235959">one minute before midnight on April 15, 1998</abbr></div><br />
<div>Status: <span class="status">needs-action</span></div><br />
<div class="summary">Submit Income Taxes</div><br />
<div class="valarm"><br />
<div>Action: <span class="action">AUDIO</span></div><br />
<div>Trigger: <span class="trigger">19980403T120000</span></div><br />
<div>Attachment: <a class="attach" type="audio/basic" href="http://host.com/pub/audio-files/ssbanner.aud">http://host.com/pub/audio-files/ssbanner.aud</a></div><br />
<div>Repeat: <span class="repeat">4</span></div><br />
<div>Duration: <span class="duration">PT1H</span></div><br />
</div><br />
</div><br />
</div><br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme :<br />
<br />
<div class="vcalendar"><br />
<div class="vtodo"><br />
<div>Posted at: <span class="dtstamp">19980130T134500Z</span></div><br />
<div>Sequence <span class="sequence">2</span></div><br />
<div>UID: <span class="uid">uid4@host1.com</span></div><br />
<div>Organizer: [mailto:unclesam@us.gov unclesam@us.gov]</div><br />
<div>Attending: [mailto:jqpublic@host.com jqpublic@host.com], <span class="partstat">ACCEPTED</span></span></div><br />
<div>Due: <abbr class="due" title="19980415T235959">one minute before midnight on April 15, 1998</abbr></div><br />
<div>Status: <span class="status">needs-action</span></div><br />
<div class="summary">Submit Income Taxes</div><br />
<div class="valarm"><br />
<div>Action: <span class="action">AUDIO</span></div><br />
<div>Trigger: <span class="trigger">19980403T120000</span></div><br />
<div>Attachment: [http://host.com/pub/audio-files/ssbanner.aud http://host.com/pub/audio-files/ssbanner.aud]</div><br />
<div>Repeat: <span class="repeat">4</span></div><br />
<div>Duration: <span class="duration">PT1H</span></div><br />
</div><br />
</div><br />
</div><br />
<br />
==== Exemple 5 : entrée de journal ====<br />
Ce qui suit est un exemple d'entrée de journa : <br />
<br />
<pre><nowiki><br />
BEGIN:VCALENDAR<br />
VERSION:2.0<br />
PRODID:-//ABC Corporation//NONSGML My Product//EN<br />
BEGIN:VJOURNAL<br />
DTSTAMP:19970324T120000Z<br />
UID:uid5@host1.com<br />
ORGANIZER:MAILTO:jsmith@host.com<br />
STATUS:DRAFT<br />
CLASS:PUBLIC<br />
CATEGORY:Project Report, XYZ, Weekly Meeting<br />
DESCRIPTION:Project xyz Review Meeting Minutes\nAgenda\n<br />
1. Review of project version 1.0 requirements.\n<br />
2. Definition of project processes.\n<br />
3. Review of project schedule.\nParticipants: John Smith, Jane Doe, Jim Dandy\n<br />
-It was decided that the requirements need to be signed off by product marketing.\n<br />
-Project processes were accepted.\n<br />
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.\n<br />
-New schedule will be distributed by Friday.\n<br />
-Next weeks meeting is cancelled. No meeting until 3/23.<br />
END:VJOURNAL<br />
END:VCALENDAR<br />
</nowiki></pre><br />
<br />
(*note* : les sauts de ligne ont été ajoutés dans la description, en réalité, ce devrait être en une ligne)<br />
<br />
Ce fragment iCalendar sous hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vcalendar"><br />
<div class="vjournal"><br />
<div>Posted at: <abbr class="dtstamp" title="19970324T120000Z">March 24, 1997, 12:00 UTC</abbr></div><br />
<div class="uid">uid5@host1.com</div><br />
<div>Organizer: <a class="organizer" href="mailto:jsmith@host.com">jsmith@host.com</a></div><br />
<div>Status: <span class="status">Draft</span></div><br />
<div>This journal is<span class="class">Public</span>.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Project Report</li><br />
<li class="category">xyz</li><br />
<li class="category">Weekly Meeting</li><br />
</ul><br />
<div class="description">Project xyz Review Meeting Minutes<br /><br />
Agenda<br /><br />
1. Review of project version 1.0 requirements.<br /><br />
2. Definition of project processes.<br /><br />
3. Review of project schedule.<br /><br />
Participants: John Smith, Jane Doe, Jim Dandy<br /><br />
-It was decided that the requirements need to be signed off by product marketing.<br /><br />
-Project processes were accepted.<br /><br />
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.<br /><br />
-New schedule will be distributed by Friday.<br /><br />
-Next weeks meeting is cancelled. No meeting until 3/23.<br />
</div><br />
</div><br />
</div><br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme :<br />
<br />
<div class="vcalendar"><br />
<div class="vjournal"><br />
<div>Posted at: <abbr class="dtstamp" title="19970324T120000Z">March 24, 1997, 12:00 UTC</abbr></div><br />
<div class="uid">uid5@host1.com</div><br />
<div>Organizer: [mailto:jsmith@host.com jsmith@host.com]</div><br />
<div>Status: <span class="status">Draft</span></div><br />
<div>This journal is<span class="class">Public</span>.</div><br />
<div>Filed under:</div><br />
<ul><br />
<li class="category">Project Report</li><br />
<li class="category">xyz</li><br />
<li class="category">Weekly Meeting</li><br />
</ul><br />
<div class="description">Project xyz Review Meeting Minutes<br /><br />
Agenda<br /><br />
1. Review of project version 1.0 requirements.<br /><br />
2. Definition of project processes.<br /><br />
3. Review of project schedule.<br /><br />
Participants: John Smith, Jane Doe, Jim Dandy<br /><br />
-It was decided that the requirements need to be signed off by product marketing.<br /><br />
-Project processes were accepted.<br /><br />
-Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.<br /><br />
-New schedule will be distributed by Friday.<br /><br />
-Next weeks meeting is cancelled. No meeting until 3/23.<br />
</div><br />
</div><br />
</div><br />
<br />
==== Exemple 6. temps Free/Busy ====<br />
<br />
Ce qui suit est un exmple d'information publiée sur le temps occupé. L'objet iCalendar pourrait être placé dans la ressource réseau www.host.com/calendar/busytime/jsmith.ifb.<br />
<br />
<pre><nowiki><br />
BEGIN:VCALENDAR<br />
VERSION:2.0<br />
PRODID:-//RDU Software//NONSGML HandCal//EN<br />
BEGIN:VFREEBUSY<br />
ORGANIZER:MAILTO:jsmith@host.com<br />
DTSTART:19980313T141711Z<br />
DTEND:19980410T141711Z<br />
FREEBUSY:19980314T233000Z/19980315T003000Z<br />
FREEBUSY:19980316T153000Z/19980316T163000Z<br />
FREEBUSY:19980318T030000Z/19980318T040000Z<br />
URL:http://www.host.com/calendar/busytime/jsmith.ifb<br />
END:VFREEBUSY<br />
END:VCALENDAR<br />
</nowiki></pre><br />
<br />
Ce fragment iCalendar sous hCalendar :<br />
<br />
<pre><nowiki><br />
<div class="vcalendar"><br />
<div>Version: <span class="version">2.0</span></div><br />
<div>ProdID:<span class="prodid">-//RDU Software//NONSGML HandCal//EN</span></div><br />
<div class="vfreebusy"><br />
<div>Organizer: <span class="organizer">MAILTO:jsmith@host.com</span></div><br />
<div>Start Time: <abbr class="dtstart" title="19980313T141711Z">March 13, 1998 14:17:11 UTC</abbr></div><br />
<div>End time: <abbr class="dtend" title="19980410T141711Z">April 10, 1998 14:17:11 UTC</abbr></div><br />
<p>Busy times:</p> <!-- note that the default is BUSY --><br />
<ol><br />
<li class="freebusy"><abbr class="dtstart" title="19980314T233000Z">1998-03-14 23:30:00 UTC</abbr> - <abbr class="dtend" title="19980315T003000Z">1998-03-15- 00:30:00 UTC</abbr></li><br />
<li class="freebusy"><abbr class="dtstart" title="19980316T153000Z">1998-03-16 15:30:00 UTC</abbr> - <abbr class="dtend" title="19980316T163000Z">1998-03-16 16:30:00 UTC</abbr></li><br />
<li class="freebusy"><abbr class="dtstart" title="19980318T030000Z">1998-03-18 03:00:00 UTC</abbr> - <abbr class="dtend" title="19980318T040000Z">1998-03-18 04:00:00 UTC</abbr></li><br />
</ol><br />
<div>URL <a class="url" href="http://www.host.com/calendar/busytime/jsmith.ifb">http://www.host.com/calendar/busytime/jsmith.ifb</a></div><br />
</div><br />
</div><br />
</nowiki></pre><br />
<br />
Ce hCalendar pourrait être affiché comme :<br />
<br />
@TODO<br />
<br />
== Autres ==<br />
<br />
* voir [[hcalendar-brainstorming]] pour plus d'exemples (qui peuvent éventuellement être migrés ici) et des analyses.</div>ScottReynenhttps://microformats.org/wiki/index.php?title=alternates-examples&diff=18048alternates-examples2007-06-17T22:04:57Z<p>ScottReynen: Reverted edit of RdeGwd, changed back to last version by Kevin Marks</p>
<hr />
<div>= Introduction =<br />
This page is to collect examples of '''alternates''', that is, places where a user may be given several different items to choose amongst that at some logical level are considered equivalent.<br />
<br />
== Discussion Participants ==<br />
<br />
=== Editor ===<br />
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix BlogMatrix, Inc.]<br />
<br />
=== Authors ===<br />
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix BlogMatrix, Inc.]<br />
* Lucas Gonze<br />
* Greg Borenstein<br />
<br />
=== Interested Folks ===<br />
<br />
= Specific Examples from the Wild =<br />
<br />
== MediaRSS ==<br />
Yahoo's [http://search.yahoo.com/mrss Media RSS] provides the &lt;media:group> tag to group alternate choices for the same media file together. Here's an example from their spec:<br />
<br />
<pre><nowiki><br />
<rss version="2.0"><br />
<channel><br />
<title>Song Site</title><br />
<link>http://www.foo.com</link><br />
<description>Songs galore at different bitrates</description><br />
<item><br />
<title>Cool song by an artist</title><br />
<link>http://www.foo.com/item1.htm</link><br />
<media:group><br />
<media:content url="http://www.foo.com/song64kbps.mp3" <br />
fileSize="1000" bitrate="64" type="audio/mpeg" <br />
isDefault="true" expression="full"/><br />
<media:content url="http://www.foo.com/song128kbps.mp3" <br />
fileSize="2000" bitrate="128" type="audio/mpeg" <br />
expression="full"/><br />
<media:content url="http://www.foo.com/song256kbps.mp3" <br />
fileSize="4000" bitrate="256" type="audio/mpeg" <br />
expression="full"/><br />
<media:content url="http://www.foo.com/song512kbps.mp3.torrent" <br />
fileSize="8000" type="application/x-bittorrent;enclosed=audio/mpeg" <br />
expression="full"/><br />
<media:content url="http://www.foo.com/song.wav" <br />
fileSize="16000" type="audio/x-wav" expression="full"/><br />
<media:credit role="musician">band member 1</media:credit><br />
<media:credit role="musician">band member 2</media:credit><br />
<media:category>music/artist name/album/song</media:category><br />
<media:rating>nonadult</media:rating><br />
</media:group><br />
</item><br />
</channel><br />
</rss><br />
</nowiki></pre><br />
<br />
Note the mixing of alternates and related metadata together under the group tag.<br />
<br />
= See Also =<br />
* [[alternates-examples]]<br />
* [[alternates-formats]]<br />
* [[alternates-brainstorming]]<br />
* [[media-metadata-examples]] -- Yahoo's Media RSS uses this</div>ScottReynenhttps://microformats.org/wiki/index.php?title=book-info-examples&diff=17599book-info-examples2007-06-17T22:04:36Z<p>ScottReynen: Reverted edit of Fx5B9b, changed back to last version by Tantek</p>
<hr />
<div>== Information Commonly Given About Books ==<br />
<br />
[[hreview|hReview]] prominently doesn't include a way to markup the author of a book. This makes sense for other kinds of reviews, but it seems glaringly deficient for books. This collection of information is intended as a starting point for a discussion about how hBookReview should differ. I'm expecting to find that most book review sites list the authors' names prominently. I'm googling around for book review blogs and other book review sites. Here are some from the first two pages of Googling.<br />
<br />
[[reviews-formats]] has some discussion of formats for reviews, including book reviews. Some of the formats use ''creator'' as an equivalent for a work's author. Others use ''author'', and sometimes they mean ''review-author'', and other times ''work-author''.<br />
<br />
The page on [[book-info-formats]] has more information and discussion on what should be included in a book-info microformat, and how that information should be marked up.<br />
<br />
See also [[citation]]. Citation encompasses books and other creative works, so hopefully progress will be made on finalizing that format.<br />
<br />
===Book Reviews===<br />
<br />
* [http://www.metacritic.com/books/ Metacritic]'s front page is a list of reviewed books, all are accompanied by the author's name. On the review page, the author's name appears in span class="subhead".<br />
<br />
* [http://www.bookclan.com/blog/ BookClan] has reviews and discussion. No special markup of the authors, but they always accompany the title.<br />
<br />
* [http://francesdinkelspiel.blogspot.com/ Ghost Word] uses '''Strong''' to mark authors.<br />
<br />
* [http://www.book-blog.blogspot.com/ Book Blog] makes a span called "PostTitle" that includes the title (in a subspan) and the author.<br />
<br />
* [http://bookreviewblog.blogspot.com/ Book Review Blog] puts title and (parenthesized) author in a link to Amazon.com.<br />
<br />
* [http://ray.camdenfamily.com/index.cfm?mode=cat&catid=0B6C189E-FB1A-A968-50BC6904B10D8649 Jedi Master] has two book reviews, and includes the author in the title once, and in the text in the other.<br />
<br />
* [http://www.mercurynews.com/mld/mercurynews/entertainment/books/ Mercury News Reviews] has book reviews every week. No one should be surprised to hear that the authors are always listed in the subheading.<br />
<br />
* [http://tls.timesonline.co.uk/ Times Literary Supplement] is a publication dedicated to book reviews. For a specific example see [http://tls.timesonline.co.uk/article/0,,25342-1886497,00.html The polyrhythms of life]. Most academic reviews display the title, author, press, price, and ISBN.<br />
<br />
* [http://www.vqronline.org/ The Virginia Quarterly Review] is another journal of literature and reviews. For a specific book review example see [http://www.vqronline.org/articles/2007/winter/fischel-crimes-enemy/ The Crimes of My Enemy]. It includes the book title, book author, press, date of publication, and price. <br />
<br />
===Other discussions of Books===<br />
<br />
* [http://amazon.com amazon] displays books with title, author, price, rating, and cover thumbnail. Of these, the author and cover picture are always links. The author link takes you to other works by the author, and the cover thumbnail takes you to a blowup.<br />
<br />
* [http://library.ci.mtnview.ca.us Libraries] have a few standard search categories: Author, Title, Subject, and catalogue number (ISBN, LoC, etc.).<br />
<br />
== CounterExamples ==<br />
<br />
* [http://www.800ceoread.com/blog/ 800 CEO Read] usually includes the author's name, but doesn't highlight it in any distinctive way.<br />
<br />
* [http://www.digital-web.com/types/book_reviews/ Digital Web Magazine] reviews technical books, and is inconsistent about mentioning authors. Sometimes the title and author are included in a [http://www.digital-web.com/articles/four_best_web_design_books/ pull quote], while at other times, the author is [http://www.digital-web.com/articles/web_redesign_2_workflow_that_works/ lost] completely. They seem to think readers aren't interested in the authors when the books are ''merely'' technical manuals.</div>ScottReynenhttps://microformats.org/wiki/index.php?title=mfo-brainstorming&diff=26136mfo-brainstorming2007-06-17T22:04:02Z<p>ScottReynen: Moved issues under relevant proposal</p>
<hr />
<div>= Microformat Opacity/Object/Opaque Brainstorming =<br />
<br />
== Can increased use of profile URIs solve this problem? ==<br />
<br />
[[profile-uris]] are already recommended. Here's a proposal to make them required whenever opacity rules come up:<br />
<br />
* Whenever one microformat is used within another, the interior microformat's profile URI MUST be used.<br />
* Parsers must disregard all content within the root element identified in an unrecognized profile.<br />
<br />
While not as flexible as an additional class name (e.g. class="mfo"), I like that profile URIs don't require publishers to think about parsing behavior.<br />
<br />
-- [[User:ScottReynen|ScottReynen]]<br />
<br />
=== Issues ===<br />
*People who publish using blogs, CMSs, Wikis etc. (including this wiki!) have no ability to add or change profile URIs in header tags. [[User:AndyMabbett|Andy Mabbett]] 14:28, 17 Jun 2007 (PDT)<br />
<br />
==Related pages==<br />
<br />
[[mfo-examples]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=mfo-brainstorming&diff=17580mfo-brainstorming2007-06-17T20:46:05Z<p>ScottReynen: Created</p>
<hr />
<div>= Microformat Opacity/Object/Opaque Brainstorming =<br />
<br />
== Can increased use of profile URIs solve this problem? ==<br />
<br />
[[profile-uris]] are already recommended. Here's a proposal to make them required whenever opacity rules come up:<br />
<br />
* Whenever one microformat is used within another, the interior microformat's profile URI MUST be used.<br />
* Parsers must disregard all content within the root element identified in an unrecognized profile.<br />
<br />
While not as flexible as an additional class name (e.g. class="mfo"), I like that profile URIs don't require publishers to think about parsing behavior.<br />
<br />
-- [[User:ScottReynen|ScottReynen]]<br />
<br />
==Related pages==<br />
<br />
[[mfo-examples]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=podcasts-fr&diff=17558podcasts-fr2007-06-17T00:05:55Z<p>ScottReynen: Reverted edit of Cv4Ajd, changed back to last version by RobertBachmann</p>
<hr />
<div><h1> microformats podcasts </h1><br />
<br />
Cette page liste différents podcasts et enregistrements audio (et/ou vidéo) qui ont fourni des explications et discussions tant pour les [[microformats-fr|microformats]] en général que les microformats spécifiques. Voir aussi les pages des microformats [[press-fr|presse]], [[presentations-fr|présentations]] et [[screencasts-fr|vidéos]]. Note : Les podcasts qui mentionnent simplement les microformats sans rentrer dans plus de discussions de détail des descriptions ou usages ne seront pas cités.<br />
<br />
SVP, sentez-vous à l'aise pour ajouter des liens vers les podcasts qui discutent de microformats !<br />
<br />
Les podcasts les plus récents sont listés en premier.<br />
== 2007 ==<br />
* 5 janvier [http://www.webdirections.org/podcasts/WD06/microformats.mp3 John Allsopp: "Microformats"] podcast à partir de [http://webdirections.org Web Directions South 2006-09-28]. Time ??:??.<br />
<br />
== 2006 ==<br />
* 5 novembre [http://www.flipclip.net/clips/siva001/692d23f566c59fa5059df18e4faf0a36 Fumi Yamazaki et Tantek Çelik sur les Microformats] (video [http://creativecommons.org/licenses/by-nc/2.1/jp/ CC-by-nc 2.1-jp]), en général, [[hcard-fr|hCard]], exemple d'ajout à un carnet d'adresses, [[hcalendar-fr|hCalendar]], Exemple d'abonnement à un Calendrier et démonstration. Fumi parle en japonais, Tantek parle en anglais et se périodiquement traduire en japonais.<br />
* 11 octobre [http://media.libsyn.com/media/carsonsystems/Tantek_Celik.mp3 Tantek : "Microformats Practices"] podcast extrait de la session du 13 septembre 2006 [[events/2006-09-13-future-of-web-apps-microformats|The Future of Web Apps à San Francisco]]. Time ??:??.<br />
* 25 Septembre [http://www.vivabit.com/atmedia2006/blog/index.php/tantek-celik-microformats-evolving-the-web-podcast/ Tantek: "Microformats: Evolving the Web] podcast extrait de la session du [[events/2006-06-16-atmedia-microformats|16 juin - @Media 2006]]. Time 1:00:12<br />
* 11 septembre [http://www.boagworld.com/archives/2006/09/dconstruct_web_services.html Paul Boag parle à Jeremy Keith des microformats]. L'interview démarre à 8:10 et finit à 15:42.<br />
* 5 septembre [http://www.beet.tv/2006/09/technorati_is_t.html Beet.tv interviewe Peter Hirshberg sur la vidéo et les microformats]<br />
* 8 août [http://www.verkko2.com/2006/08/06/jakso-2-mikroformaatit/ Jakso 2: Mikroformaatit] (Finnois) ([http://www.zengestrom.com/blog/2006/08/verkko2_on_micr.html English]). Jyri Engeström a interviewé Tantek Çelik et Ryan King à propos de leur travail sur les microformats chez Technorati et à propos des microformats en général. Il y a une introduction en finnois, mais l'entretien est en anglais.<br />
* 30 juin [http://www.weblogswork.com/2006/06/30/weblogs-worknotes-hresume/ Weblogs Worknotes: hResume]. "Alexander & moi ont donné à Tantek & Ryan une mise à jour des trucs hResume sur laquelle nous avons travaillée, et pendant que nous étions là, nous avons enregistré une discussion à propos de hResume et du succès des Microformats en général."<br />
* 26 juin [http://www.boagworld.com/archives/2006/06/podcast_40_atmedia_mainstream_application.html atMedia - Applying the lessons learnt] de Boagworld.com (30Mb MP3). Paul Boag présente le concept des Microformats dans la section Technobuster du show (commence à 6:50), en réponse à la présentation de Tantek à @media 2006. Ciblé pour un public non technique.<br />
* 11 avril 2006 [http://www.dustindiaz.com/episode-10/ Microformats, Drew, and lots of beer] (commence à la 42ème minute) Faute de meilleur titre, dans cet épisode Drew McLellan et moi ont eu la chance de discuter de la technologie des microformats avec quelques-uns de ses autres sites comme Dreamweaver Fever et 24ways. Autre que ça, nous avons discuté de quelques dernières actualités en cours sur le web comme le DOM Builder de Dan et le guide d'extension Firefox de William, et bien sûr joué à un autre jeu classique Pyramid 2.0 où j'ai échoué à nouveau misérablement.<br />
* 5 avril : [http://pod-serve.com/audiofile/filename/949/Messina_on_Microformats.mp3 Weblogs Worknotes with Chris Messina (12 MB .mp3 ~ 20 min.] Dans la première partie de nos séries d'interviews sur les microformats, nous parlons avec Chris Messina. <br />
* 5 avril : [http://www.web20show.com/articles/2006/04/04/web-2-0-show-episode-15-tantek-celik-ryan-king web2.0 show] Dans cet entretien SXSW, nous accrochons Tantek Celik et Ryan King de Technorati et des Microformats pour parler des choses sur lesquelles ils sont en train de travailler (besoin de la date de l'enregistrement)<br />
* 31 mars : [http://blogs.msdn.com/alexbarn/archive/2006/03/31/566361.aspx Microformats Podcast] ([http://alexbarnett.audioblog.com/deluge/c6d4ccaa-b6e5-9604-a721-764467d8bc66.mp3 51 mins, .mp3, 12mb, CC-by-2.5]) avec Alex Barnett, Tantek Çelik, Dan Connolly et Rohit Khare.<br />
* 23 mars : [http://www.technewsradio.com/2006/03/tech_news_radio_9.html TECH NEWS RADIO #273 | 060323| eTech 2006, Phil Windley, Digital Identity, Attention Economy, AOL, OpenAPI, Microformats] ([http://www.geekon.com/tnr/2006/03Mar/TNR_273_060323_Tech_News_Radio.mp3 6:55 mins, .mp3, 3.2mb, CC-by-sa-2.5])<br />
** Sujets : Attention, Ray Ozzie's Cut and Paste for the Web, microformats, AOL<br />
** Phil Windley : <blockquote>"In the last couple of years, microformats have kind of gone from this interesting idea, that people thought, 'ah yeah, that might be cool if you get can get anybody to do it', to dozens of companies that were here [at ETech] that had microformats built into their systems and were using them actively."</blockquote><br />
* 19 mars : [http://www.talkcrunch.com/2006/03/19/episode-2-social-networks-30/ TalkCrunch &raquo; Blog Archive &raquo; Episode 2: Social Networks 3.0] ([http://podcast.techcrunch.com/Techcrunch-Ep002-SocialNetworks.mp3 43:40min, .mp3, 10.2MB]) avec Michael Arrington, Nik Cubrilovic, Reid Hoffman et David Hornik.<br />
** Thématiques : Réseaux sociaux, microformats, numéros de version<br />
** Démarre à 17:55 minutes, Mike Arrington demande à Nik : ''"Comment définissez-vous un Web 2.0 ou un Social Network 3.0 ?"''<br />
** Nik : <blockquote>"Je pense que ce qui est intéressant est ce que Reid a évoqué plus tôt avec LinkedIn fabriquant désormais des pages disponibles pour le public, probablement une grande étape dont nous devrions plus parler, et je pense que c'est tout ce qu'est le Social Networking 3.0, à savoir supporter pleinement je l'esprère les [[microformats-fr|microformats]], et ce que voulais demander à Reid à ce sujet comme [[hcard-fr|hCard]] et [http://gmpg.org/xfn XFN] mais nous nous sommes quittés. Selon moi Social Networking 3.0 est le fait de ne pas avoir un unique réseau social de destination, cela parle de publier votre profil sur le web, et de disposer de tous ces services supplémentaires aux alentours et de faire monter toute cette information pour la rendre disponible à n'importe qui d'autre. Parce que si vous pensez à la manière dont les réseaux sociaux fonctionnent dans la vraie vie, c'est que vous n'avez pas une énorme destination où tout le monde se regroupe mais bien des plus petits réseaux sociaux de 10, 15, 20 personnes. Ainsi si LinkedIn fait en sorte que ses pages soient publiques, ce que cela signifie est que je peux construire un réseau social, et je peux dire que ces 3 personnes venant de Linkedin et ces 8 personnes qui ont des blogs font toutes partie de ce réseau social. Le Social Networking 3.0 pour moi est de la <em>décentralisation</em> de réseaux sociaux, c'est le support de ces [[microformats-fr|microformats]], et le fait de pouvoir annoncer toute cette information ensemble en utilisant d'autres services."</blockquote><br />
* 16 février (enregistré le 7 février) : [http://www.release1-0.com/freshproduce/newideas_socialtime.cfm Discussing events online] inclut un petit segment de Tantek disctant de microformats et [[hcalendar-fr|hCalendar]] particulièrement à 4 minutes et 39 secondes. Video.<br />
<br />
== 2005 ==<br />
* September 30th [http://odeo.com/audio/270407/view Microformats: Evolving the Web (Incomplete)]<br />
<br />
== Recherche ==<br />
* [http://www.podcast.de podcasts] allemands sur [http://www.podcast.de/suche/nach/mikroformat*/in/ShowSearch micro formats]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=User:Dana_Benson&diff=19482User:Dana Benson2007-06-11T02:09:40Z<p>ScottReynen: Reverted edit of Un1Bpc, changed back to last version by Dana Benson</p>
<hr />
<div>A masters student at Oregon State University interested in doing his thesis on a firefox API enabling extension developers to easily interface with Microformats.</div>ScottReynenhttps://microformats.org/wiki/index.php?title=Main_Page-jp&diff=20129Main Page-jp2007-06-11T02:09:34Z<p>ScottReynen: Reverted edit of NgrOwf, changed back to last version by PigN8j</p>
<hr />
<div>#REDIRECT [[Main Page-ja]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=Rel-Tag&diff=31476Rel-Tag2007-06-11T00:36:43Z<p>ScottReynen: Reverted edit of AsnAp7, changed back to last version by 64.81.240.149</p>
<hr />
<div>#REDIRECT [[rel-tag]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=dtend&diff=19480dtend2007-06-11T00:33:05Z<p>ScottReynen: Reverted edit of ZjrUf1, changed back to last version by AndyMabbett</p>
<hr />
<div>'''dtend''' (end-date) is a property of [[hcalendar|hCalendar]].</div>ScottReynenhttps://microformats.org/wiki/index.php?title=distributed-conversation-examples-fr&diff=17436distributed-conversation-examples-fr2007-06-11T00:32:58Z<p>ScottReynen: Reverted edit of MrtB5e, changed back to last version by EslRhl</p>
<hr />
<div>= Exemples de Conversation Distribuée =<br />
<br />
Ceci est une page d'explication pour documenter les différentes méthodes utilisées pour annoter les conversations en ligne qu'elles soient distribuées ou non. L'objectif des études de cette page est de servir d'arrière-plan pour la conception d'un microformat destiné à annoter les conversations distribués sur les blogs et d'autres médias en ligne.<br />
<br />
voir [[distributed-conversation-brainstorming-fr|brainstorming conversation distribuée]] pour de plus amples discussions sur ce sujet.<br />
voir [[distributed-conversation-formats-fr|conversation-distribuée-formats]] pour les formats.<br />
<br />
== Auteurs ==<br />
<br />
* [[User:EranGloben|Eran Globen]]<br />
* [[User:BenjaminCarlyle|Benjamin Carlyle]]<br />
* ...<br />
<br />
(traduction en cours [[Christophe Ducamp]])<br />
<br />
== Exemples Web ==<br />
<br />
=== Author, href et blockquote ===</div>ScottReynenhttps://microformats.org/wiki/index.php?title=User:MarkLentczner&diff=26139User:MarkLentczner2007-06-11T00:32:54Z<p>ScottReynen: Reverted edit of Pg6G2q, changed back to last version by MarkLentczner</p>
<hr />
<div>== Mark Lentczner ==<br />
<br />
You can find out more at [http://www.ozonehouse.com/mark/ my home page].<br />
<br />
I work at [http://lindenlab.com Linden Lab], engineering the infrastructure of [http://secondlife.com Second Life].<br />
<br />
I am the principle designer by the experimental (and far from complete) programming language [http://www.wheatfarm.org/ Wheat].</div>ScottReynenhttps://microformats.org/wiki/index.php?title=User:Robert_Merrill&diff=22852User:Robert Merrill2007-06-11T00:32:27Z<p>ScottReynen: Reverted edit of JpvHu0, changed back to last version by Robert Merrill</p>
<hr />
<div>My name is Robert Merrill. I am a technical recruiter who blogs professionally at, [http://www.utahtechjobs.com www.utahtechjobs.com] and personally at [http://www.utahtechjobs.com/robertmerrill www.utahtechjobs.com/robertmerrill].<br />
<br />
I am interested in hResume to simplify resume aquisition, aggregation and (most-importantly) to bring intelligence to the resume-search process.<br />
<br />
I first learned about Microformats at a [http://www.devutah.com DevUtah Geek Dinner] where [http://www.windley.com/ Phil Windley] presented on hCard and hCalendar</div>ScottReynenhttps://microformats.org/wiki/index.php?title=User:HectorGarcia&diff=19507User:HectorGarcia2007-06-11T00:32:14Z<p>ScottReynen: Reverted edit of Su7Kzx, changed back to last version by HectorGarcia</p>
<hr />
<div>Hector Garcia<br />
<br />
Spanish Translator<br />
<br />
[http://microformats.org/wiki/Main_Page-sp Spanish main]<br />
<br />
[http://microformats.org/wiki/introduction-sp Introducción a los microformatos]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=xoxo-pt-br&diff=19471xoxo-pt-br2007-06-10T21:34:21Z<p>ScottReynen: Reverted edit of TuhMel, changed back to last version by QptQof</p>
<hr />
<div><h1> XOXO 1.0: Extensible Open XHTML Outlines </h1><br />
<br />
XOXO é um formato de esboço simples, aberto escrito em padrão XHTML e adequado para ser embutido em (X)HTML, Atom, RSS, e XML arbitrário. XOXO é um dos muitos [[microformats-pt-br|microformatos]] de padrões aberto.<br />
<br />
__TOC__<br />
<br />
== Draft Specification 2004-10-01 ==<br />
<br />
=== Editor ===<br />
[http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc]<br />
<br />
=== Autores ===<br />
* [http://epeus.blogspot.com/ Kevin Marks], [http://technorati.com Technorati, Inc]<br />
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc] (formerly of [http://microsoft.com/ Microsoft Corporation])<br />
* [http://diveintomark.org/ Mark Pilgrim], [http://ibm.com IBM]<br />
* [http://www.blogologue.com/ Morten W. Petersen]<br />
<br />
=== Copyright ===<br />
{{MicroFormatCopyrightStatement2003}}<br />
<br />
=== Patentes ===<br />
{{MicroFormatPatentStatement}}<br />
<br />
== Prefácio ==<br />
Quando estávamos discutindo [http://developers.technorati.com/wiki/attentionxml Attention.xml], Tantek apontou que XHTML tem tudo de necessário para expressar semanticamente esboços e subscrição em blogroll-derivados em um formato XML que são ambos renderizável interativamente por navegadores e analisável por motores XML rígidas (strict). Esta página está aqui para discutir essa idéia.<br />
<br />
=== Nome ===<br />
XOXO significa eXtensible Open XHTML Outlines, e é pronunciado variadamente como 'ecks oh ecks oh', 'zho-zho' ou 'sho-sho'.<br />
<br />
== Sumário ==<br />
Essa especificação define um novo tipo de documento XHTML que é baseada sob o módulo de estrutura e módulos definido em Modularização de XHTML<br />
<br />
XOXO é um dos muitos [[microformats-pt-br|microformatos]]. Essa especificação define um novo tipo de documento XHTML que é baseada sob o módulo de estrutura e módulos definido em Modularização de XHTML ([http://www.w3.org/TR/xhtml-modularization XHTMLMOD]). O propósito do tipo de documento XOXO é para servir como base para esboço de XHTML amigável para processamento por motores XML e para fácil renderização interativa por browsers.<br />
<br />
== O Tipo de Documento XOXO ==<br />
O tipo de documento XOXO é composto dos seguintes módulos XHTML. Os elementos, atributos e modelos de conteúdo mínimos associado com estes módulos são definidos pela "Modularização de XHTML"<br />
([http://www.w3.org/TR/xhtml-modularization XHTMLMOD]). Os elementos que estão listados aqui são para propósitos de informação, mas as definições de "Modularização de XHTML" devem ser consideradas definitivas. Na versão online desse documento, os módulos online na lista abaixo fazem ligação para definição dos módulos dentro da atual versão de "Modularização de XHTML"<br />
<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_structuremodule Structure Module]<br />
body, head, html, title<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_hypertextmodule Hypertext Module]<br />
a<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_listmodule List Module]<br />
dl, dt, dd, ol, ul, li<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_metamodule Metainformation Module]<br />
meta<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_stylemodule Stylesheet Module]<br />
style element<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_styleattributemodule Style Attribute Module]<br />
style attribute<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_linkmodule Link Module]<br />
link<br />
[http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_legacymodule Legacy Module]<br />
Attribute compact on ol and ul<br />
<br />
=== O Perfil XOXO ===<br />
<br />
Veja [[xoxo-profile]] para o perfil [http://gmpg.org/xmdp XMDP] de XOXO que define os valores XOXO para o atributo class.<br />
<br />
== Simples Fragmento XOXO ==<br />
<br />
=== Marcação ===<br />
<br />
<pre><nowiki><ol class='xoxo'><br />
<li>Assunto 1<br />
<ol><br />
<li>subponto a</li><br />
<li>subponto b</li><br />
</ol><br />
</li><br />
<li>Assunto 2<br />
<ol compact="compact"><br />
<li>subponto c</li><br />
<li>subponto d</li><br />
</ol><br />
</li><br />
<li>Assunto 3<br />
<ol><br />
<li>subponto e</li><br />
</ol><br />
</li><br />
</ol><br />
</nowiki></pre><br />
<br />
=== Exemplo de Renderização ===<br />
<pre><nowiki><br />
1. Assunto 1<br />
a. subponto a<br />
b. subponto b<br />
2. Assunto 2<br />
3. Assunto 3<br />
a. subponto e<br />
</nowiki></pre><br />
=== Uso do atributo 'compact' ===<br />
<br />
Note que o uso do atributo 'compact' indica que os subpontos de título de "Assunto 2" não estão em um estágio expandido. A ausência do atributo 'compact' indica que outros títulos estão em um estágio expandido.<br />
<br />
=== Regras de Estilo Padrão para o Exemplo da Renderização ===<br />
<br />
<pre><nowiki><br />
ol.xoxo { list-style:decimal; }<br />
ol.xoxo ol { list-style:lower-latin; }<br />
ol[compact="compact"] { display:none; }<br />
</nowiki></pre><br />
<br />
<br />
== Mais Exemplos Simples ==<br />
<br />
MarkP fez um conjunto de exemplos que demostra ambos a simplicidade de marcação e a riquesa de apresentação que é possível:<br />
<br />
* [http://diveintomark.org/public/2004/01/xo-flat.xo simple arquivo XO que pode ser embutido diretamente em uma página XHTML]<br />
* [http://diveintomark.org/public/2004/01/xo-embeddable.xo XO with nested groups, also directly embeddedable in XHTML]<br />
* [http://diveintomark.org/public/2004/01/xo-standalone.xo XO as a standalone XHTML page] ([http://validator.w3.org/check?uri=http://diveintomark.org/public/2004/01/xo-standalone.xo valid XHTML])<br />
* [http://diveintomark.org/public/2004/01/xo-with-style.xo XO as a standalone XHTML page, styled with CSS] ([http://validator.w3.org/check?uri=http://diveintomark.org/public/2004/01/xo-with-style.xo also valid XHTML])<br />
* [http://homepage.mac.com/ctholland/thelab/outlines/ Chris Holland Outline Helper]: tweaked one of above samples, yanked CSS for simplicity, added reference to [http://homepage.mac.com/ctholland/thelab/outlines/outlines.css outlines.css] and [http://homepage.mac.com/ctholland/thelab/outlines/outlines.js outlines.js], pasted a few different combinations of ul/ol/li with the compact attribute.<br />
** na tentativa de cumprir com príncipios semanticos o atributo "compact" para os elementos ol e ul é o que conduzem o estágio de exibição. Por scripting, estou definindo classes pertercentes ao elemento li para adicionar flexibilidade de estilização, através do CSS Gurus devee estar apto a substitur "li.expanded" no outlines.css com algum outro seletor CSS que diz "selecione um nó li que contém um nó ol com um atributo 'compact'"<br />
<br />
== Propriedades de Itens Esboço ==<br />
Esboços tipicamente consiste de uma hiearquia de pontos e subpontos. Cada um desses pontos (item do esboço) si próprio pode ter algumas propriedades (como atributos ou metadata) que são necessários para ser representado. Talvez a mais comum propriedade adicional em itens de esboço na prática é a URL como demostrado nos exemplos de Mark Pilgrim acima<br />
<br />
Até mesmo o texto label/title de um item de esboço pode ser considerado uma propriedade comum. Algumas tais propriedades comum:<br />
<br />
* text /texto<br />
* description /descrição<br />
* url (frequentemente chamado de xmlurl ou htmlurl; as veses de permalink)<br />
* title /título<br />
* type /tipo (hint of the MIME type of the resource indicated by the URL)<br />
<br />
Em geral, propriedades em um item de esboço <code><nowiki><li></nowiki></code> <br />
são representado por um lista de definição alojado. A rigor, é o primeiro <code><nowiki><dl></nowiki></code> dentro do <code><nowiki><li></nowiki></code> e antes de qualquer seguinte <code><nowiki><ol></nowiki></code>, <code></div>ScottReynenhttps://microformats.org/wiki/index.php?title=User:Amette&diff=21038User:Amette2007-06-10T20:37:01Z<p>ScottReynen: Reverted edit of SsePg3, changed back to last version by Amette</p>
<hr />
<div>''amette@<system>''<br />
<br />
http://alexander-mette.de<br />
<br />
developer with [http://tikiwiki.org TikiWiki]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=hcalendar-examples-in-wild&diff=16553hcalendar-examples-in-wild2007-05-08T12:18:13Z<p>ScottReynen: /* New Examples */</p>
<hr />
<div><h1>hCalendar Examples in the wild</h1><br />
<br />
This page is an '''informative''' section of the [[hcalendar|hCalendar specification]].<br />
<br />
The following sites have published events using [[hcalendar|hCalendar]], and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc. <br />
<br />
If events on your site are marked up with hCalendar, feel free to add it to the top of this list. Please be sure to include at least one URL of a page on your site that includes actual [[hcalendar|hCalendar]] markup. Examples added without the URL of a page with hCalendar markup may be removed.<br />
<br />
Want to get started with writing an [[hcalendar|hCalendar]] event? Use the [http://microformats.org/code/hcalendar/creator hCalendar creator] to write up an event and publish it, or follow the [[hcalendar-authoring|hCalendar authoring tips]] to add hCalendar markup to your page of upcoming events or events you mention in blog posts, wikis, etc.<br />
<br />
Don't forget that you can add one of our [[buttons#hCalendar|buttons]] to the page, to indicate the presence of hCalendar microformats. For example: http://www.boogdesign.com/images/buttons/microformat_hcalendar.png. If you can link it back to [[hcalendar|hCalendar]] (or even page on your website, about your use of the microformat), so much the better!<br />
<br />
==New Examples==<br />
<br />
Please add new examples to the '''top''' of this section.<br />
* [http://playinghere.com/ Playing Here] uses hCalendar for live music shows in America, [http://playinghere.com/2007/07/07/CA/Los_Angeles/The_Hollywood_Bowl/ e.g.]<br />
* [http://www.thsh.co.uk THSH] uses iCalendar for events at Town Hall Birmingham and Symphony Hall Birmingham<br />
* [http://www.anfsusa.org/ America-Nepal Friendship Society] uses hCalendar for its program events<br />
** Example here: [http://www.anfsusa.org/news/programs-projects/ ANFS: Programs &amp; Projects]<br />
* [http://www.friendsofthechildrenny.org/ Friends of the Children, New York] - uses hCalendar for upcoming fundraising events<br />
** Example here: [http://www.friendsofthechildrenny.org/events.html Events]<br />
* [http://www.depechemode.de www.depechemode.de] - uses hCalendar for events in the party guide<br />
** Example here: [http://www.depechemode.de/parties/show-party.php?cat=1 Depeche Mode Parties]<br />
* [http://last.fm last.fm] - uses hCalendar on all concert announcements.<br />
** Example here: [http://www.last.fm/event/75615 Rise Against at Arena, Wien]<br />
* [http://www.radiotimes.com Radio Times] - now mark up all their radio and TV listings.<br />
**The hCals on listings are good, but on pages for individual programmes, they have no date/times - for instance [http://www.radiotimes.com/ListingsServlet?event=10&channelId=56&programmeId=57876521&jspLocation=/jsp/prog_details_fullpage.jsp]<br />
** Would benefit from using [[include-pattern]] for channel name in main listings. This would facilitate the writing of parsers to set audio or video recording software. [[User:AndyMabbett|Andy Mabbett]]<br />
* [http://nederlandskamerkoor.nl Dutch Chamber Choir] uses hCalendar to notify visitors of their tour schedule.<br />
* [http://cloudislands.com Cloud Islands] uses hCalendar to notify our customers about the conferences we'll be attending.<br />
* [http://www.international.unt.edu UNT International] uses hCalendar for events (see esp. [http://www.international.unt.edu/offices/welcome/events/intlweek/calendar International Week 2007 Event Calendar])<br />
* [http://www.rockisland.com/%7elopezmuseum/index.html The Lopez Island Historical Society and Museum] uses hCalendar for events<br />
* [http://futureofwebapps.com/schedule.html Future of Web Apps London] lists its schedule in hcalendar. <br />
* [http://leicesteryha.org.uk/cgi-bin/leoprog Leicester YHA Group's programme page] uses hCalendar and hCard to mark up forthcoming events and their organisers.<br />
* [http://www.wadip.org.uk/pages/events.php Wadhurst Independent Photography events] lists forthcoming events in hCalendar format.<br />
* [http://xlntads.com/about-xlntads/development-schedule.php XLNTads-development schedule] has their project development schedule timeline marked up in hcal (as well as contacts in hCard)<br />
* [http://www.jaama.co.uk Jaama] have their event details as iCal downloads on their [http://www.jaama.co.uk/HS_Seminars.aspx workshops] page.<br />
* [http://3amproductions.net 3AM Productions] has employee education ([http://3amproductions.net/jason.php Jason], [http://3amproductions.net/gilbert.php Gilbert]) marked up in hCalendar<br />
* The [http://neatta.org New England Antique Tractor & Truck Association] (of all sites) has their 15 upcoming events marked up in hCalendar (as well as contacts in hCard and classifieds in hListing)<br />
* [http://diarised.com Diarised] is a quick and simple online tool to help pick the best time for a meeting, uses hCalendar for meeting information.<br />
* [http://etnies.com/ etnies.com] uses hCalendar on each sports home page ([http://etniesskate.com/ etniesskate.com]) and the [http://etnies.com/extra/calendar/ calendar of events] page.<br />
* [http://www.mdas.org/ La maison des associations de Strasbourg] uses hCalendar on event pages.<br />
* [http://nuggetshoops.com/schedule.php NuggetsHoops] , an NBA fansite, uses hCalendar for each remaining game in the current season.<br />
* [http://wikevent.org WikEvent] aims to make it as easy as possible to put events on the web with semantic markup, including hCalendar for events and hCard for venues and artists.<br />
* [http://fundyfilm.ca/calendar/ The Fundy Film Society] uses hCalendar for their calendar of upcoming film screenings.<br />
* Psychology Press and Routledge's Behavioral Sciences' publishing division have implemented hCalendar on their conferences listings on 17 of their websites (example on the conference listing on their [http://www.clinicalpsychologyarena.com/resources/conferences.asp Clinical Psychology Arena])<br />
* [http://jhtc.org Jewish High Tech Community] uses hCalendar on event pages.<br />
*[http://www.gore-tex.com/remote/Satellite?c=fabrics_content_c&cid=1162322807952&pagename=goretex_en_US%2Ffabrics_content_c%2FKnowWhatsInsideDetail Gore-Tex "Know What's Inside"] tour dates in hCalendar by [http://microformats.org/wiki/User:Csarven csarven]<br />
* [http://finetoothcog.com/site/stolen_bikes Finetoothcog] uses hCalendar to markup when bikes are stolen.<br />
* [https://www.urbanbody.com/information/contact-us Urban Body Men's Clothing] uses hCalendar for business hours and hCard for business locations.<br />
* [http://www.infoiasi.ro The website of the Faculty of Computer Science], "A. I. Cuza" University Ia&#351;i, Romania, uses hCalendar to markup events.<br />
* [http://www.crosbyheritage.co.uk/events/ Colin Crosby Heritage Tours] uses hCalendar to markup events.<br />
* [http://www.facebook.com Facebook] use hCalendar to markup events.<br />
* [http://www.newbury-college.ac.uk/ Newbury College UK] uses a smattering of hCalendar and hCard<br />
* [http://07.pagesd.info/ardeche/agenda.aspx 07.pagesd.info] uses hCalendar and hCard to mark up events of the Ardèche département in France.<br />
* [http://climbtothestars.org Stephanie Booth] announced the [http://climbtothestars.org/archives/2006/09/14/microformats-et-bloggy-friday-doctobre/ Bloggy Friday for October 2006] using hCalendar.<br />
* The [http://www.westmidlandbirdclub.com/ West Midland Bird Club], in the English Midlands, uses hCal (with nested hCard) on its [http://www.westmidlandbirdclub.com/diary/ diary of birding events].<br />
* [http://www.comtec-ars.com/press-releases/ ComTec audience response systems' press releases] use hCalendar as a method to organize by title and date.<br />
* [http://webdirections.org/program/ The Web Directions Conference (Sydney Australia)] uses hCalendar for their program. It uses axis and headers for events in a table, and demonstrates how easy it is to make the whole thing downloadable using X2V.<br />
* [http://www.thestreet.org.au/ The Street Theatre (Canberra, Australia)] now uses hCalendar for performances on its [http://www.thestreet.org.au/whats_on.htm What's On] page.<br />
* [http://www.clacksweb.org.uk Clackmannanshire Council] uses hCalendar on its [http://www.clacksweb.org.uk/community/events/ event diary] listing pages and individual event pages.<br />
* [http://www.markthisdate.com/ Calendarportal MarkThisDate.com] now uses hCalendar for all calendars. On our website visitors can add calendars and download calendars to Outlook, Lotus Notes, iCal, Netvibes, 30Boxes, Google Calendar and many others. Over 600 calendars were already uploaded. <br />
* [http://mogue.jp/ mogue] uses hCalendar at [http://mogue.jp/event/1000/ event detail] pages.<br />
* [http://www.gustavus.edu/events/nobelconference/2006/schedule.cfm 2006 Nobel Conference] uses hCalendar for the conference schedule<br />
* [http://www.geekinthepark.co.uk Geek in the Park] uses hCalendar for the event information. -- by [[User:Trovster|trovster]]<br />
* [http://www.besancon.fr/ official site of Besançon (France)] for its events<br />
* [http://2006.dconstruct.org/schedule/ Conference schedule for d.Construct 2006] is published using hCalendar.<br />
* [http://local.yahoo.com Yahoo Local] now supports hCalendar<br />
* We used hcalendar for the [http://www.fuckparade.org/flyer/2006/ F’parade flyer 2006], a counter demonstration to the Love Parade in Berlin, alas the '''Firefox tails extension''' doesn't get a summary when it's an alt-text in an image.<br />
* [http://www.harper-adams.ac.uk/press/events.cfm Harper Adams University College] uses hCalendar to mark up all University events on the Homepage and Events Calendar page.<br />
* [http://www.capital.edu/ Capital University] uses hCalendar on multiple pages to provide feeds of events, relevant to page content<br />
* [http://www.thesession.org/events/ The Session events] uses hCalendar to mark up concerts, festivals and workshops related to Irish traditional music.<br />
* [http://rubyandrails.org/usergroups/newcastle ncl.rb] uses hCalendar to mark up new meetings.<br />
* [http://gross.org.za/calendar GROSSUG Calendar] - Uses hCalendar to mark up meetings and other events.<br />
* [http://www.webanalyticsassociation.org/en/calendarevents/search.asp Web Analytics Association] - hCalendar microformat is in place on all Tendenci sites on the calendar events search page and consolidated list page.<br />
* [http://www.tendenci.com/en/calendarevents/search.asp Tendenci Calendar Events] with hCalendar<br />
* [http://www.argolon.com/2006/04/17/web20-conference-in-dublin/ Web2.0 Conference in Dublin] hCalendar event<br />
* [http://www.meetup.com/ Meetup.com] has marked up [http://www.meetup.com/cities/us/ny/new_york city event calendars], [http://photo.meetup.com/100/events/ group event lists], and [http://www.meetup.com/ signed-in homepages] with hCalendar.<br />
* [http://ukwindsurfing.com/ ukwindsurfing.com] has marked upcoming events with hCalendar, and the [http://ukwindsurfing.com/events/ events page] in a table.<br />
* [http://ocono.com/ ocono.com] has marked up it's "Upcoming Events" list with hCalendar.<br />
* [http://www.austinbloggers.org/ Austin Bloggers] has marked up their "Upcoming Events" box with hCalendar ([http://www.austinbloggers.org/blog/a/001123.html announcement]).<br />
* Ning's cloneable Group app has [[hcalendar|hCalendar]] markup on its [http://group.ning.com/index.php?controller=event&action=list event calendar] and [http://group.ning.com/index.php?controller=event&action=view&id=727220 event detail] pages.<br />
* [http://tantek.com/microformats/2006/03-01-TechPlenAgenda.html Agenda: W3C Technical Plenary Day, March 1 2006] has [[hcard|hCard]] and [[hcalendar|hCalendar]] markup. ([http://www.w3.org/2006/03/01-TechPlenAgenda.html original here]).<br />
* The National Arbor Day Foundation has started using hCalendars for their [http://arborday.org/programs/conferences/communityforestry/index.cfm upcoming] [http://arborday.org/programs/conferences/hazardtrees-treeplanting/ conferences].<br />
* [http://www.stateofflux.com/ State of Flux street art site] has started adding events in hCalendar format<br />
* The [http://barcamp.org/#BarCamps BarCamp home page lists upcoming BarCamps marked up with hCalendar] and even has a "Subscribe..." link.<br />
* [http://www.w3.org/2005/12/allgroupoverview.html 2006 W3C Technical Plenary Week] has marked up the schedule and events for the week with hCalendar.<br />
* [http://www.code4lib.org/2006/schedule code4lib Conference 2006 Schedule] is marked up with hCalendar as [http://www.code4lib.org/node/65 announced on their blog].<br />
* [http://grouper.ieee.org/groups/754 IEEE 754 Working Group] - trying hCalendar for upcoming meetings.<br />
* [http://www.pehuen.org/node/494 Elecciones 2005 Chile] - the first spanish language hCalendar event found in the wild.<br />
* [http://www.codewitch.org/it/2005/11/17/no-creative-commons-no-party/ Giocolando » No Creative Commons? No Party!] is marked up with hCalendar<br />
* [http://www.cmprofessionals.org/events/calendar.html CM Pros Events Calendar] by Bob Doyle<br />
* [http://www.midgard-project.org/community/events/ Midgard CMS Event calendar] - as [http://bergie.iki.fi/blog/new-event-calendar-for-midcom.html blogged by Henri Bergius] <br />
* [http://www.iowamilitaryveteransband.com/schedule/ Iowa Military Veterans Band Schedule] - hCalendar markup [http://weblog.randomchaos.com/archive/2005/10/24/Microformats/ added by Scott Reynen]<br />
* [http://www.funfairgames.net/weblog/posts/00000011.html Upcoming events on Jason A.R. Moody Amusements Weblog] posted by Jason Moody on 15 Oct 2005. [http://www.funfairgames.net/weblog/index.html His weblog] in general has hCalendar events posted inside the blog posts.<br />
* [http://tantek.com/microformats/2005/syndicate/tracks-sessions-schedule.html Syndicate - Tracks &amp; Sessions]<br />
* [http://tantek.com/microformats/2005/web2/program.html Web 2.0 Conference schedule page marked up with hCalendar]<br />
* [http://www.thisiscmon.com/ C'MON] is a rock band from Canada, and their [http://www.thisiscmon.com/shows/ tour dates] have been marked up by [http://www.d2digitalmedia.com/ Ray Dickman] with hCalendar.<br />
* [http://ifreebusy.com/ ifreebusy.com] will display freebusy information using hCalendar. See this [http://ifreebusy.com/neiljensen/freebusy/ example].<br />
* [http://we05.com/ Web Essentials 05] has marked up their [http://we05.com/program.cfm program schedule table with hCalendar], using the 'axis' and 'headers' attributes.<br />
* [http://www.asdvbonaparte.nl/ ASDV Bonaparte] is a Dutch debating society. Their events calendar has been marked up with the hCalendar conventions.<br />
* [http://chocnvodka.blogware.com/blog Suw Charman] has marked up [http://suw.org.uk/archives/category/events/ her events] with hCalendar.<br />
* [http://www.blogbusinesssummit.com/ Blog Business Summit] has published their [http://www.blogbusinesssummit.com/details.htm event details] marked up with hCalendar.<br />
* [http://eventful.com Eventful.com] publishes all events with hCalendar and venues with [[hcard|hCard]]. Took them only 15 minutes to implement both! Their Atom feeds also contain hCalendar/hCard.<br />
* [http://upcoming.org Upcoming.org] publishes all events and lists of events with hCalendar. Took them only an hour to add hCalendar support to the site.<br />
** The dtend values for events with no time specified (like [http://upcoming.org/event/110145/ | Burning Man] are not exclusive. This causes problems when sending the microformats info to places like Google. They do correct the dtend when exporting to Outlook though. They have been made aware of the problem.<br />
* The [http://laughingsquid.com/squidlist/calendar/ Laughing Squid Calendar] events, [http://laughingsquid.com/squidlist/calendar/9949/2005/5/9 e.g. this party], now supports hCalendar.<br />
* [http://paulschreiber.com/ Paul] Schreiber's [http://concerts.shrub.ca/ Sunnyvale House Concerts] site publishes hCalendar event information for upcoming concerts. In addition the [http://concerts.shrub.ca/shows Past Shows] page contains hCalendar events for all past concerts.<br />
* [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]. <br />
* [http://tantek.com/log Tantek's Thoughts], specifically the "Events" roll in the right-most column.<br />
* [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.<br />
* [http://norman.walsh.name/2005/itinerary/ Norm Walsh's travel schedule] use hCalendar as well as GRDDL.<br />
* [http://www.policyawareweb.org/2005/ftf2/paw-mtg Policy Aware Web (PAW) Project Meeting] uses hCalendar to record date-related decisions, and uses a vtodo microformat to record action items.<br />
* The [http://lufgi4.informatik.rwth-aachen.de Laboratory for Dependable Distributed Systems] publishes it's [http://lufgi4.informatik.rwth-aachen.de/cfps list of notable CfPs on dependability and security] with hCalendar-todo elements.<br />
* The [http://laughingsquid.com/laughing-squid-10th-anniversary-party/ Laughing Squid 10th Anniversary Party] has an hcalendar page.<br />
* SPRACI has hcalendar versions of its nightlife/clubbing/gigs/festivals listings for many cities worldwide - eg: [http://www.spraci.com/listhcalendar.php?parea=sydney&category=all Events in Sydney] (check the [http://www.spraci.com/api/ API] pages in the faq section of [http://www.spraci.com/ SPRACI] for more info about the area/city keywords and category tags to use to get data for your city/categories<br />
* WWF-Australia events calendars: [http://wwf.org.au/act/events/ What's on], [http://wwf.org.au/act/volunteer/ Volunteer]<br />
* [http://rubyholic.com rubyholic] uses hCalendar to publish calendars for ruby groups.<br />
* [http://www.bath.ac.uk/whats-on/ University of Bath What's On] uses hCalendar on individual event pages<br />
* The [http://www.kiez-ev.de/ Kiez] is a small cinema and has published its [http://www.kiez-ev.de/programm program] marked up with hCalendar<br />
<br />
===World Cup Kick-off===<br />
* [http://www.worldcupkickoff.com/ World Cup KickOff] where you can download and keep all the fixtures you are interested in so you will never miss a single game of the 2006 football World Cup!<br />
** This link was on the [http://www.lifehacker.com/software/sports/world-cup-start-times-for-ical-etc-175393.php Lifehackers site] and made its way to the yahoo news site:<br />
<br />
<blockquote><br />
Mon May 22, 4:00 PM ET<br />
The World Cup, one of the world's most watched sporting events, is almost upon us. If you've ever tried to follow your favorite team through the Cup you know that it can sometimes be difficult to know when they're on. World Cup Kickoff can help.<br />
<br />
World Cup KickOff is all you will ever need for knowing all the match details for the upcoming World Cup 2006. Whether you use your mobile phone, MS Outlook, Apple iCal or Mozilla Calendar, you can download and keep all the fixtures you are interested in so you will never miss a single game!<br />
<br />
Next tip? We'll show you how to get up at 2 AM to watch your matches. ;0) Thanks to Tom for the tip!<br />
</blockquote><br />
<br />
== Examples with some problems ==<br />
If you find a problem with any example in any other section, please move it here, and note the precise problem and cite the section of the [[hcalendar | hCalendar spec]] that appears to be violated. If the example that was moved here is yours, and you want to improve it, see the [[hcalendar-faq| hCalendar FAQ]], or raise any queries on [[hcalendar-issues| hCalendar issues]] or [[mailing-lists#microformats-discuss|the mailing list]], where people will be happy to help you. <br />
<br />
* [http://www.ischool.washington.edu/ iSchool of the University of Washington] - now embeds hCalendar markup on all of it's events<br />
** Example here: [http://www.ischool.washington.edu/events/calendar.aspx Events Calendar]<br />
** Uses 12-hour time values, not 24-hour (e.g. 0700 for 7pm) [[User:AndyMabbett|Andy Mabbett]] 14:07, 24 Apr 2007 (PDT)<br />
* [http://www.gretchenland.com Gretchen] has their show schedule marked up with hCalendar<br />
** Example here: [http://www.gretchenland.com/shows Upcoming Concert Dates]<br />
**Invalid: <code><nowiki><SPAN title="2007-04-21" class="dtstart">04.21.2007</SPAN></nowiki></code> [[User:AndyMabbett|Andy Mabbett]] 02:08, 20 Apr 2007 (PDT)<br />
* I'd be happy if some future french Pinko-marketing meetings (CantineCamp) could require the use of hCalendar for listing some informal lunches in Paris. [http://www.wikiservice.at/fractal/wikidev.cgi?FR/PinkoMarketing/CantineCampParis10 CantineCampParis10 is an example] to include a hCalendar + hCard markup on the wiki-page. When converting to vCard, "Mendès" accent is malformed in a french outlook 2003 "address book". I've looked UTF-8 example but could not find any way to correct. Any idea ? -- [[User:ChristopheDucamp|xtof]] 01:09, 26 Mar 2007 (PDT)<br />
* [http://www.joomlamug.com Joomla! Melbourne User Group] uses hCalendar markup for listing of all events.<br />
** No examples on cited page. [[User:AndyMabbett|Andy Mabbett]] 15:06, 31 Jan 2007 (PST)<br />
* [http://www.webfeet.org/events.html Webfeet events] includes hCalendar markup in its aggregated events lists.<br />
** <s>Possibly a case where <nowiki><abbr></nowiki> won't work for dtstart/dtend as there are many events listed under a single date. [[User:Webf|Webf]] 15:19, 15 Jan 2007 (PST)</s><br />
**Malformed e.g <code><nowiki><span class="dtstart" title="20070120"></span></nowiki></code> [[User:AndyMabbett|Andy Mabbett]] 15:41, 15 Jan 2007 (PST)<br />
** Continue the discussion under [[hcalendar-issues|hCalendar Issues]] perhaps. [[User:Webf|Webf]] 22:25, 15 Jan 2007 (PST)<br />
* [http://www.theatrestudies.llc.ed.ac.uk/ Theatre Studies: European Theatre] at the University of Edinburgh uses hCalendar to markup news and events on the index page.<br />
**<s>Uses "display:none" on image. [[User:AndyMabbett|Andy Mabbett]] 15:32, 13 Nov 2006 (PST)</s> Removed img tag from hCard<br />
* [http://www.bokle.de/ s'Bokle] is a German music pub. Their events calendar has been marked up with hCalendar.<br />
** improper use of rrule --[[User:RyanKing|RyanKing]] 16:04, 6 Jan 2006 (PST)<br />
* [http://plan9.tryphon.org/nancy/list Plan9] - Uses hCalendar to mark up events !<br />
** <s>dtstart/dtend are implemented on span element [[User:TomArmitage|Tom Armitage]] June 23, 2006</s> --[[User:Tim|Tim]] 13:34, 4 Mar 2007 (PST) Fixed now<br />
* [http://www.socaltech.com socalTECH] is a news and information site. Their front page event listing is marked up with hCalendar.<br />
** dtstart/dtend implemented on span element [[User:TomArmitage|Tom Armitage]] June 23, 2006<br />
* [http://www.multipack.co.uk The Multipack] features a vevent for the next meeting information.<br />
** dtstart/dtend are implemented on em element [[User:TomArmitage|Tom Armitage]] June 23, 2006<br />
* [http://paulschreiber.com/ Paul] Schreiber's [http://iceoasis.shrub.ca/ unofficial schedule site] publishes hCalendar information for upcoming hockey games at [http://www.iceoasis.com/ Ice Oasis]<br />
** dtstart/dtend are implemented on td element [[User:TomArmitage|Tom Armitage]] June 23, 2006<br />
<br />
- whilst Tails parses the "title" attribute for dtstart/dtend on <em>any</em> element (does Tails still do this?), that is incorrect. The title attribute only provides semantics for the <code><nowiki><abbr></nowiki></code> element, while for elements in general like <code><nowiki><span></nowiki></code>, only the contents of the element are used. This is a simplification and see [[hcard-parsing|hCard parsing]] for details. Technorati Microformats Search only looks for the title attribute on <code><nowiki><abbr></nowiki></code> tags per the rules from [[hcard-parsing|hCard parsing]] which apply to [[hcalendar-parsing|hCalendar parsing]] as well.<br />
<br />
== Reviewed Examples ==<br />
If you have reviewed a New Example (and you are not the author of the example) and believe it to be valid, go ahead and move it here.<br />
* ...<br />
<br />
== Related Pages ==<br />
{{hcalendar-related-pages}}</div>ScottReynenhttps://microformats.org/wiki/index.php?title=faq&diff=18115faq2007-05-06T15:15:47Z<p>ScottReynen: Moving new FAQ to proper location</p>
<hr />
<div><h1> Microformats FAQ </h1><br />
<br />
This page document frequently asked questions about microformats. For frequently asked questions from the [[press]], see [[press-faq]].<br />
<br />
If you're looking for a microformat for marking up FAQs, see [[question-answer]].<br />
<br />
__TOC__<br />
<br />
== Wiki specific questions ==<br />
===Q: ''How do I create a username? Why won't it let me use my preferred username?''===<br />
<br />
A: First, read this: http://en.wikipedia.org/wiki/Wikipedia:Username . Second, real names are preferred to pseudonyms/handles etc. Real names encourage better transparency and accountability. Third, the most common problem creating a user name is forgetting to capitalize the first letter of the user name. Try using a WikiCase version of your full name as username, e.g. RyanKing.<br />
<br />
== Email list ==<br />
===Q: ''I've joined the discussion mailing list but am not seeing my replies anywhere. Why?''===<br />
<br />
A: There is no moderation on microformats-discuss, but it only accepts posts from subscribers. You MUST post to microformats-discuss using the email address you used to subscribe.<br />
<br />
===Q: ''What does "The message's content type was not explicitly allowed" mean?'' ===<br />
<br />
A: Please go read [http://microformats.org/mailinglists-policies/ mailinglists-policies]. In particular note:<br />
<blockquote><br />
'''No HTML or RTF e-mail''' period, end of story, full stop. Your mail client should let you configure it so you can send plain text messages. Make use of this ability or else there are no guarantees that anyone will be able to read your email.<br />
</blockquote><br />
The mailing lists are set up to automatically reject email that is sent as text/html. Thus please configure your email client to send plain text (text/plain) email.<br />
<br />
== Basic Microformat Questions ==<br />
===Q: What does ''xxx'' mean?"===<br />
<br />
A: See our [[glossary]].<br />
<br />
===Q: ''When should I use a microformat? What are they for?"===<br />
<br />
A: You are writing some HTML that contains useful human-readable information (such as a piece of contact information). You say to yourself: I would like to mark this up with some classes now for styling. You look up the relevant microformat, and you<br />
pull in the standard names. You don't have to make your own up, and now your page is machine-readable too. Bonus!<br />
<br />
Microformats are designed to make the data you already publish for humans available to machines. It allows applications as simple as cut-and-paste or as complex as a seach engine to use your data effectively.<br />
<br />
===Q: ''Are microformats dependent upon (X)HTML?''===<br />
<br />
A: Microformats are made to be embeddable. They can be embedded in (X)HTML, RSS, Atom or anywhere (X)HTML is allowed.<br />
<br />
<br />
===Q: ''Microformats sound great. How can I help?''===<br />
<br />
A: Take a look at http://microformats.org/discuss to see some ways to join the conversations about microformats, and the [[to-do]] list for things to help out with.<br />
<br />
<br />
===Q: ''I'd like to make a donation to the microformat cause. How can I do this?''===<br />
<br />
A: Thank you for your willingness to support microformats. We've only recently started this site and have decided that while we are figuring out exactly how to accept donations, we will be passing along donations to other good causes. Please consider donating to another cause like Red Cross, perhaps directed to help victims of recent natural disasters.<br />
<br />
<br />
===Q: ''Which microformats have been implemented?'' ===<br />
<br />
A: See the [[implementations]] page.<br />
<br />
<br />
===Q: ''Which microformats should I implement?''===<br />
<br />
A: Chances are you that your website already has data very similar to several microformats. For example, you probably have people and/or their contact information somewhere. That information could be marked up with [[hcard|hCard]], see the [[hcard-authoring|hCard authoring]] page for step by step instructions. If you are publishing press releases, try using [[hatom|hAtom]].<br />
<br />
<br />
===Q: ''Do you have any link badges I can add to my website/blog?''===<br />
<br />
A: There are some [[buttons]] but we can certainly use more! Please contribute what you come up with!<br />
<br />
<br />
===Q. ''Are there any tools that support microformats?''===<br />
<br />
A. Yes...tons... [[implementations]].<br />
<br />
===Q. Is there a way to indicate that a given web page contains markup that conforms to one or more microformats? ===<br />
<br />
A. The HTML HEAD element's '<code>profile</code>' attribute alerts applications to the potential presence of microformats. The [http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.4.4.3 W3C HTML Specification] describes more about the profile attribute, and the [http://gmpg.org/xmdp/description XMDP description] documents how it is used.<br />
<br />
===Q. ''What about using new URI schemes instead of class names, e.g. for geo information?''===<br />
<br />
A. In general, it is more work, and less content-publisher friendly, to ask publishers to use URI schemes instead of class names.<br />
<br />
Authors aren't publishing links to geo information.<br />
<br />
They're publishing *visible text* of [[geo]] information.<br />
<br />
So the easiest thing to do, for the author, is to leave it as visible text.<br />
<br />
Thus, it makes the most sense to do the simple thing of just wrapping that<br />
visible text with a little bit of markup, rather than asking the author to<br />
move (or copy) it into an attribute, which may or may not require a<br />
reformatting of the data as well.<br />
<br />
It would make sense from a usability persepective to hyperlink geo information to a maps page or something, so that clicking it actually does something. If you forced them to use a hypothetical "geo:" protocol instead, then that would interfere, since you can only hyperlink something to one destination.<br />
<br />
<br />
===Q: ''Who controls microformats?''===<br />
<br />
A: An open community. Microformats are open standards licensed under Creative Commons Attribution. Much of the work here was begun on [http://developers.technorati.com/wiki Technorati's Developer Wiki], but Technorati has since divested control of these microformat standards to the open community here. The microformats.org domain is registered to Rohit Khare (see [http://whois.uberdose.com/microformats.org Whois microformats.org]), CommerceNet is graciously hosting the servers, but claims no control over microformat standards. Anyone may follow the established [[process]] and contribute towards the development of microformat standards.<br />
<br />
Any required [[governance]] of the microformats IRC channel, wiki, and mailing lists (and very little ''has been'' required) is discussed by a group of volunteer administrators, who are listed on that page.<br />
<br />
===Q: ''Who is the registrar for microformats?''===<br />
<br />
A: There is no central registry. Microformats are registered in a distributed manner using profiles. For more information on profiles see http://microformats.org/wiki/profile-uris and http://gmpg.org/xmdp/<br />
<br />
Conflicts and interoperability are managed through social processes rather than a formal registry. Current microformat profiles can be found at http://gmpg.org, http://w3.org, and http://microformats.org.<br />
<br />
<br />
===Q: ''So multiple microformats with the same name can be valid?''===<br />
<br />
A: Yes. The community at microformats.org can hopefully play a role in determining which is preferred by bringing interested folks together in one place and helping them resolve that question. As long as each microformat maintains a valid profile, each can be used effectively.<br />
<br />
<br />
===Q: ''How do I validate my microformated content?''===<br />
<br />
A: Currently there is no automatic general-purpose validator for microformats (See [[to-do#for_all_microformats|To Do - for all microformats]]). There are however some microformat-specific tools listed on the [[implementations]] page which can help with validation. [https://addons.mozilla.org/firefox/4106/ Operator] does a good job of compliant parsing for microformats in general. For [[hcard|hCard]], try the [http://feeds.technorati.com/contacts/ Technorati Contacts Feed service]. For [[hcalendar|hCalendar]], try the [http://feeds.technorati.com/events/ Technorati Events Feed service]. Also, posting your examples to the [http://microformats.org/discuss microformats-discuss mailing list], and adding them to the respective examples/implementations sections/pages will very often get folks from the community to review and validate them for you.<br />
<br />
===Q: ''How do microformats breach language barriers?===<br />
'''Would we have to "force" non-English speaking web page developers to use something like class="name" (as opposed to "namen" or "nom") for their productions to be properly indexed by agents?'''<br />
<br />
A: Yes, but that's no different to using English words like "class", "span" or "head". This was briefly discussed on the microformats-discuss list most recently as "Language Maps" but has been raised before that. Some folks have raised the issue that microformats use English names for properties, and they would like alternate (non-English) names in other (natural) languages, and perhaps try to establish a mapping between them. As microformats property names are based on existing standards (see [[process]], and [[naming-principles]]), this is another problem that is far outside the scope of microformats. As Ryan King put it, this is a pre-existing (unsolved) "problem" with English-based HTML, the English-based CSS, the English-based HTTP and so on. Note that this is NOT about the internationalization of the content and data itself - which is of course an excellent goal, advocated and promoted by microformats and the standards they are based on (e.g. W3C, IETF). This is purely about the names of the properties (and enumerated values) in the formats. See also [[internationalization]].<br />
<br />
===Q: ''How come microformats sometimes to linger as Drafts even though they seem usable?'' ===<br />
<br />
A: [http://microformats.org/wiki/faq#Q:_Who_controls_microformats.3F Tantek] went over this at the recent [http://2007.sxsw.com/interactive/programming/panels/?action=show&id=IAP060234 The Growth and Evolution of Microformats] panel at [http://en.wikipedia.org/wiki/South_by_Southwest SXSW]. He conveyed that it was important to have a basic software implementation -- even an experimental one -- before moving a format from Draft to Specification. It can sometimes be hard to recognize subtle inconsistencies within a format by eye; however, in the process of implementing a format-reader in code, inconsistencies (if any) can become much more noticeable (due to [[dry | DRY / Don't Repeat Yourself]], among other programming best practices). Then, once such a tool has been created (in effect, confirming the programmability of the format), it can be transitioned to a Specification (so as to encourage other machine-based implementations).<br />
<br />
== Creating and Suggesting New Microformats ==<br />
<br />
===Q. ''I would like to author a new microformats open standards specification for my site/business. How do I get started?''===<br />
<br />
A. The first thing to do before attempting a new microformat open standard is to make as much use of existing [[microformats]] open standards as possible in whatever site you are looking to mark up with your new microformat, as a way of learning what is left to be done. That is, at a minimum first:<br />
* Mark up all people and organizations as [[hcard|hCards]].<br />
* Mark up all events and time based things as [[hcalendar|hCalendar]] events.<br />
* Mark up all reviews as [[hreview|hReviews]].<br />
* etc.<br />
Then join the microformats [http://microformats.org/discuss discuss list], and ask folks what they think of your use of the microformats and if it can be improved.<br />
<br />
From that experience you will then be able to figure out what is left to be specified. Otherwise it is too hard to approach the "whole problem".<br />
<br />
Once you have completed that, take a look at the microformats [[process]] for how to walk through the steps of creating a new microformat, and note the specific problem you are trying to solve to the microformats-discuss list. This will help you find more people to help you solve the problems you are trying to solve.<br />
<br />
===''Q How do I know if an idea for a Microformat has already been suggested in the past?''===<br />
<br />
A. Check the list of proposed and rejected microformats. <br />
* [[rejected-formats]]<br />
<br />
===Q. ''What if I can't find real-world examples of a standard I'd like to propose?''===<br />
<br />
A. If we can't find real-world examples of the '''types of data''' a proposal would address, it's probably not suitable for a microformat. If we only can't find real-world examples of the '''specific markup''' a proposal would use for that data, however, that's not really a problem. It's actually the lack of such standard markup in real-world publishing around a specific problem that suggests the need for increased consensus.<br />
<br />
== Specific Microformat Questions ==<br />
If you have a question regarding a specific microformat, you may want to check the FAQ specific to that microformat.<br />
* [[hatom-faq]]<br />
* [[hcalendar-faq]]<br />
* [[hcard-faq]]<br />
* [[hreview-faq]]<br />
* [[rel-faq]]<br />
* [[rel-tag-faq]]<br />
* [http://gmpg.org/xfn/faq xfn-faq]<br />
* [[xfolk-faq]]<br />
* [[xmdp-faq]]<br />
* [[xoxo-faq]]<br />
<br />
== Class interactions ==<br />
<br />
===Q. ''Are there issues with page styling when specific class values are used?''===<br />
<br />
A. There might be. However, any such issues can be easily (trivially) worked around by using contextual selectors.<br />
<br />
<br />
===Q. ''How does the use of class values for semantics interact with the use of class values for attaching CSS styles?''===<br />
<br />
A. The class attribute takes a space separated set of class names [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 HTML4 reference]. Thus both author and microformat defined class names may be used in the same class attribute. In addition, microformat class names provide the author with a consistent set of class names to use for styling. If the author is already using using specific class names, they can continue to do so, and include microformat class names. If the author is already using a class name that happens to also be a microformat class name, then the author may want to consider using contextual CSS class selectors to make sure that avoid any unintentional styling effects.<br />
<br />
See also: <br />
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]<br />
* [http://tantek.com/log/2004/07.html#classmeaningnotshow Class For Meaning Not For Show]<br />
* [http://www.meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competant Classing], by Eric Meyer for discussion of choosing class names in (X)HTML<br />
* [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling] - Ryan King dispells common misconceptions about the ''HTML'' class attribute.<br />
<br />
<br />
== <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> semantics ==<br />
<br />
===''Q. Is it semantically meaningless to use divs?'' ===<br />
<br />
A. Yes, both <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> have nearly no semantics. <code>&lt;div&gt;</code> can be used to represent a "division" of the page content. Similarly <code>&lt;span&gt;</code> can be used to reperesent that that "span" of text has some meaning, but the specifics of what that meaning is undefined by the <code>&lt;span&gt;</code>.<br />
<br />
<br />
===''Q. Does the use of <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> elements add any semantics to web pages?''===<br />
<br />
A. According to the [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.4 HTML 4 spec], <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> "offer a generic mechanism for adding structure to documents." Their only meaning is in dividing documents into sections, and as such, their presence implies that the content within has a specific, but undefined by the element markup, semantic. Thus they are nearly semantic-free.<br />
<br />
===''Q. Why do the examples on the wiki use <code class="element">&lt;span&gt;</code> and <code class="element">&lt;div&gt;</code> for nearly everything?''===<br />
<br />
A. <code class="element">&lt;span&gt;</code> and <code class="element">&lt;div&gt;</code> are generic elements in HTML. When you use microformats, you should pick the most specific semantic element available for the semantics you are trying to express. You might, for example, apply <code>class="vevent"</code> to a <code><nowiki><tr></nowiki></code>, or <code>class="vcard"</code> to a <code><nowiki><p></nowiki></code>.<br />
<br />
== Class semantics ==<br />
<br />
===Q. ''How will microformat class names impact page size?''===<br />
<br />
A. You probably won't notice any impact on page size when authoring with microformats. Our experience is that people use comparably sized class names, and [[semantic-class-names|semantic class names]] are now considered an industry best practice. Some sites are successfully publishing millions of microformats, and we haven't heard any complaints yet. You are more likely to gain space savings by more fully adopting [[microformats#the_microformats_principles|the principles of microformats]], and eliminating tables for layout.<br />
<span class="todo">''TODO: Consider creating a new section for web authoring tips? Or at least linking to another site that advocates good authorship.''</span><br />
<br />
===Q. ''Can an element have more than one class''===<br />
<br />
A. Yes, the class attribute can contain a space delimited list of classes. For example:<br />
&lt;p class=&quot;todo idea&quot;&gt;Write high quality and simple mark-up.&lt;/p&gt;<br />
<br />
See W3C HTML 4.01 Specification: [http://www.w3.org/TR/html401/struct/global.html#adef-class 7.5.2 Element identifiers: the id and class attributes]<br />
<br />
===Q. ''Do (X)HTML class names have semantics?''===<br />
<br />
A. The HTML4 specification does not define any particular class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], nor does it define any particular semantic for class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], except that they "may be used for general user agent processing" [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF]. However, the [http://www.w3.org/TR/WD-htmllink-970328#profile" draft of "Hypertext Links in HTML"], allows for a "profile" to define meanings for those classes. [http://gmpg.org/xmdp/ XMDP] is a format for defining meta data profiles for (X)HTML, and thus an XMDP profile can be used to define the meanings of class names. <br />
<br />
See also:<br />
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]<br />
* [http://www.w3.org/TR/WD-htmllink-970328 Hypertext Links in HTML]<br />
<br />
===Q. ''I thought one of the main goals of CSS was to separate data from presentation. Isn’t this sneaking presentation back into data?''===<br />
<br />
A. This is a quite commonly expressed objection to the way microformats uses class, but it's based on a misunderstanding of the way the class attribute in HTML was designed. Yes, class is very commonly,and appropriately used by web designers in conjunction with CSS to style pages, and in truth, it is often overused for that, but despite this, class, according to the HTML specification "has several roles in HTML", including [http://www.w3.org/TR/html4/struct/global.html#h-7.5.2 "for general purpose processing by user agents"].<br />
<br />
Microformats utilize this second aspect of the class (and id) attribute, and do so legitimately. It is not an abuse of the class or id attribute to use it to add semantic context to a document. Nor is the use of class in and of itself presentational - in fact, it is an important mechanism for separating presentation from structured content. <br />
<br />
For some more on using class semantically, here are some articles<br />
<br />
* [http://meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competent Classing by Eric Meyer]<br />
* [http://www.w3.org/QA/Tips/goodclassnames Use class with semantics in mind, W3C]<br />
* [http://tantek.com/log/2004/07.html#d20t2359 More about the class attribute, Tantek Çelik]<br />
<br />
== Microformats and Spam ==<br />
===''Q. Given that Google now looks at hidden content as potential spam, will invisible microformats be considered spam?''===<br />
<br />
A. It is advisable not to hide information in your site, regardless of whether it is microformated or not. Microformats provide a mechanism for marking up ''visible'' content. Any mechanism for embedding ''invisible'' or hidden content risks being considered spam due to the fact that invisible (meta)data inevitably ends up being abused. Avoid invisible (meta)data. Publish visible data.<br />
<br />
== Design Patterns with Abbr &amp; Title ==<br />
===''Q. Why is ABBR being used when the title attribute is available on all HTML elements?''===<br />
<br />
In the datetime design pattern the title attribute is used for the value of the property and the node value is used as the display value. &lt;abbr title="value-here"&gt;Display-Here&lt;/abbr&gt;. <br />
<br />
A. The short answer is that &lt;abbr&gt; has the correct semantics.<br />
<br />
The longer answer is that the value is often an abbreviated version of the formal value. Of course, if you don't want to use an &lt;abbr&gt;, you can use another element like this:<br />
<br />
&lt;abbr title="2006-12-31T12:59:59Z" class="dtstamp"&gt;New Year&lt;/abbr&gt;<br />
<br />
&lt;span class="dtstamp"&gt;2006-12-31T12:59:59Z&lt;/span&gt;<br />
<br />
In addition, microformats encourage the content to be visible and thus prefer the text of an element rather than using the 'title' attribute or any other less visible alternative. The exception is made for datetimes and abbr due to the fact that microformats are for humans first, machines second. Thus the content of the abbr element is used to provide human visible content and the machine equivalent is placed in the less visible (but still easily verifiable) 'title' attribute.<br />
<br />
== Nesting of elements ==<br />
===''Q. It seems that <code>&lt;span class=&quot;vcard fn org&quot; id=&quot;club&quot;&gt;...&lt;/span&gt;</code> should work. Is this correct?''===<br />
<br />
A. No. See [http://microformats.org/wiki/hcard-faq#nesting-properties]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=faq&diff=16456faq2007-05-06T15:14:28Z<p>ScottReynen: New FAQ: What if I can't find real-world examples of a standard I'd like to propose?</p>
<hr />
<div><h1> Microformats FAQ </h1><br />
<br />
This page document frequently asked questions about microformats. For frequently asked questions from the [[press]], see [[press-faq]].<br />
<br />
If you're looking for a microformat for marking up FAQs, see [[question-answer]].<br />
<br />
__TOC__<br />
<br />
== Wiki specific questions ==<br />
===Q: ''How do I create a username? Why won't it let me use my preferred username?''===<br />
<br />
A: First, read this: http://en.wikipedia.org/wiki/Wikipedia:Username . Second, real names are preferred to pseudonyms/handles etc. Real names encourage better transparency and accountability. Third, the most common problem creating a user name is forgetting to capitalize the first letter of the user name. Try using a WikiCase version of your full name as username, e.g. RyanKing.<br />
<br />
== Email list ==<br />
===Q: ''I've joined the discussion mailing list but am not seeing my replies anywhere. Why?''===<br />
<br />
A: There is no moderation on microformats-discuss, but it only accepts posts from subscribers. You MUST post to microformats-discuss using the email address you used to subscribe.<br />
<br />
===Q: ''What does "The message's content type was not explicitly allowed" mean?'' ===<br />
<br />
A: Please go read [http://microformats.org/mailinglists-policies/ mailinglists-policies]. In particular note:<br />
<blockquote><br />
'''No HTML or RTF e-mail''' period, end of story, full stop. Your mail client should let you configure it so you can send plain text messages. Make use of this ability or else there are no guarantees that anyone will be able to read your email.<br />
</blockquote><br />
The mailing lists are set up to automatically reject email that is sent as text/html. Thus please configure your email client to send plain text (text/plain) email.<br />
<br />
== Basic Microformat Questions ==<br />
===Q: What does ''xxx'' mean?"===<br />
<br />
A: See our [[glossary]].<br />
<br />
===Q: ''When should I use a microformat? What are they for?"===<br />
<br />
A: You are writing some HTML that contains useful human-readable information (such as a piece of contact information). You say to yourself: I would like to mark this up with some classes now for styling. You look up the relevant microformat, and you<br />
pull in the standard names. You don't have to make your own up, and now your page is machine-readable too. Bonus!<br />
<br />
Microformats are designed to make the data you already publish for humans available to machines. It allows applications as simple as cut-and-paste or as complex as a seach engine to use your data effectively.<br />
<br />
===Q: ''Are microformats dependent upon (X)HTML?''===<br />
<br />
A: Microformats are made to be embeddable. They can be embedded in (X)HTML, RSS, Atom or anywhere (X)HTML is allowed.<br />
<br />
<br />
===Q: ''Microformats sound great. How can I help?''===<br />
<br />
A: Take a look at http://microformats.org/discuss to see some ways to join the conversations about microformats, and the [[to-do]] list for things to help out with.<br />
<br />
<br />
===Q: ''I'd like to make a donation to the microformat cause. How can I do this?''===<br />
<br />
A: Thank you for your willingness to support microformats. We've only recently started this site and have decided that while we are figuring out exactly how to accept donations, we will be passing along donations to other good causes. Please consider donating to another cause like Red Cross, perhaps directed to help victims of recent natural disasters.<br />
<br />
<br />
===Q: ''Which microformats have been implemented?'' ===<br />
<br />
A: See the [[implementations]] page.<br />
<br />
<br />
===Q: ''Which microformats should I implement?''===<br />
<br />
A: Chances are you that your website already has data very similar to several microformats. For example, you probably have people and/or their contact information somewhere. That information could be marked up with [[hcard|hCard]], see the [[hcard-authoring|hCard authoring]] page for step by step instructions. If you are publishing press releases, try using [[hatom|hAtom]].<br />
<br />
<br />
===Q: ''Do you have any link badges I can add to my website/blog?''===<br />
<br />
A: There are some [[buttons]] but we can certainly use more! Please contribute what you come up with!<br />
<br />
<br />
===Q. ''Are there any tools that support microformats?''===<br />
<br />
A. Yes...tons... [[implementations]].<br />
<br />
===Q. Is there a way to indicate that a given web page contains markup that conforms to one or more microformats? ===<br />
<br />
A. The HTML HEAD element's '<code>profile</code>' attribute alerts applications to the potential presence of microformats. The [http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.4.4.3 W3C HTML Specification] describes more about the profile attribute, and the [http://gmpg.org/xmdp/description XMDP description] documents how it is used.<br />
<br />
===Q. ''What about using new URI schemes instead of class names, e.g. for geo information?''===<br />
<br />
A. In general, it is more work, and less content-publisher friendly, to ask publishers to use URI schemes instead of class names.<br />
<br />
Authors aren't publishing links to geo information.<br />
<br />
They're publishing *visible text* of [[geo]] information.<br />
<br />
So the easiest thing to do, for the author, is to leave it as visible text.<br />
<br />
Thus, it makes the most sense to do the simple thing of just wrapping that<br />
visible text with a little bit of markup, rather than asking the author to<br />
move (or copy) it into an attribute, which may or may not require a<br />
reformatting of the data as well.<br />
<br />
It would make sense from a usability persepective to hyperlink geo information to a maps page or something, so that clicking it actually does something. If you forced them to use a hypothetical "geo:" protocol instead, then that would interfere, since you can only hyperlink something to one destination.<br />
<br />
<br />
===Q: ''Who controls microformats?''===<br />
<br />
A: An open community. Microformats are open standards licensed under Creative Commons Attribution. Much of the work here was begun on [http://developers.technorati.com/wiki Technorati's Developer Wiki], but Technorati has since divested control of these microformat standards to the open community here. The microformats.org domain is registered to Rohit Khare (see [http://whois.uberdose.com/microformats.org Whois microformats.org]), CommerceNet is graciously hosting the servers, but claims no control over microformat standards. Anyone may follow the established [[process]] and contribute towards the development of microformat standards.<br />
<br />
Any required [[governance]] of the microformats IRC channel, wiki, and mailing lists (and very little ''has been'' required) is discussed by a group of volunteer administrators, who are listed on that page.<br />
<br />
===Q: ''Who is the registrar for microformats?''===<br />
<br />
A: There is no central registry. Microformats are registered in a distributed manner using profiles. For more information on profiles see http://microformats.org/wiki/profile-uris and http://gmpg.org/xmdp/<br />
<br />
Conflicts and interoperability are managed through social processes rather than a formal registry. Current microformat profiles can be found at http://gmpg.org, http://w3.org, and http://microformats.org.<br />
<br />
<br />
===Q: ''So multiple microformats with the same name can be valid?''===<br />
<br />
A: Yes. The community at microformats.org can hopefully play a role in determining which is preferred by bringing interested folks together in one place and helping them resolve that question. As long as each microformat maintains a valid profile, each can be used effectively.<br />
<br />
<br />
===Q: ''How do I validate my microformated content?''===<br />
<br />
A: Currently there is no automatic general-purpose validator for microformats (See [[to-do#for_all_microformats|To Do - for all microformats]]). There are however some microformat-specific tools listed on the [[implementations]] page which can help with validation. [https://addons.mozilla.org/firefox/4106/ Operator] does a good job of compliant parsing for microformats in general. For [[hcard|hCard]], try the [http://feeds.technorati.com/contacts/ Technorati Contacts Feed service]. For [[hcalendar|hCalendar]], try the [http://feeds.technorati.com/events/ Technorati Events Feed service]. Also, posting your examples to the [http://microformats.org/discuss microformats-discuss mailing list], and adding them to the respective examples/implementations sections/pages will very often get folks from the community to review and validate them for you.<br />
<br />
===Q: ''How do microformats breach language barriers?===<br />
'''Would we have to "force" non-English speaking web page developers to use something like class="name" (as opposed to "namen" or "nom") for their productions to be properly indexed by agents?'''<br />
<br />
A: Yes, but that's no different to using English words like "class", "span" or "head". This was briefly discussed on the microformats-discuss list most recently as "Language Maps" but has been raised before that. Some folks have raised the issue that microformats use English names for properties, and they would like alternate (non-English) names in other (natural) languages, and perhaps try to establish a mapping between them. As microformats property names are based on existing standards (see [[process]], and [[naming-principles]]), this is another problem that is far outside the scope of microformats. As Ryan King put it, this is a pre-existing (unsolved) "problem" with English-based HTML, the English-based CSS, the English-based HTTP and so on. Note that this is NOT about the internationalization of the content and data itself - which is of course an excellent goal, advocated and promoted by microformats and the standards they are based on (e.g. W3C, IETF). This is purely about the names of the properties (and enumerated values) in the formats. See also [[internationalization]].<br />
<br />
===Q: ''How come microformats sometimes to linger as Drafts even though they seem usable?'' ===<br />
<br />
A: [http://microformats.org/wiki/faq#Q:_Who_controls_microformats.3F Tantek] went over this at the recent [http://2007.sxsw.com/interactive/programming/panels/?action=show&id=IAP060234 The Growth and Evolution of Microformats] panel at [http://en.wikipedia.org/wiki/South_by_Southwest SXSW]. He conveyed that it was important to have a basic software implementation -- even an experimental one -- before moving a format from Draft to Specification. It can sometimes be hard to recognize subtle inconsistencies within a format by eye; however, in the process of implementing a format-reader in code, inconsistencies (if any) can become much more noticeable (due to [[dry | DRY / Don't Repeat Yourself]], among other programming best practices). Then, once such a tool has been created (in effect, confirming the programmability of the format), it can be transitioned to a Specification (so as to encourage other machine-based implementations).<br />
<br />
== Creating and Suggesting New Microformats ==<br />
<br />
===Q. ''I would like to author a new microformats open standards specification for my site/business. How do I get started?''===<br />
<br />
A. The first thing to do before attempting a new microformat open standard is to make as much use of existing [[microformats]] open standards as possible in whatever site you are looking to mark up with your new microformat, as a way of learning what is left to be done. That is, at a minimum first:<br />
* Mark up all people and organizations as [[hcard|hCards]].<br />
* Mark up all events and time based things as [[hcalendar|hCalendar]] events.<br />
* Mark up all reviews as [[hreview|hReviews]].<br />
* etc.<br />
Then join the microformats [http://microformats.org/discuss discuss list], and ask folks what they think of your use of the microformats and if it can be improved.<br />
<br />
From that experience you will then be able to figure out what is left to be specified. Otherwise it is too hard to approach the "whole problem".<br />
<br />
Once you have completed that, take a look at the microformats [[process]] for how to walk through the steps of creating a new microformat, and note the specific problem you are trying to solve to the microformats-discuss list. This will help you find more people to help you solve the problems you are trying to solve.<br />
<br />
===Q. ''What if I can't find real-world examples of a standard I'd like to propose?''===<br />
<br />
A. If we can't find real-world examples of the '''types of data''' a proposal would address, it's probably not suitable for a microformat. If we only can't find real-world examples of the '''specific markup''' a proposal would use for that data, however, that's not really a problem. It's actually the lack of such standard markup in real-world publishing around a specific problem that suggests the need for increased consensus.<br />
<br />
===''Q How do I know if an idea for a Microformat has already been suggested in the past?''===<br />
<br />
A. Check the list of proposed and rejected microformats. <br />
* [[rejected-formats]]<br />
<br />
== Specific Microformat Questions ==<br />
If you have a question regarding a specific microformat, you may want to check the FAQ specific to that microformat.<br />
* [[hatom-faq]]<br />
* [[hcalendar-faq]]<br />
* [[hcard-faq]]<br />
* [[hreview-faq]]<br />
* [[rel-faq]]<br />
* [[rel-tag-faq]]<br />
* [http://gmpg.org/xfn/faq xfn-faq]<br />
* [[xfolk-faq]]<br />
* [[xmdp-faq]]<br />
* [[xoxo-faq]]<br />
<br />
== Class interactions ==<br />
<br />
===Q. ''Are there issues with page styling when specific class values are used?''===<br />
<br />
A. There might be. However, any such issues can be easily (trivially) worked around by using contextual selectors.<br />
<br />
<br />
===Q. ''How does the use of class values for semantics interact with the use of class values for attaching CSS styles?''===<br />
<br />
A. The class attribute takes a space separated set of class names [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 HTML4 reference]. Thus both author and microformat defined class names may be used in the same class attribute. In addition, microformat class names provide the author with a consistent set of class names to use for styling. If the author is already using using specific class names, they can continue to do so, and include microformat class names. If the author is already using a class name that happens to also be a microformat class name, then the author may want to consider using contextual CSS class selectors to make sure that avoid any unintentional styling effects.<br />
<br />
See also: <br />
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]<br />
* [http://tantek.com/log/2004/07.html#classmeaningnotshow Class For Meaning Not For Show]<br />
* [http://www.meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competant Classing], by Eric Meyer for discussion of choosing class names in (X)HTML<br />
* [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling] - Ryan King dispells common misconceptions about the ''HTML'' class attribute.<br />
<br />
<br />
== <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> semantics ==<br />
<br />
===''Q. Is it semantically meaningless to use divs?'' ===<br />
<br />
A. Yes, both <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> have nearly no semantics. <code>&lt;div&gt;</code> can be used to represent a "division" of the page content. Similarly <code>&lt;span&gt;</code> can be used to reperesent that that "span" of text has some meaning, but the specifics of what that meaning is undefined by the <code>&lt;span&gt;</code>.<br />
<br />
<br />
===''Q. Does the use of <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> elements add any semantics to web pages?''===<br />
<br />
A. According to the [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.4 HTML 4 spec], <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> "offer a generic mechanism for adding structure to documents." Their only meaning is in dividing documents into sections, and as such, their presence implies that the content within has a specific, but undefined by the element markup, semantic. Thus they are nearly semantic-free.<br />
<br />
===''Q. Why do the examples on the wiki use <code class="element">&lt;span&gt;</code> and <code class="element">&lt;div&gt;</code> for nearly everything?''===<br />
<br />
A. <code class="element">&lt;span&gt;</code> and <code class="element">&lt;div&gt;</code> are generic elements in HTML. When you use microformats, you should pick the most specific semantic element available for the semantics you are trying to express. You might, for example, apply <code>class="vevent"</code> to a <code><nowiki><tr></nowiki></code>, or <code>class="vcard"</code> to a <code><nowiki><p></nowiki></code>.<br />
<br />
== Class semantics ==<br />
<br />
===Q. ''How will microformat class names impact page size?''===<br />
<br />
A. You probably won't notice any impact on page size when authoring with microformats. Our experience is that people use comparably sized class names, and [[semantic-class-names|semantic class names]] are now considered an industry best practice. Some sites are successfully publishing millions of microformats, and we haven't heard any complaints yet. You are more likely to gain space savings by more fully adopting [[microformats#the_microformats_principles|the principles of microformats]], and eliminating tables for layout.<br />
<span class="todo">''TODO: Consider creating a new section for web authoring tips? Or at least linking to another site that advocates good authorship.''</span><br />
<br />
===Q. ''Can an element have more than one class''===<br />
<br />
A. Yes, the class attribute can contain a space delimited list of classes. For example:<br />
&lt;p class=&quot;todo idea&quot;&gt;Write high quality and simple mark-up.&lt;/p&gt;<br />
<br />
See W3C HTML 4.01 Specification: [http://www.w3.org/TR/html401/struct/global.html#adef-class 7.5.2 Element identifiers: the id and class attributes]<br />
<br />
===Q. ''Do (X)HTML class names have semantics?''===<br />
<br />
A. The HTML4 specification does not define any particular class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], nor does it define any particular semantic for class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], except that they "may be used for general user agent processing" [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF]. However, the [http://www.w3.org/TR/WD-htmllink-970328#profile" draft of "Hypertext Links in HTML"], allows for a "profile" to define meanings for those classes. [http://gmpg.org/xmdp/ XMDP] is a format for defining meta data profiles for (X)HTML, and thus an XMDP profile can be used to define the meanings of class names. <br />
<br />
See also:<br />
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]<br />
* [http://www.w3.org/TR/WD-htmllink-970328 Hypertext Links in HTML]<br />
<br />
===Q. ''I thought one of the main goals of CSS was to separate data from presentation. Isn’t this sneaking presentation back into data?''===<br />
<br />
A. This is a quite commonly expressed objection to the way microformats uses class, but it's based on a misunderstanding of the way the class attribute in HTML was designed. Yes, class is very commonly,and appropriately used by web designers in conjunction with CSS to style pages, and in truth, it is often overused for that, but despite this, class, according to the HTML specification "has several roles in HTML", including [http://www.w3.org/TR/html4/struct/global.html#h-7.5.2 "for general purpose processing by user agents"].<br />
<br />
Microformats utilize this second aspect of the class (and id) attribute, and do so legitimately. It is not an abuse of the class or id attribute to use it to add semantic context to a document. Nor is the use of class in and of itself presentational - in fact, it is an important mechanism for separating presentation from structured content. <br />
<br />
For some more on using class semantically, here are some articles<br />
<br />
* [http://meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competent Classing by Eric Meyer]<br />
* [http://www.w3.org/QA/Tips/goodclassnames Use class with semantics in mind, W3C]<br />
* [http://tantek.com/log/2004/07.html#d20t2359 More about the class attribute, Tantek Çelik]<br />
<br />
== Microformats and Spam ==<br />
===''Q. Given that Google now looks at hidden content as potential spam, will invisible microformats be considered spam?''===<br />
<br />
A. It is advisable not to hide information in your site, regardless of whether it is microformated or not. Microformats provide a mechanism for marking up ''visible'' content. Any mechanism for embedding ''invisible'' or hidden content risks being considered spam due to the fact that invisible (meta)data inevitably ends up being abused. Avoid invisible (meta)data. Publish visible data.<br />
<br />
== Design Patterns with Abbr &amp; Title ==<br />
===''Q. Why is ABBR being used when the title attribute is available on all HTML elements?''===<br />
<br />
In the datetime design pattern the title attribute is used for the value of the property and the node value is used as the display value. &lt;abbr title="value-here"&gt;Display-Here&lt;/abbr&gt;. <br />
<br />
A. The short answer is that &lt;abbr&gt; has the correct semantics.<br />
<br />
The longer answer is that the value is often an abbreviated version of the formal value. Of course, if you don't want to use an &lt;abbr&gt;, you can use another element like this:<br />
<br />
&lt;abbr title="2006-12-31T12:59:59Z" class="dtstamp"&gt;New Year&lt;/abbr&gt;<br />
<br />
&lt;span class="dtstamp"&gt;2006-12-31T12:59:59Z&lt;/span&gt;<br />
<br />
In addition, microformats encourage the content to be visible and thus prefer the text of an element rather than using the 'title' attribute or any other less visible alternative. The exception is made for datetimes and abbr due to the fact that microformats are for humans first, machines second. Thus the content of the abbr element is used to provide human visible content and the machine equivalent is placed in the less visible (but still easily verifiable) 'title' attribute.<br />
<br />
== Nesting of elements ==<br />
===''Q. It seems that <code>&lt;span class=&quot;vcard fn org&quot; id=&quot;club&quot;&gt;...&lt;/span&gt;</code> should work. Is this correct?''===<br />
<br />
A. No. See [http://microformats.org/wiki/hcard-faq#nesting-properties]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=hlisting-feedback&diff=16223hlisting-feedback2007-04-18T03:52:05Z<p>ScottReynen: /* Listing Action */</p>
<hr />
<div>== Schema Issues ==<br />
<br />
=== Item ===<br />
<br />
* is class="item" a part of the spec? It is not clear from the highlight in the proposal.<br />
* if it is, is it optional (as in the [[hlisting-proposal#Schema|schema]]) or required (as implied by the item [[hlisting-proposal#Item_Metadata|item metadata]] section). My feeling is that it should be required<br />
<br />
-- [[DavidJanes]] 2006-11-18<br />
<br />
=== Listing Action ===<br />
<br />
* "listing action" is another one that confuses me, is that two words, one word "listing-action" or just a tag with some of the recommended values... it is required, but i don't see it in action on edgeio.com or Dealtagger<br />
<br />
-- [[BrianSuda]] 2006-11-18<br />
<br />
* I think the listing action semantics are all wrong. Actions should not be hidden in class attributes. These are not classes of data. The class of data is "listing-action". The action itself is content. I think <nowiki><span class="offer rent">for rent</span></nowiki> should be more like <nowiki><abbr title="offer" class="listing-action">for</abbr> <span class="listing-aciton">rent</span></nowiki> [[User:ScottReynen|ScottReynen]] 20:52, 17 Apr 2007 (PDT)<br />
<br />
=== Make Info/Photo fields Optional ===<br />
<br />
WordPress has a great WYSIWYG editor that lets you drag & drop images. <br />
But the only semantic identification it uses is the HTML <img> element. <br />
So how do we get a photo to be identified from all the images inside the description?<br />
<br />
1. Manually edit the HTML that WordPress creates to add the class.<br />
2. Add another UI doubling the one already used by WordPress, sans drag & drop, strictly for images designated as photos.<br />
3. Tag every single image as photo.<br />
4. Have the crawler interpret every single image as photo.<br />
<br />
I'm not sure we want to push the complexity to the edge, that's like asking people to create only valid XHTML pages and not rendering anything that refuses to validate. This is about humans first, machines second. If complexity needs to exist, it should be not in the blog, but in the crawlers.<br />
<br />
-- Assaf Arkin<br />
<br />
== Default Action ==<br />
I think it's good form to have a default for every required field, since someone out there is going to drop any given requried field in the land of microformats. In that spirit, the default for listing type is offer, since wanted ads are << 10% in the real world. What I don't know is what the default action should be; the most neutral of them is ''announce'', which I am using in my parser.<br />
<br />
-- Rohit<br />
<br />
== Donations ==<br />
<br />
Sell and Rent are obvious enough verbs; what does Trade mean, though? Barter? And what about one-sided gifts, like donations or "free to recycle"? Should we replace Trade and offer Donate in its place?<br />
<br />
-- Rohit<br />
<br />
== Desire to Inherit Context ==<br />
<br />
When it comes to blog posting, I’d like to see us address the following:<br />
<br />
1. '''Less is more'''. Or in reverse, people are lazy, and the less fields they need to fill in order to sell a couch or find a date, the more they'll use the plugin. So I'm trying to visualize how this plays in with the user interface and how we can keep it as simple as possible.<br />
<br />
2. '''DRY'''. We want to capture as much information as possible from what is already available in the blog post. We already have summary (title), listing date/time (post date/time), permalink, author information, tags/categories.<br />
<br />
3. '''Keep it simple'''. And here I'm talking about setup and being able to extend your blog's functionality without too much fuss. This one is a bit more tricky, so I'll go into details.<br />
<br />
WordPress uses templates to render the blog post. The template then calls the WordPress API to render the title, a second call to render the content, and another call to render any additional metadata (e.g. <br />
publish date, categories, author). These separate calls allow people to play with the formatting and apply any styling they like.<br />
<br />
The way uPress works, is by processing the blog post before it goes back to the filter, creating the hEvent (to be: hListing) element around it, and adding any relevant fields into the blog post. So what you fill in the form, finds its way to the post content. As a result, setting up the plugin requires two steps: drop it to the plugins directory, and activate.<br />
<br />
Unfortunately, I only get to process the content of the post. I can't easily include the title inside the hListing element, or any other metadata about the post, even though I have access to it. If I duplicate that information, the post stops being readable. And to wrap the entire post (not just body) inside a microformat element, I need to tweak the template. Except people use different templates, and I can't tweak all of them.<br />
<br />
So the more context we use, the better the plugin becomes.<br />
<br />
-- Assaf Arkin<br />
<br />
<br />
<br />
== '''On hReview''' ==<br />
<br />
This draft was heavily influenced by hReview. That's a good thing. We don’t want to duplicate efforts; are learning from the mistakes of others; and converging on a cohesive set of specifications. I want to eventually add hReview and hCard to my plugin. So this strategy of borrowing from existing microformats helps me get it done quicker. It took me all of five minutes to leverage address formatting from hEvent.<br />
<br />
But we also need to recognize that hReview could also be more blogging friendly. The specification is great, but the implementations are lacking. I think the reason is that hReview was designed for greenfield applications that specifically deal with emitting reviews. The design did not take into consideration applications that already deal with content, but want to supplement it with reviews, listings, etc. There's no mention of such consideration in the spec.<br />
<br />
We want to appeal to the wide populace of bloggers who just want to get stuff done. Rather than put the burden on millions of bloggers out there, we should place the burden on the few companies developing crawlers.<br />
<br />
What would Tantek say? I think he'd ask us to focus on use cases, real examples. I'm presenting one such example. The use case involves a blogger who just wants to sell something on their blog, with the minimum amount of effort and cognitive friction. They want the listing to be discovered, aggregated and searched by others.<br />
<br />
-- Assaf Arkin<br />
<br />
<br />
== '''Neighborhood Name''' ==<br />
<br />
With the exception of housing, most classified listings don’t contain a specific address (e.g., if I’m selling my couch, you don’t need to know where I live in the listing). Some location information, however, is important. In most suburban areas, the name of the town is sufficient. In cities, however, neighborhood is important and more contextually relevant than zipcode (simply a region defined by the post office).<br />
<br />
This is a tough problem that needs to be solved but outside the context of this discussion. We think there are other cases the could benefit from it, including hReview and hEvent. We recommend that this debate be surface in the adr microformation discussion (e.g., perhaps extend the locality field (city) to optionally include a neighborhood)<br />
<br />
-- Craig Donato & Assaf Arkin<br />
<br />
<br />
<br />
== '''Listing Action, Listing Type, Item Type''' ==<br />
<br />
We heavily debated how to classify a listing. Search engines or marketplaces typically need to understand what type of listing it is (e.g., personal ad, house for sale, music) to effectively reference or index a listing. <br />
<br />
We initially considered proposing a single category field that contained tags (in addition to the tags field). Not only did this seem duplicative, it also seemed like too much of a good thing. In a previous project, Assaf managed to successfully overload everything into tags (including dates and locations), and run time-based and location-based searches, and ended up concluding it's a bad idea.<br />
<br />
We eventually decided to propose the use three parametric field that when used together could define any type of listing independent of the words use to describe. These ended up being: listing-type (are you offering something or looking for something; listing-action (are you trying to sell, rent, or announce something); and item type (what item is referenced by the action such as a job opening, product, housing). By making small modifications to this vocabulary, users can specify an extremely wide range of potential transactions. This seemed more feasible given that the UI used to produce the hListing could abstract some of this from the user (as Assaf demonstrated in his demo plugin).<br />
<br />
For example:<br />
<br />
{|<br />
!Desired Transaction<br />
!Listing Type<br />
!Listing Action<br />
!Item Type<br />
|-<br />
|Merchandise For Sale<br />
|Offer<br />
|Sell<br />
|Product<br />
|-<br />
|Looking to Buy Merchandise<br />
|Wanted<br />
|Sell<br />
|Product<br />
|-<br />
|Selling Tickets<br />
|Offer<br />
|Sell<br />
|Event<br />
|-<br />
|Apartment For Rent<br />
|Offer<br />
|Rent<br />
|Housing<br />
|-<br />
|Looking for Apartment<br />
|Wanted<br />
|Rent<br />
|Housing<br />
|-<br />
|Room for Rent (Roommate)<br />
|Offer<br />
|Rent<br />
|Housing<br />
|-<br />
|Looking for a Date<br />
|Offer||Wanted<br />
|Announce, Meet<br />
|-<br />
|Job Opening<br />
|Offer<br />
|Announce<br />
|Opening<br />
|-<br />
|Looking for a Job (Resume)<br />
|Wanted<br />
|Announce<br />
|Opening<br />
|-<br />
|Music Lessons<br />
|Offer<br />
|Service<br />
|Business<br />
|-<br />
|Trade Couch for TV<br />
|Offer<br />
|Trade<br />
|Product<br />
|-<br />
|Pet for Adoption<br />
|Offer<br />
|Announce<br />
|Animal?<br />
|}<br />
-- Craig Donato<br />
<br />
== Vertical ==<br />
Adding "vertical" to the schema would take this idea a lot further and would add enough flexibility to kill off the need for further formats like hJob etc. Specific verticals could be set (jobs, real estate, rentals, auto, other) with additional fields added as subsets of each vertical. <br />
<br />
* vertical: rentals<br />
* listing type: offer<br />
* item type: house (vs. appartment)<br />
* listing action: rent<br />
<br />
-- [[User:AaronMentele|Aaron Mentele]] (2006-12-26)<br />
<br />
== Eliminate Item Type ==<br />
<br />
Can we eliminate item type and simply use tags? Or perhaps inferred item type from the item info?<br />
<br />
== hClassified? ==<br />
<br />
There are meanings of "listing" that wouldn't fit this format.. might not hClassified be a more descriptive name? It's not overconstraining... 'classifieds' being very broad in practice and the meaning very informally/functionally defined. Or has the 'listing' train left the station? <br />
<br />
== What about retail? == <br />
<br />
Retail is out of scope for hListing, sure -- but what microformat should a retail seller of (e.g. mass-produced) goods use? hForSale? hProduct?<br />
<br />
== Retail ==<br />
<br />
Funnily enough, hProduct is always something that I've thought about.<br />
<br />
I'd be bold enough to say that it will be one of the main uses of microformats in the future. Imagine the amount of shops, price comparison, product review and many more type of sites. It doesn't have to be for profit, it could just be someones product, on their site, that they are displaying.<br />
<br />
I'd be willing to help and continue development of a spec for 'hProduct'.<br />
<br />
Adam Craven<br />
<br />
<br />
== Thubnail Class ==<br />
Hello. I'm not sure I understand everything correctly, but from reading the hListing proposal it seems that one should put pictures of the listed subject into the "photo" class. I'm wondering if also we may wish to have a "thumnail" class or perhaps something like "photo-thumbnail" to denote thumbnail images.<br />
-Andrew<br />
<br />
<br />
== Validator ==<br />
Perhaps to foster development of this type, someone (who knows a lot more about microformats than I) should put a validator type page out there. I realize that microformats, by their nature are a loose specification (it's not as strict as validating say an XML rss feed). But having something that I can use to at least verify that what I'm coding is actually recognized as an hListing by someone other than myself would be very helpful.<br />
-Andrew<br />
<br />
<br />
Blogmatrix have added hListing to their microformats parser [http://tools.blogmatrix.com/extract/ here]<br />
-d4rr3ll<br />
<br />
== Extraction of hProduct ==<br />
<br />
I think it would be wise to extract product information into [[hproduct|hProduct]] and simply maintain the listing for listing-specific data (such as actual price/suggested price, location, timeframe, etc.).<br />
<br />
Also, regarding price, I think going with the currency microformat makes sense, but I also think there should be specifics around the type of price being shown. For instance, there is a MSRP which is tied to the product (and ''should'' be in hProduct), then there is the asking price (or in the case of cars, the dealer invoice, sticker price, etc.). Perhaps going the route of<br />
<br />
<pre><nowiki><p class="price actual money"><br />
<abbr class="currency" title="USD">$</abbr>3.00<br />
</p></nowiki></pre><br />
<br />
would make more sense?<br />
- Aaron Gustafson<br />
<br />
<br />
== Use for Microphilanthropy and Volunteer listings ==<br />
<br />
Adding 'Donate', as Rohit suggested, would open up hListing for use by microphilanthropy sites like www.Kiva.org or www.DonorsChoose.org (I work there.) See here for an example of one of our listings:<br />
<br />
http://www.donorschoose.org/donors/proposal.html?id=64964<br />
<br />
So an organization seeking a donation would format it Listing Type: Wanted, Listing Action: Donate, Listing Item: Cash<br />
<br />
Someone looking to donate an old PC would format it Listing Type: Offer, Listing Action: Donate, Listing Item: Product<br />
<br />
An organization trying to find a volunteer would have Listing Type: Wanted, Listing Action: Donate, Listing Item: Service<br />
<br />
Note that some organizations (like Kiva) are doing microloans, instead of microphilanthropy. So in addition to Sell, Rent, Trade, Meet, Announce, and Donate, "Loan" would be useful as a Listing Action. (Could also be useful for facilitating borrowing relationships of items.)<br />
<br />
One other addition to hListing that might be useful in this context is Cost. In a commercial setting (say, you're trying to sell a used item on eBay), Cost would represent what you paid for the item. So Price - Cost would get you the markup (or markdown). In a philanthropic context, Cost would represent the cost to make a project happen. If the project were already partially funded, then Price < Cost, and Price / Cost would give you the % remaining to completely fund that project. (Many microphilanthropy sites bundle lots of donations to make up one project.)<br />
<br />
-- Mike Everett-Lane</div>ScottReynenhttps://microformats.org/wiki/index.php?title=adr-poll&diff=15455adr-poll2007-04-11T01:39:06Z<p>ScottReynen: /* General comments */</p>
<hr />
<div>=Change to adr spec=<br />
<br />
Further to discussion at [[hcard-brainstorming#ADR with no children]], it is proposed to amend the [[adr]] spec, and the corresponding part of the hCard spec, thus:<br />
<br />
<blockquote><br />
Where the <code>adr</code> has content, but no valid sub-properties, parsers ['''MAY | SHOULD | MUST'''] output the content of that <code>adr</code> as a single vCard ['''output-field'''] field.<br />
</blockquote><br />
<br />
Please indicate you support or objections preferred wording and choice of output-field, below, using an asterisk and three tildes (<nowiki>* ~~~</nowiki>), followed by any comments. Please indicate your preferences, even if you object to the main proposal, so that they may still be considered if the proposal carries. You may change your votes at any time, until a community decision is made.<br />
<br />
==Main proposal==<br />
<br />
===Support===<br />
* [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
===Object===<br />
* [[User:Brian|Brian Suda]]<br />
* [[User:ScottReynen|Scott Reynen]]<br />
<br />
==Wording==<br />
<br />
===MAY===<br />
<br />
===SHOULD===<br />
<br />
===MUST===<br />
* [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
==Output field==<br />
<br />
===street-address===<br />
<br />
===extended-address===<br />
* [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
===region===<br />
<br />
===locality===<br />
<br />
==General comments==<br />
ADR is for structured information, if you do NOT have structured information then use the LABEL property. There is NO REASON to make any specical conditions for the ADR element. The spec and RFC are clear enough on these topics<br />
:<code>Label</code> is not a sub-property of <code>adr</code>; it is therefore not suitable for addresses with no <code>fn</code>. Th reasons for this proposal are as outlined on the issues page cited. [[User:AndyMabbett|Andy Mabbett]] 14:13, 10 Apr 2007 (PDT)<br />
::this makes no sense? ofcourse LABEL is not a sub-property of ADR, it is ANOTHER property entirerly designed SPECIFICALLY for address information with no structure! The use of LABEL has been added to the issues-page already and attiquitely addresses this issue - if your CMS can NOT add the fine grained support for different ADR sub-properties then it should be class="label" instead of class="adr". As for FN i don't understand what you are attempted to describe. ADR and FN are seperate. An ADR does NOT need an FN and an FN does NOT need an ADR? neither are sub-properties of each other? therefore it is completely acceptable to have an FN and a LABEL and an ADR and/or any combination of them. [[User:Brian|Brian Suda]] 21:18, 10 Apr 2007 (GMT)<br />
:::<code>Label</code> is a sub-property of <code>hCard</code>, which requires an <code>fn</code>. <code>Adr</code> is a stand-alone uF. <code>Label</code> is not.[[User:AndyMabbett|Andy Mabbett]] 14:25, 10 Apr 2007 (PDT)<br />
<br />
None of the proposed output fields seem suitable for unstructured address information. They all have specific meanings that we couldn't maintain by putting arbitrary address information into them. Also, why not just use ad-hoc semantic HTML, e.g. class="address", for this? I don't see any benefit to using ADR for something incompatible with existing ADR tools. [[User:ScottReynen|Scott Reynen]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=adr-poll&diff=15432adr-poll2007-04-11T01:37:52Z<p>ScottReynen: /* General comments */</p>
<hr />
<div>=Change to adr spec=<br />
<br />
Further to discussion at [[hcard-brainstorming#ADR with no children]], it is proposed to amend the [[adr]] spec, and the corresponding part of the hCard spec, thus:<br />
<br />
<blockquote><br />
Where the <code>adr</code> has content, but no valid sub-properties, parsers ['''MAY | SHOULD | MUST'''] output the content of that <code>adr</code> as a single vCard ['''output-field'''] field.<br />
</blockquote><br />
<br />
Please indicate you support or objections preferred wording and choice of output-field, below, using an asterisk and three tildes (<nowiki>* ~~~</nowiki>), followed by any comments. Please indicate your preferences, even if you object to the main proposal, so that they may still be considered if the proposal carries. You may change your votes at any time, until a community decision is made.<br />
<br />
==Main proposal==<br />
<br />
===Support===<br />
* [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
===Object===<br />
* [[User:Brian|Brian Suda]]<br />
* [[User:ScottReynen|Scott Reynen]]<br />
<br />
==Wording==<br />
<br />
===MAY===<br />
<br />
===SHOULD===<br />
<br />
===MUST===<br />
* [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
==Output field==<br />
<br />
===street-address===<br />
<br />
===extended-address===<br />
* [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
===region===<br />
<br />
===locality===<br />
<br />
==General comments==<br />
ADR is for structured information, if you do NOT have structured information then use the LABEL property. There is NO REASON to make any specical conditions for the ADR element. The spec and RFC are clear enough on these topics<br />
:<code>Label</code> is not a sub-property of <code>adr</code>; it is therefore not suitable for addresses with no <code>fn</code>. Th reasons for this proposal are as outlined on the issues page cited. [[User:AndyMabbett|Andy Mabbett]] 14:13, 10 Apr 2007 (PDT)<br />
::this makes no sense? ofcourse LABEL is not a sub-property of ADR, it is ANOTHER property entirerly designed SPECIFICALLY for address information with no structure! The use of LABEL has been added to the issues-page already and attiquitely addresses this issue - if your CMS can NOT add the fine grained support for different ADR sub-properties then it should be class="label" instead of class="adr". As for FN i don't understand what you are attempted to describe. ADR and FN are seperate. An ADR does NOT need an FN and an FN does NOT need an ADR? neither are sub-properties of each other? therefore it is completely acceptable to have an FN and a LABEL and an ADR and/or any combination of them. [[User:Brian|Brian Suda]] 21:18, 10 Apr 2007 (GMT)<br />
:::<code>Label</code> is a sub-property of <code>hCard</code>, which requires an <code>fn</code>. <code>Adr</code> is a stand-alone uF. <code>Label</code> is not.[[User:AndyMabbett|Andy Mabbett]] 14:25, 10 Apr 2007 (PDT)<br />
<br />
None of the proposed output fields seem suitable for unstructured ADR information. They all have specific meanings that we couldn't maintain by putting arbitrary address information into them. Also, why not just use ad-hoc semantic HTML for this, e.g. class="address"? I don't see any benefit to using ADR for unstructured addresses. [[User:ScottReynen|Scott Reynen]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=adr-poll&diff=15431adr-poll2007-04-11T01:33:07Z<p>ScottReynen: /* Object */</p>
<hr />
<div>=Change to adr spec=<br />
<br />
Further to discussion at [[hcard-brainstorming#ADR with no children]], it is proposed to amend the [[adr]] spec, and the corresponding part of the hCard spec, thus:<br />
<br />
<blockquote><br />
Where the <code>adr</code> has content, but no valid sub-properties, parsers ['''MAY | SHOULD | MUST'''] output the content of that <code>adr</code> as a single vCard ['''output-field'''] field.<br />
</blockquote><br />
<br />
Please indicate you support or objections preferred wording and choice of output-field, below, using an asterisk and three tildes (<nowiki>* ~~~</nowiki>), followed by any comments. Please indicate your preferences, even if you object to the main proposal, so that they may still be considered if the proposal carries. You may change your votes at any time, until a community decision is made.<br />
<br />
==Main proposal==<br />
<br />
===Support===<br />
* [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
===Object===<br />
* [[User:Brian|Brian Suda]]<br />
* [[User:ScottReynen|Scott Reynen]]<br />
<br />
==Wording==<br />
<br />
===MAY===<br />
<br />
===SHOULD===<br />
<br />
===MUST===<br />
* [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
==Output field==<br />
<br />
===street-address===<br />
<br />
===extended-address===<br />
* [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
===region===<br />
<br />
===locality===<br />
<br />
==General comments==<br />
ADR is for structured information, if you do NOT have structured information then use the LABEL property. There is NO REASON to make any specical conditions for the ADR element. The spec and RFC are clear enough on these topics<br />
:<code>Label</code> is not a sub-property of <code>adr</code>; it is therefore not suitable for addresses with no <code>fn</code>. Th reasons for this proposal are as outlined on the issues page cited. [[User:AndyMabbett|Andy Mabbett]] 14:13, 10 Apr 2007 (PDT)<br />
::this makes no sense? ofcourse LABEL is not a sub-property of ADR, it is ANOTHER property entirerly designed SPECIFICALLY for address information with no structure! The use of LABEL has been added to the issues-page already and attiquitely addresses this issue - if your CMS can NOT add the fine grained support for different ADR sub-properties then it should be class="label" instead of class="adr". As for FN i don't understand what you are attempted to describe. ADR and FN are seperate. An ADR does NOT need an FN and an FN does NOT need an ADR? neither are sub-properties of each other? therefore it is completely acceptable to have an FN and a LABEL and an ADR and/or any combination of them. [[User:Brian|Brian Suda]] 21:18, 10 Apr 2007 (GMT)<br />
:::<code>Label</code> is a sub-property of <code>hCard</code>, which requires an <code>fn</code>. <code>Adr</code> is a stand-alone uF. <code>Label</code> is not.[[User:AndyMabbett|Andy Mabbett]] 14:25, 10 Apr 2007 (PDT)</div>ScottReynenhttps://microformats.org/wiki/index.php?title=User:ScottReynen&diff=18390User:ScottReynen2007-04-11T01:32:51Z<p>ScottReynen: </p>
<hr />
<div>email: scott@randomchaos.com<br />
<br />
AIM: imnotscott<br />
<br />
Phone: 515-710-2725<br />
<br />
[http://log.makedatamakesense.com/ Website]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=citation-brainstorming&diff=15286citation-brainstorming2007-04-03T14:08:16Z<p>ScottReynen: /* Brian's straw format */ decapitalized "straw" so it doesn't look like a formal name</p>
<hr />
<div><h1> Citation Brainstorming </h1><br />
<br />
== See also ==<br />
* [[citation]]<br />
* [[citation-examples]]<br />
* [[citation-formats]]<br />
* [[citation-faq]]<br />
<br />
__TOC__<br />
<br />
== Contributors ==<br />
<br />
* ...<br />
* ... (a bunch of good folks!)<br />
* Tantek Çelik<br />
* Tim White<br />
* Michael McCracken<br />
* Brian Suda<br />
* [[User:AndyMabbett|Andy Mabbett]]<br />
<br />
== Use Cases ==<br />
<br />
To focus the discussion, please add use cases below that will help show what problems the citation microformat will be solving.<br />
<br />
I've included two, focusing on consuming information - I've assumed that use cases for generating microformatted content would just involve the desire to enable your content to be consumed better, but I'm interested to see if there's something I'm missing here -Mike<br />
<br />
=== Acquiring reference information from the web ===<br />
<br />
A user either finds an author's papers page, or is viewing the results of a search and would like to import the information about the displayed papers into their local reference database, for the purposes of cataloging things they've read, adding notes, and using the information to generate later citations, potentially in other forms, such as BibTeX or Docbook, for inclusion in a publication of their own.<br />
<br />
Notes: In this case, it isn't important to the user what format the citation takes as displayed on the page where they find it. What *is* important is that it contains enough information to allow generation of the format they will ultimately re-publish it in. This implies that it may be worthwhile to err a little on the side of verbosity.<br />
<br />
Also, links to downloadable full representations of the cited work are very important - e.g. a link to the PDF of a journal article, or to a music file.<br />
<br />
=== Subscribing to reading lists, periodicals, etc ===<br />
<br />
I would like to be able to leverage my news aggregator with hAtom to subscribe to a remote source for citation information, for example:<br />
<br />
* a reading list for a seminar<br />
* The publication list for a conference (e.g., subscribe to SIGGRAPH and see the updated conference proceedings every year)<br />
* the issues of a journal<br />
* a particular research group or researcher's publications<br />
* Not just research: a popular author's publications (e.g., [http://www.gladwell.com/archive.html Malcolm Gladwell's Archive])<br />
<br />
=== Aggregating reading lists and reviews ===<br />
<br />
A citation microformat-specific aggregator could provide a decentralized version of [http://citeulike.org/ CiteULike]. Libraries, authors, research groups, and publishers could mark up their collections, while other people on weblogs or review sites could add tags and reviews.<br />
<br />
At least, having a well-adopted microformat would make writing tools like CiteULike much better, since it relies in some cases on screen-scraping publisher web-sites.<br />
<br />
=== Cut & Paste from web pages ===<br />
Capturing/copying HTML from web pages for use in other applications (especially when those apps present HTML as output), such as pasting into Word, or a specialized application like [http://www.google.com/notebook Google Notebook], [http://onfolio.com Onfolio] or [http://www.kaboodle.com Kaboodle]. When such captures are made, it makes sense to keep track of the full citation data, including the date it was accessed, which may or may not be the date it was published. <br />
<br />
=== Blogs quoting other resources, including blogs ===<br />
Any blog that cites online content, whether a blog or news article, could use an hCitation to properly link to the cited reference. Such citations could include the access date when the blogger made the citation, because resources on the other side of those links can change without notice. <br />
<br />
Instead, today we have simple formating with a link to the permaURL. The citation data is completely lacking. See [http://doc.weblogs.com Doc Searl's blog] for a style of referencing that could benefit from proper a citation uF.<br />
<br />
<br />
Fascinating... after I added the last two use cases, I realized they focus on potentially marginal cases. The first because it is missing the "output" part of the cut & paste, where the uF would actually be used as part of the paste. The latter because bloggers have a working citation mechanism that is just a link to the URL (hopefully a permaURL). One could argue they wouldn't want a full hCitation. And in fact, until a tool exists that makes it easy, they probably won't. However, a tool that cuts & pastes from anywhere on the web into a blog with a full citation seems like a nice tool. But again, I'm not really paving the cowpaths with these ideas. -Joe Andrieu<br />
<br />
===Finding in Library===<br />
Find a copy of the cited work in a nearby library (as with [http://ocoins.info/ OpenCOinS]). [[User:AndyMabbett|AndyMabbett]] 04:55, 4 Nov 2006 (PST)<br />
<br />
===Buy a copy===<br />
Find the cited work on, for example, Amazon or [http://www.abebooks.com/ ABE]; or subscribe to a journal via its own website. [[User:AndyMabbett|AndyMabbett]] 04:55, 4 Nov 2006 (PST)<br />
<br />
===Find reviews===<br />
Find third-party reviews of the cited work. [[User:AndyMabbett|AndyMabbett]] 04:55, 4 Nov 2006 (PST)<br />
<br />
===Give citation data for the page being visited===<br />
<br />
Adding a class of, say, "self" to an attribute of the proposed strawman would allow users (or user agents) to extract the data required to cite the page being visited, when referring to it elsewhere. There would be the added advantage of allowing the citation to be ignored by any parser which might be building a "tree" of citations, and preventing the setting up of an infinite loop. <br />
<br />
For evidence of published "self citation" data (albeit on a secondary page) see the "cite this article" link on any Wikipedia entry, e.g. [http://en.wikipedia.org/w/index.php?title=Special:Cite&page=West_Midland_Bird_Club&id=115894372] from [http://en.wikipedia.org/wiki/West_Midland_Bird_Club].<br />
<br />
See also [http://en.wikipedia.org/wiki/Wikipedia_talk:Citing_Wikipedia#Citation_data_should_be_on_the_page_concerned Proposal to include on-page citation data in Wikipedia]<br />
<br />
:[[User:AndyMabbett|Andy Mabbett]] 13:47, 20 Mar 2007 (PDT)<br />
<br />
===Convert citation formats===<br />
A user agent should be capable of reading a citation from a web page, in a given format, and converting it into a second format, for use elsewhere. For a list of such formats, and examples, see [http://en.wikipedia.org/wiki/Citation#Format_styles Wikipedia, Citation styles]. [[User:AndyMabbett|Andy Mabbett]] 11:05, 30 Mar 2007 (PDT)<br />
<br />
==Examples==<br />
* (from a mailing list): <br />
:<blockquote>if you want to cite a [biomedical journal] journal article on Wikipedia [...] you can export a correctly-formatted citation for Wikipedia from HubMed using unAPI... http://hublog.hubmed.org/archives/001408.html</blockquote><br />
<br />
*[http://www.zotero.org/ Zotero], a Firefox extension to help collect, manage, and cite research sources. <br />
:[[User:AndyMabbett|Andy Mabbett]] 09:13, 21 Mar 2007 (PDT)<br />
<br />
== Original hBib Discussion ==<br />
<br />
During the WWW2005 Developer's Day [[microformats]] track, Rohit Khare gave a [[presentations|presentation]] where he discussed the microformats [[process]], and then did a quick demonstration wherein a bunch of us got on a shared Subethaedit document, and brainstormed some thoughts on what an "hBib" bibliography citation microformat would look like. Rohit placed the [http://cnlabs.commerce.net/~rohit/hBib%20Discussion.html document on his Commercenet site].<br />
<br />
* http://cnlabs.commerce.net/~rohit/hBib%20Discussion.html<br />
<br />
''An attempt to summarize and inline the linked document follows. -Mike''<br />
<br />
Two major goals were outlined by the group:<br />
<br />
* Avoid re-keying references<br />
* Adapt to new journal styles by changing CSS<br />
<br />
The fundamental problem was discussed in terms of display - the ability to transform XHTML+hBib into the many journal-specific formats. For example, how to display "et.al" when all authors are present in the source, and how to re-order the elements if a style defines a set order of elements that conflicts with the ordering in the source. Using hCard for authors was agreed on, and the beginnings of an example were shown.<br />
<br />
== XHTML Structure ==<br />
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.<br />
<br />
* There should be some sort of 'root node' that implies all child elements are for the hCitation microformat.<br />
* Since most people will have multiple citations there should be away to represent each hCitation object as a unqiue block independent of another. This is to keep the parse from finding 'author' and applying that to all citations. Each citation should be in a container (class="hcite") that is separated from others.<br />
* Perhaps class="hcite" with <code>&lt;cite&gt;</code> recommended as the root element. E.g. <code>&lt;cite class="hcite"&gt;</code> <br />
<br />
'''Note: This section was the original content of the document. Since then, class='hcite' has been agreed on as the root class name. See [http://microformats.org/wiki?title=citation-brainstorming#.27hcite.27_as_Root_Element_name explanation].'''<br />
<br />
== Citation vs. [[media-info]] ==<br />
<br />
What distinguishes a cite from say [[media-info]] (e.g. [[media-info-examples]]) is that a cite is a reference to something explicitly external to the current piece of content or document, whereas [[media-info]] describes information about content embedded or inline in the current document.<br />
<br />
== Semantic Meaning ==<br />
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?)<br />
<br />
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. ''Does this sentence make sense only historically? -Mike''<br />
<br />
== OCLC's WorldCat for titles == <br />
Question: what about using something like OCLC's [http://www.oclc.org/worldcat/open/isbnissnlinking/default.htm WorldCat] for linking titles? - Tim White<br />
<br />
== This and That ==<br />
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)<br />
<br />
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.<br />
<br />
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]<br />
<br />
== More on This and That ==<br />
<br />
Citation microformats are being explored as a possibility for citing genealogical information at [http://eatslikeahuman.blogspot.com Dan Lawyer's blog].<br />
<br />
This is a case where frequently the citation would refer to (THIS.PAGE), but would have nested within it a reference to (THAT.PAGE), possibly a few levels deep. For instance, a web page might contain data extracted from a microfilm of a census. The citation would need to include information about the web page, information about the microfilm, and information about the census. Genealogical citations are expected to include the repository (where can this book or microfilm be found. Is this the same as ''venue''?). So, at each level the information should contain the repository of the referenced item. A nesting (recursive) mechanism for citation microformats would be useful in this case. Is this the function of the "container" element in the Straw Format?<br />
<br />
== Date Formatting ==<br />
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. <br />
<br />
These are all the different fields from various citation formats that are of temporal nature:<br />
* Date (available | created | dateAccepted | dateCopyrighted | dateSubmitted | issued | modified | valid)<br />
* originInfo/dateIssued<br />
* originInfo/dateCreated<br />
* originInfo/dateCaptured<br />
* originInfo/dateOther<br />
* month<br />
* year<br />
* Copyright Year<br />
* Date - Generic<br />
* Date of Confernce<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<br />
<br />
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. <br />
<br />
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.<br />
<br />
...<br />
<br />
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<br />
<br />
<br />
'''Important'''<br />
Sometimes we need a date range and not simply a date (e.g. 4-6 May 2006). See ''Conference Citation'' examples later on this page. - Discoleo<br />
<br />
'''Seasons'''<br />
Some journals have seasonal issues (e.g. "Summer 2006 edition") instead of, or as well as, editions labelled by month or other calendar-date. [[User:AndyMabbett|AndyMabbett]] 05:05, 4 Nov 2006 (PST)<br />
<br />
== Tags ==<br />
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.<br />
<br />
<br />
== MARC / MODS / Dublin Core ==<br />
<br />
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.<br />
<br />
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]):<br />
<br />
<pre><nowiki><br />
<div class="book" lang="en"><br />
<h3 class="fn">Arithmetic /</h3><br />
<p>By <span class="creator"><span class="fn">Sandburg, Carl</span>,<br />
<span class="date">1878-1967</span></span>,<br />
and <span class="illustrator">Rand, Ted</span></p><br />
<p>Publisher: <span class="publisher"><span class="fn">Harcourt Brace Jovanovich</span>,<br />
<span class="locality">San Diego</span></span></p><br />
<p>Published: <span class="issued">1993</span></p><br />
<p class="description">A poem about numbers and their characteristics. Features<br />
anamorphic, or distorted, drawings which can be restored to normal by viewing<br />
from a particular angle or by viewing the image's reflection in the provided<br />
Mylar cone.</p><br />
<p class="note">One Mylar sheet included in pocket.</p><br />
<p>Subjects:</p><br />
<ul><br />
<li class="subject">Arithmetic</li><br />
<li class="subject">Children's poetry, American.</li><br />
<li class="subject">Arithmetic</li><br />
<li class="subject">American poetry</li><br />
<li class="subject">Visual perception</li><br />
</ul><br />
</div><br />
</nowiki></pre><br />
<br />
== Basic Citation Stuctures ==<br />
There are basic structures to any citation, this is an overview of some of the types<br />
[http://www.users.muohio.edu/darcusb/misc/citations-spec.html http://www.users.muohio.edu/darcusb/misc/citations-spec.html]<br />
<br />
<br />
== Concerns not addressed by existing formats ==<br />
<br />
There are some aspects '''NOT adequately''' covered by existing formats. I have addressed this issue on the OpenOffice.org wiki page, too. [see http://wiki.services.openoffice.org/wiki/Bibliographic_Database for an extending discussion, the paragraph on ''Reference Types'']<br />
<br />
<br />
These issues pertain mainly to '''Errata''', '''Comments and Authors Reply''' and '''Article Retractions'''.<br />
* a bidirectional link could be necessary to implement these features (original article <=> eratum, reply, retraction letter)<br />
* '''IMPORTANT: Errata'''<br />
** Erata: one or more Corrections might be posted in various issues of the journal<br />
** this is usually cited as: Orininal Article Citation Data (Correction available in ''Journal, Issue Nr, Year, Pages'') (repeat for more than one correction)<br />
** it is possibly never cited alone<br />
** there should be a link to the original article, while the original article should contain a link to this ''Errata''<br />
* '''IMPORTANT: Commentary and Author Reply'''<br />
** similar to Errata, there might be one or more Comments and Author Replys; this should be stored, too<br />
** however, it is usually not included in the original citation<br />
** it might be used however in a citation, but I do not know exaclty how to cite it optimally (original article should be provided as well) <br />
* '''IMPORTANT: Article Retraction'''<br />
** an article may be retracted because of plagiarism or some other flaw<br />
** this should not be used any further in the research<br />
** however, it might be used e.g. for an article on plagiarism or flawed research<br />
** there should be therefore one field storing this information, too, and a link to:<br />
** the published withdrawal letter (which explains why the article was retracted)<br />
<br />
* this issue may need a time-controlled event<br />
* '''IMPORTANT: electronic publishing ahead of print (EPUB)'''<br />
** more and more articles are initially posted online, before the published article gets actually printed<br />
** How should this be used/cited?<br />
** Is this changed, after the print version becomes available?<br />
<br />
<br />
== Outstanding Issues ==<br />
The 3 main points i (Brian) came across so far are:<br />
1) IDENTIFIERS<br />
2) FORMAT TYPES<br />
3) NESTING<br />
<br />
1) In hCard/hCalendar there is a UID field. Added with URL it makes for a great unique identifier. There are loads of other identifers besides URL, ISBN, LOC call number, SKU, ISSN, etc. Many of these are unique in their domain, but not globally unique. So how to they get marked-up? Much like the hCard TEL/ADR properties, we can use something like:<br />
<pre><br />
<nowiki><br />
<div class="uid"><span class="type">ISBN</span>: <span<br />
class="value">123456</span></div><br />
</nowiki><br />
</pre><br />
This makes the encoding the most extensible... if we start use class="isbn" then it is an enumerated list, with class="type" it is open ended.<br />
<br />
2) I keep mis-using "format", format is the medium - hardback, softback. The TYPE (there probably is a better word - container?) is book, article, conference, manifesto, etc. Much like the identifers we can make an enumerated list of values, class="book", class="article", but that boxes us in, whereas something like: <pre><nowiki><span class="type">article</span></nowiki></pre> leaves things more open.<br />
<br />
3) Nesting citation data in a citation. The ability to nest the same microformat inside itself is something that other microformats don't explicitly handle.<br />
<br />
The two options are:<br />
i) Using class="book"<br />
<pre><br />
<nowiki><br />
<div class="hcite"><br />
<div class="book"><br />
<span class="fn">Book Title</span><br />
<div class="chapter"><br />
<span class="fn">Chapter Title</span><br />
</div><br />
</div><br />
</div><br />
</nowiki><br />
</pre><br />
<br />
This makes things easy to nest and to figure out exactly what is<br />
associated with what, but the downside is that we have enumerated<br />
lists of values for the class properties.<br />
<br />
ii) using the TYPE for book<br />
<pre><br />
<nowiki><br />
<div class="hcite"><br />
<div class="type">book</div><br />
<span class="fn">Book Title</span><br />
<div class="type">chapter</div><br />
<span class="fn">Chapter Title</span><br />
</div><br />
</nowiki><br />
</pre><br />
<br />
now the class="fn" is not nested inside the class="book" or<br />
class="chapter" so there would have to be some other mechanism to<br />
associate the data with the type.<br />
<br />
== Brian's straw format ==<br />
<br />
=== implied schema (examples) ===<br />
+ publisher<br />
+ language<br />
+ description<br />
+ title<br />
+ creator<br />
+ journal<br />
+ volume<br />
+ issue<br />
+ page <br />
+ edition<br />
+ identifier<br />
+ tags<br />
+ format<br />
+ date published<br />
+ copyright<br />
- audience<br />
<br />
=== implied schema (formats) ===<br />
+ publisher<br />
+ language<br />
+ description<br />
+ title<br />
+ creator<br />
+ volume<br />
+ pages<br />
+ edition<br />
+ issue<br />
+ identifier<br />
+ tags<br />
+ format<br />
+ date published<br />
+ date copyrighted<br />
- subtitle<br />
- image <br />
- excerpt<br />
- index terms<br />
- series title<br />
- publication<br />
- journal<br />
- part (1 of X)<br />
<br />
UNION of the two schemas<br />
+ (PLUS) means common properties<br />
- (MINUS) means unique to the schema<br />
<br />
<br />
=== Working straw schema ===<br />
<br />
This list records discussion about the common schema from above. The format is ''descriptive-name'' (''optional-recommended-element'' 'class-name') (''link to explanation'').<br />
<br />
If there is no explanation link, that field should be considered either obvious or up for debate. If you're not sure which, it's up for debate.<br />
<br />
* root element ('hcite') ([http://microformats.org/wiki?title=citation-brainstorming#.27hcite.27_as_Root_Element_name explanation])<br />
** title ('title')<br />
** Author / Editor etc. ('creator')<br />
** Pages ('pages')<br />
*** note: this can be any value<br />
** container ('container hcite')<br />
*** A nested hcite element that represents a containing item (like a book for a chapter) ([http://microformats.org/wiki?title=citation-brainstorming#Container discussion and link to mailing list thread])<br />
** Volume Number ('volume')<br />
** Edition ('edition')<br />
** Issue number ('issue')<br />
** Tags (href rel='tag')<br />
** Format ('format')<br />
*** Note - this is unclear at present - does format mean 'type', as in 'book' vs. 'article'? --[[User:Mike|Mike]] 22:53, 16 Jan 2007 (PST)<br />
** date published ('date-published') ([http://microformats.org/wiki?title=citation-brainstorming#Date_Fields explanation])<br />
** date accessed ('date-accessed') ([http://microformats.org/wiki?title=citation-brainstorming#Date_Fields explanation])<br />
** publisher<br />
** language<br />
** Abstract / description ('description')<br />
** URI (href class='uri') ([http://microformats.org/wiki?title=citation-brainstorming#The_URI_Element explanation])<br />
** identifier<br />
*** an (not necessarily globally unique) identifier, such as a cite-key, pubmed ID number, or simply the reference number or string within a publication ([1] or [CLRS2001])<br />
<br />
==== Notes about missing / changed fields in the schema ====<br />
<br />
This section lists fields that are intentionally ''not'' included in the straw schema, or are not represented directly, and links to discussion about each.<br />
<br />
* date copyrighted ([http://microformats.org/wiki?title=citation-brainstorming#Date_Fields explanation])<br />
<br />
=== Examples ===<br />
<br />
Markup examples using the above format:<br />
<br />
==== Book ====<br />
<br />
This is Brian's original example<br />
<br />
<pre><br />
<nowiki><br />
<ul class="bibliography"><br />
<li class="hcite" xml:lang="en-gb"><br />
<br />
<!-- publisher data as hCard--;<br />
<div class="publisher vcard"><br />
<span class="fn org">ABC Publishing Co.</span><br />
<span class="country-name">United Kingdom</span><br />
...<br />
</div><br />
<br />
<!-- author(s) data as hCard --><br />
<div class="creator vcard"><br />
<span class="fn n"><span class="given-name">John <span class="family-name">Doe</span></span><br />
...<br />
</div><br />
<br />
<!-- location data --><br />
<span class="fn">Foobar!</span><br />
<span class="description">World Class Book about foobar</span><br />
<span class="volume">1</span><br />
<span class="issue">1</span><br />
<span class="edition">1</span><br />
<span class="pages">1-10</span><br />
<span class="format">article</span><br />
<br />
<!-- differed to the UID debate --><br />
<span class="identifier">12345678</span><br />
<br />
<!-- keywords --><br />
<a class="keyword" rel="tag" href="/tags/foo">foo</a><br />
<span class="keyword">bar</span><br />
<br />
<!-- date properties --><br />
Published <abbr class="date-published" title="20060101">January 1st 1006</abbr><br />
Copyright <abbr class="copyright" title="20060101">2006</abbr><br />
</li><br />
...<br />
</ul><br />
<br />
<p class="hcite">Have you read <span class="title"><abbr title="book" class="format">Foo Bar</abbr></span>? <br />
It was written by <span class="author vcard"><span class="fn">John Doe</span></span>. <br />
It only came out a <abbr class="dtpublished" title="20060101">few months ago</abbr></p><br />
</nowiki><br />
</pre><br />
<br />
Note: the "format" property above is incorrect. Format would refer more the physical characteristics of an item, rather than its type or genre (e.g. "article", "book", etc.). I'd rather have the main class for the li be "article" in this context, than the fairly meaningless "citation." Of course, one could have both, which would be fine too. -- bruce<br />
<br />
Note: Could we use ROLE from hCard to identify editors, translators, authors, etc?<br />
This was discussed on the mailing list and the idea was dropped [http://microformats.org/discuss/mail/microformats-discuss/2006-September/005694.html]<br />
<br />
'''Comments''' : [[User:Singpolyma|singpolyma]] 08:03, 16 Jun 2006 (PDT) : keywords should be [[rel-tag]], and probably also [[XOXO]] (the same way the citation list is)<br />
<br />
[[User:RCanine|RCanine]] 11:55, 18 Dec 2006 (EST) :<br />
<br />
* Is there a reason not to re-use "published" from hAtom instead of inventing a new, basically equivalent term in "dtpublished"?<br />
** note - date-published was decided on for the field, example changed to reflect it --[[User:Mike|Mike]] 10:12, 30 Mar 2007 (PDT)<br />
* Missing a URL/URI/IRI/UID etc. field example (ISBN for Book).<br />
* Does the "copyright" class conflict with [http://www.whatwg.org/specs/web-apps/current-work/#class WHATWG's definition]?<br />
* WRT Bruce's comment, I'm currently using class="article citation" for my writing, as it has the most flexibility with CSS styles for titles (e.g. Book titles .citation>.fn must be italicized, while article titles must not, their container should).<br />
* Speaking of containers, we need an "in" or "collection" field for journal articles or articles-in-books, or is that covered by "publisher"?<br />
<br />
==== Citing Private Communication ====<br />
<br />
Needs an example.<br />
<br />
==== Citing Legal Cases ====<br />
Needs an example. <br />
see [http://microformats.org/wiki/citation-examples-markup#Wikipedia_Court_Case Wikipedia example] for inspiration.<br />
<br />
==== Citing a Book ====<br />
<br />
needs an example<br />
<br />
==== Citing a journal article ====<br />
<br />
From an old entry in PubMed - J Aersp Med. [http://www.ncbi.nlm.nih.gov/entrez/query.fcgi?db=pubmed&cmd=Retrieve&dopt=AbstractPlus&list_uids=4611181&query_hl=7&itool=pubmed_docsum link]<br />
<br />
<pre><nowiki><br />
<span class="hcite"><br />
<span class="creator vcard"><span class="fn">R R Burton</span></span>,<br />
<span class="creator vcard"><span class="fn">S D Leverett</span></span>, and<br />
<span class="creator vcard"><span class="fn">E D Michaelson</span></span><br />
<br />
<span class="title">Man at high sustained +Gz acceleration: a review.</span><br />
In <span class="container hcite"><br />
<abbr class="type" title="Journal">J.</abbr><abbr class="title" title="Aerospace medicine">Aersp. Med.</abbr><br />
<span class="uri uid">urn:issn:0001-9402</span><br />
<span class="volume">45</span><br />
<span class="issue">10</span><br />
<abbr class="date-published" title="101974">Oct, 1974</abbr><br />
</span>, pages <span class="page">1115-36</span>.<br />
<br />
</span><br />
<br />
</nowiki></pre><br />
<br />
Note, I'm not entirely sure about the issn urn here.<br />
<br />
==== Citing a magazine article ====<br />
<br />
needs an example<br />
<br />
==== Citing a Patent ====<br />
<br />
Drawn from this [http://microformats.org/wiki/citation-examples#U.S._Patent example from Wikipedia]:<br />
<br />
<pre><nowiki><br />
<li class="hcite"><a href="http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4,405,829" class="url" <br />
title="http://patft.uspto.gov/netacgi/nph-Parser?patentnumber=4,405,829"><br />
<span class="format">U.S. Patent</span> <span class="identifier">4,405,829</span></a>:<br />
<span class="description">The <a href="/wiki/RSA" title="RSA">RSA</a> patent, a famous software patent on the ground-breaking <br />
and highly unobvious algorithm for public key encryption, widely used for secure communications <br />
in many industries nowdays</span><br />
</li><br />
</nowiki></pre><br />
<br />
==== Citing a conference publication====<br />
<br />
Based on the [http://microformats.org/wiki/citation-examples#ACM_Digital_Library_Search_Result_Examples conference publication reference example].<br />
<br />
Changed Oct 06 to conform with [http://microformats.org/wiki/citation-brainstorming#Brian.27s_Straw_format Brian's format]. --[[User:Mike|Mike]] 18:09, 12 Oct 2006 (PDT)<br />
(everything but the url class should be in line with that proposal)<br />
<br />
L. Hochstein, J. Carver, F. Shull, S. Asgari, V. Basili, J. K. Hollingsworth, and M. Zelkowitz, “Hpc programmer productivity: A case study of novice hpc programmers,” in Proceedings of ACM/IEEE Supercomputing Conference, 2005.<br />
<br />
<pre><nowiki><br />
<span class="hcite"><br />
<span class="creator vcard"><span class="fn">Lorin Hochstein</span><br />
<span class="org"> University of Maryland, College Park </span></span>,<br />
<span class="creator vcard"><span class="fn"> Jeff Carver </span> <br />
<span class="org"> Mississippi State University </span> </span>,<br />
<span class="creator vcard"><span class="fn"> Forrest Shull </span> <br />
<span class="org"> Fraunhofer Center Maryland </span> </span>,<br />
<span class="creator vcard"><span class="fn"> Sima Asgari</span> <br />
<span class="org"> University of Maryland, College Park </span> </span>,<br />
<span class="creator vcard"><span class="fn"> Victor Basili</span> <br />
<span class="org"> Fraunhofer Center Maryland </span> </span>,<br />
<span class="creator vcard"><span class="fn"> Jeffrey K. Hollingsworth</span> <br />
<span class="org"> University of Maryland, College Park </span> </span>, and <br />
<span class="creator vcard"><span class="fn"> Marv Zelkowitz</span> <br />
<span class="org"> University of Maryland, College Park </span> </span>,<br />
<br />
<a class="title url" href="http://dx.doi.org/10.1109/SC.2005.53">HPC Programmer Productivity: A Case Study of Novice HPC Programmers</a>. <br />
(<span class="format">conference publication</span>)<br />
<span class="container hcite"><br />
<a class="title url" href="...">Proceedings of ACM/IEEE Supercomputing Conference</a><br />
<abbr class="date-published" title="20051126T0000-0800">2005</abbr><br />
</span><br />
page <span class="pages">35</span><br />
<span class="publisher vcard"><br />
<span class="fn">IEEE Computer Society<br />
</span><br />
<span class="adr"><br />
<span class="locality">Washington</span>,<br />
<span class="region">DC</span><br />
</span><br />
</span><br />
<a class="url eprint" href="http://portal.acm.org/...">PDF of full text from ACM</a><br />
<br />
DOI: <a class="url uid" href="http://dx.doi.org/10.1109/SC.2005.53">10.1109/SC.2005.53</a><br />
Tags: <br />
<a class="keyword" rel="tag" href="results.cfm?query=genterm%3A%22Design%22 ...">Design</a>,<br />
<a class="keyword" rel="tag" href="results.cfm?query=genterm%3A%22Experimentation%22 ....">Experimentation</a>,<br />
<a class="keyword" rel="tag" href="results.cfm?query=genterm%3A%22Measurement%22...">Measurement</a>,<br />
<a class="keyword" rel="tag" href="results.cfm?query=genterm%3A%22Performance%22 ...">Performance</a><br />
<br />
<span class="description">In developing High-Performance Computing (HPC) software, ....</span><br />
</span><br />
</nowiki></pre><br />
<br />
<br />
'''Note''' (From [[Discoleo]], Sept. 06)<br />
* sometimes, the citation must include '''Town/Country''' and '''Precise Date/Date Range''', e.g.<br />
** ''Gillespie SH, Dickens A.'' Variation in mutation rate of quinolone resistance in Streptococcus pneumoniae [abstract P06-17A]. In: Abstracts of the 3rd International Symposium on Pneumococci and Pneumococcal Disease (Anchorage, 5-9 May 2002).Washington, DC: American Society of Microbiology, 2002.<br />
** ''Bassetti, M.; Righi, E.; Rebesco, B.; Molinari, MP.; Costa, A.; Fasce, R.; Cruciani, M.; Bassetti, D.; Bobbio Pallavicini, F.'' 44th Annual Interscience Conference on Antimicrobial Agents and Chemotherapy (ICAAC). Washington, DC; 2004. Epidemiological trends in nosocomial candidemia in ICU: A five-year Italian perspective.<br />
** ''Peacock JE, Wade JC, Lazarus HM, et al.'' Ciprofloxacin/piperacillin vs. tobramycin/piperacillin as empiric therapy for fever in neutropenic cancer patients, a randomized, double-blind trial [abstract 373]. In: Program and abstracts of the 37th Interscience Conference on Antimicrob Agents and Chemotherapy (Toronto). Washington, DC: American Society for Microbiology, 1997.<br />
<br />
==== Citing an external website ====<br />
<br />
This is based on a formal citation of a website in the references section of a research paper, but could also be used for in-line links that had added information. Here's the original:<br />
<br />
[25] David Stern, "eprint Moderator Model", http://www.library.yale.edu/scilib/modmodexplain.html (version dated Jan 25, 1999)<br />
<br />
<pre><nowiki><br />
<cite class="hcite"><br />
<a class="fn url" href="http://www.library.yale.edu/scilib/modmodexplain.html">eprint Moderator Model</a><br />
<span class="author vcard"><br />
<a href="http://pantheon.yale.edu/~dstern/dsbio.html" class="url fn">David Stern</a><br />
</span> <br />
<abbr class="dtpublished" title="19990125T0000-0500"><br />
Jan 25, 1999<br />
</abbr><br />
</cite><br />
</nowiki></pre><br />
<br />
=== Discussion of Straw Format elements ===<br />
<br />
This section is to provide explanations for posterity about the elements of the straw format, linking to discussions on the list and elsewhere if possible.<br />
<br />
==== 'hcite' as Root Element name ====<br />
<br />
This discussion took place in January of 2007, with [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008098.html voting occurring on the mailing list].<br />
<br />
It was decided to use 'hcite' as the root element's class-name for uniqueness and to reflect a trend in using 'h' to start microformat names.<br />
<br />
==== The URI Element ====<br />
<br />
It was decided to use URI for both http links to available copies or URNs.<br />
This encompasses URLs that link directly to online copies as well as through resolvers using URIs such as urn:isbn: 0521890012<br />
<br />
See the discussion from [http://microformats.org/discuss/mail/microformats-discuss/2006-November/007390.html November] and [http://microformats.org/discuss/mail/microformats-discuss/2006-December/007403.html December].<br />
<br />
==== Date Fields ====<br />
<br />
Brian's original straw format had three date fields, "accessed", "copyrighted", and "published".<br />
After examining the examples of usage on the web, it was clear that 'copyrighted' was not used in the examples we have.<br />
It was used once, but without a corresponding 'published' field (OCLC WorldCat), and it seems in that case to be used as <br />
an equivalent to 'published'.<br />
<br />
I updated the straw citation to include only 'accessed' and 'published' on January 31. --[[User:Mike|Mike]] 00:26, 31 Jan 2007 (PST)<br />
<br />
I've mentioned more than once that "date-published" is misleadingly specific; too much for real world citations. Consider that many books are published in the year preceding their copyright date, which is in fact the date used for citation. I'd prefer just "date" and "date-accessed" as a first cut. --[[User:BDarcus|Bruce]] 3 Feb 2007<br />
<br />
See the discussion from the [http://microformats.org/discuss/mail/microformats-discuss/2007-January/008175.html 'dates' thread on the list].<br />
<br />
==== Container ====<br />
<br />
Discussion about how to represent containing relationships is on the thread [http://microformats.org/discuss/mail/microformats-discuss/2007-March/thread.html 'nesting container elements']<br />
<br />
== Old straw format discussion ==<br />
<br />
Saved here so that I'm not just deleting people's comments.<br />
<br />
<br />
=== Mike straw format suggestion (Deprecated) ===<br />
<br />
In the interests of starting debate and having something concrete to fix, I suggest the following structure for a format. It is probably very incomplete and I claim no microformat expertise. I'm just trying to follow existing patterns. Comments and ridicule are both solicited. -Mike<br />
<br />
'''NOTE:''' This format is here for historical reference. Because it was not based on existing examples, I've deprecated it and contributed examples to Brian's format. If you feel that any missing elements in here should be in the final format, find examples for them and contribute to Brian's schema. Thanks! --[[User:Mike|Mike]] 18:22, 12 Oct 2006 (PDT)<br />
<br />
==== In General ====<br />
<br />
The ''citation'' format is based on a set of fields common to many bibliographic data formats, which are often implied by standard citation display styles but not explicitly marked up in practice on the web.<br />
<br />
==== Schema ====<br />
<br />
The citation schema consists of the following:<br />
<br />
* cite <br />
** title: required, text (class = fn)<br />
** subtitle: optional, text<br />
** authors: optional, use hCard<br />
** publication date: optional<br />
** link(s) to instantiations, optional, url or use rel-enclosure? (class=url)<br />
** UID, optional (for ISBN, DOI - use existing uid class) | permalink<br />
** series (aka volume/issuenum) , optional (''not as sure how to handle these - suggestions?'')<br />
** pages: startpage & endpage, optional, text<br />
** venue, optional (hCard)<br />
** publisher, optional (hCard)<br />
** container: optional (nested hCite)<br />
** abstract, optional (blockquote + class="abstract" ?)<br />
** notes, optional (blockquote + class="notes" ?)<br />
** keywords, optional (rel-tag)<br />
** image, optional (for inclusion inline, unlike the url)<br />
** copyright, optional (rel-license)<br />
** ''what else am I missing?''<br />
*** language, optional<br />
<br />
''Looks good, but I question the use of hCard for names. Due to ambiguity issues, requring hCard would lead to extra markup in order to apply just a name, hence [http://microformats.org/discuss/mail/microformats-discuss/2006-March/003487.html the need for a root element]. We should extract the N optimization of hCard like we did with adr, in order to ease this problem.'' --[[User:RCanine|Ryan Cannon]]<br />
<br />
Perhaps a Retrieved Date or Access Date would be appropriate for citing online resources. For example at http://www.crlt.umich.edu/publinks/facment_biblio.html <br />
you see citations like this<nowiki>:</nowiki><br />
<blockquote><br />
Chief Academic Officers of the Big 12 Universities (2000). Big 12 Faculty Fellowship Program. Retrieved December 20, 2000 from the World Wide Web: http://www.k-state.edu/provost/academic/big12/big12guide.htm.<br />
</blockquote><br />
--[[User:JoeAndrieu|Joe Andrieu]]<br />
<br />
<br />
==== Discussion about citing legal cases ====<br />
<br />
Here's some info I found about citing law:<br />
<br />
I'm not a lawyer, so I'm relying on the published [http://www.legalbluebook.com "blue book" standard], at least the only part of it I can get without paying $25. I'd be happy to hear improvements from experts in the field - how do lawyers mark up references to case law in HTML now?<br />
<br />
From groklaw.net and eff.org, I find mostly just links to PDFs with the name of the case as the link text. Or just this, from EFF:<br />
<pre><nowiki><br />
<h1>The Betamax Case</h1><br />
<h2>Sony Corp. of America v. Universal City Studios, 464 U.S. 417 (1984)</h2><br />
</nowiki></pre><br />
<br />
From an example at the sample bluepages: http://www.legalbluebook.com/pdfs/bluepages.pdf<br />
5 basic components:<br />
*1 name of the case (citation title)<br />
*2 published source in which case may be found (citation containing publication?)<br />
*3 a parenthetical indicating the court and year of decision (citation venue?)<br />
*4 other parenthetical information, if any (citation notes?)<br />
*5 subsequent history of the case, if any (citation notes?)<br />
<br />
Here's two examples from the bluebook. Note that there are very strict rules about abbreviations in that source!<br />
<br />
Holland v. Donnelly, 216 F. Supp. 2d 227, 230 (S.D.N.Y. 2002), aff'd, 324 F.3d 99 (2d Cir. 2003).<br />
<br />
Green v. Georgia, 442 U.S. 95, 97 (1979) (per curiam) (holding that exclusion of relevant evidence at sentencing hearing constitutes denial of due process).<br />
<br />
<br />
== Examples in the wild ==<br />
Pages which start to use the discussion above to create working examples in using hcite:<br />
(This section could be used as a base for a page like "hcite-examples-in-wild" later).<br />
<br />
<br />
Please add new examples to the top of this section.<br />
* [http://www.demo.vorlagen.uni-erlangen.de/univis/mitarbeiter.shtml/georg-hager.shtml Example User Page] at the regional computer lab Erlangen, Germany, based on the universal information system UnivIS marked up with vcard, hcalender (optional, if user makes a lecture) and hcite.<br />
<br />
== discussions ==<br />
* [[citation-irc-notes-2006-04-09]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=geo-extension-elevation&diff=14475geo-extension-elevation2007-03-20T16:12:46Z<p>ScottReynen: Initial examples</p>
<hr />
<div>= Geo Elevation =<br />
An exploration of adding elevation information to geo data.<br />
<br />
== The Problem ==<br />
Publishers of elevation information on the web could make additional use of this information (e.g. in Google Earth) with a standard format.<br />
<br />
== Participants ==<br />
* Alexander Graf<br />
<br />
== Real-World Examples ==<br />
<br />
=== State High Points (http://www.waypoint.org/gps2-list210.html) ===<br />
<pre><nowiki><br />
<tr><br />
<td>CA</td><br />
<br />
<td><a href="./batting.500/">7/2/2001</a></td><br />
<td><a href="./batting.500/">California</a></td><br />
<td>Mount Whitney</td><br />
<td>14,494</td><br />
<td>36&deg; 35'N,<br>118&deg; 17'W</td><br />
<br />
<td>36&deg; 34.721'N,<br>118&deg; 17.466'W</td><br />
<td>CA Mt. Whitney 1:24,000, Mt. Langley 1:24,000</td><br />
</tr><br />
</nowiki></pre><br />
== Existing Practices ==<br />
<br />
== Proposal ==<br />
<br />
== See Also ==<br />
* [[geo]]</div>ScottReynenhttps://microformats.org/wiki/index.php?title=mailing-list-unmoderation&diff=14408mailing-list-unmoderation2007-03-19T15:36:32Z<p>ScottReynen: </p>
<hr />
<div>Andy Mabbett was moderated (rather than banned for a week) in early 2007 on the microformats mailing lists at the time for both his frequent off-topic posts, and his ignoring of several warnings from admins to please stop doing so. Ernie P. (a longstanding overwhelmingly positive contributor to the community) has proposed unmoderating Andy at this point.<br />
* +1 Ernie P.<br />
* +1 David Janes<br />
* +1 Nic James Ferrier<br />
* +1 Tantek<br />
* +1 Scott Reynen<br />
* ... add your opinion (+1 unmoderate, 0 no opinion, -1 keep moderated) and your name</div>ScottReynen