https://microformats.org/wiki/api.php?action=feedcontributions&user=PaulWilkins&feedformat=atomMicroformats Wiki - User contributions [en]2024-03-28T08:18:45ZUser contributionsMediaWiki 1.38.4https://microformats.org/wiki/index.php?title=hresume&diff=23264hresume2007-11-09T19:52:50Z<p>PaulWilkins: Change #j references to the more meaningful #pedro-name</p>
<hr />
<div><!-- HELP: Can someone please tell me the difference between a specification and a "draft" specification? Thanks. (Dreftymac) --><br />
<h1> hResume </h1><br />
<br />
hResume is a microformat for publishing resumes and CVs. hResume is one of several open microformat standards suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML.<br />
<br />
Want to get started with writing an hResume? Use the [http://hresume.weblogswork.com/hresumecreator/ hResume Creator] to create your hResume and publish it, or follow the hResume authoring tips to add hResume markup to your web page or blog. <br />
<br />
<h2> Microformats Draft Specification </h2><br />
<br />
; Editor/Author: [http://theryanking.com Ryan King]<br />
; Acknowledgments: See [http://microformats.org/wiki/hresume#Acknowledgements acknowledgments].<br />
<br />
Microformats [http://microformats.org/wiki/hresume#Copyright copyright] and [http://microformats.org/wiki/hresume#Patents patents] statements apply.<br />
<br />
{{rfc-2119-intro}}<br />
<br />
__TOC__<br />
<br />
== Status ==<br />
Draft, version 0.1.<br />
<br />
== Introduction ==<br />
=== Semantic XHTML Design Principles ===<br />
{{SemanticXHTMLDesignPrinciples}}<br />
<br />
== Format ==<br />
=== In General ===<br />
The hResume format is based on a set of fields common to numerous resumes published today on the web. Where possible field names have been chosen and reused from preexisting microformats.<br />
<br />
=== Schema ===<br />
The hResume schema consists of the following:<br />
<br />
* hResume<br />
** summary. optional. text.<br />
** contact info. required. {{must}} use [[hcard|hCard]]; {{should}} use <code class="element">&lt;address&gt;</code> + [[hcard|hCard]].<br />
** experience. optional. One or more [[hcalendar]] events with the class name '<code class="class-name">experience</code>', with an embedded [[hcard|hCard]] indicating the job title, name of company, address of company etc.<br />
** education. optional One or more [[hcalendar]] events with the class name '<code class="class-name">education</code>', with an embedded [[hcard|hCard]] indicating the name of school, address of school etc.<br />
** skills. optional. phrases or keywords using the [[rel-tag]] microformat with the class name '<code class="class-name">skill</code>'.<br />
** affiliations. optional. the class name <code class="class-name">affiliation</code> along with an [[hcard]] of the organization<br />
** publications. optional. One or more citations. Use cite tag.<br />
<br />
=== Field details ===<br />
The fields of the hResume schema represent the following:<br />
<br />
* '''<code class="class-name">hresume</code>''':: root class name<br />
* '''<code class="class-name">summary</code>''':: The class name <code class="class-name">summary</code> is used to mark up an overview of qualifications and objectives.<br />
* '''contact''':: Current contact info in an [[hCard]]; {{should}} use <code class="element">&lt;address&gt;</code> with [[hCard]] when possible.<br />
* '''<code class="class-name">education</code>''':: the class name '<code class="class-name">education</code>' is applied to an [[hcalendar]] event.<br />
* '''<code class="class-name">experience</code>''':: the class name '<code class="class-name">experience</code>' is applied to an [[hcalendar]] event. Job titles/positions should use an [[hCard]].<br />
* '''<code class="class-name">skill</code>''':: An hResume may be tagged using the [[rel-tag]] microformat and the '<code class="class-name">skill</code>' class name.<br />
* '''<code class="class-name">affiliation</code>''':: The class name <code="class-name">affiliation</code> is used along with an [[hcard]] of the organization<br />
* '''<code class="class-name">publications</code>''':: just use <code class="element">&lt;cite&gt;</code>. When there is a [[citation]] microformat, then that can be used in combination with the cite element to further markup the components of the citation.<br />
<br />
=== XMDP Profile ===<br />
* [[hresume-profile]] (@TODO)<br />
<br />
=== Notes ===<br />
This section is informative.<br />
<br />
*...<br />
<br />
== Examples ==<br />
=== Summary ===<br />
An example summary:<br />
<br />
<pre><nowiki><br />
<p class="summary"><br />
I have 10 years experience with all Web 2.0 technologies– I've been working with Ajax since 1996, <br />
designing with pastels while others will still using tiled background images and frames...<br />
</p><br />
</nowiki></pre><br />
<br />
=== Contact ===<br />
<pre><nowiki><br />
<address class="vcard"><br />
<span class="fn">Pedro Sanchez</span><br />
<span class="adr"><br />
<span class="street-address">123 Fake St.</span><br />
<span class="locality">Preston</span>, <span class="region">Idaho</span> <span class="postal-code">83263</span><br />
</span><br />
<span>Email: <a class="email" href="mailto:joe@example.com">pedro@vote-for-pedro.com</a></span><br />
<span>Homepage: <a class="url" href="http://vote-for-pedro.com/">vote-for-pedro.com</a></span><br />
<span>Phone: <span class="tel">+01.208.555.4567</span></span><br />
</address><br />
</nowiki></pre><br />
<br />
=== Education ===<br />
<pre><nowiki><br />
<ol class="vcalendar"><br />
<li class="education vevent"><br />
<a class="url summary" href="http://example.edu/">Preston High School</a><br />
(<abbr class="dtstart" title="2001-01-24">2001</abbr> - <abbr class="dtend" title="2005-05-25">2005</abbr>)<br />
</li><br />
...<br />
</nowiki></pre><br />
<br />
=== Experience ===<br />
==== Basic ====<br />
A basic experience event:<br />
<br />
<pre><nowiki><br />
<ol class="vcalendar"><br />
<li class="experience vevent"><br />
<span class="summary">President</span>,<br />
<span class="location">Preston High School</span>,<br />
<abbr class="dtstart" title="2004-09-01">May 2004</abbr> - <abbr title="2005-05-25">present</abbr><br />
</li><br />
...<br />
</nowiki></pre><br />
<br />
==== Job Titles ====<br />
To express one or more job titles/positions in the same experience event you should use one or more [[hcard|hCard]]s. hCard requires the <code class="class-name">fn</code> ("formatted name") field, but it isn't customary to repeat your name for every job title you mark up in [[hResume|hresume]]. So, you may use an <code class="element">&lt;object&gt;</code> and the class name '<code class="class-name">include</code>' with a reference to the <code class="class-name">fn</code> somewhere else on the page. <br />
<br />
Currently, the recommended way to reference includes within microformats is to use a hyperlink with class="include". See [[include-pattern|include-pattern]] for details.<br />
<br />
For example, this hCard refers to another hCard:<br />
<br />
Using <code>&lt;a&gt;</code>:<br />
<pre><br />
<span class="vcard"><br />
<a href="#pedro-name" class="include" title="Pedro Sanchez"></a><br />
<span class="org">Preston High School</span><br />
<span class="title">Class President</span><br />
</span><br />
</pre><br />
<br />
Using <code>&lt;object&gt;</code>:<br />
<pre><br />
<span class="vcard"><br />
<object data="#pedro-name" class="include"></object><br />
<span class="org">Preston High School</span><br />
<span class="title">Class President</span><br />
</span><br />
</pre><br />
<br />
Where "<code class="attr-value">pedro-name</code>" is the id attribute value of the "<code class="mf-prop">fn n</code>" element of the contact hCard at the top of the page, e.g. (shown here as a verbose hCard for purposes of illustration that the reference may be to a subtree, not just a text node):<br />
<br />
<pre><nowiki><br />
<address class="vcard"><br />
<span class="fn n" id="pedro-name"><br />
<span class="given-name">Pedro</span><br />
<span class="family-name">Sanchez</span><br />
</span><br />
</address><br />
</nowiki></pre><br />
<br />
This method of hCard property indirection via an object element [[include-pattern|has been generalized]] to apply to any/all string/text properties in hCard.<br />
<br />
Note: the object data attribute {{must}} be a local ID reference. External references (which would require a consuming application to load an external resource) are not supported by this method.<br />
<br />
=== Skills ===<br />
Some sample skills tags:<br />
<pre><nowiki><br />
I have skills in <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Bow_%28weapon%29">bow hunting</a> <br />
and <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Nunchucks">nunchucks</a>.<br />
</nowiki></pre><br />
<br />
=== Affiliations ===<br />
<pre><nowiki><br />
<span class="affiliation vcard"><span class="fn org">National Honor Society</span></span><br />
</nowiki></pre><br />
<br />
=== Publications ===<br />
<pre><nowiki><br />
<cite>Breeding Ligers for Fun and Magic</cite>, Idaho Press, 2004.<br />
</nowiki></pre><br />
<br />
== Examples in the wild ==<br />
See [[hresume-examples-in-wild]]<br />
<br />
== Implementations ==<br />
This section is '''informative'''.<br />
<br />
The following implementations have been developed which either generate or parse hResumes. If you have an hResume implementation, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page. <br />
<br />
* [http://linkedin.com LinkedIn] generates hResume for all Public Profiles. [http://www.linkedin.com/in/steveganz LinkedIn Public Profile Example].<br />
<br />
* [http://www.antix.co.uk Anthony Johnston] has implemented hResume (Creation and Import) in the [http://cv.antix.co.uk Antix CV Builder], an example resume using this site can be found [http://cv.antix.co.uk/ant here]<br />
** The example resume is ''invalid''; job titles are marked with an hCard that is missing a "fn" (either directly or via object). --[[User:Gazza|Gazza]] 04:23, 1 May 2007 (PDT)<br />
<br />
* The [http://spurinc.com Spur] team has created an hResume WordPress plugin located at [http://hresume.weblogswork.com/?page_id=3 hResume Plugin]. See an example of the hResume markup [http://hresume.weblogswork.com/?page_id=6 here]. Neat feature of the hResume plugin is that it automatically creates a new page for the resume - no cutting and pasting...<br />
<br />
* The [http://www.ssdesigninteractive.com/ssdesign Sajid Saiyed] has created an hResume WordPress plugin located at [http://www.ssdesigninteractive.com/ssdesign/?p=96 Microformat Resume Plugin]. See an example of the hResume markup [http://www.ssdesigninteractive.com/ssdesign/?page_id=95 here].<br />
<br />
* Spur also created a standalone hResume Creator located at [http://hresume.weblogswork.com/hresumecreator/ hResume Creator]. The creator will generate hResume markup ready to cut and paste into your webpage.<br />
<br />
== Copyright ==<br />
* [[User:Tantek|Tantek]]: I release all my contributions to this specification into the public domain and I encourage the other authors to do so as well.<br />
* [[RyanKing]]: I release all of my contributions to the public domain.<br />
<br />
Per the above, and the public domain release on the author, [[User:RyanKing|RyanKing]]'s, user page this specification is released into the public domain.<br />
<br />
{{MicroFormatPublicDomainContributionStatement}}<br />
<br />
== Patents ==<br />
{{MicroFormatPatentStatement}}<br />
<br />
== References ==<br />
=== Normative References ===<br />
* [[hcard|hCard]]<br />
* [[hcalendar|hCalendar]]<br />
* [[include-pattern|include pattern]]<br />
* [http://www.w3.org/TR/REC-html40/ HTML 4]<br />
* [http://www.w3.org/TR/xhtml1/ XHTML]<br />
* [http://gmpg.org/xmdp/ XMDP]<br />
* [[rel-tag| Rel-Tag]]<br />
* [[rfc-2119]]<br />
* @TODO<br />
<br />
=== Informative References ===<br />
* @TODO<br />
<br />
== Acknowledgements ==<br />
=== Concept ===<br />
* [http://theryanking.com/ Ryan King] ([http://technorati.com Technorati])<br />
* [http://tantek.com/ Tantek Çelik] ([http://technorati.com Technorati])<br />
* James Levine ([http://simplyhired.com Simply Hired])<br />
* [http://epeus.blogspot.com/ Kevin Marks] ([http://technorati.com Technorati])<br />
<br />
== Related Pages ==<br />
{{hresume-related-pages}}<br />
<br />
== Further Reading ==<br />
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].</div>PaulWilkinshttps://microformats.org/wiki/index.php?title=include-pattern&diff=23226include-pattern2007-11-07T20:09:32Z<p>PaulWilkins: /* Hyperlink example */</p>
<hr />
<div><h1>Include Pattern</h1><br />
{{TOC-right}}<br />
Initially developed as part of [[resume-brainstorming]], the include pattern is a mechanism to include a portion of data from one area of a page into another area of the same page. The following is documentation for re-use of the pattern in other microformats, and for publishers working with it.<br />
<br />
;Editors: Tantek Çelik<br />
: Ben Ward<br />
<br />
== background ==<br />
<br />
[[hresume|hResume]] needed the ability to include a name from one hCard at the top of a resume — the person's contact details — into into the separate hCards used in the same person's employment history. Repeating so much data would be inconvenient to publishers, irritating to consumers and would not have matched the existing publishing techniques used in Resumes and Curriculum Vitæ. The include pattern is a mechanism to reference data from the same page, avoiding repetition.<br />
<br />
== scope ==<br />
<br />
The include pattern is strictly limited to the scope of the current page. It cannot be used to include content from other URLs.<br />
<br />
== quick reference==<br />
<br />
The include-pattern is a mechanism to include content from one microformat into another microformat elsewhere in the same document, using hyperlinks (recommended) or OBJECT. For example:<br />
<br />
<pre><nowiki><a class="include" href="#author" title="James Levine"></a></nowiki></pre><br />
<pre><nowiki><object class="include" data="#author"></object></nowiki></pre><br />
<br />
In specs which cite the include-pattern, either of the above code snippets will cause a microformats parser to replace the A or OBJECT element with class name "include" with the content fragment with ID "author". Full examples follow.<br />
<br />
== in general==<br />
<br />
To reference includes, use an include element with class name "include" and a document fragment identifier. The content to be included should have an ID attribute set, and that ID should be referenced from the HREF or DATA attribute at the point of inclusion.<br />
<br />
The include element with class name "include" indicates a reference to a sub-tree elsewhere in the document which must be included in-place by microformat parsers. That is, the element with class "include" is _replaced_ in the DOM by the referenced sub-tree.<br />
<br />
To prevent infinite loops, if a class="include" refers to itself or to an ancestor in the parse tree, then it is ignored and has no effect on the parser.<br />
<br />
Per the [[include-pattern#Scope|scope]], the OBJECT 'data' attribute and hyperlink 'href' attribute MUST be local ID references when used as include pattern instances. External references (requiring a consuming application to load an external resource) are not supported by this method.<br />
<br />
There are two HTML elements available to reference includes, hyperlink/Anchor and OBJECT. They are documented below.<br />
<br />
These methods of property indirection via a hyperlink element can apply to any/all properties in class-based microformats, but should only be used where a microformat explicitly states that the include-pattern is a dependency. For example, [[XOXO]] does not reference the include-pattern at this time, so sub-trees cannot be included by reference in XOXO. [[hResume]] and [[hReview]] do reference the include pattern.<br />
<br />
=== Hyperlink ===<br />
<br />
The recommended way to reference includes within microformats is to use a hyperlink.<br />
<br />
==== Hyperlink example====<br />
<br />
Here is an [[hcard|hCard]] from the beginning of a resume, shown here as a verbose hCard.<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<span class="fn n" id="jl-name"><br />
<span class="given-name">James</span> <span class="family-name">Levine</span><br />
</span><br />
</span><br />
</nowiki></pre> <br />
<br />
Elsewhere on the page, a second hCard re-uses the "fn n" content from the first hCard:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<a href="#jl-name" class="include">James</a><br />
<span class="org">SimplyHired</span><br />
<span class="title">Microformat Brainstormer</span><br />
</span><br />
</nowiki></pre> <br />
<br />
A microformat parser must treat the second hCard as follows, with the hyperlink include element completely replaced (including inner-text) by the sub-tree that was referenced:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<span class="fn n" id="jl-name"><br />
<span class="given-name">James</span> <span class="family-name">Levine</span><br />
</span><br />
<span class="org">SimplyHired</span><br />
<span class="title">Microformat Brainstormer</span><br />
</span><br />
</nowiki></pre><br />
<br />
==== notes and issues ====<br />
<br />
Note: The <code>id</code> attribute value in the example "jl-name" was chosen for demonstration purposes. The text of the value has no semantic per the include-pattern other than to connect the source of the include to the destination. Authors {{should}} use good [[POSH]] techniques to choose <code>id</code> and <code>class</code> names.<br />
<br />
Using the hyperlink include pattern causes no known issues in any web browser, as long as hyperlink includes without content are hidden with CSS. See below for details.<br />
<br />
Authors {{should}} supply content text or at least <code>title</code> attribute text for the hyperlink itself. This can require repeating a small piece of information (such as a person's name in an hCard), or including generic text suitable for the context of the page. <br />
<br />
===== accessibility =====<br />
<strong>Hyperlinks presented as an extracted list.</strong> There are two points of view on this. <span id="Accessibility_concerns">The first is that the user experience of Assistive Technology can(might?) be severely degraded by the presence of hyperlinks which do not contain text ('''citation needed''').</span> The second is that the first claim is only a side effect of some Assistive Technologies extracting the hyperlinks in a document and presenting them as a list, and that such technologies / features have no right to do so, and therefore it is not your problem to worry about. See [http://joeclark.org/appearances/atmedia2007/#context Joe Clark: When accessibility is not your problem: Headings and links read out of context], in particular:<br />
<blockquote><p>As writers, we are not authorizing you or Jaws to pull out our link text and remix it. Why don’t you rearrange the sentences, too?</p></blockquote><br />
<br />
<strong>Hyperlinks and tab focusing in common browsers</strong>. As noted in the [http://microformats.org/wiki/include-pattern-feedback include-pattern feedback page], any visible hyperlink used with an <code>href</code> attribute ends up in the browser's tab cycle. This affects all keyboard users (both sighted users that can't/don't operate a mouse, or screen reader users in the extreme case). Even empty hyperlinks receive focus. This can be tested by modifying the code of the original [http://allinthehead.com/demo/include.html a@include test page] to visually follow the tabbing from one hyperlink to the next (using CSS or, for test purposes, subtly changing the <code>href</code>, tabbing through the page, and observing the change in the URL displayed in the browser's status bar). Hyperlinks hidden with CSS <code>display:none</code> do not end up in the browser's tab cycle.<br />
<br />
Thus it is recommended that Hyperlink Include Pattern hyperlinks lacking inline content {{should}} be hidden with CSS. As they have no content, this stylistic change has no net effect on the document's content semantics from a user's perspective.<br />
<br />
=== Object ===<br />
<br />
The Object Include Pattern is semantically superior to the Hyperlink Include; it is being used to embed content into the page. The <code>object</code> element based include was the original developed include pattern. However, there are serious browser compatibility issues that can affect some implementation scenarios and thus the above Hyperlink Include Pattern was developed and is now preferred.<br />
<br />
==== Object example ====<br />
<br />
Here is the same [[hcard|hCard]] from the beginning of the resume in the previous example.<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<span class="fn n" id="jl-name"><br />
<span class="given-name">James</span> <span class="family-name">Levine</span><br />
</span><br />
</span><br />
</nowiki></pre> <br />
<br />
Elsewhere on the page, a second hCard re-uses the "fn n" content from the first hCard:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<object data="#jl-name" class="include"></object><br />
<span class="org">SimplyHired</span><br />
<span class="title">Microformat Brainstormer</span><br />
</span><br />
</nowiki></pre> <br />
<br />
A microformat parser must treat the second hCard as follows, with the <code>object</code> include element completely replaced by the sub-tree that it referenced:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<span class="fn n" id="jl-name"><br />
<span class="given-name">James</span> <span class="family-name">Levine</span><br />
</span><br />
<span class="org">SimplyHired</span><br />
<span class="title">Microformat Brainstormer</span><br />
</span><br />
</nowiki></pre><br />
<br />
This method of hCard property indirection via an object element can apply to any/all properties in class-based microformats.<br />
<br />
=== notes and issues===<br />
* Unlike the hyperlink pattern, the Object Include Pattern does not require any textual fallback. This makes it invisible to Assistive Technology with no adverse affect.<br />
* Apple's Safari (WebKit-based) browser has some rendering issues with this use of <code>object</code>: You should set a width and height of "0" for the include elements to resolve this ('''version(s) affected needed''').<br />
* Bugs have been reported in some web browsers (Internet Explorer, Safari, Firefox) that <code>object</code> elements referencing fragments of the same document erroneously cause the browser to make additional HTTP requests ('''version(s) affected needed'''). For scenarios where HTTP requests are a sensitive performance measure, this makes the Object Include Pattern inappropriate.<br />
* Versions of Microsoft Internet Explorer with ActiveX controls disabled will throw a warning prompt upon finding an <code>object</code> element ('''version(s) affected needed''').<br />
<br />
== acknowledgements ==<br />
<br />
Thanks to discussions and brainstorms with a bunch of folks: [http://theryanking.com/ Ryan King], James Levine, the whole crowd at the [http://mashupcamp.com/index.cgi?HAtomFinalization Microformats specifications working session] at MashupCamp, [http://suda.co.uk/ Brian Suda], [http://randomchaos.com/ Scott Reynen], [http://allinthehead.com/ Drew McLellan].<br />
<br />
== specifications using ==<br />
* [[hresume|hResume]]<br />
* [[hreview|hReview]]<br />
<br />
=== considering ===<br />
All class-based microformats {{should}} consider using and explicitly normatively stating support for the include pattern.<br />
* [[hatom|hAtom]]<br />
* [[hcalendar|hCalendar]]<br />
* [[hcard|hCard]]<br />
<br />
== implementations ==<br />
* X2V implements the [[include-pattern]] when parsing [[hcard|hCards]] and [[hcalendar|hCalendars]] for both object.include and a.include.<br />
<br />
== references ==<br />
<br />
=== normative ===<br />
* HTML 4.01<br />
<br />
=== informative ===<br />
* [[hcard|hCard]]<br />
* [[hresume|hResume]]<br />
* XHTML 1.0<br />
<br />
== related pages==<br />
{{include-pattern-related-pages}}<br />
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].</div>PaulWilkinshttps://microformats.org/wiki/index.php?title=include-pattern&diff=23225include-pattern2007-11-07T20:08:38Z<p>PaulWilkins: /* Hyperlink example */</p>
<hr />
<div><h1>Include Pattern</h1><br />
{{TOC-right}}<br />
Initially developed as part of [[resume-brainstorming]], the include pattern is a mechanism to include a portion of data from one area of a page into another area of the same page. The following is documentation for re-use of the pattern in other microformats, and for publishers working with it.<br />
<br />
;Editors: Tantek Çelik<br />
: Ben Ward<br />
<br />
== background ==<br />
<br />
[[hresume|hResume]] needed the ability to include a name from one hCard at the top of a resume — the person's contact details — into into the separate hCards used in the same person's employment history. Repeating so much data would be inconvenient to publishers, irritating to consumers and would not have matched the existing publishing techniques used in Resumes and Curriculum Vitæ. The include pattern is a mechanism to reference data from the same page, avoiding repetition.<br />
<br />
== scope ==<br />
<br />
The include pattern is strictly limited to the scope of the current page. It cannot be used to include content from other URLs.<br />
<br />
== quick reference==<br />
<br />
The include-pattern is a mechanism to include content from one microformat into another microformat elsewhere in the same document, using hyperlinks (recommended) or OBJECT. For example:<br />
<br />
<pre><nowiki><a class="include" href="#author" title="James Levine"></a></nowiki></pre><br />
<pre><nowiki><object class="include" data="#author"></object></nowiki></pre><br />
<br />
In specs which cite the include-pattern, either of the above code snippets will cause a microformats parser to replace the A or OBJECT element with class name "include" with the content fragment with ID "author". Full examples follow.<br />
<br />
== in general==<br />
<br />
To reference includes, use an include element with class name "include" and a document fragment identifier. The content to be included should have an ID attribute set, and that ID should be referenced from the HREF or DATA attribute at the point of inclusion.<br />
<br />
The include element with class name "include" indicates a reference to a sub-tree elsewhere in the document which must be included in-place by microformat parsers. That is, the element with class "include" is _replaced_ in the DOM by the referenced sub-tree.<br />
<br />
To prevent infinite loops, if a class="include" refers to itself or to an ancestor in the parse tree, then it is ignored and has no effect on the parser.<br />
<br />
Per the [[include-pattern#Scope|scope]], the OBJECT 'data' attribute and hyperlink 'href' attribute MUST be local ID references when used as include pattern instances. External references (requiring a consuming application to load an external resource) are not supported by this method.<br />
<br />
There are two HTML elements available to reference includes, hyperlink/Anchor and OBJECT. They are documented below.<br />
<br />
These methods of property indirection via a hyperlink element can apply to any/all properties in class-based microformats, but should only be used where a microformat explicitly states that the include-pattern is a dependency. For example, [[XOXO]] does not reference the include-pattern at this time, so sub-trees cannot be included by reference in XOXO. [[hResume]] and [[hReview]] do reference the include pattern.<br />
<br />
=== Hyperlink ===<br />
<br />
The recommended way to reference includes within microformats is to use a hyperlink.<br />
<br />
==== Hyperlink example====<br />
<br />
Here is an [[hcard|hCard]] from the beginning of a resume, shown here as a verbose hCard.<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<span class="fn n" id="jl-name"><br />
<span class="given-name">James</span> <span class="family-name">Levine</span><br />
</span><br />
</span><br />
</nowiki></pre> <br />
<br />
Elsewhere on the page, a second hCard re-uses the "fn n" content from the first hCard:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<a href="#jl-name" class="include">James Levine</a><br />
<span class="org">SimplyHired</span><br />
<span class="title">Microformat Brainstormer</span><br />
</span><br />
</nowiki></pre> <br />
<br />
A microformat parser must treat the second hCard as follows, with the hyperlink include element completely replaced (including inner-text) by the sub-tree that was referenced:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<span class="fn n" id="jl-name"><br />
<span class="given-name">James</span> <span class="family-name">Levine</span><br />
</span><br />
<span class="org">SimplyHired</span><br />
<span class="title">Microformat Brainstormer</span><br />
</span><br />
</nowiki></pre><br />
<br />
==== notes and issues ====<br />
<br />
Note: The <code>id</code> attribute value in the example "jl-name" was chosen for demonstration purposes. The text of the value has no semantic per the include-pattern other than to connect the source of the include to the destination. Authors {{should}} use good [[POSH]] techniques to choose <code>id</code> and <code>class</code> names.<br />
<br />
Using the hyperlink include pattern causes no known issues in any web browser, as long as hyperlink includes without content are hidden with CSS. See below for details.<br />
<br />
Authors {{should}} supply content text or at least <code>title</code> attribute text for the hyperlink itself. This can require repeating a small piece of information (such as a person's name in an hCard), or including generic text suitable for the context of the page. <br />
<br />
===== accessibility =====<br />
<strong>Hyperlinks presented as an extracted list.</strong> There are two points of view on this. <span id="Accessibility_concerns">The first is that the user experience of Assistive Technology can(might?) be severely degraded by the presence of hyperlinks which do not contain text ('''citation needed''').</span> The second is that the first claim is only a side effect of some Assistive Technologies extracting the hyperlinks in a document and presenting them as a list, and that such technologies / features have no right to do so, and therefore it is not your problem to worry about. See [http://joeclark.org/appearances/atmedia2007/#context Joe Clark: When accessibility is not your problem: Headings and links read out of context], in particular:<br />
<blockquote><p>As writers, we are not authorizing you or Jaws to pull out our link text and remix it. Why don’t you rearrange the sentences, too?</p></blockquote><br />
<br />
<strong>Hyperlinks and tab focusing in common browsers</strong>. As noted in the [http://microformats.org/wiki/include-pattern-feedback include-pattern feedback page], any visible hyperlink used with an <code>href</code> attribute ends up in the browser's tab cycle. This affects all keyboard users (both sighted users that can't/don't operate a mouse, or screen reader users in the extreme case). Even empty hyperlinks receive focus. This can be tested by modifying the code of the original [http://allinthehead.com/demo/include.html a@include test page] to visually follow the tabbing from one hyperlink to the next (using CSS or, for test purposes, subtly changing the <code>href</code>, tabbing through the page, and observing the change in the URL displayed in the browser's status bar). Hyperlinks hidden with CSS <code>display:none</code> do not end up in the browser's tab cycle.<br />
<br />
Thus it is recommended that Hyperlink Include Pattern hyperlinks lacking inline content {{should}} be hidden with CSS. As they have no content, this stylistic change has no net effect on the document's content semantics from a user's perspective.<br />
<br />
=== Object ===<br />
<br />
The Object Include Pattern is semantically superior to the Hyperlink Include; it is being used to embed content into the page. The <code>object</code> element based include was the original developed include pattern. However, there are serious browser compatibility issues that can affect some implementation scenarios and thus the above Hyperlink Include Pattern was developed and is now preferred.<br />
<br />
==== Object example ====<br />
<br />
Here is the same [[hcard|hCard]] from the beginning of the resume in the previous example.<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<span class="fn n" id="jl-name"><br />
<span class="given-name">James</span> <span class="family-name">Levine</span><br />
</span><br />
</span><br />
</nowiki></pre> <br />
<br />
Elsewhere on the page, a second hCard re-uses the "fn n" content from the first hCard:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<object data="#jl-name" class="include"></object><br />
<span class="org">SimplyHired</span><br />
<span class="title">Microformat Brainstormer</span><br />
</span><br />
</nowiki></pre> <br />
<br />
A microformat parser must treat the second hCard as follows, with the <code>object</code> include element completely replaced by the sub-tree that it referenced:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<span class="fn n" id="jl-name"><br />
<span class="given-name">James</span> <span class="family-name">Levine</span><br />
</span><br />
<span class="org">SimplyHired</span><br />
<span class="title">Microformat Brainstormer</span><br />
</span><br />
</nowiki></pre><br />
<br />
This method of hCard property indirection via an object element can apply to any/all properties in class-based microformats.<br />
<br />
=== notes and issues===<br />
* Unlike the hyperlink pattern, the Object Include Pattern does not require any textual fallback. This makes it invisible to Assistive Technology with no adverse affect.<br />
* Apple's Safari (WebKit-based) browser has some rendering issues with this use of <code>object</code>: You should set a width and height of "0" for the include elements to resolve this ('''version(s) affected needed''').<br />
* Bugs have been reported in some web browsers (Internet Explorer, Safari, Firefox) that <code>object</code> elements referencing fragments of the same document erroneously cause the browser to make additional HTTP requests ('''version(s) affected needed'''). For scenarios where HTTP requests are a sensitive performance measure, this makes the Object Include Pattern inappropriate.<br />
* Versions of Microsoft Internet Explorer with ActiveX controls disabled will throw a warning prompt upon finding an <code>object</code> element ('''version(s) affected needed''').<br />
<br />
== acknowledgements ==<br />
<br />
Thanks to discussions and brainstorms with a bunch of folks: [http://theryanking.com/ Ryan King], James Levine, the whole crowd at the [http://mashupcamp.com/index.cgi?HAtomFinalization Microformats specifications working session] at MashupCamp, [http://suda.co.uk/ Brian Suda], [http://randomchaos.com/ Scott Reynen], [http://allinthehead.com/ Drew McLellan].<br />
<br />
== specifications using ==<br />
* [[hresume|hResume]]<br />
* [[hreview|hReview]]<br />
<br />
=== considering ===<br />
All class-based microformats {{should}} consider using and explicitly normatively stating support for the include pattern.<br />
* [[hatom|hAtom]]<br />
* [[hcalendar|hCalendar]]<br />
* [[hcard|hCard]]<br />
<br />
== implementations ==<br />
* X2V implements the [[include-pattern]] when parsing [[hcard|hCards]] and [[hcalendar|hCalendars]] for both object.include and a.include.<br />
<br />
== references ==<br />
<br />
=== normative ===<br />
* HTML 4.01<br />
<br />
=== informative ===<br />
* [[hcard|hCard]]<br />
* [[hresume|hResume]]<br />
* XHTML 1.0<br />
<br />
== related pages==<br />
{{include-pattern-related-pages}}<br />
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].</div>PaulWilkinshttps://microformats.org/wiki/index.php?title=include-pattern&diff=23201include-pattern2007-11-06T23:05:10Z<p>PaulWilkins: Consistant naming of author in examples</p>
<hr />
<div><h1>Include Pattern</h1><br />
{{TOC-right}}<br />
Initially developed as part of [[resume-brainstorming]], the include pattern is a mechanism to include a portion of data from one area of a page into another area of the same page. The following is documentation for re-use of the pattern in other microformats, and for publishers working with it.<br />
<br />
;Editors: Tantek Çelik<br />
: Ben Ward<br />
<br />
== background ==<br />
<br />
[[hresume|hResume]] needed the ability to include a name from one hCard at the top of a resume — the person's contact details — into into the separate hCards used in the same person's employment history. Repeating so much data would be inconvenient to publishers, irritating to consumers and would not have matched the existing publishing techniques used in Resumes and Curriculum Vitæ. The include pattern is a mechanism to reference data from the same page, avoiding repetition.<br />
<br />
== scope ==<br />
<br />
The include pattern is strictly limited to the scope of the current page. It cannot be used to include content from other URLs.<br />
<br />
== quick reference==<br />
<br />
The include-pattern is a mechanism to include content from one microformat into another microformat elsewhere in the same document, using hyperlinks (recommended) or OBJECT. For example:<br />
<br />
<pre><nowiki><a class="include" href="#author">James Levine</a></nowiki></pre><br />
<pre><nowiki><object class="include" data="#author"></object></nowiki></pre><br />
<br />
In specs which cite the include-pattern, either of the above code snippets will cause a microformats parser to replace the A or OBJECT element with class name "include" with the content fragment with ID "author". Full examples follow.<br />
<br />
== in general==<br />
<br />
To reference includes, use an include element with class name "include" and a document fragment identifier. The content to be included should have an ID attribute set, and that ID should be referenced from the HREF or DATA attribute at the point of inclusion.<br />
<br />
The include element with class name "include" indicates a reference to a sub-tree elsewhere in the document which must be included in-place by microformat parsers. That is, the element with class "include" is _replaced_ in the DOM by the referenced sub-tree.<br />
<br />
To prevent infinite loops, if a class="include" refers to itself or to an ancestor in the parse tree, then it is ignored and has no effect on the parser.<br />
<br />
Per the [[include-pattern#Scope|scope]], the OBJECT 'data' attribute and hyperlink 'href' attribute MUST be local ID references when used as include pattern instances. External references (requiring a consuming application to load an external resource) are not supported by this method.<br />
<br />
There are two HTML elements available to reference includes, hyperlink/Anchor and OBJECT. They are documented below.<br />
<br />
These methods of property indirection via a hyperlink element can apply to any/all properties in class-based microformats, but should only be used where a microformat explicitly states that the include-pattern is a dependency. For example, [[XOXO]] does not reference the include-pattern at this time, so sub-trees cannot be included by reference in XOXO. [[hResume]] and [[hReview]] do reference the include pattern.<br />
<br />
=== Hyperlink ===<br />
<br />
The recommended way to reference includes within microformats is to use a hyperlink.<br />
<br />
==== Hyperlink example====<br />
<br />
Here is an [[hcard|hCard]] from the beginning of a resume, shown here as a verbose hCard.<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<span class="fn n" id="jl-name"><br />
<span class="given-name">James</span> <span class="family-name">Levine</span><br />
</span><br />
</span><br />
</nowiki></pre> <br />
<br />
Elsewhere on the page, a second hCard re-uses the "fn n" content from the first hCard:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<a href="#jl-name" class="include" title="James Levine"></a><br />
<span class="org">SimplyHired</span><br />
<span class="title">Microformat Brainstormer</span><br />
</span><br />
</nowiki></pre> <br />
<br />
A microformat parser must treat the second hCard as follows, with the hyperlink include element completely replaced (including inner-text) by the sub-tree that was referenced:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<span class="fn n" id="jl-name"><br />
<span class="given-name">James</span> <span class="family-name">Levine</span><br />
</span><br />
<span class="org">SimplyHired</span><br />
<span class="title">Microformat Brainstormer</span><br />
</span><br />
</nowiki></pre> <br />
<br />
==== notes and issues ====<br />
<br />
Note: The <code>id</code> attribute value in the example "jl-name" was chosen for demonstration purposes. The text of the value has no semantic per the include-pattern other than to connect the source of the include to the destination. Authors {{should}} use good [[POSH]] techniques to choose <code>id</code> and <code>class</code> names.<br />
<br />
Using the hyperlink include pattern causes no known issues in any web browser, apart from keyboard access problems noted below. <br />
<br />
Authors {{should}} supply content text or at least <code>title</code> attribute text for the hyperlink itself. This can require repeating a small piece of information (such as a person's name in an hCard), or including generic text suitable for the context of the page. <br />
<br />
===== accessibility =====<br />
There are two points of view on this. <span id="Accessibility_concerns">The first is that the user experience of Assistive Technology can(might?) be severely degraded by the presence of hyperlinks which do not contain text ('''citation needed''').</span> The second is that the first claim is only a side effect of some Assistive Technologies extracting the hyperlinks in a document and presenting them as a list, and that such technologies / features have no right to do so, and therefore it is not your problem to worry about. See [http://joeclark.org/appearances/atmedia2007/#context Joe Clark: When accessibility is not your problem: Headings and links read out of context], in particular:<br />
<blockquote><p>As writers, we are not authorizing you or Jaws to pull out our link text and remix it. Why don’t you rearrange the sentences, too?</p></blockquote><br />
<br />
However, this is current behaviour of current user agents. From the [http://microformats.org/about/ microformats about page]: <blockquote>microformats are: [...] adapted to current behaviors and usage patterns</blockquote><br />
<br />
As noted in the [http://microformats.org/wiki/include-pattern-feedback include-pattern feedback page], any hyperlink used with an <code>href</code> attribute ends up in the browser's tab cycle. This affects all keyboard users (both sighted users that can't/don't operate a mouse, or screen reader users in the extreme case). Even empty hyperlinks receive focus. This can be tested by modifying the code of the original [http://allinthehead.com/demo/include.html a@include test page] to visually follow the tabbing from one hyperlink to the next (using CSS or, for test purposes, subtly changing the <code>href</code>, tabbing through the page, and observing the change in the URL displayed in the browser's status bar). <br />
<br />
=== Object ===<br />
<br />
The Object Include Pattern is semantically superior to the Hyperlink Include; it is being used to embed content into the page. The <code>object</code> element based include was the original developed include pattern. However, there are serious browser compatibility issues that can affect some implementation scenarios and thus the above Hyperlink Include Pattern was developed and is now preferred.<br />
<br />
==== Object example ====<br />
<br />
Here is the same [[hcard|hCard]] from the beginning of the resume in the previous example.<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<span class="fn n" id="jl-name"><br />
<span class="given-name">James</span> <span class="family-name">Levine</span><br />
</span><br />
</span><br />
</nowiki></pre> <br />
<br />
Elsewhere on the page, a second hCard re-uses the "fn n" content from the first hCard:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<object data="#jl-name" class="include"></object><br />
<span class="org">SimplyHired</span><br />
<span class="title">Microformat Brainstormer</span><br />
</span><br />
</nowiki></pre> <br />
<br />
A microformat parser must treat the second hCard as follows, with the <code>object</code> include element completely replaced by the sub-tree that it referenced:<br />
<br />
<pre><nowiki><br />
<span class="vcard"><br />
<span class="fn n" id="jl-name"><br />
<span class="given-name">James</span> <span class="family-name">Levine</span><br />
</span><br />
<span class="org">SimplyHired</span><br />
<span class="title">Microformat Brainstormer</span><br />
</span><br />
</nowiki></pre><br />
<br />
This method of hCard property indirection via an object element can apply to any/all properties in class-based microformats.<br />
<br />
=== notes and issues===<br />
* Unlike the hyperlink pattern, the Object Include Pattern does not require any textual fallback. This makes it invisible to Assistive Technology with no adverse affect.<br />
* Apple's Safari (WebKit-based) browser has some rendering issues with this use of <code>object</code>: You should set a width and height of "0" for the include elements to resolve this ('''version(s) affected needed''').<br />
* Bugs have been reported in some web browsers (Internet Explorer, Safari, Firefox) that <code>object</code> elements referencing fragments of the same document erroneously cause the browser to make additional HTTP requests ('''version(s) affected needed'''). For scenarios where HTTP requests are a sensitive performance measure, this makes the Object Include Pattern inappropriate.<br />
* Versions of Microsoft Internet Explorer with ActiveX controls disabled will throw a warning prompt upon finding an <code>object</code> element ('''version(s) affected needed''').<br />
<br />
== acknowledgements ==<br />
<br />
Thanks to discussions and brainstorms with a bunch of folks: [http://theryanking.com/ Ryan King], James Levine, the whole crowd at the [http://mashupcamp.com/index.cgi?HAtomFinalization Microformats specifications working session] at MashupCamp, [http://suda.co.uk/ Brian Suda], [http://randomchaos.com/ Scott Reynen], [http://allinthehead.com/ Drew McLellan].<br />
<br />
== specifications using ==<br />
* [[hresume|hResume]]<br />
* [[hreview|hReview]]<br />
<br />
=== considering ===<br />
All class-based microformats {{should}} consider using and explicitly normatively stating support for the include pattern.<br />
* [[hatom|hAtom]]<br />
* [[hcalendar|hCalendar]]<br />
* [[hcard|hCard]]<br />
<br />
== implementations ==<br />
* X2V implements the [[include-pattern]] when parsing [[hcard|hCards]] and [[hcalendar|hCalendars]] for both object.include and a.include.<br />
<br />
== references ==<br />
<br />
=== normative ===<br />
* HTML 4.01<br />
<br />
=== informative ===<br />
* [[hcard|hCard]]<br />
* [[hresume|hResume]]<br />
* XHTML 1.0<br />
<br />
== related pages==<br />
{{include-pattern-related-pages}}<br />
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].</div>PaulWilkinshttps://microformats.org/wiki/index.php?title=process-issues&diff=21262process-issues2007-09-08T00:50:26Z<p>PaulWilkins: </p>
<hr />
<div><h1>process issues</h1><br />
<br />
These are issues that have been raised about the microformats [[process]] with broadly varying degrees of merit. Thus some issues are <span style="text-transform:uppercase">rejected</span> for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be <span style="text-transform:uppercase">accepted</span> and perhaps cause changes or improved explanations in the spec. <br />
<br />
<strong style="text-transform:uppercase">Important</strong>: Please read the [[process-faq|process FAQ]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.<br />
<br />
Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well.<br />
<br />
__TOC__<br />
<br />
== Closed Issues ==<br />
Resolved issues that have no further actions to take. These will likely be moved to a separate page like [[process-issues-closed]].<br />
* none yet.<br />
<br />
== Resolved Issues ==<br />
Issues that are resolved, but may have outstanding [[to-do]] items. As issues are resolved, they will be moved from the top of the [[process-issues#Issues|issues list]] to the bottom of this section.<br />
* none yet.<br />
<br />
== Issues ==<br />
Please add new issues to the '''bottom''' of the list by copying and pasting the [[hcard-issues#Template|template]]. Please follow-up resolved or rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.<br />
<br />
=== 2007 ===<br />
* {{OpenIssue}} 2007-09-07 raised by [http://wiki.digitalbazaar.com/en/Haudio-case-study#Problems_Encountered_with_Microformats Manu Sporny]<br />
*# Issue 1: What constitutes "Enough Examples"<br />
*# Issue 2: Proper interpretation of W3C standards<br />
*# Issue 3: Keeping up with changes to the process becomes frustrating<br />
<br />
== Template ==<br />
Please use this format (copy and paste this to the end of the list to add your issues):<br />
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].<br />
*# Issue 1: Here is the first issue I have.<br />
*# Issue 2: Here is the second issue I have.<br />
<br />
== Related Pages ==<br />
* [[process]]<br />
* [[process-faq]]</div>PaulWilkinshttps://microformats.org/wiki/index.php?title=hcalendar-brainstorming&diff=17408hcalendar-brainstorming2007-05-04T02:37:59Z<p>PaulWilkins: Correction to date of proposed enddate</p>
<hr />
<div><h1> hCalendar Brainstorming </h1><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 />
__TOC__<br />
<br />
== Authors ==<br />
<br />
* [http://suda.co.uk/ Brian Suda]<br />
* [http://tantek.com/log/ Tantek Çelik]<br />
<br />
== hCalendar authoring best practices ==<br />
<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 />
*## 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 />
Real world example in the wild of a tabular event calendar marked up in this fashion: [http://we05.com/program.cfm Web Essentials 05 Session program].<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 and axis attributes 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 />
<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 />
== 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 />
== 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 />
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://clioweb.org/archive/2006/05/04/css-based-timelines/ CSS-Based Timelines]<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 />
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 namespac<ETH>H �n 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 />
=== 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 />
== 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 />
<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>PaulWilkinshttps://microformats.org/wiki/index.php?title=to-do&diff=13394to-do2007-02-07T02:50:22Z<p>PaulWilkins: Wait for confirmation from O'Reilly on ETel hCard update</p>
<hr />
<div><h1>To Do</h1><br />
<br />
This page is for posting [[microformats]] related shared to do items. If you want to use this page for your microformats related to-do items, create a section with your name on it. The reason we are keeping these all on the same page is to make it easier to tell when people are working on similar things, and to make it more obvious when people help out with other people's tasks. In theory this probably won't scale, but let's first see how it does in practice. :) - [http://tantek.com Tantek]<br />
<br />
__TOC__<br />
<br />
== Lazyweb ==<br />
<br />
Just some nice things, feel free to do any of these.<br />
<br />
=== for all microformats ===<br />
* quick and easy "how to" pages for each microformat. [[use]] is a good overall start.<br />
* brief summary statements for each microformat that explain why it matters, what does it accomplish for the publisher.<br />
* write up [http://microformats.org/discuss/ mailing-list] questions and answers in the appropriate [[faq]] pages.<br />
* validators. See the hReview section below as there has been a request for an hReview validator in particular. See [http://norman.walsh.name/2006/04/13/validatingMicroformats Norman Walsh's blog post "Validating microformats"] for some valuable analysis and validation pseudo-code (prose description), which are useful steps towards building microformat validators.<br />
* Add [http://verselogic.net/projects/wordpress/wordpress-openid-plugin/ OpenID] to Microformats Blog.<br />
<br />
=== hReview ===<br />
* [[hreview|hReview]] support in Ecto (hey Adriaan!), requested by Andy Smith<br />
* an [[hreview|hReview]] validator.<br />
* a semantic, clean css star rating picker (e.g. a UI widget to rate from 1-5 stars)<br />
** both [http://komodomedia.com/blog/index.php/2005/08/24/creating-a-star-rater-using-css/ this] and [http://factorycity.net/demos/drupal/rating/default.html this] have some flaws. Ask [[User:RyanKing|Ryan King]] for an explanation.<br />
<br />
=== hCard ===<br />
* microformatted versions of conference pages<br />
** Wait for confirmation from O'Reilly webmaster on revision of the [http://conferences.oreillynet.com/etel2006/ ETel] [http://conferences.oreillynet.com/pub/w/44/speakers.html speaker's page] with all the speakers marked up with [[hcard|hCard]] and links to "Add hCards to Address Book" etc., similar to the [http://tantek.com/microformats/2005/web2/speakers.html Web 2.0 speakers page which Tantek did a revision of last fall].<br />
* vcard to hcard converter<br />
** would be nice to have a web upload UI that would take one or more vCards from apple's address book and give them back to you as hCards<br />
** [[User:RobertBachmann | RobertBachmann]] suggests starting points:<br />
*** For Ruby: http://vpim.rubyforge.org/ <br />
*** For C: http://freshmeat.net/projects/libvc/<br />
*** For Python: http://www.nongnu.org/python-pdi/<br />
*** For PHP: http://pear.php.net/package/Contact_Vcard_Parse/<br />
* add export support for microformats to [http://www.turingart.com/abForWeb_lan__en.htm AB to Web]<br />
* A mash-up with google maps that will take any url with a hcard (or hcard's) and map the location(s) on a map (similar to [http://austin.adactio.com/ austin.adactio.com])<br />
<br />
=== hCalendar/hCard/hReview editor ===<br />
* onblur in the URL field (e.g. on hCalendar), goes out and tries to retrieve an object of same time (e.g. an hCalendar vevent) from that URL and uses it to autofill the form, same thing if the creator is loaded with that URL prefilled (e.g. due to a ?url=http://example.com/ in the URL that loads the creator).<br />
<br />
=== WordPress patches for microformats ===<br />
* submit patches for WordPress code/templates for microformats improvement<br />
** &lt;address class="vcard"&gt; improvement in post author publication (e.g. home page of http://microformats.org/ )<br />
* Wordpress plugin for microformats, specifically hReview and hCalendar<br />
** See [http://www.surfarama.com/index.php?p=227 lazyweb request]<br />
<br />
=== Yahoo Open Source Library Patches ===<br />
<br />
Several of these could very much be improved with a little microformats markup. Do we just make patches and submit them? Contact Nate Koechley at Yahoo (see Tantek for contact info) to follow-up.<br />
<br />
* [http://developer.yahoo.net/yui/ Yahoo! User Interface Library]<br />
* [http://developer.yahoo.net/ypatterns/ Yahoo! Design Patterns Library]<br />
* [http://www.yuiblog.com Yahoo! User Interface Blog]<br />
<br />
=== Drupal patches for microformats ===<br />
* [http://groups.drupal.org/microformats-in-drupal Microformat Module for Drupal] A group discussing ways to implement microformats in Drupal. Currently looking to support hAtom, hCard and hCalendar to start with. Contact digitalspaghetti at gmail dot com if you are interested in contributing to the project.<br />
<br />
=== Adding Microformats to Existing Pages ===<br />
<br />
* See [[advocacy#Adding_Microformats_to_Existing_Sites|advocacy: Adding microformats to existing sites]].<br />
<br />
<br />
<br />
===rel-tagging on Wikipedia===<br />
Somebody familiar with the "rel-tag" microformat might want to add details, and a link to the relevant page on this Wiki, to the [http://en.wikipedia.org/wiki/Tag_%28metadata%29 Wikipedia page on tagging]. [[User:AndyMabbett|Andy Mabbett]] 14:07, 3 Jan 2007 (PST)<br />
<br />
== Tantek ==<br />
<br />
I'm keeping a few microformats related to-do items here both for my own convenience, and for folks looking to help out with small tasks. If so, just create a new section with your name, and and maybe copy the item there, and put your name next to the item in my list. We'll figure this out as we go along. Thanks, [http://tantek.com Tantek].<br />
<br />
=== overall priority ordering ===<br />
# Protect the community from threats (wiki damage, mailing list pain or noise), repair damage, add measures to reduce future damage<br />
# Help publishers with established microformats: [[hcard|hCard]], [[hcalendar|hCalendar]], [[hreview|hReview]], [[xfolk|xFolk]]<br />
# Help implementers with established microformats<br />
# Wiki cleanup/gardening for existing established microformats<br />
# Site usability<br />
# Iterate on existing established microformats, resolve issues/feedback etc.<br />
# Community dynamics, [[process]] and [[principles]] improvements to help guide new microformats developments<br />
# Emerging in-demand microformats: [[hlisting|hListing]], [[citation]] using abovementioned process and principles improvements.<br />
# New microformat requests<br />
# Other<br />
<br />
=== protect the community ===<br />
* Analyze [[Special:Recentchanges]] and [http://microformats.org/discuss mailing-lists] and:<br />
** add to [[mailing-lists]] policies/guidelines accordingly.<br />
** privately email violaters kindly asking them to improve their behavior<br />
** work with admins on next steps for individuals negatively impacting the community<br />
** recognize noisy/distracting threads on the email list, document responses/answers to such subjects on the appropriate page(s) on the wiki, and reply to those threads with the URLs to the documentation on the wiki. Putting the responses/answers on the wiki helps by hopefully providing preemptive answers to some who might reraise the subjects on the list in the future, and helps the community quickly terminate such threads by using the answers on the wiki.<br />
<br />
=== help publishers ===<br />
* (: [[advocacy]] - add pages/sites that could use microformats, update them with sample markup, find contacts for those pages to get them updated, and send requests to update their sites with microformats including sample markup.<br />
<br />
==== *-authoring microformats wiki pages ====<br />
* Add some tips to [[hcard-authoring]]<br />
** a tutorial on creating an hCard for your site<br />
** specific instructions for common blogging platforms<br />
** instructions for more properties (match at least the set that is in the [http://microformats.org/code/hcard/creator hCard creator])<br />
* Create [[hreview-authoring]] - a tutorial on how to blog reviews so that they'll be aggregated.<br />
<br />
* *-authoring for all microformats: [[hcalendar-authoring]], [[hreview-authoring]], [[xfolk-authoring]], [[hatom-authoring]]<br />
<br />
==== help with microformat examples in the wild ====<br />
Go over all "common" pages (both logged out and logged in states) of the following sites which have some microformats already, and verify each page is as microformatted as it can be with high fidelity [[hcalendar|hCalendar]] and [[hcard|hCard]] etc. Document full support of each implementation's microformats on the implementations page (perhaps create a separate page for each implementation, e.g. [[flickr]], [[upcoming]], [[eventful]] etc.) Document any exceptions as needed. In no particular order:<br />
* Flickr.com (3.5m hCards)<br />
* Upcoming.org (100k hCalendar events, 100k hCard venues)<br />
** home page<br />
* Eventful.com (100k hCalendar events, 100k hCard venues)<br />
* Yahoo! Tech (300k products with hReviews)<br />
* JudysBook.com (???k hReviews)<br />
* ... lots more, get from "Implementations" and "Examples in the Wild" sections of specs.<br />
<br />
=== help implementers ===<br />
* wordpress improvements<br />
** WP admin for new profiles<br />
*** should simply read blog URL<br />
*** look for hcards and parse them<br />
* [http://gmpg.org/xfn/creator XFN Creator] localizations<br />
** Get someone to verify the [http://gmpg.org/xfn/creator-ru XFN Creator Russian localization].<br />
** Add it to the [http://gmpg.org/xfn/tools XFN Tools] page.<br />
** Add rel="alternate" href="creator-ru" &lt;link&gt;s to the other XFN Creators.<br />
* Conference Schedule Creator<br />
** We need to ASAP build a simple conference schedule creator (and editor?) that builds upon the hCalendar creator. We should make it *trivial* for conference organizers to build/edit/publish an [[hcalendar|hCalendar]] schedule for their conference, including auto-generated "Subscribe..." link which produces the proper "webcal:..." link with X2V. Note: see the "axis" and "header" attributes in HTML4, specifically in the section on Tables. (Done. Feedback wanted. [http://dmitry.baranovskiy.com/work/csc/ Conference Schedule Creator])<br />
<br />
=== wiki cleanup ===<br />
==== for all microformat specs ====<br />
* modularize any specs which are > 30K in order to avoid loss/corruption like [http://microformats.org/wiki?title=Special:Contributions&target=Evan Evan's 14 June edits] to [[hcard|hCard]], [[rel-tag]], and [[xoxo|XOXO]].<br />
** [[hcard|hCard]] -<br />
*** [[hcard-examples-in-the-wild]] group/sort by individuals, organizations, and hosting sites. Consider moving largest subsection to its own page as well.<br />
** [[rel-tag]]<br />
** [[xoxo]]<br />
<br />
==== update specification section organization ====<br />
In particular, the introduction/boilerplate/headers. [[hresume|hResume]] has an experimental abbreviated intro/headers section, and links to more details further below, based on some ideas that Ryan King and I had for improving the readability of the microformats specifications. [[hreview|hReview]] has some similar improvements, but different. We need to:<br />
# Figure out if the new intro/headers structure in [[hresume|hResume]] and/or [[hreview|hReview]] is an improvement, and if it could be better. Perhaps figure out the requirements for an intro/header section<br />
#* Shorter tends to be better<br />
#* Must be comprehensive enough to "print and read"<br />
#* Must detail authorship/editorship<br />
#* Must detail copyright/patent statements<br />
# Write up a template - make it self-documenting per the requirements<br />
# Update existing specifications with the new intro/headers structure.<br />
## [[hcard|hCard]]<br />
## [[hcalendar|hCalendar]]<br />
## [[hreview|hReview]]<br />
<br />
==== reorganizing Implementations sections ====<br />
* sort implementations by authoring/creating/publishing, browsing/viewing, converting/importing, indexing/searching.<br />
<br />
Hmmm... I like: '''A'''uthoring, '''B'''rowsing, '''C'''onverting, '''I'''ndexing, '''L'''ibraries (for developers), and '''P'''otential (for open source projects we want to add support to). Anybody have alternative suggestions for this vocabulary? I don't have a particularly strong preference so I'm going to go with these four until I find examples that don't fit, or someone suggests something better.<br />
<br />
See: [http://microformats.org/wiki/hcalendar#Implementations hCalendar Implementations] for a first attempt at this. Assuming folks like that, we can go ahead with categorizing the implementations sections of other microformats specifications.<br />
<br />
* [[hcard-implementations]] - organize by same subsections as [[hcalendar-implementations]].<br />
<br />
==== reorg Examples in the Wild sections ====<br />
* include more *key* details per example, e.g. precise or estimates of counts for services<br />
* collate/sort examples in the wild by <br />
** hosting services - where users/people actively contribute to the growth (e.g. Flickr profile hCards)<br />
** publishing services - where lots of data is published from some datasource/database (e.g. Yahoo! Local)<br />
** companies/groups/organizations member pages (and their own) - pages for a group's site where they list members or employees (e.g. Technorati staff page)<br />
** individiual companies/organizations contact info pages<br />
** individual people's contact info pages<br />
* of course at some point this won't scale, but that will be a very good problem to have, and by then I'm sure we'll have services to point to that provide queries and search results for all this data.<br />
<br />
=== site usability ===<br />
* figure out how to get wordpress to autopost blog posts to the microformats-announce list<br />
** ideally use the from address of the author of the blog post<br />
** maybe photomatt knows how to do this.<br />
<br />
=== iterate on current microformats ===<br />
==== [[hcard|hCard]] ====<br />
* [[hcard-examples]]<br />
** add examples of [[hcard|hCard]]s with work telephone, mailing address etc.<br />
** add examples of marking up an organization vs. a person, then link to it from [http://microformats.org/wiki/hcard#Organization_Contact_Info hCard spec section on Organization Contact Info].<br />
** add example of organization-name and organization-unit usage.<br />
* [[hcard-examples-in-wild]]<br />
** Group examples in the wild according to:<br />
*** Individuals - one card per person, perhaps sort alphabetically<br />
*** Organizations - one card per organization, alphabetical again<br />
*** Institutions (which list more than one person), with a count estimating the # of hCards, e.g. 40k for Avon. Also indicate complexity of information supplied, eg. just name+number vs. complete details<br />
*** Online Profiles (which host profiles for more than one person) with a count estimating the # of hCards, e.g. 3.5m for Flickr.com<br />
*** Online Venues (which provide listings for businesses or organizations) with a count estimating the # of venues, e.g. ~10k for Upcoming.org<br />
*** Speakers Listings (lists of speakers on conference sites) with a count estimating the # of speakers, e.g. ~300 for SXSW 2006.<br />
** help dglazkov markup: http://glazkov.com/blog/archive/2003/12/17/147.aspx<br />
* [[hcard-brainstorming]]<br />
** need property for gender (see [[hcard-faq#How_is_gender_represented|proposal in hCard FAQ]] and discussion in [[hcard-issues]]) - use tags for now, add to hCard creator<br />
** solve [[hcard-brainstorming#Auto-Discovery|autodiscovery]] of more canonical/thorough hCard<br />
<br />
==== [[hcalendar|hCalendar]] ====<br />
* re-add a list of properties per the [[hcard#Property_List|hCard property list]].<br />
* formalize [http://microformats.org/wiki/hcalendar- brainstorming#Tabular_event_calendars]<br />
* flesh out [[hcalendar-examples]] and do a once over on markup/presentation of what RFC2445 examples would look like<br />
* need spec details and then [[hcalendar-examples]] of multi-instance [[hcalendar|hCalendar]] events<br />
* need spec details and then [[hcalendar-examples]] of repeating events<br />
* add explicit explanation and examples for LOCATION [[hcard|hCards]] and ATTENDEE [[hcard|hCards]], perhaps on a separate [[hcalendar-examples]] page.<br />
* need to resolve all outstanding [[hcalendar-issues]] to-do items.<br />
* create [[hcalendar-profile]] and have folks verify it. note that it will likely need reconciliation with the [[hcard-profile]], especially since [[hcalendar|hCalendar]] normatively depends on [[hcard|hCard]]. Probably makes sense to have a combined profile which hCalendar would use.<br />
<br />
==== [[hreview|hReview]] ====<br />
* Write hReview 0.3 XMDP profile, and reconcile with [[hcalendar-profile]] and [[hcard-profile]]. Makes sense to have a combined profile of all three for hReview, since hReview normatively depends on hCard and hCalendar.<br />
<br />
==== summary Examples in the Wild page ====<br />
* need to create a summary / overall [[examples-in-the-wild]] page <br />
** parallel the summary/overall [[implementations]] page.<br />
** use newly reoganized content from the above "reoganizing Examples in the Wild" task<br />
<br />
==== parsing ====<br />
* *-parsing for all microformats: [[hcalendar-parsing]], [[hreview-parsing]], [[xfolk-parsing]], [[hatom-parsing]]<br />
<br />
=== introduction / community ===<br />
* microformats-discuss<br />
** introductory email template for new subscribers needs to direct people to [[process]] and [[how-to-play]]<br />
* Need to add more to the [[naming-principles]], to cover in particular:<br />
** avoid using the same name to mean two things<br />
** avoid using two names to mean the same thing<br />
** seek to keep the microformats vocabulary minimal, memorable, and usable.<br />
* update and add details/simplifications to [[process]] given the past several months of experience. in particular:<br />
** clarify requirement (MUST rather than SHOULD) of *-examples, *-formats, before any *-brainstorming. <br />
** Add details of encouragement to experiment with simple semantic class names from *-brainstorming proposals to gain real world experience with real world content.<br />
** note SHOULD prerequisite of use of all relevant microformats on real world web pages, along with documenting such use in respective "Examples in the Wild" sections, before proposing any new microformats.<br />
<br />
==== principles and process ====<br />
Create the following pages and document/fill them with content from other pages, email lists, and [[presentations]].<br />
* [[principles]] - mostly [[microformats#the_microformats_principles|documented in the microformats]] page.<br />
* clearer statement of both copyright and patents both in specific specs and in general<br />
<br />
==== profiles ====<br />
* update XMDP with new required features:<br />
** ability for one profile to include/import another (rel="import" ?)<br />
** ability to reference an XMDP via rel="profile" (similar to XHTML2 rel value by same name)<br />
** ability/suggestion to reference an XMDP using &lt;a href&gt; in addition to &lt;link&gt;<br />
<br />
==== community mark ====<br />
* Can we make "microformat" and "microformats" into [http://factoryjoe.com/blog/2006/01/14/the-case-for-community-marks/ Community Marks]?<br />
<br />
==== document issue resolutions ====<br />
* Prefixing has already been considered and rejected for microformats in general. Note [[naming-conventions]], limited vocabulary, and exceptions made for [[hatom|hAtom]] and how we went about doing so.<br />
<br />
=== emerging microformats ===<br />
* [[citation]]<br />
* [[hlisting|hListing]]<br />
* [[media-info]]<br />
* [[licensing]]<br />
<br />
=== new microformat requests ===<br />
* expense reports (really just a list of "expense" items), [http://flickr.com/photos/edyson/56774178/ requested by ED], should look at UBL as a pre-existing format<br />
* photo-notes microformat<br />
** clean up Subethaedit notes from working session with Greg Elin, Ryan King, Kevin Marks, Suw Charman and email to folks and figure out next steps<br />
** iterate on [[photo-note-examples]] and start [[photo-note-formats]] and [[photo-note-brainstorming]].<br />
<br />
=== other ===<br />
* Add XPath equivalents where appropriate in [[hcard-parsing]]<br />
<br />
==Ryan==<br />
=== wiki cleanup ===<br />
* possibly move dead proposals off of homepage?<br />
<br />
=== hCalendar/hCard/hReview creator improvements ===<br />
* get all creators working in IE/Win, IE/Mac, Safari/OSX.3<br />
<br />
=== other ===<br />
* add an example of how to use DURATION in hcalendar see http://www.policyawareweb.org/2005/ftf2/paw-mtg#item15) -> verify http://svn.lifelint.com/hcalendar_tests/calendar-todo-multiple-attendees-and-alarm.xml<br />
<br />
=== rel-payment ===<br />
* update rel-payment to reference the IANA registry [http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02055.html]<br />
<br />
=== hcalendar ===<br />
* make sure we explicitly disallow 'vjournal'<br />
<br />
== Dimitri Glazkov ==<br />
<br />
* Figure out REST/Microformats thing<br />
* Work on result set idea<br />
* Implement h-creators using Web Forms 2.0<br />
<br />
== Chris Messina ==<br />
<br />
=== General ===<br />
<br />
* Work on a microformat for play-lists (is it just a XOXO ordererd list of play-items?)<br />
* Work on a microformat for play-item (take a look at [[media-info-examples]])<br />
* Work on microformats tutorial for designers<br />
* Add support for OpenID to micformats wiki<br />
* Add support for [http://verselogic.net/projects/wordpress/wordpress-openid-plugin/ OpenID] to the microformats blog.<br />
* Read GTD (at least the first two chapters).<br />
<br />
=== Campaigns ===<br />
<br />
* Get Blogger to support hAtom and hCard<br />
* <strike>Get LinkedIn to support hCard, hResume, hCalendar</strike> and XFN<br />
* Get XING to support <strike>hCard</strike>, hCalendar, hResume and XFN<br />
* Get Digg to support microformats.<br />
<br />
=== Wishlist ===<br />
<br />
* Microformat for "buyable items" (see [[listing-examples]] and related documents)<br />
* Location MF -- right click "map this" (see [[geo]] and [[adr]])<br />
* Better hCard support in the browser -- right click "IM this person...", "Add to contacts" (see [http://factoryjoe.com/blog/2006/03/20/flocktails-for-flock/ Flocktails])<br />
* Better hCal support -- support many views of same hCal data on one page using XSLT<br />
* We need something that a designer/web programmer can come to and leave w/ 2 examples of each microformat that they can apply right away... a "microformats styleguide for designers", if you will.<br />
* invoicing microformat<br />
* better microformats wiki theme<br />
* Define flow for OpenID + XFN + hcard<br />
<br />
== Robert Bachmann ==<br />
<br />
=== hAtom2Atom ===<br />
<br />
Some ideas for features which could be implemented :<br />
<br />
(If you are interested in one of this features, add "<i>+1 Your Name</i>")<br />
<br />
<ul><br />
<li><br />
Join all hfeed's inside a page (or a fragment thereof) into one feed using [http://greenbytes.de/tech/webdav/rfc4287.html#element.source atom:source] semantics.<br />
</li><br />
<li><br />
Extraction of <code>atom:content</code>, <code>atom:summary</code> and <code>atom:title</code>:<br />
* <code>atom:content</code> and <code>atom:summary</code> as HTML <br />
* <code>atom:content</code> and <code>atom:summary</code> as plain-text<br />
* <code>atom:title</code> as XHTML<br />
* <code>atom:title</code> as HTML<br />
</li><br />
<li>Support for other XSLT engines:<br />
* MSXML<br />
* .Net System.Xml<br />
* Sablotron<br />
* Oracle XSLT<br />
* XT<br />
* hAtom2Atom written using XSL 2.0?<br />
** Do you think this would be useful? I have created a barebones version, doesn't yet take in all the parsing rules yet, but I'd be happy to share. Moving to XSL 2.0 does make things a bit cleaner and more efficient. - Matt Dertinger.<br />
</li><br />
<li>Support for other output formats: (hAtom2<i>xyz</i>.xsl)<br />
* RSS 2.0 (meanwhile use hAtom2Atom.xsl and [http://atom.geekhood.net/ atom2rss.xsl]) -- <i>+1 Matt Dertinger</i><br />
* RSS 1.0 (meanwhile use hAtom2Atom.xsl and [http://cvs.4suite.org/viewcvs/uogbuji/atom2rss.xslt atom2rss.xslt]) -- <i>+1 Matt Dertinger</i><br />
* AtomOWL (meanwhile use hAtom2Atom.xsl and [http://dannyayers.com/2005/11/22/atomowl-xslt-progress/ atom2rdfxml.xsl])-- <i>+1 Matt Dertinger</i><br />
* JSON?<br />
** Does it make sense to consider a canonical representation of microformats (either case by case, or in general) in JSON? E.g. so that a JSON API that returned contact information could return an hCard-equivalent chunk of JSON. - Tantek.<br />
</li><br />
</ul><br />
<br />
([[User:Singpolyma|singpolyma]] 01:02, 9 May 2006 (PDT) -- Not XSLT, but see http://xoxotools.ning.com/hatom2rss.php for hatom to RSS2.0 conversion)<br />
<br />
== Brian Suda ==<br />
=== Citation Microformats ===<br />
* Add all my notes to the Wiki<br />
* Start the process of naming the properties using existing names<br />
<br />
=== X2V ===<br />
Make changes and update site (almost stable)<br />
Get ATTENDEE and other strange attributes working<br />
==== WARNINGS and ERROR ====<br />
work on the warnings and error output for the pre-check in X2V<br />
<br />
=== FAQ ===<br />
* clean-up the MF FAQs<br />
* clean-up FAQs from the major microformats<br />
* pull Questions from the mailing list and document them to the FAQs and example<br />
<br />
== Mark Rickerby ==<br />
<br />
=== Current Tasks ===<br />
<br />
* Follow up on usability review<br />
** Edits to homepage feature box text <br />
** Draft of [[getting-started]] page<br />
* Review content for new pages - [[start-simple]], [[modularity]], [[reuse]], [[humans-first]]<br />
* xoxo datatype examples<br />
** test case lists<br />
** transmitting key/value lists<br />
* practical feedback on hresume<br />
<br />
=== Wishlist ===<br />
<br />
* hmmm<br />
<br />
== Ernest Prabhakar ==<br />
=== Wiki-Thon Proposal ===<br />
Set aside several hours (probably a Friday night US PST) for focused work on the Wiki, including both physical (e.g., a room in the Bay Area) and virtual (IRC/iChat) participants.<br />
<br />
==== Goals ====<br />
# Improve understanding of what needs to be done for Wiki<br />
#* IMHO - this should be done here, in [[to-do]] incrementally. -Tantek<br />
# Tackle larger projects (~1-2 hours) than people usually have time for<br />
#* I'd like to see these projects *documented* first on [[to-do]] before we spend 1-2 hours of a bunch of folk's collective time to go through them. -Tantek<br />
# Motivate community to have fun with otherwise tedious "housecleaning" chores<br />
<br />
==== Agenda (Wishlist) ====<br />
In parallel:<br />
* Coalesce/prioritize existing To-Do items (above)<br />
* Review/revise desired pathways for:<br />
** New users learning about microformats<br />
*** e.g., intro, about, explore, tutorials, etc.<br />
*** cf. [http://www.rubyonrails.com/ Rails] front page<br />
****Get Excited (Why, background, motivation)<br />
****Get Started (What, downloads, getting started)<br />
****Get Better (How, tutorials, )<br />
****Get Involved (Who)<br />
** Microformat lifecycle<br />
*** e.g., research->brainstorm->proposal->spec->maintain<br />
*** see http://theryanking.com/microformats/method.txt --[[User:RyanKing|RyanKing]] 15:35, 22 Feb 2006 (PST)<br />
*** ensure information easy to find, follow, and up-to-date<br />
* Review existing specs for completeness and consistency<br />
* Identify areas of 'bitrot' or 'hole-filling'<br />
* Do it!<br />
<br />
== Dan Connolly ==<br />
<br />
[[User:DanC|DanC]] hopes to sync up on these tasks in [[irc]] roughly<br />
weekly, during Wednesday afternoon (Chicago time) "office hours". See also my [http://esw.w3.org/topic/DanConnolly esw todo list and someday pile].<br />
<br />
* from SxSW in Austin<br />
** build a combined hcalendar/hcard profile; resolve issues in [[profile-uris]].<br />
*** with XSLT transformation to RDF<br />
** finish [[hcard-tests]]<br />
*** figure out [[include-pattern]] boundaries<br />
<br />
* Medium term<br />
** sync [[hcalendar-tests]] and [http://www.w3.org/2002/12/cal/ RDF calendar] tests and CALSIFY<br />
*** reconsider RDF calendar naming conventions<br />
** update my CV/resume using [[hResume]] and [[citation-formats]]<br />
*** get an answer from the CALSIFY WG re [http://lists.w3.org/Archives/Public/www-rdf-calendar/2006Apr/0006.html dtstart and date vs datetime ] 21 Apr 2006<br />
*** refine [[hatom]] so that it's suitable for the workflow around the W3C homepage.<br />
<br />
* from WWW2006<br />
** follow up on GRDDL as escape valve for microformats proposals, much like CSS was an escape valve for HTML tag proposals.<br />
<br />
* Someday pile<br />
** set up a timezone registry based on wikipedia and semantic mediawiki. As discussed in [[datetime-design-pattern]], iCalendar's by-value timezone passing is broken. see [http://lists.w3.org/Archives/Public/www-rdf-calendar/2006Apr/0002.html reconsidering timezones in light of hCalendar and CALSIFY] and [http://dig.csail.mit.edu/breadcrumbs/node/91 Toward Semantic Web data from Wikipedia]<br />
** noodle on a playlist format and some of the media RSS stuff like [[media-info-brainstorming]], [[media-metadata-examples]] (re playlists: XSPF, SMIL, RDF, and microformats 9 Sep 2005)<br />
** check out that hReview bug stuff...<br />
** noodle on [[meeting-minutes-brainstorming]] and [http://esw.w3.org/topic/MeetingRecords MeetingRecords in the esw wiki].<br />
** noodle on clipboard scenarios, esp how RDFa works in the general case but isn't as author-friendly as domain-specific syntaxes.<br />
<br />
[[User:DanC|DanC]] 15:39, 31 May 2006 (PDT)<br />
<br />
== Chris Casciano ==<br />
<br />
[[User:ChrisCasciano|ChrisCasciano]] <br />
<br />
* get around to updating [[hatom-issues]] with some multi feed rules/exceptions.<br />
* <del>Update textpattern plugin with simple hreview support and get a new release out</del><br />
* Redesign placenamehere.com and include hatom<br />
* Follow up with technorati folks on pingerati reviews getting lost (note: this will require publishing more reviews and theen watching them through the update process)<br />
* <del>prototype a NetNewsWire microformat extractor (CSS+AppleScript)</del><br />
<br />
== Drew McLellan ==<br />
<br />
[[User:DrewMcLellan|DrewMcLellan]] <br />
<br />
* Build an hReview profile for [http://allinthehead.com/hkit/ hKit] and test<br />
* Update the [http://www.webstandards.org/action/dwtf/microformats/ Dreamweaver extensions] to mirror recent changes in the online builders<br />
* <del>Publish an hCard to JSON service on [http://tools.microformatic.com/ tools.microformatic.com] using hKit.</del><br />
* Further develop blog comment form hCard collection ideas.<br />
* Version of hReview creator using hKit to import business details from an hCard<br />
<br />
== Christophe Ducamp (french localization) ==<br />
<br />
[[Christophe Ducamp]]<br />
* translate red links on [[Main_Page-fr]]<br />
* localize a [http://www.elanceur.org/microformats/index.html french version] of the official website <br />
** ask authorization to the authors<br />
** migration could be done on any collaborative CMS<br />
** test a cocomment system (based on local-wiki)<br />
** complete with original links <br />
* find experts for peer-reviewing<br />
* update [http://fr.wikipedia.org/wiki/Microformats French-wikipedia:Microformats] via cowriting [http://fr.wikipedia.org/wiki/Discuter:Microformats on discussion page] (directly originated from the english article) + french examples to be found + local resources.<br />
<br />
== Frances Berriman ==<br />
<br />
[[User:Phae|Frances Berriman]]<br />
<br />
* Work on styles for [[zen-garden]] project.<br />
* Style HTML cheatsheet to match Brian Suda's PDF.<br />
* Write simplified help/implementation documents (how tos) for all finalised Microformats.<br />
* Re-organise general FAQ and simplify<br />
** (Feel free to add suggested tasks to my list below:)<br />
*** Help converge on organization efforts ~bewest :-)<br />
<br />
== Ben West (bewest) ==<br />
<br />
[[User:BenWest|bewest]]<br />
* fight spam<br />
* help tend wiki<br />
<br />
=== Vocabulary ===<br />
A lot of knowledge work is about maintaining sets of vocabulary. Now that the vocabulary is emerging, it may be time start making sure everyone is "on the same page," especially since some of the language is highly symbolic.<br />
Terms:<br />
* "boil the ocean" A huge task. "A phrase used in the industry to describe an attempt at something that is way too ambitious. For example, "They're trying to get their site launched by COMDEX. They could easier boil the ocean." from <http://www.netlingo.com/right.cfm?term=boil%20the%20ocean><br />
* microformats: more than one microformat<br />
* microformat: see my definition on http://microformats.org/wiki/what-are-microformats#BenWest<br />
* data fidelity: the extent to which a data format might be considered lossy. eg HTML is often seen as a lossy format because the information parsed out of a resource may not fully match the information orginally encoded. Non-lossy formats have a very high data fidelity, while lossy formats have low data fidelity. Microformats seek to increase data fidelity of html.<br />
* market: the locus of economic forces<br />
<br />
: See [[glossary]]. [[User:AndyMabbett|Andy Mabbett]] 13:57, 7 Dec 2006 (PST)<br />
<br />
=== Creators ===<br />
_Concession_: my plans involve reuse of code, which would involve non-compatible changes with the current inline model. This is a nice feature, so maybe I should be branching instead.<br />
* <strike>Start hatom creator.</strike> http://dichotomize.com/uf/hatom/creator.html<br />
* Code Reuse. These creators are downright handy, and I’ve reimplemented the vcard one on my own site. Instead, let’s make these widgetized. Let’s decide on a more or less canonical html structure and create some javascript that will create the desired microformat. Something as easy to use as new Microformat.hCard($('mycontainer')); would be awesome. Right now, if someone makes an improvement to the hCard creator, the other creators don’t get the benefit. Spec this out!<br />
* About Section. Is there an official creator page? If so, let’s point to that. The about paragraph is getting longer and longer with phrases like “which is based on…” repeated over and over.<br />
* Default all dates to “right now”. Provide an easy to use calendar type widget to change dates.<br />
* hAtom creator: Add multiple. It’d be nice to add an arbitrary number of entries.<br />
* hAtom creator: Optional feed enclosure. Check box to wrap the entry/entries in an hfeed.<br />
* Edit URI: Allow someone to enter a URI and edit whatever microformat is found on the page.<br />
* Optionals. If the format requires, say, a vcard, the creator can defer to an external URI or can trust the user to fill it in later.<br />
* Common stylesheet. I suppose this goes with the reuseable code idea… we have many great coders, we should be reusing eachothers’ work.<br />
* Use Amazon's ECS to pull in information about products when there is an ASIN in the item URI.<br />
<br />
=== Information Architecture ===<br />
'''Help Welcomed! Please leave your name'''<br />
Add complaints to [[wiki-feedback]]!<br />
Helping to make the wiki easier to use. I'd like to see the main page more towards a format like http://simile.mit.edu/solvent/ with the big questions right out front:<br />
* What Is This?<br />
* What can I do here?<br />
* Is there a demo?<br />
* Where can I learn more?<br />
I'd like to change the front page to this kind of design.<br />
==== Support Pages ====<br />
There are several categories of things in the wiki. Can we enumerate them?<br />
* About the Community<br />
** Where to find information.<br />
** Who are the stake holders?<br />
** FAQs<br />
* Web/Architectural Philosophy<br />
** Community Principles<br />
** Why are we doing this?<br />
** XML and Namespaces<br />
** Semantic XHTML<br />
** Common Misconceptions<br />
** Concession and Disposition of Criticism<br />
** FAQs<br />
* Specs<br />
** Examples<br />
** Discussion<br />
** Exploration<br />
** Use Cases<br />
** Implementations<br />
** The spec itself.<br />
<br />
* Tips and Tricks for Authoring ([[User:BenWest|BenWest]] 15:00, 9 Dec 2006 (PST))<br />
** how to author semantic html<br />
** choosing class names<br />
** using HTML's general extension mechanisms<br />
** advocating use<br />
** collaborating/reusing HTML<br />
** debugging HTML: use pastebin, separate out the relevant bits.<br />
** getting help from the community<br />
** applying Microformats.<br />
<br />
Can others agree and or refine this list? Should I take it to the -discuss list? How do we create consensus on how the wiki should be organized in order to make it more usable? And how can we turn that consensus into actionable changes?<br />
<br />
The wiki should also capture wisdom that stems from discussions that don't produce microformats. For example, Chris Messina suggests a "Best Of" page suitable for capturing this kind of wisdom. I think we can think of a given microformat as being at a place in a spectrum that ranges from "not yet thought of", to "interesting but needs work," or even "rejected", and of course including all the stages familiar to the microformats processes (eg examples, brainstorming, etc...).<br />
If there were such a page would it:<br />
* Belong to a microformat? (eg hcard-bestof)<br />
* or to the global namespace? (eg /wiki/wisdom/foobar-format)<br />
(I think Chris Messina suggests that it belongs to a given microformat, but then how do we collect wisdom from non-microformats?)<br />
<br />
Considering that the wiki page named with the microformat (i.e. /wiki/hcard) is the one that people will mostly likely look to first for learning about a particular format, I'd think it'd make more sense and create a more welcoming feel to convert these pages to an intro page introducing the format for the beginner and linking to resources like tutorials and creators. Spec pages would then be relocated to wiki/*-spec -- [[User:Cgriego|Cgriego]] 13:25, 16 Oct 2006 (PDT)<br />
<br />
====Mike Schinkel's Comments====<br />
<br />
My suggestion on the list was for us to use a convention that the entry page (i.e.<br />
http://microformats.org/wiki/hcard) would be an index into a list of<br />
(psuedo) standardized sub pages so that it would be very people to <br />
find what is important to them. For example, is a list of potential sub pages:<br />
<br />
* Microformat<br />
** Specification<br />
** Tutorial<br />
** Examples<br />
** Use cases<br />
** Reference<br />
** Discussion<br />
** Brainstorming (might be combined w/Discussion)<br />
** Implementations<br />
** Related Pages<br />
** Further Reading<br />
** All (Uses Mediawiki's "includes" to create a page including all sub pages; very useful for printing & reading offline)<br />
<br />
These pages would be located respectively at<br />
<br />
* http://microformats.org/wiki/hcard/<br />
** http://microformats.org/wiki/hcard/Specification<br />
** http://microformats.org/wiki/hcard/Tutorial<br />
** http://microformats.org/wiki/hcard/Examples<br />
** http://microformats.org/wiki/hcard/Use_cases<br />
** http://microformats.org/wiki/hcard/Reference<br />
** http://microformats.org/wiki/hcard/Discussion<br />
** http://microformats.org/wiki/hcard/Brainstorming<br />
** http://microformats.org/wiki/hcard/Implementations<br />
** http://microformats.org/wiki/hcard/Related_Pages<br />
** http://microformats.org/wiki/hcard/Further_Reading<br />
** http://microformats.org/wiki/hcard/All<br />
<br />
Please note I am suggesting an architecture not a specific list of sub pages. The list of sub pages should be defined by both reviewing existing information during site reorganization, and then via discussion on the list in an attempt to discover and extract which sub pages are needed for most/all microformats.<br />
<br />
'''NOTE''': This differs from above in that the spec if not viewed as a top level structure but instead the microformat itself and the spec would be under the microformat. In this context "microformat" is a more abstract concept and "spec" is a more concrete thing. Another way to think about it would be that each microformat would have it's own mini home page and then things like "spec" are the pages listed on its home page.<br />
<br />
== Matt Dertinger (Thewhoo) ==<br />
<br />
[[User:Thewhoo]]<br />
<br />
=== hAtom2Atom ===<br />
<ul><br />
<li>Support for other XSLT engines:<br />
* hAtom2Atom written using XSL 2.0<br />
</li><br />
<li>Support for other output formats: (hAtom2<i>xyz</i>.xsl)<br />
* RSS 2.0 (meanwhile use hAtom2Atom.xsl and [http://atom.geekhood.net/ atom2rss.xsl])<br />
* RSS 1.0 (meanwhile use hAtom2Atom.xsl and [http://cvs.4suite.org/viewcvs/uogbuji/atom2rss.xslt atom2rss.xslt])<br />
* AtomOWL (meanwhile use hAtom2Atom.xsl and [http://dannyayers.com/2005/11/22/atomowl-xslt-progress/ atom2rdfxml.xsl])<br />
</li><br />
</ul><br />
<br />
=== Microformats Proposals ===<br />
<ul><br />
<li>rel="disclaimer":<br />
* Purpose: to create a semantic linkage (relationship) between a foot-note or end-note marker and the actual location of the text that the marker refers to.</li><br />
<li>rel="external":<br />
* Purpose: to formalize what is already in existence in the wild. The use of rel="external" to refer to a document that is external or outside of the current domain.</li><br />
</ul><br />
<br />
== Henri Bergius ==<br />
<br />
[[User:HenriBergius|Henri Bergius]]<br />
<br />
* Add hKit support for automatically populating contact details into [http://www.openpsa.org/version2/openpsa/contacts.html OpenPsa Contacts] CRM<br />
* Implement Tail scripts for adding things into Midgard<br />
<br />
== Justin Thorp ==<br />
* Start researching examples for a To-do microformat<br />
<br />
== [[User:MarkLentczner|Mark Lentczner]] ==<br />
<br />
* Get Second Life's event web pages to have proper event microformats data<br />
** Add [[hcard|hCard]] to profile pages<br />
** Add [[hcalendar|hCalendar]] to events listings<br />
* Start pinging pingerati.net/ping/$url when pages are updated<br />
* Collaborate on designing how to integrate microformats, metadata and objects in [http://secondlife.com/ Second Life].<br />
<br />
== [[User:DerrickPallas|Derrick Pallas]] ==<br />
=== microformat proposal: dependancy ===<br />
* looking for examples of directed graphs on the web<br />
* applications in<br />
** software engineering<br />
*** automatically build library dependency trees<br />
*** distribute security alerts to people that link to your code<br />
** any directed, acyclic graph<br />
*** getting dressed in the morning<br />
*** cooking<br />
* orthogonal to xfn<br />
** people don't have versions<br />
*** libfoo requires libbar-2.0 or later<br />
** people don't have optional relationships<br />
*** ex: at build time, compile in SSL support if present<br />
** people don't have exclusive-or relationships<br />
*** ex: in Gentoo, syslog, syslog-ng, and metalog satisfy virtual/syslog<br />
*** ex: the Ruby library RMagick requires ImageMagick xor GraphicsMagick<br />
<br />
== Nick Drago (Drago516) ==<br />
<br />
[[User:Drago516]]<br />
<br />
* work on [[operating-hours]] and [[operating-hours-examples]]</div>PaulWilkins