https://microformats.org/wiki/api.php?action=feedcontributions&feedformat=atom&user=FilMicroformats Wiki - User contributions [en]2026-04-21T08:17:57ZUser contributionsMediaWiki 1.38.4https://microformats.org/wiki/index.php?title=geo&diff=8399geo2006-08-20T11:22:38Z<p>Fil: /* Implementations */ jQuery and geo</p>
<hr />
<div><h1> geo </h1><br />
<br />
'''geo''' (working name, pronounced "gee-oh") is a simple format for marking up geographic latitude longitude information, suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. '''geo''' is a 1:1 representation of the "geo" property in the vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) in XHTML, one of several open [[microformats|microformat]] standards.<br />
__TOC__<br />
<br />
== Draft Specification ==<br />
<br />
=== Editor/Author ===<br />
[http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]<br />
<br />
=== Copyright ===<br />
{{MicroFormatCopyrightStatement2005}}<br />
<br />
=== Patents ===<br />
{{MicroFormatPatentStatement}}<br />
<br />
=== Inspiration and Acknowledgments ===<br />
Thanks to everyone who participated in the [[geo-bof-2005-06-30|Geo Microformat BOF at O'Reilly's Where 2.0 conference]], and in particular to [http://radar.oreilly.com/nat/ Nat Torkington] and Vee McMillen of [http://oreilly.com O'Reilly] for [http://conferences.oreillynet.com/cs/where2005/view/e_sess/7476 arranging and hosting the BOF]. Thanks to Chris Hibbbert for providing the [http://www.geocaching.com/seek/cache_details.aspx?guid=dc4754bf-64d5-4f28-8715-45ad2505c86f real world geo-caching example].<br />
<br />
== Introduction and Background ==<br />
The vCard standard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]), has been broadly and interoperably implemented (e.g. Apple's Address Book application). The [[hcard|hCard]] microformat has similarly received significant adoption, from numerous sites publishing the format, to hCard to vCard proxies, to clientside javascript parsers.<br />
<br />
At the [http://conferences.oreillynet.com/where/ Where 2.0 conference] in June 2005, there was widespread recognition that the community needed a way to simply and easily publish visible, extractable, geographic location information on the Web, given how often bloggers, and numerous other sites publish such information. The [[geo-bof-2005-06-30|geo microformat BOF]] discussed this very topic, and concluded with a consensus decision to just try using ''geo'' from vCard/hCard.<br />
<br />
This specification introduces the '''geo''' microformat, which is a 1:1 representation of the aforementioned ''geo'' property from the vCard standard, by simply reusing the ''geo'' property and sub-properties as-is from the [[hcard|hCard]] microformat.<br />
<br />
Publishers can both embed '''geo''' addresses directly in their web pages and feeds, as well as markup existing latitude/longitude coordinates in the context of the rest of the information in their web pages and feeds.<br />
<br />
If the publisher knows and is publishing the ''name'' of the location in addition to its geo lat/long, then the publisher MUST use [[hcard|hCard]] instead of just '''geo''' to publish the name and geo lat/long of the location.<br />
<br />
If the publisher knows and is publishing the address of the location, OR if the address of the location was what was actually entered by a human, and the publisher simply turned that into lat/long using some sort of a service, then the publisher SHOULD use [[adr]] to publish the actual human entered address information since that communicates far more semantic information than a simple geo lat/long coordinate.<br />
<br />
== Semantic XHTML Design Principles ==<br />
{{semantic-xhtml-design-principles}}<br />
<br />
== Format ==<br />
=== Singular Properties ===<br />
<br />
Note that all the properties in '''geo''' are singular properties, and thus the first descendant element with that class should take effect, any others being ignored.<br />
<br />
=== Human vs. Machine readable ===<br />
<br />
If an <code>&lt;abbr&gt;</code> element is used for a property, then the <code>title</code> attribute of the <code>&lt;abbr&gt;</code> element is the value of the property, instead of the contents of the element, which instead provide a human presentable version of the value.<br />
<br />
=== Value excerpting ===<br />
<br />
Sometimes only part of an element which is the equivalent for a property should be used for the value of the property. For this purpose, the special class name <code>value</code> is used to excerpt out the subset of the element that is the value of the property. See [[hcard|hCard]] for details on this.<br />
<br />
=== Root Class Name ===<br />
<br />
The root class name for an geo location is <code>geo</code>.<br />
<br />
=== Property List ===<br />
<br />
This is the list of properties in geo, taken from [[hcard|hCard]]:<br />
<br />
* latitude<br />
* longitude<br />
<br />
=== XMDP Profile ===<br />
<br />
See [[hcard-profile]] for the [http://gmpg.org/xmdp XMDP] profile of hCard which contains the above complete list of properties, with references to their RFC 2426 definitions.<br />
<br />
=== Parsing Details ===<br />
<br />
See [[hcard-parsing|hCard parsing]], with the only difference being that "geo" is the root class name, rather than "vcard".<br />
<br />
== Examples ==<br />
<br />
This section is informative.<br />
<br />
=== Example from RFC2426 ===<br />
<br />
Section 3.4.2 of RFC2426 has a simple geo example:<br />
<br />
<pre><nowiki><br />
GEO:37.386013;-122.082932<br />
</nowiki></pre><br />
<br />
this vCard fragment as a geo, as [http://microformats.org/wiki/hcard-examples#3.4.2_GEO_Type_Definition first documented on the hCard examples page]:<br />
<br />
<pre><nowiki><br />
<span class="geo"><br />
<span class="latitude">37.386013</span>, <br />
<span class="longitude">-122.082932</span><br />
</span><br />
</nowiki></pre><br />
<br />
this geo could be displayed as: <br />
<br />
37.386013, -122.082932<br />
<br />
<br />
=== Real world geo example ===<br />
<br />
Here is a sample of published lat/long info (from [http://www.geocaching.com/seek/cache_details.aspx?guid=dc4754bf-64d5-4f28-8715-45ad2505c86f geocaching: Noble Steed]):<br />
<br />
<pre><nowiki><br />
N 37° 24.491 W 122° 08.313<br />
</nowiki></pre><br />
<br />
With geo markup:<br />
<br />
<pre><nowiki><br />
<div class="geo"><br />
<abbr class="latitude" title="37.408183">N 37° 24.491</abbr> <br />
<abbr class="longitude" title="-122.13855">W 122° 08.313</abbr><br />
</div><br />
</nowiki></pre><br />
<br />
This geo might be displayed as:<br />
<br />
<abbr class="latitude" title="37.408183">N 37° 24.491</abbr> <br />
<abbr class="longitude" title="-122.13855">W 122° 08.313</abbr><br />
<br />
Note that since the real world example used a more human readable presentation of the geo coordinates, we use the [[abbr-design-pattern]] to keep that more human readable presentation, and in addition provide the respective absolute numerical values for the geo.<br />
<br />
== Examples in the wild ==<br />
This section is '''informative'''.<br />
<br />
The following sites have published geos, outside their normal context of hCards, and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc., in addition to [[hcard|hCard]] examples in the wild. If you find geos outside of hCards anywhere else, feel free to add them to the top of this list. Once the list grows too big, we'll make a separate wiki page.<br />
<br />
* [http://ocono.com/ ocono.com] has marked each of it's "Upcoming Events" items with lat/long values.<br />
* [http://harry.hchen1.com/mylife.htm Harry Chen has marked up his geo location]<br />
* [http://www.multimap.com Multimap.com] uses the geo microformat to mark up latitude and longitude values on map pages.<br />
* [http://rasterweb.net/raster/ Pete Prodoehl] geotags posts on his blog.<br />
* [http://07.pagesd.info/ 07.pagesd.info] uses the geo microformat to mark up latitude and longitude values for each commune of the Ardèche département in France.<br />
* [http://www.openguides.org/ OpenGuides] has support for the geo microformat in svn, and for now you can see it in action on the [http://cotswolds.openguides.org/ Cotswolds OpenGuide]<br />
<br />
== Implementations ==<br />
This section is '''informative'''.<br />
<br />
The following implementations have been developed which either generate or parse geos outside the context of hCards. If you have an geo 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://code.highearthorbit.com/greaseroute/index.php GreaseRoute] is a GreaseMonkey user script (also available as a simple Firefox Extension) which will add icons for displaying the MapQuest map of a [[geo]]. Written by [http://highearthorbit.com Andrew Turner] <br />
* [http://www.podster.de/page/geotest podster.de] finds geo markups in podcast RSS Feeds and maps soundseeing episodes on a map (German only)<br />
* [http://blog.codeeg.com/ Calvin Yu] has written a [http://blog.codeeg.com/2006/01/28/using-microformats-to-plot-my-favorite-places/ web service that will allow you plot and describe places on a Yahoo Map easily] using [[hreview|hReview]] and [[geo]].<br />
* [http://bluesmoon.blogspot.com/ Philip Tellis] has written a [http://bluesmoon.blogspot.com/2006/01/of-microformats-and-geocoding.html javascript to add maps to geo markup on pages]<br />
* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] is a plugin for [http://textpattern.com/ Textpattern] that supports embedding geos and other microformats in templates and blog posts. Written by [http://placenamehere.com/ Chris Casciano].<br />
* [http://bluesmoon.blogspot.com/ Philip Tellis] has written some javascript to [http://bluesmoon.blogspot.com/2006/01/of-microformats-and-geocoding.html convert the geo microformat to a google map] using [[geo]].<br />
* Brian Suda has written some [http://suda.co.uk/projects/microformats/geo/ geo extracting] code to convert geo microformats to KML for use with Google Maps and Google Earth. There is also a bookmarklet to extract the data and pass it to google maps automatically. He is working on a GeoRSS version for Yahoo! Maps as well.<br />
* Fil explains [http://www.jquery.info/spip.php?article7 how to use the geo microformat with the javascript library jQuery] [http://jquery.com].<br />
<br />
== References ==<br />
=== Normative References ===<br />
* [[hcard|hCard]]<br />
<br />
=== Informative References ===<br />
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426] ([http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426])<br />
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]<br />
<br />
=== Similar Work ===<br />
* [[adr]]<br />
* [[hcalendar|hCalendar]]<br />
* [[XOXO]]<br />
<br />
== Work in progress ==<br />
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added.<br />
<br />
== Discussions ==<br />
<br />
* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].<br />
<br />
=== Q&A ===<br />
* If you have any questions about hCard, check the [[hcard-faq|hCard FAQ]] first, and if you don't find answers, add your questions! (Odds are that any geo question will apply to hCard as well).<br />
<br />
=== Issues ===<br />
* Please add any issues with the specification to the separate [[hcard-issues|hCard issues]] document. Ditto.<br />
* Proposals for changes, additions and other thoughts about [[geo]] may be found in the [[hcard-brainstorming|hCard brainstorming]] page.<br />
<br />
== Additional Related Reading and Sites ==<br />
<br />
* [http://www.census.gov/geo/www/tiger/tigermap.html TIGER Map Service]</div>Filhttps://microformats.org/wiki/index.php?title=geo-fr&diff=8450geo-fr2006-08-20T11:21:30Z<p>Fil: /* Implémentations */ jQuery et geo</p>
<hr />
<div><h1> geo </h1><br />
<br />
'''geo''' (nom de travail, prononcé "ji-oh") est un simple format pour baliser l'information latitude longitude, adaptable pour embarquement dans le (X)HTML, Atom, RSS et le XML arbitraire. '''geo''' est une représentation 1:1 de la propriété "geo" dans le standard vCard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]) dans XHTML, l'un des nombreux standards [[microformats|microformat]] ouverts.<br />
__TOC__<br />
<br />
== Spécification Brouillon / Draft ==<br />
<br />
=== Editeur/Auteur ===<br />
[http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]<br />
<br />
=== Traduction en cours ===<br />
<br />
[[Christophe Ducamp]]<br />
<br />
=== Copyright ===<br />
{{MicroFormatCopyrightStatement2005-fr}}<br />
<br />
=== Patents ===<br />
{{MicroFormatPatentStatement-fr}}<br />
<br />
=== Inspiration et Remerciements ===<br />
Merci à tous ceux qui ont participé dans le [[geo-bof-2005-06-30|Geo Microformat BOF à la conférence Where 2.0 de O'Reilly]], et tout particulièrement [http://radar.oreilly.com/nat/ Nat Torkington] et Vee McMillen de [http://oreilly.com O'Reilly] pour [http://conferences.oreillynet.com/cs/where2005/view/e_sess/7476 organiser et héberger le BOF].<br />
Merci à Chris Hibbbert pour avoir fourni [http://www.geocaching.com/seek/cache_details.aspx?guid=dc4754bf-64d5-4f28-8715-45ad2505c86f l'exemple de geo-cache du vrai monde].<br />
<br />
== Introduction et Historique ==<br />
Le standard vCard ([http://www.ietf.org/rfc/rfc2426.txt RFC2426]), a été largement implémenté de façon interopérable (par ex. l'application carnet d'adresses d'Apple). Le microformat [[hcard-fr|hCard]] a de manière similaire reçu une adoption significative de la part de nombreux sites publiant le format des proxies hCards aux vCards, jusqu'aux parseurs javascript côté client.<br />
<br />
A la [http://conferences.oreillynet.com/where/ conférence Where 2.0] en juin 2005, il y a eu une reconnaissance largement acceptée que la communauté avait besoin d'un moyen pour publier simplement et facilement sur le web une information d'adresse qui soit visible, extractible, compte tenu du fait que souvent les blogueurs et les nombreux autres sites publient des informations d'adresses. Le [[geo-bof-2005-06-30|geo microformat BOF]] a discuté tout particulièrement de ce sujet et s'est conclu avec une décision consensuelle de simplement essayer d'utiliser ''geo'' venant de vCard/hCard.<br />
<br />
Cette spécification présente le microformat '''geo''', qui est une représentation 1:1 de la propriété mentionnée ci-dessus ''geo'' extraite du standard vCard en réutilisant simplement la propriété ''geo'' et les sous-propriétés telles quelles extraites du microfomat [[hcard-fr|hCard]].<br />
<br />
Les auteurs peuvent à la fois embarquer directement des adresses '''geo''' dans leurs pages web et fils, tout comme baliser des adresses existantes dans le contexte du reste de l'information dans leurs pages web et fils.<br />
<br />
Si l'auteur connaît et publie le '''name''' de l'endroit en plus de sa geo lat/long, alors l'auteur DOIT utiliser [[hcard-fr|hCard]] au lieu de simplement '''geo''' pour publier le nom et le geo lat/long du lieu.<br />
<br />
Si l'auteur connaît et publie l'adresse du lieu, OU si l'adrese du lieu était ce qui était véritablement saisi par un humain, et que l'auteur ait simplement passé ça en lat/long en utilisant quelque sorte de service, alors l'auteur DEVRAIT utiliser [[adr-fr|adr]] pour publier l'information véritable humaine saisie parce qu'elle communique bien plus d'information sémantique que de simples coordonnées geo lat/long.<br />
<br />
== Principes de Design XHTML Sémantique ==<br />
{{semantic-xhtml-design-principles-fr}}<br />
<br />
== Format ==<br />
=== Propriétés Singulières ===<br />
<br />
Remarquez que toutes les propriétés dans '''geo''' sont des propriétés singulières et par conséquent le premier élément descendant avec cette classe devrait prendre effet, tous les autres étant ignorés.<br />
<br />
=== Lisible Humain vs Machine ===<br />
<br />
Si un élément <code>&lt;abbr&gt;</code> est utilisé pour une propriété, alors l'attribut <code>title</code> de l'élément <code>&lt;abbr&gt;</code> est la valeur de la propriété, au lieu des contenus de l'élément, ce qui fournit à la place une version humainement présentable de la valeur.<br />
<br />
=== Extraction Valeur ===<br />
<br />
Parfois, seule la partie d'un élément qui est l'équivalent pour une propriété devrait être utilisée pour la valeur de la propriété. A cette intention, le le nom de classe <code>value</code> est utilisé pour extraire la partie de l'élément qui est la valeur de la propriété. Voir [[hcard-fr|hCard]] pour les détails à ce sujet.<br />
<br />
=== Nom Classe Racine ===<br />
<br />
Le nom de classe racine pou une adresse '''adr''' est <code>geo</code>.<br />
<br />
=== Liste Propriétés ===<br />
<br />
Ceci est la liste des propriétés dans '''geo''', extraite de [[hcard-fr|hCard]] :<br />
<br />
* latitude<br />
* longitude<br />
<br />
=== Profil XMDP ===<br />
<br />
Voir [[hcard-profile-fr|profil hCard]] pour le profil [http://gmpg.org/xmdp XMDP] de hCard qui contient la liste complète au-dessus des propriétés, avec des références vers leurs définitions RFC 2426.<br />
<br />
=== Détails Parsage ===<br />
Voir [[hcard-parsing-fr|parsage hCard]], avec la seule différence étant que "geo" est le nom de classe racine, plutôt que "vcard".<br />
<br />
<br />
== Exemples ==<br />
<br />
Cette section est informative.<br />
<br />
=== Exemple extrait de RFC2426 ===<br />
<br />
La section 3.4.2 de RFC2426 a un exemple geo simple :<br />
<br />
<pre><nowiki><br />
GEO:37.386013;-122.082932<br />
</nowiki></pre><br />
<br />
ce fragment de vCard comme un geo [http://microformats.org/wiki/hcard-examples-fr#3.4.2_D.C3.A9finition_Type_GEO initialement documenté sur la page des exemples de hCard] :<br />
<br />
<pre><nowiki><br />
<span class="geo"><br />
<span class="latitude">37.386013</span>, <br />
<span class="longitude">-122.082932</span><br />
</span><br />
</nowiki></pre><br />
<br />
ce geo pourrait être affiché sous : <br />
<br />
37.386013, -122.082932<br />
<br />
<br />
=== Exemple geo du vrai monde ===<br />
<br />
Voici un échantillon d'info publiée lat/long (tiré de [http://www.geocaching.com/seek/cache_details.aspx?guid=dc4754bf-64d5-4f28-8715-45ad2505c86f geocaching: Noble Steed]) :<br />
<br />
<pre><nowiki><br />
N 37° 24.491 W 122° 08.313<br />
</nowiki></pre><br />
<br />
avec un balisage geo : <br />
<br />
<pre><nowiki><br />
<div class="geo"><br />
<abbr class="latitude" title="37.408183">N 37° 24.491</abbr> <br />
<abbr class="longitude" title="-122.13855">W 122° 08.313</abbr><br />
</div><br />
</nowiki></pre><br />
<br />
Ce geo pourrait être aussi afficher comme :<br />
<br />
<abbr class="latitude" title="37.408183">N 37° 24.491</abbr> <br />
<abbr class="longitude" title="-122.13855">W 122° 08.313</abbr><br />
<br />
Notez que parce que l'exemple du vrai monde utilisait un présentation lisible humainement des coordonnées géo, nous utilisons le [[abbr-design-pattern-fr|abbr-design-pattern-fr]] pour conserver cette présentation plus lisible humainement, et en plus elle fournit les valeurs numériques respectives absolues pour le geo.<br />
<br />
== Examples dans la jungle ==<br />
Cette section est '''informative'''.<br />
<br />
Les sites suivants ont publié des geo en dehors du contexte normal des hCards, et sont par conséquent un endroit génial pour commencer à regarder des exemples "dans la jungle" afin d'essayer de parser, indexer, organiser, etc., en plus des exemples [[hcard-fr|hCard]] dans la jungle. Si vous trouvez des geos en dehors des hCards n'importe où ailleurs, sentez-vous à l'aise pour les ajouter en haut de cette liste. Une fois que la liste sera devenue trop grosse, nous ferons une page wiki séparée.<br />
<br />
* [http://ocono.com/ ocono.com] a balisé chacun de ses items "Upcoming Events" avec des valeurs lat/long.<br />
* [http://harry.hchen1.com/mylife.htm Harry Chen a balisé son lieu geo]<br />
* [http://www.multimap.com Multimap.com] utilise le geoformat pour baliser les valeurs latitude et longitude sur des pages cartes.<br />
* [http://rasterweb.net/raster/ Pete Prodoehl] geotague les billets sur son blog.<br />
* [http://07.pagesd.info/ 07.pagesd.info] utilise le microformat geo pour baliser les valeurs latitude et longitude pour chaque commune du département d'Ardèche en France.<br />
* [http://www.openguides.org/ OpenGuides] a le support pour le microformat geo dans svn et à cette heure vosu pouvez le voir en action sur l'[http://cotswolds.openguides.org/ OpenGuide Cotswolds]<br />
<br />
== Implémentations ==<br />
Cette section est '''informative'''.<br />
<br />
Les implémentations suivantes ont été développées et soit génèrent ou parsent des geos en dehors du contexte des hCards. Si vous avez une implémentation geo, sentez-vous libre de l'ajouter en haut de la liste. Une fois que la liste sera devenue trop grosse, nous ferons une page wiki séparée.<br />
* [http://code.highearthorbit.com/greaseroute/index.php GreaseRoute] est un script utilisateur GreaseMonkey (disponible aussi sous une simple extenstion Firefox) qui ajoutera des icônes pour l'affichage de la carte MapQuest d'un [[geo-fr|geo]]. Ecrit par [http://highearthorbit.com Andrew Turner]<br />
* [http://www.podster.de/page/geotest podster.de] trouve les balisages geo dans les fils RSS podcast et cartes sonorisées sur une carte (Allemagne seulement)<br />
* [http://blog.codeeg.com/ Calvin Yu] a écrit un [http://blog.codeeg.com/2006/01/28/using-microformats-to-plot-my-favorite-places/ web service qui vous permettra de tracer et décrire facilement des endroits sur une Yahoo Map] utilisant [[hreview-fr|hReview]] and [[geo-fr|geo]].<br />
* [http://bluesmoon.blogspot.com/ Philip Tellis] a écrit un [http://bluesmoon.blogspot.com/2006/01/of-microformats-and-geocoding.html javascript pour ajouter des cartes au balisage geo sur les pages]<br />
* [http://placenamehere.com/TXP/pnh_mf/ pnh_mf] est un plugin for [http://textpattern.com/ Textpattern] qui supporte l'embarquement des geos et autres microformats dans les gabarits et billets de blogs. Ecrit par [http://placenamehere.com/ Chris Casciano].<br />
* [http://bluesmoon.blogspot.com/ Philip Tellis] a écrit quelque javascript pour [http://bluesmoon.blogspot.com/2006/01/of-microformats-and-geocoding.html convertir le microformat geo en une google map] utilisant [[geo-fr|geo]].<br />
* Brian Suda a érit une sorte de code [http://suda.co.uk/projects/microformats/geo/ d'extraction geo] pour convertir les microformats geo vers KML pour utilisation avec Google Maps et Google Earth. Il existe aussi un bookmarklet pour extraire la donnée et la passer automatiquement vers google maps. Il travaille actuellement sur une version GeoRSS pour Yahoo! Maps.<br />
* Fil indique dans un article [http://www.jquery.info/spip.php?article7 comment exploiter le microformat geo avec la librarie javascript jQuery] [http://jquery.com].<br />
<br />
== Références ==<br />
=== Références Normatives ===<br />
* [[hcard-fr|hCard]]<br />
<br />
=== Références Informatives ===<br />
* [http://www.ietf.org/rfc/rfc2426.txt vCard RFC2426] ([http://www.w3.org/2002/12/cal/rfc2426 HTML reformatted version of RFC2426])<br />
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]<br />
<br />
=== Travaux Similaires ===<br />
* [[adr-fr|geo]]<br />
* [[hcalendar-fr|hCalendar]]<br />
* [[XOXO-fr|XOXO]]<br />
<br />
== Chantier en cours ==<br />
Cette spécification est un travail en cours. Au fur et à mesure que des aspects additionnels seront discutés, compris et écrits, ils seront ajoutés.<br />
<br />
== Discussions ==<br />
<br />
* Voir [http://www.technorati.com/cosmos/referer.html les blogs qui discutent de cette page].<br />
<br />
=== Q&R ===<br />
* Si vous avez quelque question à propos de hCard, regardez d'abord les [[hcard-faq-fr|FAQ hCard]] et si vous ne trouvez pas de réponses, ajoutez vos questions ! (Les chances sont celles que toute question '''adr''' s'appliquera tout aussi bien à [[hcard-fr|hCard]]).<br />
<br />
=== Problématiques ===<br />
* SVP, ajoutez toutes les problématiques avec la spécification sur le documen séparé [[hcard-issues-fr|problématiques hCard]]. Ditto.<br />
* Des propositions pour modifications, additions et autres idées à propos de [[geo-fr|geo]] peuvent être trouvées dans la page [[hcard-brainstorming|hCard brainstorming]].<br />
<br />
<br />
== Sites Supplémentaires en Rapport à Consulter ==<br />
<br />
* [http://www.census.gov/geo/www/tiger/tigermap.html TIGER Map Service]</div>Filhttps://microformats.org/wiki/index.php?title=rest/rails&diff=5950rest/rails2006-04-02T08:01:46Z<p>Fil: /* Examples (TBD) */ fix typo</p>
<hr />
<div>= Rails on REST Wish List =<br />
<br />
While nominally focused on specific feature requests to add to Rails, in fact many of these recommendations are also relevant for other frameowrks, and even general "REX".<br />
<br />
== REST-style URIs ==<br />
<br />
That is, make the default URL style:<br />
http://host/base/table/id/style<br />
as in:<br />
http://localhost:3000/mydemo/person/113<br />
<br />
for the default view, with an optional "/edit" on the end for, e.g., forms vs. a list.<br />
<br />
This is subtly different than the current "table/action/id" which scaffolding generates. The central concept in REST is that every object (noun) should have a unique URI, and having an action inlined screws that up.<br />
<br />
=== URL Suffix Proposal ===<br />
<br />
Explicitly allow URL suffixes for alternate representations. Something like:<br />
<br />
;http://host/base/person/1/@table :return entity as a &lt;table> row (XOXT)<br />
&lt;tr>&lt;th scope="col">&lt;abbr title="fn">Full (Formatted) Name&lt;/abbr>&lt;/td>...&lt;/tr><br />
&lt;tr id="person.1">&lt;td class="fn">Ernie Prabhakar&lt;/td>...&lt;/tr><br />
<br />
;http://host/base/person/1/@ol :return entity as an indexed list (XOXO)<br />
&lt;ol id="person.1" class="xoxo"><br />
&lt;li class="fn">Ernie Prabhakar&lt;/li><br />
...<br />
&lt;/ol><br />
<br />
;http://host/base/person/1/@dl :return entity as a keyed dictionary (XOXO)<br />
&lt;dl id="person.1" class="xoxo" ><br />
&lt;dt>&lt;abbr title="fn">Full Name:&lt;/abbr>&lt;/dt>&lt;dd class="fn">Ernie Prabhakar&lt;/dd><br />
...<br />
&lt;/dl><br />
<br />
;http://host/base/person/1/@form :return entity as a POSTable form<br />
&lt;dl id="person.1" class="xoxo" ><br />
&lt;dt>&lt;label for="person.1.fn">&lt;abbr title="fn">Full (Formatted) Name&lt;/abbr>&lt;/label>&lt;/dt><br />
&lt;dd>&lt;input class="fn" type="text" id="person.1.fn" value="Ernie Prabhakar"/>&lt;/dd><br />
...<br />
&lt;/dl><br />
<br />
With presumably one of these as the default (no suffix) representation.<br />
The idea is to:<br />
* extend REST to allow multiple server-side representations<br />
* focus on structure ("form") not actions ("edit")<br />
* make it easy to incorporate partials via AHAH with appropriate structure<br />
* avoid the need to tweak data templates; use CSS to format the result instead<br />
<br />
== POST vs. GET ==<br />
<br />
Right now, as far as I can tell, Rails doesn't differentiate results from a POST vs. results from a GET. Those are semantically different in REST, so I'd like [to know] a way to handle that cleanly. Dan Kubb suggests:<br />
<br />
:What if the behavior for the RESTful dispatcher is to call Person.index ONLY if the corresponding Person.get_index wasn't available? Likewise for PUT requests, it would use Person.index only if Person.put_index wasn't available. I think that would be in-line with standard rails behavior.<br />
<br />
== PUT & DELETE ==<br />
<br />
There should be a standard way to generate web pages that invoke all the HTTP verbs, even if modern browsers don't yet. The microformat for how this is handled today is probably something like:<br />
<br />
<form method="post" action="/person/123"><br />
<!-- ... some other fields containing attributes of the person ... --><br />
<input type="hidden" name="method" value="put" /><br />
<input type="submit" name="method_put" value="Save" /><br />
<input type="submit" name="method_delete" value="Delete" /><br />
</form><br />
<br />
The logic to dispatch is pretty simple:<br />
<br />
def tunneled_method<br />
allowed_methods.find { |m| params['method_' + m] } || params[:method]<br />
end<br />
<br />
A plus to using naming conventions within the form is that<br />
javascript could be written so that when the appropriate button<br />
is clicked a real PUT and DELETE can be done via AJAX.<br />
<br />
== XOXO-style templates ==<br />
<br />
I'd like the default rhtml templates to be XOXO-compatible (e.g., dt/dd rather than &lt;p&gt;/&lt;br&gt;).<br />
<br />
== Columns as class names ==<br />
<br />
In addition to 'human_readable' column names, I'd like there to be a parameter for the equivalent 'css-friendly' representation of those columns -- and for the default templates to include that.<br />
<br />
== Complete, functioning, customizable web application ==<br />
<br />
I want to be able to do something like:<br />
<br />
$ script/generate rex modelA modelB<br />
<br />
And get a full-blown web application which includes:<br />
* the front page, including navigation links to various model objects.<br />
* search boxes<br />
* entry forms<br />
* AHAH (ajax) responses<br />
* both list- and table- oriented model representations<br />
<br />
The ideal is that I could use a combination of CSS and AHAH to generate the desired look, feel, and behavior of my website without actually having to touch existing HTML. As a bonus, I also want it complete enough that I can write a REST-spider to easily discover all the valid URIs and queries. Hey, a guy can dream...<br />
<br />
== XOXO instead of YAML for configuration ==<br />
<br />
Okay, this last one is really nit-picky, and a little odd, but it would (IMHO) be more consistent. Right now, the config is the only non-HTML, non-Ruby file, and I at least had never seen YAML before so it looked out of place. Granted, using XHTML for config files is a little freaky at first, but when you think about it, its no worse than using custom XML tags (and way more interoperable). I'll even write the Ruby serializer myself if I have to...<br />
<br />
== OPTIONS Handling ==<br />
<br />
The controller should be able to handle OPTIONS requests<br />
and know what specific methods it can handle for a given<br />
URI.<br />
<br />
== Output Content Negotiation ==<br />
<br />
It would be nice to be able to have the view look at<br />
the Accept headers and choose the best template to<br />
output.<br />
<br />
For example, imagine you had the following files:<br />
<br />
* index.rhtml<br />
* index.rxml<br />
* index.rtxt<br />
<br />
If the browser sent the Accept as text/html then the<br />
index.rhtml would be used. For text/plain the<br />
index.rtxt would be used, and so on.<br />
<br />
If there was a way for a view handler to "register"<br />
itself and say what mime types it knows how to handle,<br />
then the optimal handler could be chosen at runtime.<br />
The handlers could do anything they want in order<br />
to output the response body, including using libraries<br />
like GD.<br />
<br />
== Input Content Negotiation ==<br />
When a request has a body, it needs to be parsed and<br />
stored into the request parameters. Rails handles<br />
normal web forms and multi-part form input.. but<br />
it would be nice to be able to write custom handlers<br />
that knows how to parse requests for specific<br />
mime-types and set the appropriate request parameters<br />
inside rails.<br />
<br />
This would allow you to POST a web form or a yaml<br />
string and have the values funneled into the same<br />
parameters -- your controller wouldn't care where<br />
the data is come from. I realize yaml is supported<br />
by rails natively, but it should be possible to<br />
register handlers for any other mime types.<br />
<br />
Perl's Catalyst MVC is starting to do this with<br />
their HTTP::Body module.. they made it so you can<br />
write custom modules to parse any mime-types and<br />
set the request parameters.<br />
<br />
== HEAD responses ==<br />
<br />
Responses to HEAD requests should be identical to<br />
GET requests, minus the body. Rails should omit sending<br />
the body for HEAD requests, but still send all the appropriate<br />
headers. Its especially important that the Content-Length be<br />
the same for HEAD and GET responses.<br />
<br />
== Conditional GET requests ==<br />
<br />
When writing mod_perl handlers I was able to do something<br />
equivalent to:<br />
<br />
def get_index<br />
# do some work to set up @resource<br />
set_etag @resource.digest_hash<br />
set_last_modified @resource.updated_at<br />
return not_modified if conditional_get?<br />
render<br />
end<br />
<br />
This resulted in a snappier response from some apps since it<br />
didn't require a full transfer if it was not modified since<br />
my last request.<br />
<br />
== AJAX apps to use HTTP more fully ==<br />
<br />
Most Rails AJAX apps use only GET and POST, but they should be encouraged to use the full set of HTTP verbs in examples.<br />
<br />
Encouragement of Conditional GET in AJAX apps would be a bonus as well.<br />
<br />
= Proposal =<br />
As proposed on April 1st by Charlie Savage, in response to Dan Kubb<br />
<br />
== Syntax ==<br />
The currently proposed syntax is:<br />
<pre> resource :collection do |r| <br />
r.post do <br />
end <br />
end</pre> <br />
Where 'r' is an instance of a Resource class. At first I preferred a simpler syntax, like this:<br />
<pre> resource :collection do <br />
method.post do <br />
end <br />
end</pre> <br />
Where method represents the HTTP verb (GET, POST, PUT)? Or maybe even:<br />
<pre> resource :collection do <br />
request.post? do <br />
end <br />
end</pre> <br />
However, do you have to have an instance of the resource class to achieve the 4 points you brought up (more details in original email):<br />
# Handling OPTIONS requests.<br />
# Returning 405 when appropriate<br />
# Return 501 when appropriate<br />
# Checking If-* request <br />
<br />
These all would be good features to have. If they require having a resource class passed as "r" then I can agree to this approach.<br />
<br />
== Templates ==<br />
You mentioned that you'd expect these responses for different methods:<br />
;GET - 200 OK : Response Body <br />
;POST - 303 See Other : No Response Body, Location header to newly created resource <br />
;PUT - 303 See Other : No Response Body, Location header to resource <br />
;DELETE - 303 See Other : No Response Body, Location header to collection resource <br />
Using regular HTML forms I'd agree. However, this breaks down when using XmlHttpRequest. For example, if I do a post and it fails and I want to return an error message. Doing a redirect is a bit silly since the URL in the browser address bar isn't going to change anyway - its easier to just return the result from the POST. Same is true for a PUT, whether an update is successful or not.<br />
Thus, I think we must provide a system where you can provide a response body regardless of the method. One approach is Peter's proposal of just using a standardized directory structure:<br />
<pre> view<br />
my_controller<br />
resource1<br />
get<br />
put<br />
resource2<br />
post<br />
delete</pre><br />
I like this concept. However, maybe it would be confusing since Rails uses directories for nested classes (MyNamespace::MySubNamespace::MyController). Thus, we could go use the name mangling I currently do now, i.e., get_resource1, or resource1_get (which I like better because it groups the templates for a resource together a bit more clearly). <br />
<br />
== Editors ==<br />
We seem to be in complete agreement. I.E:<br />
;/book/1 : Viewable representation of book #1 retrieved by GET<br />
;/book/1/editor : Editable representation of book #1, will PUT to /book/1<br />
;/book/creator : Form to create a new book, will POST to /book<br />
<br />
== Top Level Resources ==<br />
Here is something Peter and I disagree about. Do you prefer this style:<br />
=== Option #1 ===<br />
<pre> def MyController<br />
resource :collection do |r|<br />
...<br />
end<br />
resource :member do |r|<br />
...<br />
end<br />
resource :editor do |r|<br />
...<br />
end<br />
end</pre><br />
<br />
=== Option #2 ===<br />
Or this:<br />
<pre> def MyController<br />
r.get<br />
...<br />
end<br />
r.post<br />
...<br />
end<br />
resource :member do |r|<br />
...<br />
end<br />
resource :editor do |r|<br />
...<br />
end<br />
end</pre><br />
The difference being in the first case you insist every resource must be defined via "resource" while in the second you say that the controller is the top level resource. When I first did my RestController I went with option #1 because it seemed more elegant. However, I quickly changed my mind when actually writing code because it turned out to be annoying having to add the extra syntax. This was particularly true for controllers that are just single resources. For example, say you have geocoding functionality so you have a GeocoderController. It does just one thing, GETs geocoding results so there is no concept of collection/member. Thus I favor option #2 as a syntax shortcut.<br />
<br />
== Caching ==<br />
Sounds like we've agreed that caching is important, but is not part of the Rest Controller. Thus, you'll split that off the caching functionality into another plugin that can work with a Rest Controller.<br />
<br />
== Implementation ==<br />
I see that your implementation is significantly different than mine. I map :resource to a Ruby module, which gets included in a controller. In contrast, you map :resource to a Ruby method. Within that method you create an instance of a Ruby class called Resource and then execute the provided block in its context. <br />
<br />
This disadvantage of my approach is that there is method renaming that goes on under the scenes, which you have to know about in order to get filters to work correctly. The disadvantage I see to your implementation is that all the methods for a resource get mapped under a single Ruby method. It seems that would make it hard to apply filters to specific methods. I.E., how could I apply a filter to a GET method of the resource Member but not to the POST? It would be great if we could use the existing filter syntax without change, but I'm guessing that might not be reasonable because now we are dealing with Resources and Methods as opposed to Actions. Anyway, this is something I think is important to solve.<br />
<br />
Also, how does your Rest controller interact with the base ActionController? I'm not seeing it being include anywhere...could you point me to the appropriate code.<br />
<br />
== Examples (TBD) ==<br />
<br />
Last, it would be good to have an example controller for people to play with. Something simple, like a ProductController or maybe copying one of the examples from the Agile Web Development book.</div>Filhttps://microformats.org/wiki/index.php?title=hatom&diff=5614hatom2006-03-27T15:34:50Z<p>Fil: /* 0.1 hAtom implementations */ Sedna is hAtom 0.1 compliant now</p>
<hr />
<div><h1> hAtom 0.1 </h1><br />
<br />
hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is based on a subset of the [http://www.atomenabled.org/ Atom] syndication format. hAtom is one of several [[microformats]] open standards.<br />
<br />
__TOC__<br />
== Draft Specification ==<br />
<br />
=== Editor/Author ===<br />
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix.com BlogMatrix, Inc.]<br />
<br />
=== Contributors ===<br />
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]<br />
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]<br />
<br />
=== Copyright ===<br />
{{MicroFormatCopyrightStatement2005}}<br />
<br />
=== Patents ===<br />
{{MicroFormatPatentStatement}}<br />
<br />
== Introduction ==<br />
<br />
hAtom is a [[microformat]] for identifying semantic information in weblog posts and practically any other place [http://www.atomenabled.org/ Atom] may be used, such as news articles. hAtom content is easily added to most blogs by simple modifications to the blog's template definitions.<br />
<br />
== Semantic XHTML Design Principles ==<br />
{{semantic-xhtml-design-principles}}<br />
<br />
== Format ==<br />
=== In General ===<br />
The [http://atomenabled.org/developers/syndication/#person Atom Syndication Format] provides the conceptual basis for this microformat, with the following caveats:<br />
<br />
* Atom provides a lot more functionality that we need for a "blog post" microformat, so we've taken the minimal number of elements needed.<br />
* the "logical" model of hAtom is that of Atom. If there is a conflict, Atom should be taken as correct.<br />
* the "physical" model of hAtom -- the actual writing of elements -- is a lot more varied than Atom provides for, due to the variety of ways weblogs are actually produced in the wild. The hAtom microformat provides a number of rules for "bridging the gap"<br />
<br />
=== Schema ===<br />
Schema elements are based on the Atom nomenclature and follow the microformat pattern of prefixing a unique identifier (in this case, '<code>h</code>') on the outermost container elements -- the Feed or Entry. The parts of this microformat are based on analysis of many weblog, bulletin board and media posts and can be read [[blog-post-brainstorming#Discovered_Elements]].<br />
<br />
The hAtom schema consists of the following:<br />
<br />
* hfeed ('''<code>hfeed</code>'''). optional.<br />
* hentry ('''<code>hentry</code>'''). <br />
** '''<code>entry-title</code>'''. required. text.<br />
** '''<code>entry-content</code>'''. required. text.<br />
** '''<code>entry-summary</code>'''. optional. text.<br />
** '''<code>updated</code>'''. required using [[datetime-design-pattern]].<br />
** '''<code>published</code>'''. optional using [[datetime-design-pattern]].<br />
** '''<code>author</code>'''. required using '''[[hcard|hCard]]'''.<br />
** '''<code>bookmark</code>''' (permalink). optional, using '''[[rel-bookmark]]'''.<br />
** tags. optional. keywords or phrases, using '''[[rel-tag]]'''.<br />
<br />
Some required elements have defaults if missing, see below.<br />
<br />
=== Field and Element Details ===<br />
<br />
===== Feed =====<br />
* a Feed element is identified by the class name <code>hfeed</code><br />
* a Feed element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1 Atom feed]<br />
* the Feed element is optional and, if missing, is assumed to be the page<br />
* hAtom documents MAY have multiple Feed elements<br />
<br />
===== Feed Category =====<br />
* a Feed Category element is identified by [[rel-tag]]<br />
* a Feed MAY have a Feed Category<br />
* a Feed Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside a [http://www.atomenabled.org/developers/syndication/#optionalFeedElements feed]<br />
* Feed Category elements MUST appear inside a Feed element but not inside an Entry element<br />
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code><br />
<br />
===== Entry =====<br />
* an Entry element is identified by class name <code>hentry</code><br />
* an Entry element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom entry]<br />
* any microformat content inside a <code>&lt;blockquote></code> or <code>&lt;q></code> element within the Entry is should not be considered part of the Entry.<br />
: ''This allows quoting other microformated data without worry of corrupting the model''<br />
<br />
===== Entry Category =====<br />
* an Entry Category element is identified by [[rel-tag]]<br />
* an Entry MAY have an Entry Category<br />
* an Entry Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside an [http://www.atomenabled.org/developers/syndication/#optionalEntryElements entry]<br />
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code><br />
<br />
===== Entry Title =====<br />
* an Entry Title element is identified by the class name <code>entry-title</code><br />
* an Entry SHOULD have an Entry Title<br />
* an Entry Title element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.14 Atom entry title]<br />
* if the Entry Title is missing, use<br />
** the first <code>&lt;h#></code> element in the Entry, or<br />
** the <code>&lt;title></code> of the page, if there is no enclosing Feed element, or<br />
** assume it is the empty string<br />
<br />
===== Entry Content =====<br />
* an Entry Content element is identified by class name <code>entry-content</code><br />
* an Entry SHOULD have Entry Content<br />
* an Entry Content element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#atomContent Atom content]<br />
* an Entry MAY have 0 or more Entry Content elements. The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry<br />
: ''Many weblogs split content into multiple sections with a "Read More" link and javascript tricks. This is also needed in cases where Entry Titles are coded inline and are considered part of the content.''<br />
* if the Entry Content is missing, assume it is the empty string<br />
<br />
===== Entry Summary =====<br />
* an Entry Summary element is identified by class name <code>entry-summary</code><br />
* an Entry Summary element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.13 Atom summary]<br />
* an Entry MAY have 0 or more Entry Summary elements. The "logical Entry Summary" of an Entry is the concatenation, in order of appearance, of all the Entry Summarys within the Entry<br />
<br />
===== Entry Permalink =====<br />
* an Entry Permalink element is identified by [[rel-bookmark]]<br />
* an Entry SHOULD have an Entry Permalink<br />
* an Entry Permalink element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7 Atom link in an entry]<br />
* if the Entry Permalink is missing, use the URI of the page; if the Entry has an "id" attribute, add that as a fragment to the page URI to distinguish individual entries<br />
<br />
===== Entry Updated =====<br />
* an Entry Updated element is identified by class name <code>updated</code><br />
* an Entry Updated element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15 Atom updated]<br />
* an Entry SHOULD have an Entry Updated element<br />
* use the [[datetime-design-pattern]] to encode the updated datetime<br />
* if there is no Entry Updated element,<br />
** use the Entry Published element, if present<br />
** otherwise the page is invalid hAtom<br />
<br />
===== Entry Published =====<br />
* an Entry Published element is identified by the class name <code>published</code><br />
* an Entry Published element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9 Atom published]<br />
* use the [[datetime-design-pattern]] to encode the published datetime<br />
<br />
===== Entry Author =====<br />
* an Entry Author element is represented by class name <code>author</code><br />
* an Entry Author element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.1 Atom author]<br />
* an Entry Author element MUST be encoded in an [[hcard|hCard]]<br />
* an Entry Author element SHOULD be encoded in an <code>&lt;address></code> element<br />
* an Entry SHOULD have at least one Entry Author element<br />
* an Entry MAY have more than one Entry Author elements<br />
* if the Entry Author is missing<br />
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code>&lt;address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]<br />
** otherwise the entry is invalid hAtom<br />
<br />
=== XMDP Profile ===<br />
<pre><br />
<dl class="profile"><br />
<dt>class</dt><br />
<dd><p><br />
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class"><br />
HTML4 definition of the 'class' attribute.</a><br />
This meta data profile defines some 'class' attribute values (class names) <br />
and their meanings as suggested by a <br />
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile"><br />
draft of "Hypertext Links in HTML"</a>.<br />
<dl><br />
<dt>hfeed</dt><br />
<dd><br />
The concept of atom:feed from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>hentry</dt><br />
<dd><br />
The concept of atom:entry from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>entry-title</dt><br />
<dd><br />
The concept of atom:title inside of an atom:entry from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>entry-content</dt><br />
<dd><br />
The concept of atom:content from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>entry-summary</dt><br />
<dd><br />
The concept of atom:summary from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>bookmark</dt><br />
<dd><br />
The concept of atom:link (without any "rel") with an atom:entry from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>published</dt><br />
<dd><br />
The concept of atom:published from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>updated</dt><br />
<dd><br />
The concept of atom:updatedfrom <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>author</dt><br />
<dd><br />
The concept of atom:author from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
</dl><br />
</dd><br />
</dl><br />
</pre><br />
<br />
== Examples ==<br />
<br />
See [[hatom-examples]].<br />
<br />
== Examples in the wild ==<br />
This section is '''informative'''.<br />
<br />
=== 0.1 hAtom implementations ===<br />
<br />
* [http://ChunkySoup.net/ ChunkySoup.net] has redesigned using hAtom 0.1 and hCards on the entire site -- by [[User:ChrisCasciano|Chris Casciano]]<br />
* [http://sedna.spip.org/sedna/ Sedna RSS] (a feed aggregator based on SPIP, by Fil, IZO and others; GPLd sources are available at [http://zone.spip.org/trac/spip-zone/browser/_squelettes_/sedna SPIP-Zone])<br />
<br />
=== Pre 0.1 hAtom implementations ===<br />
These pages conform to an older draft standard and need to be updated.<br />
<br />
* [http://blog.davidjanes.com Ranting and Roaring] (David Janes)<br />
* [http://www.myelin.co.nz/post/ Second p0st] (Phil Pearson)<br />
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Sound Advice] (Benjamin Carlyle)<br />
* [http://rbach.priv.at/hAtom2Atom/Changelog/ hAtom2Atom.xsl’s Changelog] is published as hAtom and Atom.<br />
<br />
== Implementations ==<br />
<br />
This section is '''informative'''.<br />
<br />
* [http://rbach.priv.at/hAtom2Atom/ hAtom2Atom.xsl] transforms hAtom to Atom (as the name suggests.)<br />
* There is now an [http://www.lukearno.com/projects/hatom2atom/ hatom2atom proxy] that uses hAtom2Atom.xsl.<br />
<br />
These pages are awaiting updating to 0.1:<br />
<br />
* the [http://www.trinityanne.com/tools/extract/ Almost Universal Microformat Parser] can extract hAtom content from webpages ([http://www.trinityanne.com/tools/extract/?uri=http%3A%2F%2Fblog.davidjanes.com&microformat=hatom&submit=Submit example])<br />
* the [http://www.trinityanne.com/tools/greasemonkey/microformat-action.user.js microformat-action] [[greasemonkey|Greasemonkey]] script detects hAtom content on webpages and will call the [http://www.trinityanne.com/tools/extract/ Almost Universal Microformat Parser]<br />
* the [http://www.blogmatrix.com/tools/rewrite/ hAtom Template Rewriter] converts Blogger, MovableType and Wordpress templates into hAtom compatible ones -- (hopefully) without presentation impact<br />
<br />
== References ==<br />
=== Normative References ===<br />
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]<br />
* [http://www.atomenabled.org/ Atom]<br />
* [[hcard-parsing]]<br />
<br />
=== Informative References ===<br />
<br />
==== Specifications That Use hAtom ====<br />
<br />
==== Similar Work ====<br />
<br />
* [http://rdfs.org/sioc/ Semantically-Interlinked Online Communities (SIOC) RDF Ontology]<br />
<br />
== Work in progress ==<br />
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. There is a separate document where we are keeping our brainstorms and other explorations relating to hAtom:<br />
<br />
* [[blog-post-brainstorming|blog-post Brainstorming]]<br />
<br />
=== Version 0.1 ===<br />
<br />
Version 0.1 was released 28 February 2006.<br />
<br />
== Discussions ==<br />
<br />
* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].<br />
<br />
=== Q&A ===<br />
* If you have any questions about hAtom, check the [[hatom-faq|hAtom FAQ]], and if you don't find answers, add your questions!<br />
<br />
=== Issues ===<br />
* Please add any issues with the specification to the separate [[hatom-issues|hAtom issues]] document.<br />
<br />
<br />
<br />
==See Also==<br />
* [[hatom|hAtom]] - the draft proposal<br />
* [[hatom-hints|hAtom Hints]] - help for implementors<br />
* [[hatom-issues]] - problems? complaints? ideas? Put them here<br />
* [[hatom-faq]] - knowledge base<br />
* [[blog-post-brainstorming]]<br />
* [[blog-post-formats]]<br />
* [[blog-post-examples]]<br />
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)</div>Filhttps://microformats.org/wiki/index.php?title=hatom&diff=5595hatom2006-03-27T15:34:15Z<p>Fil: /* Pre 0.1 hAtom implementations */ sedna is hatom 0.1 compliant now</p>
<hr />
<div><h1> hAtom 0.1 </h1><br />
<br />
hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is based on a subset of the [http://www.atomenabled.org/ Atom] syndication format. hAtom is one of several [[microformats]] open standards.<br />
<br />
__TOC__<br />
== Draft Specification ==<br />
<br />
=== Editor/Author ===<br />
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix.com BlogMatrix, Inc.]<br />
<br />
=== Contributors ===<br />
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]<br />
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]<br />
<br />
=== Copyright ===<br />
{{MicroFormatCopyrightStatement2005}}<br />
<br />
=== Patents ===<br />
{{MicroFormatPatentStatement}}<br />
<br />
== Introduction ==<br />
<br />
hAtom is a [[microformat]] for identifying semantic information in weblog posts and practically any other place [http://www.atomenabled.org/ Atom] may be used, such as news articles. hAtom content is easily added to most blogs by simple modifications to the blog's template definitions.<br />
<br />
== Semantic XHTML Design Principles ==<br />
{{semantic-xhtml-design-principles}}<br />
<br />
== Format ==<br />
=== In General ===<br />
The [http://atomenabled.org/developers/syndication/#person Atom Syndication Format] provides the conceptual basis for this microformat, with the following caveats:<br />
<br />
* Atom provides a lot more functionality that we need for a "blog post" microformat, so we've taken the minimal number of elements needed.<br />
* the "logical" model of hAtom is that of Atom. If there is a conflict, Atom should be taken as correct.<br />
* the "physical" model of hAtom -- the actual writing of elements -- is a lot more varied than Atom provides for, due to the variety of ways weblogs are actually produced in the wild. The hAtom microformat provides a number of rules for "bridging the gap"<br />
<br />
=== Schema ===<br />
Schema elements are based on the Atom nomenclature and follow the microformat pattern of prefixing a unique identifier (in this case, '<code>h</code>') on the outermost container elements -- the Feed or Entry. The parts of this microformat are based on analysis of many weblog, bulletin board and media posts and can be read [[blog-post-brainstorming#Discovered_Elements]].<br />
<br />
The hAtom schema consists of the following:<br />
<br />
* hfeed ('''<code>hfeed</code>'''). optional.<br />
* hentry ('''<code>hentry</code>'''). <br />
** '''<code>entry-title</code>'''. required. text.<br />
** '''<code>entry-content</code>'''. required. text.<br />
** '''<code>entry-summary</code>'''. optional. text.<br />
** '''<code>updated</code>'''. required using [[datetime-design-pattern]].<br />
** '''<code>published</code>'''. optional using [[datetime-design-pattern]].<br />
** '''<code>author</code>'''. required using '''[[hcard|hCard]]'''.<br />
** '''<code>bookmark</code>''' (permalink). optional, using '''[[rel-bookmark]]'''.<br />
** tags. optional. keywords or phrases, using '''[[rel-tag]]'''.<br />
<br />
Some required elements have defaults if missing, see below.<br />
<br />
=== Field and Element Details ===<br />
<br />
===== Feed =====<br />
* a Feed element is identified by the class name <code>hfeed</code><br />
* a Feed element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1 Atom feed]<br />
* the Feed element is optional and, if missing, is assumed to be the page<br />
* hAtom documents MAY have multiple Feed elements<br />
<br />
===== Feed Category =====<br />
* a Feed Category element is identified by [[rel-tag]]<br />
* a Feed MAY have a Feed Category<br />
* a Feed Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside a [http://www.atomenabled.org/developers/syndication/#optionalFeedElements feed]<br />
* Feed Category elements MUST appear inside a Feed element but not inside an Entry element<br />
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code><br />
<br />
===== Entry =====<br />
* an Entry element is identified by class name <code>hentry</code><br />
* an Entry element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom entry]<br />
* any microformat content inside a <code>&lt;blockquote></code> or <code>&lt;q></code> element within the Entry is should not be considered part of the Entry.<br />
: ''This allows quoting other microformated data without worry of corrupting the model''<br />
<br />
===== Entry Category =====<br />
* an Entry Category element is identified by [[rel-tag]]<br />
* an Entry MAY have an Entry Category<br />
* an Entry Category element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.2 Atom category] inside an [http://www.atomenabled.org/developers/syndication/#optionalEntryElements entry]<br />
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code><br />
<br />
===== Entry Title =====<br />
* an Entry Title element is identified by the class name <code>entry-title</code><br />
* an Entry SHOULD have an Entry Title<br />
* an Entry Title element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.14 Atom entry title]<br />
* if the Entry Title is missing, use<br />
** the first <code>&lt;h#></code> element in the Entry, or<br />
** the <code>&lt;title></code> of the page, if there is no enclosing Feed element, or<br />
** assume it is the empty string<br />
<br />
===== Entry Content =====<br />
* an Entry Content element is identified by class name <code>entry-content</code><br />
* an Entry SHOULD have Entry Content<br />
* an Entry Content element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#atomContent Atom content]<br />
* an Entry MAY have 0 or more Entry Content elements. The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry<br />
: ''Many weblogs split content into multiple sections with a "Read More" link and javascript tricks. This is also needed in cases where Entry Titles are coded inline and are considered part of the content.''<br />
* if the Entry Content is missing, assume it is the empty string<br />
<br />
===== Entry Summary =====<br />
* an Entry Summary element is identified by class name <code>entry-summary</code><br />
* an Entry Summary element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.13 Atom summary]<br />
* an Entry MAY have 0 or more Entry Summary elements. The "logical Entry Summary" of an Entry is the concatenation, in order of appearance, of all the Entry Summarys within the Entry<br />
<br />
===== Entry Permalink =====<br />
* an Entry Permalink element is identified by [[rel-bookmark]]<br />
* an Entry SHOULD have an Entry Permalink<br />
* an Entry Permalink element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7 Atom link in an entry]<br />
* if the Entry Permalink is missing, use the URI of the page; if the Entry has an "id" attribute, add that as a fragment to the page URI to distinguish individual entries<br />
<br />
===== Entry Updated =====<br />
* an Entry Updated element is identified by class name <code>updated</code><br />
* an Entry Updated element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15 Atom updated]<br />
* an Entry SHOULD have an Entry Updated element<br />
* use the [[datetime-design-pattern]] to encode the updated datetime<br />
* if there is no Entry Updated element,<br />
** use the Entry Published element, if present<br />
** otherwise the page is invalid hAtom<br />
<br />
===== Entry Published =====<br />
* an Entry Published element is identified by the class name <code>published</code><br />
* an Entry Published element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9 Atom published]<br />
* use the [[datetime-design-pattern]] to encode the published datetime<br />
<br />
===== Entry Author =====<br />
* an Entry Author element is represented by class name <code>author</code><br />
* an Entry Author element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.1 Atom author]<br />
* an Entry Author element MUST be encoded in an [[hcard|hCard]]<br />
* an Entry Author element SHOULD be encoded in an <code>&lt;address></code> element<br />
* an Entry SHOULD have at least one Entry Author element<br />
* an Entry MAY have more than one Entry Author elements<br />
* if the Entry Author is missing<br />
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code>&lt;address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]<br />
** otherwise the entry is invalid hAtom<br />
<br />
=== XMDP Profile ===<br />
<pre><br />
<dl class="profile"><br />
<dt>class</dt><br />
<dd><p><br />
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class"><br />
HTML4 definition of the 'class' attribute.</a><br />
This meta data profile defines some 'class' attribute values (class names) <br />
and their meanings as suggested by a <br />
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile"><br />
draft of "Hypertext Links in HTML"</a>.<br />
<dl><br />
<dt>hfeed</dt><br />
<dd><br />
The concept of atom:feed from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>hentry</dt><br />
<dd><br />
The concept of atom:entry from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>entry-title</dt><br />
<dd><br />
The concept of atom:title inside of an atom:entry from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>entry-content</dt><br />
<dd><br />
The concept of atom:content from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>entry-summary</dt><br />
<dd><br />
The concept of atom:summary from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>bookmark</dt><br />
<dd><br />
The concept of atom:link (without any "rel") with an atom:entry from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>published</dt><br />
<dd><br />
The concept of atom:published from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>updated</dt><br />
<dd><br />
The concept of atom:updatedfrom <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>author</dt><br />
<dd><br />
The concept of atom:author from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
</dl><br />
</dd><br />
</dl><br />
</pre><br />
<br />
== Examples ==<br />
<br />
See [[hatom-examples]].<br />
<br />
== Examples in the wild ==<br />
This section is '''informative'''.<br />
<br />
=== 0.1 hAtom implementations ===<br />
<br />
* [http://ChunkySoup.net/ ChunkySoup.net] has redesigned using hAtom 0.1 and hCards on the entire site -- by [[User:ChrisCasciano|Chris Casciano]]<br />
<br />
=== Pre 0.1 hAtom implementations ===<br />
These pages conform to an older draft standard and need to be updated.<br />
<br />
* [http://blog.davidjanes.com Ranting and Roaring] (David Janes)<br />
* [http://www.myelin.co.nz/post/ Second p0st] (Phil Pearson)<br />
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Sound Advice] (Benjamin Carlyle)<br />
* [http://rbach.priv.at/hAtom2Atom/Changelog/ hAtom2Atom.xsl’s Changelog] is published as hAtom and Atom.<br />
<br />
== Implementations ==<br />
<br />
This section is '''informative'''.<br />
<br />
* [http://rbach.priv.at/hAtom2Atom/ hAtom2Atom.xsl] transforms hAtom to Atom (as the name suggests.)<br />
* There is now an [http://www.lukearno.com/projects/hatom2atom/ hatom2atom proxy] that uses hAtom2Atom.xsl.<br />
<br />
These pages are awaiting updating to 0.1:<br />
<br />
* the [http://www.trinityanne.com/tools/extract/ Almost Universal Microformat Parser] can extract hAtom content from webpages ([http://www.trinityanne.com/tools/extract/?uri=http%3A%2F%2Fblog.davidjanes.com&microformat=hatom&submit=Submit example])<br />
* the [http://www.trinityanne.com/tools/greasemonkey/microformat-action.user.js microformat-action] [[greasemonkey|Greasemonkey]] script detects hAtom content on webpages and will call the [http://www.trinityanne.com/tools/extract/ Almost Universal Microformat Parser]<br />
* the [http://www.blogmatrix.com/tools/rewrite/ hAtom Template Rewriter] converts Blogger, MovableType and Wordpress templates into hAtom compatible ones -- (hopefully) without presentation impact<br />
<br />
== References ==<br />
=== Normative References ===<br />
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]<br />
* [http://www.atomenabled.org/ Atom]<br />
* [[hcard-parsing]]<br />
<br />
=== Informative References ===<br />
<br />
==== Specifications That Use hAtom ====<br />
<br />
==== Similar Work ====<br />
<br />
* [http://rdfs.org/sioc/ Semantically-Interlinked Online Communities (SIOC) RDF Ontology]<br />
<br />
== Work in progress ==<br />
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. There is a separate document where we are keeping our brainstorms and other explorations relating to hAtom:<br />
<br />
* [[blog-post-brainstorming|blog-post Brainstorming]]<br />
<br />
=== Version 0.1 ===<br />
<br />
Version 0.1 was released 28 February 2006.<br />
<br />
== Discussions ==<br />
<br />
* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].<br />
<br />
=== Q&A ===<br />
* If you have any questions about hAtom, check the [[hatom-faq|hAtom FAQ]], and if you don't find answers, add your questions!<br />
<br />
=== Issues ===<br />
* Please add any issues with the specification to the separate [[hatom-issues|hAtom issues]] document.<br />
<br />
<br />
<br />
==See Also==<br />
* [[hatom|hAtom]] - the draft proposal<br />
* [[hatom-hints|hAtom Hints]] - help for implementors<br />
* [[hatom-issues]] - problems? complaints? ideas? Put them here<br />
* [[hatom-faq]] - knowledge base<br />
* [[blog-post-brainstorming]]<br />
* [[blog-post-formats]]<br />
* [[blog-post-examples]]<br />
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)</div>Filhttps://microformats.org/wiki/index.php?title=User:Fil&diff=15507User:Fil2006-03-24T22:01:36Z<p>Fil: </p>
<hr />
<div>Fil is fil * rezo.net, working on [http://www.spip.net/ SPIP] & microformats.<br />
<br />
== Productions ==<br />
<br />
- [http://sedna.spip.org/sedna/ Sedna RSS], an aggregator respecting hAtom 0.1;<br />
<br />
- [http://zone.spip.org/trac/spip-zone/_squelettes_/hBones/ hBones] templates for SPIP with as many microformats as we could;<br />
<br />
- [http://zone.spip.org/trac/spip-zone/_plugins_/hatom2atom/ hAtom2Atom plugin for SPIP] (based on RobertBachmann & al.'s XSLT)<br />
<br />
Fil trolls on the [http://microformats.org/wiki/irc #microformats] and #spip irc channels.</div>Filhttps://microformats.org/wiki/index.php?title=hatom-issues&diff=5615hatom-issues2006-03-24T21:53:16Z<p>Fil: /* author as an hcard is too much to require */ hum... wanted to preview, sorry</p>
<hr />
<div>= hAtom 0.2 =<br />
<br />
This section is for discussing what you'd like to see in the next version of hAtom, i.e. 0.2.<br />
<br />
== Feed <i>XXX</i> (atom:<i>xxx</i>) ==<br />
<br />
Template section: if there is something clearly from an Atom ''Feed'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.<br />
<br />
== Entry <i>XXX</i> (atom:<i>xxx</i>) ==<br />
<br />
Template section: if there is something clearly from an Atom ''Entry'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.<br />
<br />
== Author ==<br />
<br />
=== author as an hcard is too much to require ===<br />
<br />
The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]<br />
<br />
* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a &lt;div class="author"> element.<br />
** [[Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.<br />
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"<br />
** [[User:Fil|Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.<br />
<br />
* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"<br />
** [[Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.<br />
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec<br />
<br />
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki><span class="author"><span class="vcard"><span class="fn">My Name</span></span></span></nowiki></code> ; but it's not good<br />
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki><span class="author vcard"><span class="fn">My Name</span></span></nowiki></code><br />
<br />
== Other Questions and Issues ==<br />
<br />
General comments, modeling issues, algorithm issues, should have issues, etc. go here.<br />
<br />
= hAtom 0.1 =<br />
<br />
'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''<br />
<br />
This page documents the issues that have been raised regarding the [[hatom|hAtom]] draft during the course of its development, and the resolutions of those issues (often with accompanying opinions).<br />
<br />
__TOC__<br />
<br />
== Contributors ==<br />
* Danny Ayers<br />
* Robert Bachmann<br />
* Paul Bryson<br />
* Benjamin Carlyle<br />
* Chris Casciano<br />
* Tantek Çelik<br />
* David Janes<br />
* Ryan King<br />
* Kevin Marks<br />
* Scott Reynen<br />
* Brian<br />
<br />
== Feed (atom:feed)==<br />
<br />
[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' and not required (a la [[hcalendar]])''' <br />
<br />
=== Initial proposal ===<br />
<br />
<code>atomfeed</code> (or rather, "atom-entry")<br />
<br />
* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?<br />
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking<br />
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases<br />
* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML<br />
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.<br />
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.<br />
* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)<br />
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) -- <br />
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".<br />
* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:<br />
** atom-feed<br />
** hfeed<br />
<br />
=== Alternatives ===<br />
<br />
The above proposal was not fully accepted and some other possibilities were proposed:<br />
<br />
* <code>feed</code> (Atom consistency)<br />
* <code>atom-feed</code> (Atom consistency with prefix)<br />
* <code>hfeed</code> (h* uF consistency)<br />
** +1 DavidJanes<br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 MarkRickerby<br />
** +1 DannyAyers<br />
<br />
==== Discussion ====<br />
<br />
The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[Tantek]]<br />
<br />
== Entry (atom:entry) ==<br />
<br />
[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''<br />
<br />
=== Initial Proposal ===<br />
<br />
<code>atomentry</code> (or rather, "atom-entry")<br />
<br />
* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.<br />
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:<br />
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.<br />
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)<br />
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both<br />
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)<br />
*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...<br />
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del><br />
*** [[Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:<br />
**** atom-entry<br />
**** hentry<br />
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])<br />
<br />
=== Alternatives ===<br />
The above proposal was not fully accepted. Other alternatives:<br />
<br />
* <code>entry</code> (Atom consistency)<br />
** +1 [[MarkRickerby]]<br />
* <code>atom-entry</code> (Atom consistency with prefix)<br />
* <code>hentry</code> (h* uF consistency)<br />
** +1 [[DavidJanes]]<br />
** +1 [[Tantek]]<br />
** +1 [[BenjaminCarlyle]]<br />
** +1 [[RyanKing]]<br />
** +1 [[MarkRickerby]]<br />
** +1 [[DannyAyers]]<br />
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])<br />
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption<br />
<br />
==== Discussion ====<br />
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p><br />
<br />
== Entry Title (atom:title) ==<br />
<br />
[[RyanKing]]: '''STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content' '''<br />
<br />
=== proposals ===<br />
<br />
The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):<br />
<br />
* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL<br />
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.<br />
** -1 [[KevinMarks]] (clashes with atom)<br />
* <code>Subject</code>, as used by SMTP email<br />
** -1 [[RyanKing]] - different semantics, doesn't fit<br />
* <code>heading</code><br />
** -1 [[RyanKing]] - a replication of &lt;h*&gt; semantics in html<br />
* <code>entry-title</code><br />
* <code>headline</code><br />
** +1 [[Tantek]]<br />
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]<br />
** +1 [[BenjaminCarlyle]], atom:entry/title only<br />
** +&frac12; [[DavidJanes]], atom:entry/title only<br />
** +&frac12; [[PaulBryson]], redundant?<br />
* <code>title</code> (Atom consistency)<br />
** -1 [[Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.<br />
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)<br />
** +&frac12; [[PaulBryson]], clear=good / hyphenating=bad<br />
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])<br />
** &plusmn;0 [[DavidJanes]] see my note below<br />
** -1 [[Tantek]] (does not mean the "name" of the post/entry)<br />
** +1 [[BenjaminCarlyle]], atom:feed/title only<br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.<br />
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.<br />
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.<br />
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p> Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p><br />
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.<br />
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.<br />
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p><br />
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.<br />
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.<br />
<br />
== Entry Content (atom:content) ==<br />
<br />
'''STATUS - RESOLVED going with entry-content'''<br />
<br />
* <code>content</code> (Atom consistency)<br />
** -1 [[Tantek]]<br />
** +1 [[DavidJanes]]<br />
** +1 [[BenjaminCarlyle]]<br />
** +1 [[RyanKing]]<br />
** -1 [[ChrisCasciano]]<br />
** -1 KevinMarks - already too many in the wild<br />
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)<br />
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion<br />
** -1 Tantek - agreed with Ryan<br />
** -1 KevinMarks<br />
* <code>entry-content</code><br />
** +1 Niall Kennedy (proposed)<br />
** +0.5 [[Tantek]]<br />
** +1 KevinMarks<br />
** +1 [[ChrisCasciano]]<br />
* <code>atom-content</code><br />
** +0.5 [[Tantek]]<br />
* <code>hcontent</code><br />
** -1 [[Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.<br />
<br />
<br />
=== Discussion ===<br />
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.<br />
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An &lt;a rel="content" href="..."/&gt; form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.<br />
* [[ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.<br />
* [[Tantek]]: Chris Casciano is right. Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending. I have changed my vote to -1 for "content".<br />
* [[Tantek]]: I have added a few proposed alternatives based on discussions with various folks. I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing. I have split my vote among the new alternatives for now.<br />
* [[ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.<br />
* [[KevinMarks]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.<br />
* [[ChrisCasciano]] - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')<br />
<br />
== Entry Summary (atom:summary) ==<br />
<br />
'''STATUS - RESOLVED - going with 'entry-summary''''<br />
<br />
The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):<br />
<br />
* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)<br />
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. <br />
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.<br />
* <code>summary</code> (re-use from and consistency with Atom)<br />
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)<br />
* <code>partial-description</code><br />
* <code>excerpt</code><br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 DavidJanes, my only concern being that they're not always excerpts<br />
* <code>abstract</code><br />
** +1 KevinMarks<br />
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs<br />
<br />
=== Discussion ===<br />
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.<br />
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'<br />
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.<br />
* [[Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p><br />
** WordPress user interface calls it "excerpt"<br />
** MovableType user interface calls it "excerpt"<br />
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.<br />
* [[ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.<br />
* [[ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.<br />
<br />
== Entry Permalink (atom:link) ==<br />
<br />
'''STATUS - RESOLVED - 'bookmark' '''<br />
<br />
* <code>rel="bookmark"</code> (HTML consitency)<br />
** +2 DavidJanes<br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 KevinMarks<br />
<br />
=== Discussion ===<br />
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.<br />
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion<br />
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.<br />
* [[Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.<br />
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.<br />
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.<br />
** [[RyanKing]] non-issue, you can always use both.<br />
<br />
== Entry Published (atom:published) ==<br />
* <code>published</code> (Atom consistency)<br />
** +0.5 [[Tantek]]<br />
** +1 [[DavidJanes]]<br />
** +1 [[BenjaminCarlyle]]<br />
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])<br />
** +0.5 [[Tantek]] (want to consider it, while we can)<br />
* <code>VJOURNAL CREATED</code><br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.<br />
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p><br />
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"<br />
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p><br />
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards<br />
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.<br />
* [[Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.<br />
<br />
== Entry Updated (atom:updated) ==<br />
<br />
'''STATUS - RESOLVED - 'updated''''<br />
<br />
* <code>updated</code> (Atom consistency)<br />
** +1 Tantek<br />
** +1 DavidJanes<br />
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])<br />
** +&frac12; Paul Bryson, Not as human readable<br />
** +0.5 [[Tantek]] (want to consider it, while we can)<br />
* <code>last-modified</code><br />
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)<br />
** dtstamp<br />
** dtupdated<br />
<br />
=== Discussion ===<br />
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.<br />
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.<br />
* [[Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.<br />
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p><br />
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p><br />
* [[DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards<br />
go back throught [[blog-post-examples]] to see what conventions we have.<br />
* [[Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.<br />
<br />
== Entry Author (atom:author) ==<br />
<br />
'''STATUS - RESOLVED - 'author' required, should use <code>&lt;address&gt;</code>'''<br />
<br />
* <code>author</code> (Atom consistency)<br />
** +1 [[Tantek]]<br />
** +1 [[BenjaminCarlyle]]<br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?<br />
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.<br />
* [[RyanKing]] is &lt;address&gt; not sufficient for 'author' semantics?<br />
* [[DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what &lt;address&gt; implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].<br />
<br />
== Entry Contributor (atom:contributor) ==<br />
** -1 Tantek (see Discussion)<br />
* <code>contributor</code> (Atom consistency)<br />
** +1 Tantek<br />
** +1 DavidJanes<br />
<br />
=== Discussion ===<br />
* [[Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").<br />
* [[DavidJanes]]: '''RESOLUTION: DEFERRED'''<br />
<br />
== Entry Geo (geo:Point) ==<br />
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.<br />
<br />
=== GeoRSS Resources ===<br />
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]<br />
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]<br />
<br />
== Questions and Comments ==<br />
<br />
=== Limitations ===<br />
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)<br />
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]<br />
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.<br />
<br />
=== Relationship to hReview definitions needs clarification ===<br />
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:<br />
<br />
* atom:published -> hReview dtreviewed<br />
* atom:author -> hReview reviewer<br />
<br />
[[Tantek]]: "Pushed back" is the wrong direction here.<br />
<br />
The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.<br />
<br />
In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.<br />
<br />
=== hCards ===<br />
<br />
[[DavidJanes]]: Should hCards be required for the <code>&lt;address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.<br />
<br />
RESOLVED: MUST use hCard for author.<br />
<br />
* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code>&lt;address&gt;</code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code>&lt;address class="vcard"&gt;</code> we would have pretty good 1:1 mappings:<br />
** atom:name &harr; hCard’s FN<br />
** atom:email &harr; hCard’s EMAIL<br />
** atom:uri &harr; hCard’s URI<br />
* '''STATUS - OPEN'''. "MAY" is the answer.<br />
* [[Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.<br />
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p><br />
<br />
=== Comparisons ===<br />
<br />
This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:<br />
* atomentry <-> slide<br />
* content <-> slidecontent<br />
* summary <-> handout<br />
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.<br />
<br />
--[[Ernie Prabhakar]]<br />
<br />
* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p><br />
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.<br />
<br />
=== Repeated Elements ===<br />
We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].<br />
<br />
Your thoughts please... -- [[User:DavidJanes|David Janes]]<br />
<br />
'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.<br />
<br />
=== Opaqueness ===<br />
If you have concerns about [[hatom#hAtom_Opaque|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.<br />
<br />
==== Opaqueness of other microformat elements ====<br />
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.<br />
<br />
To summarise,<br />
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?<br />
<br />
-- [[BenjaminCarlyle]]<br />
<br />
* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. -- <br />
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.<br />
<br />
==== Opaqueness of summary and content ====<br />
[[DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code>&lt;ins&gt;</code> and <code>&lt;del&gt;</code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.<br />
<br />
Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.<br />
<br />
Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:<br />
<code>&lt;div class="content">&lt;div class="summary">...</div>...</div></code><br />
<br />
A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.<br />
<br />
=== Identification ===<br />
The current spec under Schema:Nomenclature:Entry includes the text:<br />
"if practical, also define id="unique-identifier" to the Entry"<br />
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?<br />
<br />
Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?<br />
<br />
The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?<br />
<br />
'''STATUS - OPEN'''.<br />
<br />
=== HTML Title ===<br />
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?<br />
<br />
=== rel-tag ===<br />
Should hAtom use rel-tag for atom category elements? -- [[DavidJanes]]<br />
<br />
* [[Tantek]]: IMHO yes.<br />
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.<br />
* rel-tag uses the last path segment of a URI as its tag, for example <code>&lt;a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.<br />
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)<br />
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.<br />
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).<br />
<br />
* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)<br />
<br />
=== Excess disambiguation rules? ===<br />
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.<br />
<br />
It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?<br />
<br />
=== Dependencies ===<br />
==== mfo ====<br />
Does this specification depend on acceptance of a hAtom-compatible mfo?<br />
See [[mfo-examples]].<br />
<br />
=== Is atom:content necessary? ===<br />
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?<br />
<br />
=== Published as default value for atom:updated ===<br />
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.<br />
<br />
I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:<br />
# If multiple updated fields exist, choose the most recent one.<br />
# If only one updated field exists, choose that value.<br />
# If no updated field exists but a published field exists, use the published value for atom:updated.<br />
: + 1 [[User:RobertBachmann|Robert Bachmann]]<br />
<br />
=== Designating the page author ===<br />
<br />
(2006-02-07 raised by [[User:RobertBachmann|Robert Bachmann]])<br />
<br />
“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”<br />
<br />
* How do I designate the page author(s)? <br />
** <code>class="author"</code> outside of the hAtom entry?<br />
** <code>&lt;address class="author"&gt;</code> outside of the hAtom entry?<br />
** <code>&lt;address&gt;</code> outside of the hAtom feed (i.e. at the page level)?<br />
* How do I designate the feed author(s)?<br />
<br />
(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])<br />
There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.<br />
<br />
==== Proposal ====<br />
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)<br />
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.<br />
<br />
== Entry Updated Required? -- Blogger ==<br />
* 2006-03-06 raised by [[User:Singpolyma|singpolyma]].<br />
*# The [[hatom|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? I ask primarily because I am wanting to update my [http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html XOXO Blog Format], which is based on hAtom, to comply with the new version of the standard -- and all my test-cases are on Blogger blogs...<br />
<br />
= See Also =<br />
* [[hatom|hAtom]] - the draft proposal<br />
* [[hatom-faq]] - knowledge base<br />
* [[blog-post-brainstorming]]<br />
* [[blog-post-formats]]<br />
* [[blog-post-examples]]<br />
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)<br />
* [[mfo-examples]]<br />
* [[naming-principles]]<br />
<br />
= Template =<br />
<br />
Please use this format (copy and paste this to the end of the list to add your issues):<br />
* 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.''</div>Filhttps://microformats.org/wiki/index.php?title=hatom-issues&diff=5537hatom-issues2006-03-24T21:52:14Z<p>Fil: /* author as an hcard is too much to require */ correct signature for Fil</p>
<hr />
<div>= hAtom 0.2 =<br />
<br />
This section is for discussing what you'd like to see in the next version of hAtom, i.e. 0.2.<br />
<br />
== Feed <i>XXX</i> (atom:<i>xxx</i>) ==<br />
<br />
Template section: if there is something clearly from an Atom ''Feed'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.<br />
<br />
== Entry <i>XXX</i> (atom:<i>xxx</i>) ==<br />
<br />
Template section: if there is something clearly from an Atom ''Entry'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.<br />
<br />
== Author ==<br />
<br />
=== author as an hcard is too much to require ===<br />
<br />
The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]<br />
<br />
* [[User:Fil Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a &lt;div class="author"> element.<br />
** [[Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.<br />
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"<br />
** [[User:Fil Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.<br />
<br />
* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"<br />
** [[Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.<br />
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec<br />
<br />
* [[User:Fil Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki><span class="author"><span class="vcard"><span class="fn">My Name</span></span></span></nowiki></code> ; but it's not good<br />
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki><span class="author vcard"><span class="fn">My Name</span></span></nowiki></code><br />
<br />
== Other Questions and Issues ==<br />
<br />
General comments, modeling issues, algorithm issues, should have issues, etc. go here.<br />
<br />
= hAtom 0.1 =<br />
<br />
'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''<br />
<br />
This page documents the issues that have been raised regarding the [[hatom|hAtom]] draft during the course of its development, and the resolutions of those issues (often with accompanying opinions).<br />
<br />
__TOC__<br />
<br />
== Contributors ==<br />
* Danny Ayers<br />
* Robert Bachmann<br />
* Paul Bryson<br />
* Benjamin Carlyle<br />
* Chris Casciano<br />
* Tantek Çelik<br />
* David Janes<br />
* Ryan King<br />
* Kevin Marks<br />
* Scott Reynen<br />
* Brian<br />
<br />
== Feed (atom:feed)==<br />
<br />
[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' and not required (a la [[hcalendar]])''' <br />
<br />
=== Initial proposal ===<br />
<br />
<code>atomfeed</code> (or rather, "atom-entry")<br />
<br />
* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?<br />
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking<br />
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases<br />
* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML<br />
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.<br />
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.<br />
* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)<br />
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) -- <br />
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".<br />
* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:<br />
** atom-feed<br />
** hfeed<br />
<br />
=== Alternatives ===<br />
<br />
The above proposal was not fully accepted and some other possibilities were proposed:<br />
<br />
* <code>feed</code> (Atom consistency)<br />
* <code>atom-feed</code> (Atom consistency with prefix)<br />
* <code>hfeed</code> (h* uF consistency)<br />
** +1 DavidJanes<br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 MarkRickerby<br />
** +1 DannyAyers<br />
<br />
==== Discussion ====<br />
<br />
The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[Tantek]]<br />
<br />
== Entry (atom:entry) ==<br />
<br />
[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''<br />
<br />
=== Initial Proposal ===<br />
<br />
<code>atomentry</code> (or rather, "atom-entry")<br />
<br />
* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.<br />
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:<br />
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.<br />
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)<br />
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both<br />
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)<br />
*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...<br />
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del><br />
*** [[Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:<br />
**** atom-entry<br />
**** hentry<br />
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])<br />
<br />
=== Alternatives ===<br />
The above proposal was not fully accepted. Other alternatives:<br />
<br />
* <code>entry</code> (Atom consistency)<br />
** +1 [[MarkRickerby]]<br />
* <code>atom-entry</code> (Atom consistency with prefix)<br />
* <code>hentry</code> (h* uF consistency)<br />
** +1 [[DavidJanes]]<br />
** +1 [[Tantek]]<br />
** +1 [[BenjaminCarlyle]]<br />
** +1 [[RyanKing]]<br />
** +1 [[MarkRickerby]]<br />
** +1 [[DannyAyers]]<br />
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])<br />
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption<br />
<br />
==== Discussion ====<br />
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p><br />
<br />
== Entry Title (atom:title) ==<br />
<br />
[[RyanKing]]: '''STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content' '''<br />
<br />
=== proposals ===<br />
<br />
The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):<br />
<br />
* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL<br />
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.<br />
** -1 [[KevinMarks]] (clashes with atom)<br />
* <code>Subject</code>, as used by SMTP email<br />
** -1 [[RyanKing]] - different semantics, doesn't fit<br />
* <code>heading</code><br />
** -1 [[RyanKing]] - a replication of &lt;h*&gt; semantics in html<br />
* <code>entry-title</code><br />
* <code>headline</code><br />
** +1 [[Tantek]]<br />
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]<br />
** +1 [[BenjaminCarlyle]], atom:entry/title only<br />
** +&frac12; [[DavidJanes]], atom:entry/title only<br />
** +&frac12; [[PaulBryson]], redundant?<br />
* <code>title</code> (Atom consistency)<br />
** -1 [[Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.<br />
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)<br />
** +&frac12; [[PaulBryson]], clear=good / hyphenating=bad<br />
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])<br />
** &plusmn;0 [[DavidJanes]] see my note below<br />
** -1 [[Tantek]] (does not mean the "name" of the post/entry)<br />
** +1 [[BenjaminCarlyle]], atom:feed/title only<br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.<br />
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.<br />
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.<br />
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p> Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p><br />
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.<br />
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.<br />
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p><br />
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.<br />
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.<br />
<br />
== Entry Content (atom:content) ==<br />
<br />
'''STATUS - RESOLVED going with entry-content'''<br />
<br />
* <code>content</code> (Atom consistency)<br />
** -1 [[Tantek]]<br />
** +1 [[DavidJanes]]<br />
** +1 [[BenjaminCarlyle]]<br />
** +1 [[RyanKing]]<br />
** -1 [[ChrisCasciano]]<br />
** -1 KevinMarks - already too many in the wild<br />
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)<br />
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion<br />
** -1 Tantek - agreed with Ryan<br />
** -1 KevinMarks<br />
* <code>entry-content</code><br />
** +1 Niall Kennedy (proposed)<br />
** +0.5 [[Tantek]]<br />
** +1 KevinMarks<br />
** +1 [[ChrisCasciano]]<br />
* <code>atom-content</code><br />
** +0.5 [[Tantek]]<br />
* <code>hcontent</code><br />
** -1 [[Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.<br />
<br />
<br />
=== Discussion ===<br />
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.<br />
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An &lt;a rel="content" href="..."/&gt; form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.<br />
* [[ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.<br />
* [[Tantek]]: Chris Casciano is right. Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending. I have changed my vote to -1 for "content".<br />
* [[Tantek]]: I have added a few proposed alternatives based on discussions with various folks. I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing. I have split my vote among the new alternatives for now.<br />
* [[ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.<br />
* [[KevinMarks]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.<br />
* [[ChrisCasciano]] - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')<br />
<br />
== Entry Summary (atom:summary) ==<br />
<br />
'''STATUS - RESOLVED - going with 'entry-summary''''<br />
<br />
The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):<br />
<br />
* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)<br />
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. <br />
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.<br />
* <code>summary</code> (re-use from and consistency with Atom)<br />
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)<br />
* <code>partial-description</code><br />
* <code>excerpt</code><br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 DavidJanes, my only concern being that they're not always excerpts<br />
* <code>abstract</code><br />
** +1 KevinMarks<br />
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs<br />
<br />
=== Discussion ===<br />
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.<br />
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'<br />
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.<br />
* [[Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p><br />
** WordPress user interface calls it "excerpt"<br />
** MovableType user interface calls it "excerpt"<br />
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.<br />
* [[ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.<br />
* [[ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.<br />
<br />
== Entry Permalink (atom:link) ==<br />
<br />
'''STATUS - RESOLVED - 'bookmark' '''<br />
<br />
* <code>rel="bookmark"</code> (HTML consitency)<br />
** +2 DavidJanes<br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 KevinMarks<br />
<br />
=== Discussion ===<br />
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.<br />
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion<br />
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.<br />
* [[Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.<br />
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.<br />
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.<br />
** [[RyanKing]] non-issue, you can always use both.<br />
<br />
== Entry Published (atom:published) ==<br />
* <code>published</code> (Atom consistency)<br />
** +0.5 [[Tantek]]<br />
** +1 [[DavidJanes]]<br />
** +1 [[BenjaminCarlyle]]<br />
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])<br />
** +0.5 [[Tantek]] (want to consider it, while we can)<br />
* <code>VJOURNAL CREATED</code><br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.<br />
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p><br />
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"<br />
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p><br />
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards<br />
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.<br />
* [[Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.<br />
<br />
== Entry Updated (atom:updated) ==<br />
<br />
'''STATUS - RESOLVED - 'updated''''<br />
<br />
* <code>updated</code> (Atom consistency)<br />
** +1 Tantek<br />
** +1 DavidJanes<br />
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])<br />
** +&frac12; Paul Bryson, Not as human readable<br />
** +0.5 [[Tantek]] (want to consider it, while we can)<br />
* <code>last-modified</code><br />
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)<br />
** dtstamp<br />
** dtupdated<br />
<br />
=== Discussion ===<br />
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.<br />
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.<br />
* [[Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.<br />
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p><br />
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p><br />
* [[DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards<br />
go back throught [[blog-post-examples]] to see what conventions we have.<br />
* [[Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.<br />
<br />
== Entry Author (atom:author) ==<br />
<br />
'''STATUS - RESOLVED - 'author' required, should use <code>&lt;address&gt;</code>'''<br />
<br />
* <code>author</code> (Atom consistency)<br />
** +1 [[Tantek]]<br />
** +1 [[BenjaminCarlyle]]<br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?<br />
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.<br />
* [[RyanKing]] is &lt;address&gt; not sufficient for 'author' semantics?<br />
* [[DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what &lt;address&gt; implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].<br />
<br />
== Entry Contributor (atom:contributor) ==<br />
** -1 Tantek (see Discussion)<br />
* <code>contributor</code> (Atom consistency)<br />
** +1 Tantek<br />
** +1 DavidJanes<br />
<br />
=== Discussion ===<br />
* [[Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").<br />
* [[DavidJanes]]: '''RESOLUTION: DEFERRED'''<br />
<br />
== Entry Geo (geo:Point) ==<br />
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.<br />
<br />
=== GeoRSS Resources ===<br />
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]<br />
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]<br />
<br />
== Questions and Comments ==<br />
<br />
=== Limitations ===<br />
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)<br />
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]<br />
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.<br />
<br />
=== Relationship to hReview definitions needs clarification ===<br />
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:<br />
<br />
* atom:published -> hReview dtreviewed<br />
* atom:author -> hReview reviewer<br />
<br />
[[Tantek]]: "Pushed back" is the wrong direction here.<br />
<br />
The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.<br />
<br />
In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.<br />
<br />
=== hCards ===<br />
<br />
[[DavidJanes]]: Should hCards be required for the <code>&lt;address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.<br />
<br />
RESOLVED: MUST use hCard for author.<br />
<br />
* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code>&lt;address&gt;</code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code>&lt;address class="vcard"&gt;</code> we would have pretty good 1:1 mappings:<br />
** atom:name &harr; hCard’s FN<br />
** atom:email &harr; hCard’s EMAIL<br />
** atom:uri &harr; hCard’s URI<br />
* '''STATUS - OPEN'''. "MAY" is the answer.<br />
* [[Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.<br />
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p><br />
<br />
=== Comparisons ===<br />
<br />
This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:<br />
* atomentry <-> slide<br />
* content <-> slidecontent<br />
* summary <-> handout<br />
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.<br />
<br />
--[[Ernie Prabhakar]]<br />
<br />
* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p><br />
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.<br />
<br />
=== Repeated Elements ===<br />
We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].<br />
<br />
Your thoughts please... -- [[User:DavidJanes|David Janes]]<br />
<br />
'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.<br />
<br />
=== Opaqueness ===<br />
If you have concerns about [[hatom#hAtom_Opaque|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.<br />
<br />
==== Opaqueness of other microformat elements ====<br />
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.<br />
<br />
To summarise,<br />
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?<br />
<br />
-- [[BenjaminCarlyle]]<br />
<br />
* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. -- <br />
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.<br />
<br />
==== Opaqueness of summary and content ====<br />
[[DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code>&lt;ins&gt;</code> and <code>&lt;del&gt;</code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.<br />
<br />
Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.<br />
<br />
Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:<br />
<code>&lt;div class="content">&lt;div class="summary">...</div>...</div></code><br />
<br />
A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.<br />
<br />
=== Identification ===<br />
The current spec under Schema:Nomenclature:Entry includes the text:<br />
"if practical, also define id="unique-identifier" to the Entry"<br />
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?<br />
<br />
Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?<br />
<br />
The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?<br />
<br />
'''STATUS - OPEN'''.<br />
<br />
=== HTML Title ===<br />
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?<br />
<br />
=== rel-tag ===<br />
Should hAtom use rel-tag for atom category elements? -- [[DavidJanes]]<br />
<br />
* [[Tantek]]: IMHO yes.<br />
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.<br />
* rel-tag uses the last path segment of a URI as its tag, for example <code>&lt;a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.<br />
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)<br />
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.<br />
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).<br />
<br />
* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)<br />
<br />
=== Excess disambiguation rules? ===<br />
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.<br />
<br />
It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?<br />
<br />
=== Dependencies ===<br />
==== mfo ====<br />
Does this specification depend on acceptance of a hAtom-compatible mfo?<br />
See [[mfo-examples]].<br />
<br />
=== Is atom:content necessary? ===<br />
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?<br />
<br />
=== Published as default value for atom:updated ===<br />
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.<br />
<br />
I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:<br />
# If multiple updated fields exist, choose the most recent one.<br />
# If only one updated field exists, choose that value.<br />
# If no updated field exists but a published field exists, use the published value for atom:updated.<br />
: + 1 [[User:RobertBachmann|Robert Bachmann]]<br />
<br />
=== Designating the page author ===<br />
<br />
(2006-02-07 raised by [[User:RobertBachmann|Robert Bachmann]])<br />
<br />
“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”<br />
<br />
* How do I designate the page author(s)? <br />
** <code>class="author"</code> outside of the hAtom entry?<br />
** <code>&lt;address class="author"&gt;</code> outside of the hAtom entry?<br />
** <code>&lt;address&gt;</code> outside of the hAtom feed (i.e. at the page level)?<br />
* How do I designate the feed author(s)?<br />
<br />
(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])<br />
There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.<br />
<br />
==== Proposal ====<br />
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)<br />
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.<br />
<br />
== Entry Updated Required? -- Blogger ==<br />
* 2006-03-06 raised by [[User:Singpolyma|singpolyma]].<br />
*# The [[hatom|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? I ask primarily because I am wanting to update my [http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html XOXO Blog Format], which is based on hAtom, to comply with the new version of the standard -- and all my test-cases are on Blogger blogs...<br />
<br />
= See Also =<br />
* [[hatom|hAtom]] - the draft proposal<br />
* [[hatom-faq]] - knowledge base<br />
* [[blog-post-brainstorming]]<br />
* [[blog-post-formats]]<br />
* [[blog-post-examples]]<br />
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)<br />
* [[mfo-examples]]<br />
* [[naming-principles]]<br />
<br />
= Template =<br />
<br />
Please use this format (copy and paste this to the end of the list to add your issues):<br />
* 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.''</div>Filhttps://microformats.org/wiki/index.php?title=hatom-issues&diff=5536hatom-issues2006-03-24T21:50:29Z<p>Fil: /* author as an hcard is too much to require */ precisions re: tantek's question</p>
<hr />
<div>= hAtom 0.2 =<br />
<br />
This section is for discussing what you'd like to see in the next version of hAtom, i.e. 0.2.<br />
<br />
== Feed <i>XXX</i> (atom:<i>xxx</i>) ==<br />
<br />
Template section: if there is something clearly from an Atom ''Feed'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.<br />
<br />
== Entry <i>XXX</i> (atom:<i>xxx</i>) ==<br />
<br />
Template section: if there is something clearly from an Atom ''Entry'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.<br />
<br />
== Author ==<br />
<br />
=== author as an hcard is too much to require ===<br />
<br />
The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]<br />
<br />
* [[User:Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a &lt;div class="author"> element.<br />
** [[Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.<br />
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"<br />
** [[User:Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.<br />
<br />
* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"<br />
** [[Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.<br />
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec<br />
<br />
* [[Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki><span class="author"><span class="vcard"><span class="fn">My Name</span></span></span></nowiki></code> ; but it's not good<br />
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki><span class="author vcard"><span class="fn">My Name</span></span></nowiki></code><br />
<br />
== Other Questions and Issues ==<br />
<br />
General comments, modeling issues, algorithm issues, should have issues, etc. go here.<br />
<br />
= hAtom 0.1 =<br />
<br />
'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''<br />
<br />
This page documents the issues that have been raised regarding the [[hatom|hAtom]] draft during the course of its development, and the resolutions of those issues (often with accompanying opinions).<br />
<br />
__TOC__<br />
<br />
== Contributors ==<br />
* Danny Ayers<br />
* Robert Bachmann<br />
* Paul Bryson<br />
* Benjamin Carlyle<br />
* Chris Casciano<br />
* Tantek Çelik<br />
* David Janes<br />
* Ryan King<br />
* Kevin Marks<br />
* Scott Reynen<br />
* Brian<br />
<br />
== Feed (atom:feed)==<br />
<br />
[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' and not required (a la [[hcalendar]])''' <br />
<br />
=== Initial proposal ===<br />
<br />
<code>atomfeed</code> (or rather, "atom-entry")<br />
<br />
* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?<br />
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking<br />
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases<br />
* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML<br />
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.<br />
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.<br />
* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)<br />
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) -- <br />
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".<br />
* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:<br />
** atom-feed<br />
** hfeed<br />
<br />
=== Alternatives ===<br />
<br />
The above proposal was not fully accepted and some other possibilities were proposed:<br />
<br />
* <code>feed</code> (Atom consistency)<br />
* <code>atom-feed</code> (Atom consistency with prefix)<br />
* <code>hfeed</code> (h* uF consistency)<br />
** +1 DavidJanes<br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 MarkRickerby<br />
** +1 DannyAyers<br />
<br />
==== Discussion ====<br />
<br />
The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[Tantek]]<br />
<br />
== Entry (atom:entry) ==<br />
<br />
[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''<br />
<br />
=== Initial Proposal ===<br />
<br />
<code>atomentry</code> (or rather, "atom-entry")<br />
<br />
* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.<br />
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:<br />
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.<br />
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)<br />
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both<br />
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)<br />
*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...<br />
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del><br />
*** [[Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:<br />
**** atom-entry<br />
**** hentry<br />
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])<br />
<br />
=== Alternatives ===<br />
The above proposal was not fully accepted. Other alternatives:<br />
<br />
* <code>entry</code> (Atom consistency)<br />
** +1 [[MarkRickerby]]<br />
* <code>atom-entry</code> (Atom consistency with prefix)<br />
* <code>hentry</code> (h* uF consistency)<br />
** +1 [[DavidJanes]]<br />
** +1 [[Tantek]]<br />
** +1 [[BenjaminCarlyle]]<br />
** +1 [[RyanKing]]<br />
** +1 [[MarkRickerby]]<br />
** +1 [[DannyAyers]]<br />
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])<br />
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption<br />
<br />
==== Discussion ====<br />
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p><br />
<br />
== Entry Title (atom:title) ==<br />
<br />
[[RyanKing]]: '''STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content' '''<br />
<br />
=== proposals ===<br />
<br />
The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):<br />
<br />
* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL<br />
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.<br />
** -1 [[KevinMarks]] (clashes with atom)<br />
* <code>Subject</code>, as used by SMTP email<br />
** -1 [[RyanKing]] - different semantics, doesn't fit<br />
* <code>heading</code><br />
** -1 [[RyanKing]] - a replication of &lt;h*&gt; semantics in html<br />
* <code>entry-title</code><br />
* <code>headline</code><br />
** +1 [[Tantek]]<br />
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]<br />
** +1 [[BenjaminCarlyle]], atom:entry/title only<br />
** +&frac12; [[DavidJanes]], atom:entry/title only<br />
** +&frac12; [[PaulBryson]], redundant?<br />
* <code>title</code> (Atom consistency)<br />
** -1 [[Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.<br />
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)<br />
** +&frac12; [[PaulBryson]], clear=good / hyphenating=bad<br />
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])<br />
** &plusmn;0 [[DavidJanes]] see my note below<br />
** -1 [[Tantek]] (does not mean the "name" of the post/entry)<br />
** +1 [[BenjaminCarlyle]], atom:feed/title only<br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.<br />
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.<br />
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.<br />
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p> Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p><br />
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.<br />
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.<br />
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p><br />
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.<br />
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.<br />
<br />
== Entry Content (atom:content) ==<br />
<br />
'''STATUS - RESOLVED going with entry-content'''<br />
<br />
* <code>content</code> (Atom consistency)<br />
** -1 [[Tantek]]<br />
** +1 [[DavidJanes]]<br />
** +1 [[BenjaminCarlyle]]<br />
** +1 [[RyanKing]]<br />
** -1 [[ChrisCasciano]]<br />
** -1 KevinMarks - already too many in the wild<br />
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)<br />
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion<br />
** -1 Tantek - agreed with Ryan<br />
** -1 KevinMarks<br />
* <code>entry-content</code><br />
** +1 Niall Kennedy (proposed)<br />
** +0.5 [[Tantek]]<br />
** +1 KevinMarks<br />
** +1 [[ChrisCasciano]]<br />
* <code>atom-content</code><br />
** +0.5 [[Tantek]]<br />
* <code>hcontent</code><br />
** -1 [[Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.<br />
<br />
<br />
=== Discussion ===<br />
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.<br />
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An &lt;a rel="content" href="..."/&gt; form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.<br />
* [[ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.<br />
* [[Tantek]]: Chris Casciano is right. Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending. I have changed my vote to -1 for "content".<br />
* [[Tantek]]: I have added a few proposed alternatives based on discussions with various folks. I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing. I have split my vote among the new alternatives for now.<br />
* [[ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.<br />
* [[KevinMarks]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.<br />
* [[ChrisCasciano]] - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')<br />
<br />
== Entry Summary (atom:summary) ==<br />
<br />
'''STATUS - RESOLVED - going with 'entry-summary''''<br />
<br />
The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):<br />
<br />
* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)<br />
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. <br />
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.<br />
* <code>summary</code> (re-use from and consistency with Atom)<br />
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)<br />
* <code>partial-description</code><br />
* <code>excerpt</code><br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 DavidJanes, my only concern being that they're not always excerpts<br />
* <code>abstract</code><br />
** +1 KevinMarks<br />
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs<br />
<br />
=== Discussion ===<br />
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.<br />
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'<br />
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.<br />
* [[Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p><br />
** WordPress user interface calls it "excerpt"<br />
** MovableType user interface calls it "excerpt"<br />
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.<br />
* [[ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.<br />
* [[ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.<br />
<br />
== Entry Permalink (atom:link) ==<br />
<br />
'''STATUS - RESOLVED - 'bookmark' '''<br />
<br />
* <code>rel="bookmark"</code> (HTML consitency)<br />
** +2 DavidJanes<br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 KevinMarks<br />
<br />
=== Discussion ===<br />
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.<br />
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion<br />
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.<br />
* [[Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.<br />
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.<br />
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.<br />
** [[RyanKing]] non-issue, you can always use both.<br />
<br />
== Entry Published (atom:published) ==<br />
* <code>published</code> (Atom consistency)<br />
** +0.5 [[Tantek]]<br />
** +1 [[DavidJanes]]<br />
** +1 [[BenjaminCarlyle]]<br />
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])<br />
** +0.5 [[Tantek]] (want to consider it, while we can)<br />
* <code>VJOURNAL CREATED</code><br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.<br />
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p><br />
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"<br />
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p><br />
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards<br />
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.<br />
* [[Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.<br />
<br />
== Entry Updated (atom:updated) ==<br />
<br />
'''STATUS - RESOLVED - 'updated''''<br />
<br />
* <code>updated</code> (Atom consistency)<br />
** +1 Tantek<br />
** +1 DavidJanes<br />
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])<br />
** +&frac12; Paul Bryson, Not as human readable<br />
** +0.5 [[Tantek]] (want to consider it, while we can)<br />
* <code>last-modified</code><br />
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)<br />
** dtstamp<br />
** dtupdated<br />
<br />
=== Discussion ===<br />
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.<br />
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.<br />
* [[Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.<br />
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p><br />
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p><br />
* [[DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards<br />
go back throught [[blog-post-examples]] to see what conventions we have.<br />
* [[Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.<br />
<br />
== Entry Author (atom:author) ==<br />
<br />
'''STATUS - RESOLVED - 'author' required, should use <code>&lt;address&gt;</code>'''<br />
<br />
* <code>author</code> (Atom consistency)<br />
** +1 [[Tantek]]<br />
** +1 [[BenjaminCarlyle]]<br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?<br />
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.<br />
* [[RyanKing]] is &lt;address&gt; not sufficient for 'author' semantics?<br />
* [[DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what &lt;address&gt; implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].<br />
<br />
== Entry Contributor (atom:contributor) ==<br />
** -1 Tantek (see Discussion)<br />
* <code>contributor</code> (Atom consistency)<br />
** +1 Tantek<br />
** +1 DavidJanes<br />
<br />
=== Discussion ===<br />
* [[Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").<br />
* [[DavidJanes]]: '''RESOLUTION: DEFERRED'''<br />
<br />
== Entry Geo (geo:Point) ==<br />
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.<br />
<br />
=== GeoRSS Resources ===<br />
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]<br />
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]<br />
<br />
== Questions and Comments ==<br />
<br />
=== Limitations ===<br />
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)<br />
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]<br />
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.<br />
<br />
=== Relationship to hReview definitions needs clarification ===<br />
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:<br />
<br />
* atom:published -> hReview dtreviewed<br />
* atom:author -> hReview reviewer<br />
<br />
[[Tantek]]: "Pushed back" is the wrong direction here.<br />
<br />
The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.<br />
<br />
In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.<br />
<br />
=== hCards ===<br />
<br />
[[DavidJanes]]: Should hCards be required for the <code>&lt;address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.<br />
<br />
RESOLVED: MUST use hCard for author.<br />
<br />
* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code>&lt;address&gt;</code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code>&lt;address class="vcard"&gt;</code> we would have pretty good 1:1 mappings:<br />
** atom:name &harr; hCard’s FN<br />
** atom:email &harr; hCard’s EMAIL<br />
** atom:uri &harr; hCard’s URI<br />
* '''STATUS - OPEN'''. "MAY" is the answer.<br />
* [[Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.<br />
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p><br />
<br />
=== Comparisons ===<br />
<br />
This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:<br />
* atomentry <-> slide<br />
* content <-> slidecontent<br />
* summary <-> handout<br />
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.<br />
<br />
--[[Ernie Prabhakar]]<br />
<br />
* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p><br />
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.<br />
<br />
=== Repeated Elements ===<br />
We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].<br />
<br />
Your thoughts please... -- [[User:DavidJanes|David Janes]]<br />
<br />
'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.<br />
<br />
=== Opaqueness ===<br />
If you have concerns about [[hatom#hAtom_Opaque|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.<br />
<br />
==== Opaqueness of other microformat elements ====<br />
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.<br />
<br />
To summarise,<br />
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?<br />
<br />
-- [[BenjaminCarlyle]]<br />
<br />
* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. -- <br />
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.<br />
<br />
==== Opaqueness of summary and content ====<br />
[[DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code>&lt;ins&gt;</code> and <code>&lt;del&gt;</code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.<br />
<br />
Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.<br />
<br />
Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:<br />
<code>&lt;div class="content">&lt;div class="summary">...</div>...</div></code><br />
<br />
A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.<br />
<br />
=== Identification ===<br />
The current spec under Schema:Nomenclature:Entry includes the text:<br />
"if practical, also define id="unique-identifier" to the Entry"<br />
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?<br />
<br />
Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?<br />
<br />
The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?<br />
<br />
'''STATUS - OPEN'''.<br />
<br />
=== HTML Title ===<br />
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?<br />
<br />
=== rel-tag ===<br />
Should hAtom use rel-tag for atom category elements? -- [[DavidJanes]]<br />
<br />
* [[Tantek]]: IMHO yes.<br />
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.<br />
* rel-tag uses the last path segment of a URI as its tag, for example <code>&lt;a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.<br />
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)<br />
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.<br />
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).<br />
<br />
* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)<br />
<br />
=== Excess disambiguation rules? ===<br />
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.<br />
<br />
It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?<br />
<br />
=== Dependencies ===<br />
==== mfo ====<br />
Does this specification depend on acceptance of a hAtom-compatible mfo?<br />
See [[mfo-examples]].<br />
<br />
=== Is atom:content necessary? ===<br />
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?<br />
<br />
=== Published as default value for atom:updated ===<br />
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.<br />
<br />
I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:<br />
# If multiple updated fields exist, choose the most recent one.<br />
# If only one updated field exists, choose that value.<br />
# If no updated field exists but a published field exists, use the published value for atom:updated.<br />
: + 1 [[User:RobertBachmann|Robert Bachmann]]<br />
<br />
=== Designating the page author ===<br />
<br />
(2006-02-07 raised by [[User:RobertBachmann|Robert Bachmann]])<br />
<br />
“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”<br />
<br />
* How do I designate the page author(s)? <br />
** <code>class="author"</code> outside of the hAtom entry?<br />
** <code>&lt;address class="author"&gt;</code> outside of the hAtom entry?<br />
** <code>&lt;address&gt;</code> outside of the hAtom feed (i.e. at the page level)?<br />
* How do I designate the feed author(s)?<br />
<br />
(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])<br />
There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.<br />
<br />
==== Proposal ====<br />
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)<br />
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.<br />
<br />
== Entry Updated Required? -- Blogger ==<br />
* 2006-03-06 raised by [[User:Singpolyma|singpolyma]].<br />
*# The [[hatom|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? I ask primarily because I am wanting to update my [http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html XOXO Blog Format], which is based on hAtom, to comply with the new version of the standard -- and all my test-cases are on Blogger blogs...<br />
<br />
= See Also =<br />
* [[hatom|hAtom]] - the draft proposal<br />
* [[hatom-faq]] - knowledge base<br />
* [[blog-post-brainstorming]]<br />
* [[blog-post-formats]]<br />
* [[blog-post-examples]]<br />
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)<br />
* [[mfo-examples]]<br />
* [[naming-principles]]<br />
<br />
= Template =<br />
<br />
Please use this format (copy and paste this to the end of the list to add your issues):<br />
* 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.''</div>Filhttps://microformats.org/wiki/index.php?title=hatom-issues&diff=5526hatom-issues2006-03-24T15:52:10Z<p>Fil: fix sedna website address</p>
<hr />
<div>= hAtom 0.2 =<br />
<br />
This section is for discussing what you'd like to see in the next version of hAtom, i.e. 0.2.<br />
<br />
== Feed <i>XXX</i> (atom:<i>xxx</i>) ==<br />
<br />
Template section: if there is something clearly from an Atom ''Feed'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.<br />
<br />
== Entry <i>XXX</i> (atom:<i>xxx</i>) ==<br />
<br />
Template section: if there is something clearly from an Atom ''Entry'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.<br />
<br />
== Author ==<br />
<br />
=== author as an hcard is too much to require ===<br />
<br />
* [[Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a &lt;div class="author"> element.<br />
<br />
* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"<br />
<br />
* [[Fil]] for the moment, to comply losely with hAtom 0.1, I will use &lt;span class="author">&lt;span class="vcard">&lt;span class="fn">My Name... ; but it's not good<br />
<br />
== Other Questions and Issues ==<br />
<br />
General comments, modeling issues, algorithm issues, should have issues, etc. go here.<br />
<br />
= hAtom 0.1 =<br />
<br />
'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''<br />
<br />
This page documents the issues that have been raised regarding the [[hatom|hAtom]] draft during the course of its development, and the resolutions of those issues (often with accompanying opinions).<br />
<br />
__TOC__<br />
<br />
== Contributors ==<br />
* Danny Ayers<br />
* Robert Bachmann<br />
* Paul Bryson<br />
* Benjamin Carlyle<br />
* Chris Casciano<br />
* Tantek Çelik<br />
* David Janes<br />
* Ryan King<br />
* Kevin Marks<br />
* Scott Reynen<br />
* Brian<br />
<br />
== Feed (atom:feed)==<br />
<br />
[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' and not required (a la [[hcalendar]])''' <br />
<br />
=== Initial proposal ===<br />
<br />
<code>atomfeed</code> (or rather, "atom-entry")<br />
<br />
* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?<br />
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking<br />
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases<br />
* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML<br />
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.<br />
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.<br />
* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)<br />
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) -- <br />
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".<br />
* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:<br />
** atom-feed<br />
** hfeed<br />
<br />
=== Alternatives ===<br />
<br />
The above proposal was not fully accepted and some other possibilities were proposed:<br />
<br />
* <code>feed</code> (Atom consistency)<br />
* <code>atom-feed</code> (Atom consistency with prefix)<br />
* <code>hfeed</code> (h* uF consistency)<br />
** +1 DavidJanes<br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 MarkRickerby<br />
** +1 DannyAyers<br />
<br />
==== Discussion ====<br />
<br />
The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[Tantek]]<br />
<br />
== Entry (atom:entry) ==<br />
<br />
[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''<br />
<br />
=== Initial Proposal ===<br />
<br />
<code>atomentry</code> (or rather, "atom-entry")<br />
<br />
* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.<br />
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:<br />
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.<br />
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)<br />
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both<br />
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)<br />
*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...<br />
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del><br />
*** [[Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:<br />
**** atom-entry<br />
**** hentry<br />
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])<br />
<br />
=== Alternatives ===<br />
The above proposal was not fully accepted. Other alternatives:<br />
<br />
* <code>entry</code> (Atom consistency)<br />
** +1 [[MarkRickerby]]<br />
* <code>atom-entry</code> (Atom consistency with prefix)<br />
* <code>hentry</code> (h* uF consistency)<br />
** +1 [[DavidJanes]]<br />
** +1 [[Tantek]]<br />
** +1 [[BenjaminCarlyle]]<br />
** +1 [[RyanKing]]<br />
** +1 [[MarkRickerby]]<br />
** +1 [[DannyAyers]]<br />
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])<br />
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption<br />
<br />
==== Discussion ====<br />
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p><br />
<br />
== Entry Title (atom:title) ==<br />
<br />
[[RyanKing]]: '''STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content' '''<br />
<br />
=== proposals ===<br />
<br />
The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):<br />
<br />
* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL<br />
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.<br />
** -1 [[KevinMarks]] (clashes with atom)<br />
* <code>Subject</code>, as used by SMTP email<br />
** -1 [[RyanKing]] - different semantics, doesn't fit<br />
* <code>heading</code><br />
** -1 [[RyanKing]] - a replication of &lt;h*&gt; semantics in html<br />
* <code>entry-title</code><br />
* <code>headline</code><br />
** +1 [[Tantek]]<br />
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]<br />
** +1 [[BenjaminCarlyle]], atom:entry/title only<br />
** +&frac12; [[DavidJanes]], atom:entry/title only<br />
** +&frac12; [[PaulBryson]], redundant?<br />
* <code>title</code> (Atom consistency)<br />
** -1 [[Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.<br />
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)<br />
** +&frac12; [[PaulBryson]], clear=good / hyphenating=bad<br />
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])<br />
** &plusmn;0 [[DavidJanes]] see my note below<br />
** -1 [[Tantek]] (does not mean the "name" of the post/entry)<br />
** +1 [[BenjaminCarlyle]], atom:feed/title only<br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.<br />
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.<br />
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.<br />
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p> Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p><br />
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.<br />
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.<br />
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p><br />
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.<br />
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.<br />
<br />
== Entry Content (atom:content) ==<br />
<br />
'''STATUS - RESOLVED going with entry-content'''<br />
<br />
* <code>content</code> (Atom consistency)<br />
** -1 [[Tantek]]<br />
** +1 [[DavidJanes]]<br />
** +1 [[BenjaminCarlyle]]<br />
** +1 [[RyanKing]]<br />
** -1 [[ChrisCasciano]]<br />
** -1 KevinMarks - already too many in the wild<br />
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)<br />
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion<br />
** -1 Tantek - agreed with Ryan<br />
** -1 KevinMarks<br />
* <code>entry-content</code><br />
** +1 Niall Kennedy (proposed)<br />
** +0.5 [[Tantek]]<br />
** +1 KevinMarks<br />
** +1 [[ChrisCasciano]]<br />
* <code>atom-content</code><br />
** +0.5 [[Tantek]]<br />
* <code>hcontent</code><br />
** -1 [[Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.<br />
<br />
<br />
=== Discussion ===<br />
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.<br />
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An &lt;a rel="content" href="..."/&gt; form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.<br />
* [[ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.<br />
* [[Tantek]]: Chris Casciano is right. Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending. I have changed my vote to -1 for "content".<br />
* [[Tantek]]: I have added a few proposed alternatives based on discussions with various folks. I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing. I have split my vote among the new alternatives for now.<br />
* [[ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.<br />
* [[KevinMarks]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.<br />
* [[ChrisCasciano]] - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')<br />
<br />
== Entry Summary (atom:summary) ==<br />
<br />
'''STATUS - RESOLVED - going with 'entry-summary''''<br />
<br />
The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):<br />
<br />
* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)<br />
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. <br />
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.<br />
* <code>summary</code> (re-use from and consistency with Atom)<br />
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)<br />
* <code>partial-description</code><br />
* <code>excerpt</code><br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 DavidJanes, my only concern being that they're not always excerpts<br />
* <code>abstract</code><br />
** +1 KevinMarks<br />
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs<br />
<br />
=== Discussion ===<br />
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.<br />
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'<br />
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.<br />
* [[Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p><br />
** WordPress user interface calls it "excerpt"<br />
** MovableType user interface calls it "excerpt"<br />
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.<br />
* [[ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.<br />
* [[ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.<br />
<br />
== Entry Permalink (atom:link) ==<br />
<br />
'''STATUS - RESOLVED - 'bookmark' '''<br />
<br />
* <code>rel="bookmark"</code> (HTML consitency)<br />
** +2 DavidJanes<br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 KevinMarks<br />
<br />
=== Discussion ===<br />
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.<br />
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion<br />
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.<br />
* [[Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.<br />
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.<br />
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.<br />
** [[RyanKing]] non-issue, you can always use both.<br />
<br />
== Entry Published (atom:published) ==<br />
* <code>published</code> (Atom consistency)<br />
** +0.5 [[Tantek]]<br />
** +1 [[DavidJanes]]<br />
** +1 [[BenjaminCarlyle]]<br />
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])<br />
** +0.5 [[Tantek]] (want to consider it, while we can)<br />
* <code>VJOURNAL CREATED</code><br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.<br />
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p><br />
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"<br />
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p><br />
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards<br />
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.<br />
* [[Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.<br />
<br />
== Entry Updated (atom:updated) ==<br />
<br />
'''STATUS - RESOLVED - 'updated''''<br />
<br />
* <code>updated</code> (Atom consistency)<br />
** +1 Tantek<br />
** +1 DavidJanes<br />
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])<br />
** +&frac12; Paul Bryson, Not as human readable<br />
** +0.5 [[Tantek]] (want to consider it, while we can)<br />
* <code>last-modified</code><br />
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)<br />
** dtstamp<br />
** dtupdated<br />
<br />
=== Discussion ===<br />
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.<br />
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.<br />
* [[Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.<br />
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p><br />
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p><br />
* [[DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards<br />
go back throught [[blog-post-examples]] to see what conventions we have.<br />
* [[Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.<br />
<br />
== Entry Author (atom:author) ==<br />
<br />
'''STATUS - RESOLVED - 'author' required, should use <code>&lt;address&gt;</code>'''<br />
<br />
* <code>author</code> (Atom consistency)<br />
** +1 [[Tantek]]<br />
** +1 [[BenjaminCarlyle]]<br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?<br />
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.<br />
* [[RyanKing]] is &lt;address&gt; not sufficient for 'author' semantics?<br />
* [[DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what &lt;address&gt; implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].<br />
<br />
== Entry Contributor (atom:contributor) ==<br />
** -1 Tantek (see Discussion)<br />
* <code>contributor</code> (Atom consistency)<br />
** +1 Tantek<br />
** +1 DavidJanes<br />
<br />
=== Discussion ===<br />
* [[Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").<br />
* [[DavidJanes]]: '''RESOLUTION: DEFERRED'''<br />
<br />
== Entry Geo (geo:Point) ==<br />
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.<br />
<br />
=== GeoRSS Resources ===<br />
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]<br />
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]<br />
<br />
== Questions and Comments ==<br />
<br />
=== Limitations ===<br />
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)<br />
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]<br />
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.<br />
<br />
=== Relationship to hReview definitions needs clarification ===<br />
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:<br />
<br />
* atom:published -> hReview dtreviewed<br />
* atom:author -> hReview reviewer<br />
<br />
[[Tantek]]: "Pushed back" is the wrong direction here.<br />
<br />
The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.<br />
<br />
In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.<br />
<br />
=== hCards ===<br />
<br />
[[DavidJanes]]: Should hCards be required for the <code>&lt;address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.<br />
<br />
RESOLVED: MUST use hCard for author.<br />
<br />
* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code>&lt;address&gt;</code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code>&lt;address class="vcard"&gt;</code> we would have pretty good 1:1 mappings:<br />
** atom:name &harr; hCard’s FN<br />
** atom:email &harr; hCard’s EMAIL<br />
** atom:uri &harr; hCard’s URI<br />
* '''STATUS - OPEN'''. "MAY" is the answer.<br />
* [[Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.<br />
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p><br />
<br />
=== Comparisons ===<br />
<br />
This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:<br />
* atomentry <-> slide<br />
* content <-> slidecontent<br />
* summary <-> handout<br />
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.<br />
<br />
--[[Ernie Prabhakar]]<br />
<br />
* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p><br />
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.<br />
<br />
=== Repeated Elements ===<br />
We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].<br />
<br />
Your thoughts please... -- [[User:DavidJanes|David Janes]]<br />
<br />
'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.<br />
<br />
=== Opaqueness ===<br />
If you have concerns about [[hatom#hAtom_Opaque|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.<br />
<br />
==== Opaqueness of other microformat elements ====<br />
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.<br />
<br />
To summarise,<br />
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?<br />
<br />
-- [[BenjaminCarlyle]]<br />
<br />
* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. -- <br />
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.<br />
<br />
==== Opaqueness of summary and content ====<br />
[[DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code>&lt;ins&gt;</code> and <code>&lt;del&gt;</code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.<br />
<br />
Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.<br />
<br />
Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:<br />
<code>&lt;div class="content">&lt;div class="summary">...</div>...</div></code><br />
<br />
A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.<br />
<br />
=== Identification ===<br />
The current spec under Schema:Nomenclature:Entry includes the text:<br />
"if practical, also define id="unique-identifier" to the Entry"<br />
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?<br />
<br />
Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?<br />
<br />
The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?<br />
<br />
'''STATUS - OPEN'''.<br />
<br />
=== HTML Title ===<br />
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?<br />
<br />
=== rel-tag ===<br />
Should hAtom use rel-tag for atom category elements? -- [[DavidJanes]]<br />
<br />
* [[Tantek]]: IMHO yes.<br />
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.<br />
* rel-tag uses the last path segment of a URI as its tag, for example <code>&lt;a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.<br />
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)<br />
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.<br />
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).<br />
<br />
* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)<br />
<br />
=== Excess disambiguation rules? ===<br />
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.<br />
<br />
It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?<br />
<br />
=== Dependencies ===<br />
==== mfo ====<br />
Does this specification depend on acceptance of a hAtom-compatible mfo?<br />
See [[mfo-examples]].<br />
<br />
=== Is atom:content necessary? ===<br />
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?<br />
<br />
=== Published as default value for atom:updated ===<br />
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.<br />
<br />
I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:<br />
# If multiple updated fields exist, choose the most recent one.<br />
# If only one updated field exists, choose that value.<br />
# If no updated field exists but a published field exists, use the published value for atom:updated.<br />
: + 1 [[User:RobertBachmann|Robert Bachmann]]<br />
<br />
=== Designating the page author ===<br />
<br />
(2006-02-07 raised by [[User:RobertBachmann|Robert Bachmann]])<br />
<br />
“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”<br />
<br />
* How do I designate the page author(s)? <br />
** <code>class="author"</code> outside of the hAtom entry?<br />
** <code>&lt;address class="author"&gt;</code> outside of the hAtom entry?<br />
** <code>&lt;address&gt;</code> outside of the hAtom feed (i.e. at the page level)?<br />
* How do I designate the feed author(s)?<br />
<br />
(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])<br />
There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.<br />
<br />
==== Proposal ====<br />
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)<br />
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.<br />
<br />
== Entry Updated Required? -- Blogger ==<br />
* 2006-03-06 raised by [[User:Singpolyma|singpolyma]].<br />
*# The [[hatom|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? I ask primarily because I am wanting to update my [http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html XOXO Blog Format], which is based on hAtom, to comply with the new version of the standard -- and all my test-cases are on Blogger blogs...<br />
<br />
= See Also =<br />
* [[hatom|hAtom]] - the draft proposal<br />
* [[hatom-faq]] - knowledge base<br />
* [[blog-post-brainstorming]]<br />
* [[blog-post-formats]]<br />
* [[blog-post-examples]]<br />
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)<br />
* [[mfo-examples]]<br />
* [[naming-principles]]<br />
<br />
= Template =<br />
<br />
Please use this format (copy and paste this to the end of the list to add your issues):<br />
* 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.''</div>Filhttps://microformats.org/wiki/index.php?title=hatom-issues&diff=5525hatom-issues2006-03-24T15:48:11Z<p>Fil: /* author as an hcard is too much to require */</p>
<hr />
<div>= hAtom 0.2 =<br />
<br />
This section is for discussing what you'd like to see in the next version of hAtom, i.e. 0.2.<br />
<br />
== Feed <i>XXX</i> (atom:<i>xxx</i>) ==<br />
<br />
Template section: if there is something clearly from an Atom ''Feed'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.<br />
<br />
== Entry <i>XXX</i> (atom:<i>xxx</i>) ==<br />
<br />
Template section: if there is something clearly from an Atom ''Entry'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.<br />
<br />
== Author ==<br />
<br />
=== author as an hcard is too much to require ===<br />
<br />
* [[Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.rezo.net/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a &lt;div class="author"> element.<br />
<br />
* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"<br />
<br />
* [[Fil]] for the moment, to comply losely with hAtom 0.1, I will use &lt;span class="author">&lt;span class="vcard">&lt;span class="fn">My Name... ; but it's not good<br />
<br />
== Other Questions and Issues ==<br />
<br />
General comments, modeling issues, algorithm issues, should have issues, etc. go here.<br />
<br />
= hAtom 0.1 =<br />
<br />
'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''<br />
<br />
This page documents the issues that have been raised regarding the [[hatom|hAtom]] draft during the course of its development, and the resolutions of those issues (often with accompanying opinions).<br />
<br />
__TOC__<br />
<br />
== Contributors ==<br />
* Danny Ayers<br />
* Robert Bachmann<br />
* Paul Bryson<br />
* Benjamin Carlyle<br />
* Chris Casciano<br />
* Tantek Çelik<br />
* David Janes<br />
* Ryan King<br />
* Kevin Marks<br />
* Scott Reynen<br />
* Brian<br />
<br />
== Feed (atom:feed)==<br />
<br />
[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' and not required (a la [[hcalendar]])''' <br />
<br />
=== Initial proposal ===<br />
<br />
<code>atomfeed</code> (or rather, "atom-entry")<br />
<br />
* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?<br />
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking<br />
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases<br />
* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML<br />
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.<br />
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.<br />
* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)<br />
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) -- <br />
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".<br />
* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:<br />
** atom-feed<br />
** hfeed<br />
<br />
=== Alternatives ===<br />
<br />
The above proposal was not fully accepted and some other possibilities were proposed:<br />
<br />
* <code>feed</code> (Atom consistency)<br />
* <code>atom-feed</code> (Atom consistency with prefix)<br />
* <code>hfeed</code> (h* uF consistency)<br />
** +1 DavidJanes<br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 MarkRickerby<br />
** +1 DannyAyers<br />
<br />
==== Discussion ====<br />
<br />
The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[Tantek]]<br />
<br />
== Entry (atom:entry) ==<br />
<br />
[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''<br />
<br />
=== Initial Proposal ===<br />
<br />
<code>atomentry</code> (or rather, "atom-entry")<br />
<br />
* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.<br />
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:<br />
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.<br />
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)<br />
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both<br />
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)<br />
*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...<br />
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del><br />
*** [[Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:<br />
**** atom-entry<br />
**** hentry<br />
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])<br />
<br />
=== Alternatives ===<br />
The above proposal was not fully accepted. Other alternatives:<br />
<br />
* <code>entry</code> (Atom consistency)<br />
** +1 [[MarkRickerby]]<br />
* <code>atom-entry</code> (Atom consistency with prefix)<br />
* <code>hentry</code> (h* uF consistency)<br />
** +1 [[DavidJanes]]<br />
** +1 [[Tantek]]<br />
** +1 [[BenjaminCarlyle]]<br />
** +1 [[RyanKing]]<br />
** +1 [[MarkRickerby]]<br />
** +1 [[DannyAyers]]<br />
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])<br />
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption<br />
<br />
==== Discussion ====<br />
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p><br />
<br />
== Entry Title (atom:title) ==<br />
<br />
[[RyanKing]]: '''STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content' '''<br />
<br />
=== proposals ===<br />
<br />
The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):<br />
<br />
* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL<br />
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.<br />
** -1 [[KevinMarks]] (clashes with atom)<br />
* <code>Subject</code>, as used by SMTP email<br />
** -1 [[RyanKing]] - different semantics, doesn't fit<br />
* <code>heading</code><br />
** -1 [[RyanKing]] - a replication of &lt;h*&gt; semantics in html<br />
* <code>entry-title</code><br />
* <code>headline</code><br />
** +1 [[Tantek]]<br />
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]<br />
** +1 [[BenjaminCarlyle]], atom:entry/title only<br />
** +&frac12; [[DavidJanes]], atom:entry/title only<br />
** +&frac12; [[PaulBryson]], redundant?<br />
* <code>title</code> (Atom consistency)<br />
** -1 [[Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.<br />
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)<br />
** +&frac12; [[PaulBryson]], clear=good / hyphenating=bad<br />
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])<br />
** &plusmn;0 [[DavidJanes]] see my note below<br />
** -1 [[Tantek]] (does not mean the "name" of the post/entry)<br />
** +1 [[BenjaminCarlyle]], atom:feed/title only<br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.<br />
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.<br />
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.<br />
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p> Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p><br />
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.<br />
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.<br />
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p><br />
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.<br />
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.<br />
<br />
== Entry Content (atom:content) ==<br />
<br />
'''STATUS - RESOLVED going with entry-content'''<br />
<br />
* <code>content</code> (Atom consistency)<br />
** -1 [[Tantek]]<br />
** +1 [[DavidJanes]]<br />
** +1 [[BenjaminCarlyle]]<br />
** +1 [[RyanKing]]<br />
** -1 [[ChrisCasciano]]<br />
** -1 KevinMarks - already too many in the wild<br />
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)<br />
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion<br />
** -1 Tantek - agreed with Ryan<br />
** -1 KevinMarks<br />
* <code>entry-content</code><br />
** +1 Niall Kennedy (proposed)<br />
** +0.5 [[Tantek]]<br />
** +1 KevinMarks<br />
** +1 [[ChrisCasciano]]<br />
* <code>atom-content</code><br />
** +0.5 [[Tantek]]<br />
* <code>hcontent</code><br />
** -1 [[Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.<br />
<br />
<br />
=== Discussion ===<br />
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.<br />
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An &lt;a rel="content" href="..."/&gt; form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.<br />
* [[ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.<br />
* [[Tantek]]: Chris Casciano is right. Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending. I have changed my vote to -1 for "content".<br />
* [[Tantek]]: I have added a few proposed alternatives based on discussions with various folks. I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing. I have split my vote among the new alternatives for now.<br />
* [[ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.<br />
* [[KevinMarks]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.<br />
* [[ChrisCasciano]] - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')<br />
<br />
== Entry Summary (atom:summary) ==<br />
<br />
'''STATUS - RESOLVED - going with 'entry-summary''''<br />
<br />
The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):<br />
<br />
* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)<br />
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. <br />
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.<br />
* <code>summary</code> (re-use from and consistency with Atom)<br />
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)<br />
* <code>partial-description</code><br />
* <code>excerpt</code><br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 DavidJanes, my only concern being that they're not always excerpts<br />
* <code>abstract</code><br />
** +1 KevinMarks<br />
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs<br />
<br />
=== Discussion ===<br />
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.<br />
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'<br />
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.<br />
* [[Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p><br />
** WordPress user interface calls it "excerpt"<br />
** MovableType user interface calls it "excerpt"<br />
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.<br />
* [[ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.<br />
* [[ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.<br />
<br />
== Entry Permalink (atom:link) ==<br />
<br />
'''STATUS - RESOLVED - 'bookmark' '''<br />
<br />
* <code>rel="bookmark"</code> (HTML consitency)<br />
** +2 DavidJanes<br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 KevinMarks<br />
<br />
=== Discussion ===<br />
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.<br />
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion<br />
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.<br />
* [[Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.<br />
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.<br />
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.<br />
** [[RyanKing]] non-issue, you can always use both.<br />
<br />
== Entry Published (atom:published) ==<br />
* <code>published</code> (Atom consistency)<br />
** +0.5 [[Tantek]]<br />
** +1 [[DavidJanes]]<br />
** +1 [[BenjaminCarlyle]]<br />
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])<br />
** +0.5 [[Tantek]] (want to consider it, while we can)<br />
* <code>VJOURNAL CREATED</code><br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.<br />
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p><br />
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"<br />
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p><br />
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards<br />
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.<br />
* [[Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.<br />
<br />
== Entry Updated (atom:updated) ==<br />
<br />
'''STATUS - RESOLVED - 'updated''''<br />
<br />
* <code>updated</code> (Atom consistency)<br />
** +1 Tantek<br />
** +1 DavidJanes<br />
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])<br />
** +&frac12; Paul Bryson, Not as human readable<br />
** +0.5 [[Tantek]] (want to consider it, while we can)<br />
* <code>last-modified</code><br />
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)<br />
** dtstamp<br />
** dtupdated<br />
<br />
=== Discussion ===<br />
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.<br />
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.<br />
* [[Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.<br />
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p><br />
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p><br />
* [[DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards<br />
go back throught [[blog-post-examples]] to see what conventions we have.<br />
* [[Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.<br />
<br />
== Entry Author (atom:author) ==<br />
<br />
'''STATUS - RESOLVED - 'author' required, should use <code>&lt;address&gt;</code>'''<br />
<br />
* <code>author</code> (Atom consistency)<br />
** +1 [[Tantek]]<br />
** +1 [[BenjaminCarlyle]]<br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?<br />
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.<br />
* [[RyanKing]] is &lt;address&gt; not sufficient for 'author' semantics?<br />
* [[DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what &lt;address&gt; implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].<br />
<br />
== Entry Contributor (atom:contributor) ==<br />
** -1 Tantek (see Discussion)<br />
* <code>contributor</code> (Atom consistency)<br />
** +1 Tantek<br />
** +1 DavidJanes<br />
<br />
=== Discussion ===<br />
* [[Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").<br />
* [[DavidJanes]]: '''RESOLUTION: DEFERRED'''<br />
<br />
== Entry Geo (geo:Point) ==<br />
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.<br />
<br />
=== GeoRSS Resources ===<br />
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]<br />
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]<br />
<br />
== Questions and Comments ==<br />
<br />
=== Limitations ===<br />
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)<br />
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]<br />
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.<br />
<br />
=== Relationship to hReview definitions needs clarification ===<br />
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:<br />
<br />
* atom:published -> hReview dtreviewed<br />
* atom:author -> hReview reviewer<br />
<br />
[[Tantek]]: "Pushed back" is the wrong direction here.<br />
<br />
The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.<br />
<br />
In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.<br />
<br />
=== hCards ===<br />
<br />
[[DavidJanes]]: Should hCards be required for the <code>&lt;address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.<br />
<br />
RESOLVED: MUST use hCard for author.<br />
<br />
* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code>&lt;address&gt;</code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code>&lt;address class="vcard"&gt;</code> we would have pretty good 1:1 mappings:<br />
** atom:name &harr; hCard’s FN<br />
** atom:email &harr; hCard’s EMAIL<br />
** atom:uri &harr; hCard’s URI<br />
* '''STATUS - OPEN'''. "MAY" is the answer.<br />
* [[Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.<br />
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p><br />
<br />
=== Comparisons ===<br />
<br />
This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:<br />
* atomentry <-> slide<br />
* content <-> slidecontent<br />
* summary <-> handout<br />
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.<br />
<br />
--[[Ernie Prabhakar]]<br />
<br />
* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p><br />
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.<br />
<br />
=== Repeated Elements ===<br />
We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].<br />
<br />
Your thoughts please... -- [[User:DavidJanes|David Janes]]<br />
<br />
'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.<br />
<br />
=== Opaqueness ===<br />
If you have concerns about [[hatom#hAtom_Opaque|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.<br />
<br />
==== Opaqueness of other microformat elements ====<br />
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.<br />
<br />
To summarise,<br />
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?<br />
<br />
-- [[BenjaminCarlyle]]<br />
<br />
* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. -- <br />
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.<br />
<br />
==== Opaqueness of summary and content ====<br />
[[DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code>&lt;ins&gt;</code> and <code>&lt;del&gt;</code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.<br />
<br />
Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.<br />
<br />
Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:<br />
<code>&lt;div class="content">&lt;div class="summary">...</div>...</div></code><br />
<br />
A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.<br />
<br />
=== Identification ===<br />
The current spec under Schema:Nomenclature:Entry includes the text:<br />
"if practical, also define id="unique-identifier" to the Entry"<br />
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?<br />
<br />
Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?<br />
<br />
The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?<br />
<br />
'''STATUS - OPEN'''.<br />
<br />
=== HTML Title ===<br />
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?<br />
<br />
=== rel-tag ===<br />
Should hAtom use rel-tag for atom category elements? -- [[DavidJanes]]<br />
<br />
* [[Tantek]]: IMHO yes.<br />
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.<br />
* rel-tag uses the last path segment of a URI as its tag, for example <code>&lt;a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.<br />
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)<br />
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.<br />
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).<br />
<br />
* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)<br />
<br />
=== Excess disambiguation rules? ===<br />
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.<br />
<br />
It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?<br />
<br />
=== Dependencies ===<br />
==== mfo ====<br />
Does this specification depend on acceptance of a hAtom-compatible mfo?<br />
See [[mfo-examples]].<br />
<br />
=== Is atom:content necessary? ===<br />
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?<br />
<br />
=== Published as default value for atom:updated ===<br />
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.<br />
<br />
I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:<br />
# If multiple updated fields exist, choose the most recent one.<br />
# If only one updated field exists, choose that value.<br />
# If no updated field exists but a published field exists, use the published value for atom:updated.<br />
: + 1 [[User:RobertBachmann|Robert Bachmann]]<br />
<br />
=== Designating the page author ===<br />
<br />
(2006-02-07 raised by [[User:RobertBachmann|Robert Bachmann]])<br />
<br />
“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”<br />
<br />
* How do I designate the page author(s)? <br />
** <code>class="author"</code> outside of the hAtom entry?<br />
** <code>&lt;address class="author"&gt;</code> outside of the hAtom entry?<br />
** <code>&lt;address&gt;</code> outside of the hAtom feed (i.e. at the page level)?<br />
* How do I designate the feed author(s)?<br />
<br />
(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])<br />
There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.<br />
<br />
==== Proposal ====<br />
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)<br />
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.<br />
<br />
== Entry Updated Required? -- Blogger ==<br />
* 2006-03-06 raised by [[User:Singpolyma|singpolyma]].<br />
*# The [[hatom|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? I ask primarily because I am wanting to update my [http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html XOXO Blog Format], which is based on hAtom, to comply with the new version of the standard -- and all my test-cases are on Blogger blogs...<br />
<br />
= See Also =<br />
* [[hatom|hAtom]] - the draft proposal<br />
* [[hatom-faq]] - knowledge base<br />
* [[blog-post-brainstorming]]<br />
* [[blog-post-formats]]<br />
* [[blog-post-examples]]<br />
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)<br />
* [[mfo-examples]]<br />
* [[naming-principles]]<br />
<br />
= Template =<br />
<br />
Please use this format (copy and paste this to the end of the list to add your issues):<br />
* 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.''</div>Filhttps://microformats.org/wiki/index.php?title=hatom-issues&diff=5524hatom-issues2006-03-24T15:46:16Z<p>Fil: /* hAtom 0.2 */ Author as hCard is too complex to *require*</p>
<hr />
<div>= hAtom 0.2 =<br />
<br />
This section is for discussing what you'd like to see in the next version of hAtom, i.e. 0.2.<br />
<br />
== Feed <i>XXX</i> (atom:<i>xxx</i>) ==<br />
<br />
Template section: if there is something clearly from an Atom ''Feed'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.<br />
<br />
== Entry <i>XXX</i> (atom:<i>xxx</i>) ==<br />
<br />
Template section: if there is something clearly from an Atom ''Entry'' that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.<br />
<br />
== Author ==<br />
<br />
=== author as an hcard is too much to require ===<br />
<br />
* [[Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.rezo.net/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a &lt;div class="author"> element.<br />
<br />
* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"<br />
<br />
<br />
<br />
<br />
== Other Questions and Issues ==<br />
<br />
General comments, modeling issues, algorithm issues, should have issues, etc. go here.<br />
<br />
= hAtom 0.1 =<br />
<br />
'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''<br />
<br />
This page documents the issues that have been raised regarding the [[hatom|hAtom]] draft during the course of its development, and the resolutions of those issues (often with accompanying opinions).<br />
<br />
__TOC__<br />
<br />
== Contributors ==<br />
* Danny Ayers<br />
* Robert Bachmann<br />
* Paul Bryson<br />
* Benjamin Carlyle<br />
* Chris Casciano<br />
* Tantek Çelik<br />
* David Janes<br />
* Ryan King<br />
* Kevin Marks<br />
* Scott Reynen<br />
* Brian<br />
<br />
== Feed (atom:feed)==<br />
<br />
[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' and not required (a la [[hcalendar]])''' <br />
<br />
=== Initial proposal ===<br />
<br />
<code>atomfeed</code> (or rather, "atom-entry")<br />
<br />
* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?<br />
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking<br />
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases<br />
* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML<br />
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.<br />
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.<br />
* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)<br />
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) -- <br />
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".<br />
* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:<br />
** atom-feed<br />
** hfeed<br />
<br />
=== Alternatives ===<br />
<br />
The above proposal was not fully accepted and some other possibilities were proposed:<br />
<br />
* <code>feed</code> (Atom consistency)<br />
* <code>atom-feed</code> (Atom consistency with prefix)<br />
* <code>hfeed</code> (h* uF consistency)<br />
** +1 DavidJanes<br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 MarkRickerby<br />
** +1 DannyAyers<br />
<br />
==== Discussion ====<br />
<br />
The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[Tantek]]<br />
<br />
== Entry (atom:entry) ==<br />
<br />
[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''<br />
<br />
=== Initial Proposal ===<br />
<br />
<code>atomentry</code> (or rather, "atom-entry")<br />
<br />
* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.<br />
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:<br />
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.<br />
** to follow the naming pattern seen in the other compound microformats ([[hCard]], [[hCalendar]], etc.)<br />
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both<br />
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)<br />
*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...<br />
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del><br />
*** [[Tantek]]: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:<br />
**** atom-entry<br />
**** hentry<br />
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])<br />
<br />
=== Alternatives ===<br />
The above proposal was not fully accepted. Other alternatives:<br />
<br />
* <code>entry</code> (Atom consistency)<br />
** +1 [[MarkRickerby]]<br />
* <code>atom-entry</code> (Atom consistency with prefix)<br />
* <code>hentry</code> (h* uF consistency)<br />
** +1 [[DavidJanes]]<br />
** +1 [[Tantek]]<br />
** +1 [[BenjaminCarlyle]]<br />
** +1 [[RyanKing]]<br />
** +1 [[MarkRickerby]]<br />
** +1 [[DannyAyers]]<br />
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])<br />
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption<br />
<br />
==== Discussion ====<br />
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal. Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p><br />
<br />
== Entry Title (atom:title) ==<br />
<br />
[[RyanKing]]: '''STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content' '''<br />
<br />
=== proposals ===<br />
<br />
The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):<br />
<br />
* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL<br />
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom.<br />
** -1 [[KevinMarks]] (clashes with atom)<br />
* <code>Subject</code>, as used by SMTP email<br />
** -1 [[RyanKing]] - different semantics, doesn't fit<br />
* <code>heading</code><br />
** -1 [[RyanKing]] - a replication of &lt;h*&gt; semantics in html<br />
* <code>entry-title</code><br />
* <code>headline</code><br />
** +1 [[Tantek]]<br />
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]<br />
** +1 [[BenjaminCarlyle]], atom:entry/title only<br />
** +&frac12; [[DavidJanes]], atom:entry/title only<br />
** +&frac12; [[PaulBryson]], redundant?<br />
* <code>title</code> (Atom consistency)<br />
** -1 [[Tantek]]. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.<br />
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)<br />
** +&frac12; [[PaulBryson]], clear=good / hyphenating=bad<br />
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])<br />
** &plusmn;0 [[DavidJanes]] see my note below<br />
** -1 [[Tantek]] (does not mean the "name" of the post/entry)<br />
** +1 [[BenjaminCarlyle]], atom:feed/title only<br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.<br />
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.<br />
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.<br />
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others. See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p> Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p><br />
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.<br />
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.<br />
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p><br />
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.<br />
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.<br />
<br />
== Entry Content (atom:content) ==<br />
<br />
'''STATUS - RESOLVED going with entry-content'''<br />
<br />
* <code>content</code> (Atom consistency)<br />
** -1 [[Tantek]]<br />
** +1 [[DavidJanes]]<br />
** +1 [[BenjaminCarlyle]]<br />
** +1 [[RyanKing]]<br />
** -1 [[ChrisCasciano]]<br />
** -1 KevinMarks - already too many in the wild<br />
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)<br />
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion<br />
** -1 Tantek - agreed with Ryan<br />
** -1 KevinMarks<br />
* <code>entry-content</code><br />
** +1 Niall Kennedy (proposed)<br />
** +0.5 [[Tantek]]<br />
** +1 KevinMarks<br />
** +1 [[ChrisCasciano]]<br />
* <code>atom-content</code><br />
** +0.5 [[Tantek]]<br />
* <code>hcontent</code><br />
** -1 [[Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.<br />
<br />
<br />
=== Discussion ===<br />
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.<br />
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An &lt;a rel="content" href="..."/&gt; form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.<br />
* [[ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.<br />
* [[Tantek]]: Chris Casciano is right. Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending. I have changed my vote to -1 for "content".<br />
* [[Tantek]]: I have added a few proposed alternatives based on discussions with various folks. I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing. I have split my vote among the new alternatives for now.<br />
* [[ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.<br />
* [[KevinMarks]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.<br />
* [[ChrisCasciano]] - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')<br />
<br />
== Entry Summary (atom:summary) ==<br />
<br />
'''STATUS - RESOLVED - going with 'entry-summary''''<br />
<br />
The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):<br />
<br />
* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)<br />
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. <br />
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.<br />
* <code>summary</code> (re-use from and consistency with Atom)<br />
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)<br />
* <code>partial-description</code><br />
* <code>excerpt</code><br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 DavidJanes, my only concern being that they're not always excerpts<br />
* <code>abstract</code><br />
** +1 KevinMarks<br />
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs<br />
<br />
=== Discussion ===<br />
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.<br />
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'<br />
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.<br />
* [[Tantek]]: Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p><br />
** WordPress user interface calls it "excerpt"<br />
** MovableType user interface calls it "excerpt"<br />
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone.<br />
* [[ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.<br />
* [[ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.<br />
<br />
== Entry Permalink (atom:link) ==<br />
<br />
'''STATUS - RESOLVED - 'bookmark' '''<br />
<br />
* <code>rel="bookmark"</code> (HTML consitency)<br />
** +2 DavidJanes<br />
** +1 Tantek<br />
** +1 BenjaminCarlyle<br />
** +1 KevinMarks<br />
<br />
=== Discussion ===<br />
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.<br />
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion<br />
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.<br />
* [[Tantek]]: Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file.<br />
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.<br />
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.<br />
** [[RyanKing]] non-issue, you can always use both.<br />
<br />
== Entry Published (atom:published) ==<br />
* <code>published</code> (Atom consistency)<br />
** +0.5 [[Tantek]]<br />
** +1 [[DavidJanes]]<br />
** +1 [[BenjaminCarlyle]]<br />
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])<br />
** +0.5 [[Tantek]] (want to consider it, while we can)<br />
* <code>VJOURNAL CREATED</code><br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.<br />
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p><br />
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"<br />
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p><br />
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards<br />
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.<br />
* [[Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.<br />
<br />
== Entry Updated (atom:updated) ==<br />
<br />
'''STATUS - RESOLVED - 'updated''''<br />
<br />
* <code>updated</code> (Atom consistency)<br />
** +1 Tantek<br />
** +1 DavidJanes<br />
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])<br />
** +&frac12; Paul Bryson, Not as human readable<br />
** +0.5 [[Tantek]] (want to consider it, while we can)<br />
* <code>last-modified</code><br />
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)<br />
** dtstamp<br />
** dtupdated<br />
<br />
=== Discussion ===<br />
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.<br />
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.<br />
* [[Tantek]]: See discussion for published. Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something. Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.<br />
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p><br />
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p><br />
* [[DavidJanes]]: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards<br />
go back throught [[blog-post-examples]] to see what conventions we have.<br />
* [[Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.<br />
<br />
== Entry Author (atom:author) ==<br />
<br />
'''STATUS - RESOLVED - 'author' required, should use <code>&lt;address&gt;</code>'''<br />
<br />
* <code>author</code> (Atom consistency)<br />
** +1 [[Tantek]]<br />
** +1 [[BenjaminCarlyle]]<br />
<br />
=== Discussion ===<br />
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?<br />
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used. Thus we should exclude it from hAtom in the first version. However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.<br />
* [[RyanKing]] is &lt;address&gt; not sufficient for 'author' semantics?<br />
* [[DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what &lt;address&gt; implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].<br />
<br />
== Entry Contributor (atom:contributor) ==<br />
** -1 Tantek (see Discussion)<br />
* <code>contributor</code> (Atom consistency)<br />
** +1 Tantek<br />
** +1 DavidJanes<br />
<br />
=== Discussion ===<br />
* [[Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor". We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").<br />
* [[DavidJanes]]: '''RESOLUTION: DEFERRED'''<br />
<br />
== Entry Geo (geo:Point) ==<br />
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.<br />
<br />
=== GeoRSS Resources ===<br />
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]<br />
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]<br />
<br />
== Questions and Comments ==<br />
<br />
=== Limitations ===<br />
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)<br />
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]<br />
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.<br />
<br />
=== Relationship to hReview definitions needs clarification ===<br />
[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:<br />
<br />
* atom:published -> hReview dtreviewed<br />
* atom:author -> hReview reviewer<br />
<br />
[[Tantek]]: "Pushed back" is the wrong direction here.<br />
<br />
The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.<br />
<br />
In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.<br />
<br />
=== hCards ===<br />
<br />
[[DavidJanes]]: Should hCards be required for the <code>&lt;address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.<br />
<br />
RESOLVED: MUST use hCard for author.<br />
<br />
* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as "The 'atom:author' element is a Person construct that indicates the author of the entry or feed." and <code>&lt;address&gt;</code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code>&lt;address class="vcard"&gt;</code> we would have pretty good 1:1 mappings:<br />
** atom:name &harr; hCard’s FN<br />
** atom:email &harr; hCard’s EMAIL<br />
** atom:uri &harr; hCard’s URI<br />
* '''STATUS - OPEN'''. "MAY" is the answer.<br />
* [[Tantek]]: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.<br />
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p><br />
<br />
=== Comparisons ===<br />
<br />
This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html S5]:<br />
* atomentry <-> slide<br />
* content <-> slidecontent<br />
* summary <-> handout<br />
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.<br />
<br />
--[[Ernie Prabhakar]]<br />
<br />
* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p><br />
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.<br />
<br />
=== Repeated Elements ===<br />
We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].<br />
<br />
Your thoughts please... -- [[User:DavidJanes|David Janes]]<br />
<br />
'''STATUS - RESOLVED'''. The spec has explicit rules for disambiguating all these items if they appear multiple times.<br />
<br />
=== Opaqueness ===<br />
If you have concerns about [[hatom#hAtom_Opaque|opaqueness]], that is, stopping interpretation below certain hAtom elements, raise them here.<br />
<br />
==== Opaqueness of other microformat elements ====<br />
How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.<br />
<br />
To summarise,<br />
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?<br />
<br />
-- [[BenjaminCarlyle]]<br />
<br />
* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. -- <br />
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.<br />
<br />
==== Opaqueness of summary and content ====<br />
[[DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code>&lt;ins&gt;</code> and <code>&lt;del&gt;</code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.<br />
<br />
Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.<br />
<br />
Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules:<br />
<code>&lt;div class="content">&lt;div class="summary">...</div>...</div></code><br />
<br />
A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.<br />
<br />
=== Identification ===<br />
The current spec under Schema:Nomenclature:Entry includes the text:<br />
"if practical, also define id="unique-identifier" to the Entry"<br />
What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?<br />
<br />
Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?<br />
<br />
The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?<br />
<br />
'''STATUS - OPEN'''.<br />
<br />
=== HTML Title ===<br />
Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?<br />
<br />
=== rel-tag ===<br />
Should hAtom use rel-tag for atom category elements? -- [[DavidJanes]]<br />
<br />
* [[Tantek]]: IMHO yes.<br />
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.<br />
* rel-tag uses the last path segment of a URI as its tag, for example <code>&lt;a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.<br />
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)<br />
* hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.<br />
* [[rel-tag]] permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).<br />
<br />
* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)<br />
<br />
=== Excess disambiguation rules? ===<br />
Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.<br />
<br />
It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?<br />
<br />
=== Dependencies ===<br />
==== mfo ====<br />
Does this specification depend on acceptance of a hAtom-compatible mfo?<br />
See [[mfo-examples]].<br />
<br />
=== Is atom:content necessary? ===<br />
Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?<br />
<br />
=== Published as default value for atom:updated ===<br />
It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.<br />
<br />
I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:<br />
# If multiple updated fields exist, choose the most recent one.<br />
# If only one updated field exists, choose that value.<br />
# If no updated field exists but a published field exists, use the published value for atom:updated.<br />
: + 1 [[User:RobertBachmann|Robert Bachmann]]<br />
<br />
=== Designating the page author ===<br />
<br />
(2006-02-07 raised by [[User:RobertBachmann|Robert Bachmann]])<br />
<br />
“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”<br />
<br />
* How do I designate the page author(s)? <br />
** <code>class="author"</code> outside of the hAtom entry?<br />
** <code>&lt;address class="author"&gt;</code> outside of the hAtom entry?<br />
** <code>&lt;address&gt;</code> outside of the hAtom feed (i.e. at the page level)?<br />
* How do I designate the feed author(s)?<br />
<br />
(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])<br />
There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.<br />
<br />
==== Proposal ====<br />
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)<br />
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.<br />
<br />
== Entry Updated Required? -- Blogger ==<br />
* 2006-03-06 raised by [[User:Singpolyma|singpolyma]].<br />
*# The [[hatom|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom'' I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? I ask primarily because I am wanting to update my [http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html XOXO Blog Format], which is based on hAtom, to comply with the new version of the standard -- and all my test-cases are on Blogger blogs...<br />
<br />
= See Also =<br />
* [[hatom|hAtom]] - the draft proposal<br />
* [[hatom-faq]] - knowledge base<br />
* [[blog-post-brainstorming]]<br />
* [[blog-post-formats]]<br />
* [[blog-post-examples]]<br />
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)<br />
* [[mfo-examples]]<br />
* [[naming-principles]]<br />
<br />
= Template =<br />
<br />
Please use this format (copy and paste this to the end of the list to add your issues):<br />
* 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.''</div>Filhttps://microformats.org/wiki/index.php?title=hreview-issues&diff=5692hreview-issues2006-03-22T19:05:44Z<p>Fil: /* hReview issues */</p>
<hr />
<div>= hReview issues =<br />
<br />
These are externally raised issues about [[hreview|hReview]] with broadly varying degrees of merit. Thus some issues are REJECTED 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 ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/log/ Tantek]<br />
<br />
See related [[hcalendar-issues]] and [[hcard-issues]].<br />
<br />
== Template ==<br />
<br />
Please use this format (copy and paste this to the end of the list to add your issues):<br />
* 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 />
== rel=&quot;self&quot; ==<br />
<br />
2005-01-04 by [[User:DavidJanes|David Janes]]:<br />
<br />
Atom defines rel=&quot;self&quot; [http://atompub.org/2005/07/11/draft-ietf-atompub-format-10.html#rfc.section.4.2.7 here]<br />
<br />
: The value &quot;self&quot; signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.<br />
<br />
HTML rel=&quot;boomark&quot; [http://www.w3.org/TR/REC-html40/types.html#type-links here]<br />
<br />
: Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The title attribute may be used, for example, to label the bookmark. Note that several bookmarks may be defined in each document.<br />
<br />
Since we're using &quot;bookmark&quot; to mean the entry point to the hReview, isn't the &quot;self&quot; redundant or overly subtle?<br />
<br />
== default lower bound ==<br />
<br />
* YYYY-MM-DD????? raised by [[User:ScottReynen|Scott Reynen]]<br />
*# ''Why is the default lower bound 1 when the [[reviews-formats|real world examples]] almost all have a lower bound of 0?''<br />
*#* REJECTED INVALID ASSUMPTION. Most [[review-examples|real-world examples]] have a lower bound of 1, not 0.<br />
<br />
== default range ==<br />
* 2006-02-23 raised by Andy Mabbett<br />
*# ''Not all marks give ratings "out of five". The value should be a percentage. Zero should be allowed.''<br />
*#* REJECTED IGNORES RESEARCH. Most [[review-examples|real-world examples]] have a range of 1.0-5.0 not a percentage. You may set the "best" bound to 100 explicitly, and the "worst" bound to 0 explicitly per the spec if necessary.<br />
*#* "most" != "all"; indeed, the page you cite has examples of "1-10" and "0-100%". I never claimed that many examples use percentages, but I'm sure a mathematician would explain that values in the range "1-5" may be expressed as percentages.<br />
*#* REJECTED RTFM. Most examples are what the defaults are based on. Please re-read both the spec and the previous resolution, 1-10 is allowed (you have to explicitly set "best" to 10), and so is 0-100 (you have to explicitly set "worst" to 0 and "best" to 100).<br />
<br />
== Specification Clarifications ==<br />
<br />
* 2006-02-01 raised by [http://tantek.com Tantek].<br />
*# ''The spec needs to clarify that there is only one "item" per "hreview".''<br />
*#* ACCEPTED. Resolved in hReview 0.3.<br />
<br />
<br />
== Multilinguism ==<br />
<br />
* 2006-03-22 raised by Fil<br />
*# the reviewer spec can't say ''For anonymous reviews, use "anonymous" (without quotes) for the full name of the reviewer.'' as this word ("anonymous") is going to be apparent on the page, and is not multilingual (and even in English someone might want to use another word, like "an anonymous coward")</div>Filhttps://microformats.org/wiki/index.php?title=hatom&diff=4052hatom2006-01-06T01:11:01Z<p>Fil: add sources link to sedna</p>
<hr />
<div>= hAtom =<br />
<br />
hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is a strongly based on a subset of the [http://www.atomenabled.org/ Atom] syndication format; every concept in hAtom has a corresponding definition in Atom. <br />
<br />
This microformat is a draft; please address your concerns, issues, comments, etc. in [[hatom-issues]].<br />
<br />
__TOC__<br />
<br />
== Draft Specification ==<br />
<br />
=== Editor ===<br />
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix.com BlogMatrix, Inc.]<br />
<br />
=== Authors ===<br />
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix.com BlogMatrix, Inc]<br />
<br />
=== Contributors ===<br />
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]<br />
<br />
=== Copyright ===<br />
{{MicroFormatCopyrightStatement2005}}<br />
<br />
=== Patents ===<br />
{{MicroFormatPatentStatement}}<br />
<br />
== Introduction ==<br />
<br />
== Semantic XHTML Design Principles ==<br />
{{semantic-xhtml-design-principles}}<br />
<br />
== Format ==<br />
=== In General ===<br />
The [http://atomenabled.org/developers/syndication/#person Atom Syndication Format] provides the conceptual basis for this microformat, with the following caveats:<br />
<br />
* Atom provides a lot more functionality that we need for a "blog post" microformat, so we've taken the minimal number of elements needed. This can (and probably should) be expanded.<br />
* the "logical" model of hAtom is that of Atom. If there is a conflict, Atom should be taken as correct.<br />
* the "physical" model of hAtom -- the actual writing of elements -- is a lot more varied than Atom provides for, due to the variety of ways weblogs are actually produced in the wild. The hAtom microformat provides a number of rules for "briding the gap"<br />
:: ''for example, if an entry is missing an author (required by Atom), it is assumed to be that of the XHTML page''<br />
<br />
=== Schema ===<br />
Schema elements are based on the Atom nomenclature and follow the microformat pattern of prefixing a unique identifier (in this case, <code>atom</code>) on the outermost container elements -- the Feed or Entry. The parts of this microformat are based on analysis of many weblog, bulletin board and media posts and can be read [[blog-post-brainstorming#Discovered_Elements]]. Note the renaming of 'EntryGroup' to 'Feed' to be more consistent with Atom ternminology.<br />
<br />
==== Nomenclature ====<br />
<br />
{| width="100%" border="1" cellspacing="0" <br />
|-<br />
! width="150" | Concept<br />
! Atom Identifier<br />
! hAtom Microformat Usage<br />
|-<br />
| Feed<br />
| <code>atom:feed</code><br />
| add <code>class="feed"</code><br />
|-<br />
| Entry<br />
| <code>atom:entry</code><br />
| Add <code>class="entry"</code>; if practical, also define <code>id="unique-identifier"</code> to the Entry.<br />
|-<br />
| Entry Title<br />
| <code>atom:title</code><br />
| Add <code>class="title"</code>, alternately by <code>&lt;h#></code>.<br />
|-<br />
| Entry Content<br />
| <code>atom:content</code><br />
| Add <code>class="content"</code> to all appropriate blocks. Multiple Entry Content blocks are logically considered one concatenated <code>atom:content</code> equivalent.<br />
|-<br />
| Entry Summary<br />
| <code>atom:summary</code><br />
| Add <code>class="summary"</code> to all appropriate blocks. Multiple Entry Summary blocks are logically considered one concatenated <code>atom:summary</code> equivalent.<br />
|-<br />
| Entry Permalink<br />
| <code>atom:link</code><br />
| Add <code>rel="bookmark"</code>.<br />
|-<br />
| Entry Published<br />
| <code>atom:published</code><br />
| Use <code>&lt;abbr class="published" title="YYYYMMYYThh:mm:ss&plusmn;ZZ:ZZ"></code>...<code>&lt;/abbr></code>, following the [[datetime-design-pattern]].<br />
|-<br />
| Entry Updated<br />
| <code>atom:updated</code><br />
| Use <code>&lt;abbr class="updated" title="YYYYMMYYThh:mm:ss&plusmn;ZZ:ZZ"></code>...<code>&lt;/abbr></code>, following the [[datetime-design-pattern]].<br />
|-<br />
| Entry Author<br />
| <code>atom:author</code><br />
| Add <code>class="author"</code> to appropriate blocks. Using <code><address class="author"></code>...<code></address></code> is recommended. Adding a [[hcard|hCard]] is highly recommended.<br />
|-<br />
| Entry Contributor<br />
| Add <code>atom:contibutor</code> to appropriate blocks.<br />
| Add <code>class="contributor"</code> to appropriate blocks. Using <code><address class="contributor"></code>...<code></address></code> is recommended. Adding a [[hcard|hCard]] is highly recommended.<br />
|}<br />
<br />
==== Nesting Rules ====<br />
<br />
{| width="100%" border="1" cellspacing="0" <br />
|-<br />
! Concept<br />
! Nests In<br />
! hAtom Opaque<br />
! Cardinality<br />
! Logical Cardinality<br />
|-<br />
| Feed<br />
| HTML document<br />
| No<br />
| 1-N<br />
| 1-N<br />
|-<br />
| Entry<br />
| Feed<br />
| No<br />
| 0-N<br />
| 0-N<br />
|-<br />
| Entry Title<br />
| Entry<br />Entry Permalink<br />
| No<br />
| 0-N<br />
| 0-1<br />
|-<br />
| Entry Content<br />
| Entry<br />
| Yes<br />
| 0-N<br />
| 0-1<br />
|-<br />
| Entry Summary<br />
| Entry<br />
| Yes<br />
| 0-N<br />
| 0-1<br />
|-<br />
| Entry Permalink<br />
| Entry<br />Entry Title<br />Entry Published<br />
| No<br />
| 0-N<br />
| 1<br />
|-<br />
| Entry Published<br />
| Entry<br />Entry Permalink<br />
| No<br />
| 0-N<br />
| 0-1<br />
|-<br />
| Entry Updated<br />
| Entry<br />Entry Permalink<br />
| No<br />
| 0-N<br />
| 1<br />
|-<br />
| Entry Author<br />
| Entry<br />
| Yes<br />
| 0-N<br />
| 1-N<br />
|-<br />
| Entry Contibutor<br />
| Entry<br />
| Yes<br />
| 0-N<br />
| 0-N<br />
|}<br />
<br />
===== hAtom Opaque =====<br />
<br />
"hAtom Opaque" specifies whether a hAtom parser should "look inside" the element for further hAtom content. If there are multiple rules applied to the same element take the OR of the two (i.e. "Yes" always wins)<br />
<br />
: ''hAtom Opaque is designed to make parsing rules less ambiguous. In particular, it allows "quoted" hAtom elements (from another blog being blockquoted, for example) ti be ignored. It also allows 'embedded' hAtom to be potentially delivered within hAtom itself, and to prevent accidental 'leaking' of other microformat information up into the hAtom container.''<br />
<br />
===== Cardinality =====<br />
<br />
How many times can an element of the given type appear in it's nesting/parent element.<br />
<br />
===== Logical Cardinality =====<br />
<br />
From a modeling/logical perspective, the number of times can an element appear.<br />
<br />
: ''This is all rule dependent, see below. For example, an Entry Permalink may appear 6 times, but each one must be the same value; an Entry Content element may appear 3 times, but they are all concatenated together to make a single logical element.''<br />
<br />
==== Rules and Definitions ====<br />
See the [[#Nesting_Rules|Nesting Rules]] section above for placement of these elements.<br />
<br />
===== Feed =====<br />
* an XHTML Feed element is identified by <code>class="feed"</code><br />
* a Feed element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1 atom feed]<br />
: ''In particular, as a container for Entrys.''<br />
* the Feed element is required, even if there is a single Entry<br />
: ''This is for disambiguation''<br />
* hAtom documents MAY have multiple, non-nested Feed elements<br />
: ''This may happen on news pages, or weblogs with "mini-blogs" on the sidebar.''<br />
<br />
===== Entry =====<br />
* an Entry element is identified by <code>class="entry"</code><br />
* an Entry element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 atom entry]<br />
* a weblog entry MUST be enclosed in a single Entry element<br />
: ''That's what it's for, after all.''<br />
* an Entry MUST have an enclosing Feed element<br />
* ''This enclosing element can be the same as the Entry -- i.e. class="feed entry" is OK for feeds with a single entry.''<br />
<br />
===== Entry Title =====<br />
* an Entry Title element is identified by <code>class="title"</code><br />
* an Entry Title element alternately be identified by <code>&lt;h#></code><br />
* an Entry Title element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.14 atom entry title]<br />
<br />
====== Disambiguation ======<br />
<br />
* the first hAtom valid element with a <code>class="title"</code> is the Entry Title<br />
: ''hAtom valid meaning somewhere where we expect it (like not inside Entry Content, for example).''<br />
* otherwise, the first hAtom valid <code>&lt;h#></code> element to appear in an hAtom document is the Entry Title<br />
* otherwise, the Entry Title is the empty string<br />
: ''Atom does not allow for an entry not to have a title.''<br />
<br />
===== Entry Content =====<br />
* an Entry Content element is identified by <code>class="content"</code><br />
* an Entry Content element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#atomContent atom content]<br />
* an Entry MAY have 0 or more Entry Content elements<br />
: ''We recognize this varies from the Atom spec: see the next rule.''<br />
* the "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry<br />
: ''Many weblogs split content into multiple sections with a "Read More" link and javascript tricks. This is also needed in cases where Entry Titles are coded inline and are considered part of the content.''<br />
* the "logical Entry Content" MUST be complete; that is, contain the entire content of the Entry<br />
: ''Otherwise it should be marked as Entry Summary.''<br />
<br />
===== Entry Summary =====<br />
* an Entry Summary element is identified by <code>class="summary"</code><br />
* an Entry Summary element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.13 atom summary]<br />
* an Entry MAY have 0 or more Entry Summary elements<br />
: ''We recognize this varies from the Atom spec: see the next rule.''<br />
* the "logical Entry Summary" of an Entry is the concatenation, in order of appearance, of all the Entry Summarys within the Entry<br />
<br />
===== Entry Permalink =====<br />
<br />
* an Entry Permalink element is identified by <code>rel="bookmark"</code><br />
: ''We recognize that we have broken from Atom terminology at this point. See [[hatom-issues]] for discussion.''<br />
: ''This may be a microformat in itself: [[rel-bookmark]].''<br />
* an Entry Permalink element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7 atom link in an entry]<br />
* Entry Permalinks SHOULD be absolute URIs<br />
* Entry Permalinks MUST be the same as the <code>atom:link</code> (or <code>rss:link</code>) used in syndication feeds<br />
: ''The intention of the previous two rules to gently force people to use strings that can be byte compared for equivalence. In general, the canonical URI should be the link used in an Atom entry.''<br />
: ''Is there a problem with FeedBurner?''<br />
* if an Entry has multiple elements marked as the Entry Permalink, they MUST have exactly the same URI<br />
* an Entry SHOULD have an Entry Permalink<br />
: ''There are circumstances (such as media pages) where this won't happen. See the next rule.''<br />
* there can be at most 1 Entry in an XHTML document without an Entry Permalink; the Entry Permalink of this Entry is the URI of the page<br />
: ''This rule is needed for media pages (i.e. a news article on cnn.com). There is some ugliness of with this because the URI could be non-canonical.''<br />
<br />
====== Disambiguation ======<br />
<br />
* The first valid element in an Entry marked as an Entry Permalink is the Entry Permalink<br />
<br />
===== Entry Published =====<br />
<br />
* an Entry Published element is identified by <code>class="published"</code><br />
* a Entry Published element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9 atom published]<br />
* the machine readable datetime should be encoded with an <code>&lt;abbr></code> element using the [[datetime-design-pattern]]; the machine readable datetime should be complete, that is, specified to the second with the timezone included<br />
: ''This is to be consistent with the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.3.3 Atom Datetime Construct].<br />
* optionally, this can be specified by an HTML element with the ISO datetime in the text.<br />
: ''This is a little uglier for the reader, but it's possible.''<br />
<br />
====== Disambiguation ======<br />
<br />
* The first valid element in an Entry marked as an Entry Published is the Entry Published element<br />
<br />
===== Entry Updated =====<br />
<br />
* an Entry Updated element is identified by <code>class="updated"</code><br />
* a Entry Updated element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15 atom updated]<br />
* the machine readable datetime should be encoded with an <code>&lt;abbr></code> element using the [[datetime-design-pattern]]; the machine readable datetime should be complete, that is, specified to the second with the timezone included<br />
: ''This is to be consistent with the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.3.3 Atom Datetime Construct].<br />
* if there is no Entry Updated element, the value is assumed to be that of Entry Published<br />
: ''Entry Published is more often available in weblog templates, so we're going with that.''<br />
* if there is no Entry Updated and Entry Published elements, transformation to Atom is problematic<br />
: ''This is because a published element is required. Suggestions would be appreciated here.''<br />
* optionally, this can be specified by an HTML element with the ISO datetime in the text.<br />
: ''This is a little uglier for the reader, but it's possible.''<br />
<br />
====== Disambiguation ======<br />
<br />
* The first valid element in an Entry marked as an Entry Updated is the Entry Updated element<br />
<br />
===== Entry Author =====<br />
<br />
* an Entry Author element is represented by <code>class="author"</code><br />
* an Entry Author element SHOULD use an XHTML <code>&lt;address></code> element<br />
* an Entry Author element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.1 atom author]<br />
* an Entry Author element SHOULD contain an [[hcard|hCard]]<br />
: ''If it does not, just consider the text to effectively be the FN''<br />
* an Entry MAY have 0 or more Entry Author elements<br />
* if an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page<br />
: ''Atom requires at least one Author''<br />
<br />
===== Entry Contibutor =====<br />
<br />
* an Entry Contibutor element is represented by <code>class="contributor"</code><br />
* an Entry Contibutor element SHOULD use an XHTML <code>&lt;address></code> element<br />
* an Entry Contibutor element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.3 atom contributor]<br />
* an Entry Contibutor element SHOULD contain an [[hcard|hCard]]<br />
: ''If it does not, just consider the text to be the FN''<br />
* an Entry MAY have 0 or more Entry Contibutor elements<br />
<br />
=== XMDP Profile ===<br />
<pre><br />
<dl class="profile"><br />
<dt>class</dt><br />
<dd><p><br />
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class"><br />
HTML4 definition of the 'class' attribute.</a><br />
This meta data profile defines some 'class' attribute values (class names) <br />
and their meanings as suggested by a <br />
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile"><br />
draft of "Hypertext Links in HTML"</a>.<br />
<dl><br />
<dt>feed</dt><br />
<dd><br />
The concept of atom:feed from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>entry</dt><br />
<dd><br />
The concept of atom:entry from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>content</dt><br />
<dd><br />
The concept of atom:content from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>summary</dt><br />
<dd><br />
The concept of atom:summary from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>bookmark</dt><br />
<dd><br />
The concept of atom:link (without any "rel") with an atom:entry from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>published</dt><br />
<dd><br />
The concept of atom:published from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>updated</dt><br />
<dd><br />
The concept of atom:updatedfrom <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>author</dt><br />
<dd><br />
The concept of atom:author from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
</dl><br />
</dd><br />
</dl><br />
</pre><br />
<br />
=== Parsing Details ===<br />
<br />
== Examples ==<br />
<br />
This section is informative.<br />
<br />
=== Transformation 1 ===<br />
<br />
A well behaved weblog.<br />
<br />
Original:<br />
<br />
<pre><nowiki><br />
<body><br />
<div id="wrap"><br />
<div id="content"><br />
...<br />
<div class="entry"><br />
<h3 id="post-60"><br />
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a><br />
</h3><br />
<p>We had a bit of trouble with ...</p><br />
<p>We&#8217;ve restored the wiki and ...</p><br />
<p>If anyone is working to combat said spammers ...</p><br />
<br />
<h4 class="tags">Technorati Tags:</h4><br />
<ul class="tags"><br />
<li><a href="http://technorati.com/tag/mediawiki" rel="tag">mediawiki</a></li><br />
<li><a href="http://technorati.com/tag/microformats" rel="tag">microformats</a></li><br />
<li><a href="http://technorati.com/tag/spam" rel="tag">spam</a></li><br />
</ul><br />
<br />
<ul class="post-info"><br />
<li><br />
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">October 10th, 2005</a><br />
</li><br />
<li><br />
<address class="vcard"><a class="url fn" href="http://theryanking.com">Ryan King</a></address><br />
</li><br />
<li><br />
<a href="http://www.microformats.org/blog/...">4 Comments</a><br />
</li><br />
</ul><br />
</div><br />
<br />
<div class="entry"><br />
....<br />
</div><br />
...<br />
</div><br />
</div><br />
</body><br />
</nowiki></pre><br />
<br />
Transformed to hAtom compliant (shown in UPPER CASE for visibility only):<br />
<br />
<pre><nowiki><br />
<body><br />
<div id="wrap"><br />
<div CLASS="FEED" id="content"><br />
...<br />
<div class="entry" ID="post-60"><br />
<h3><br />
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a><br />
</h3><br />
<DIV CLASS="CONTENT"><br />
<p>We had a bit of trouble with ...</p><br />
<p>We&#8217;ve restored the wiki and ...</p><br />
<p>If anyone is working to combat said spammers ...</p><br />
</DIV><br />
<br />
<h4 class="tags">Technorati Tags:</h4><br />
<ul class="tags"><br />
<li><a href="http://technorati.com/tag/mediawiki" rel="tag">mediawiki</a></li><br />
<li><a href="http://technorati.com/tag/microformats" rel="tag">microformats</a></li><br />
<li><a href="http://technorati.com/tag/spam" rel="tag">spam</a></li><br />
</ul><br />
<br />
<ul class="post-info"><br />
<li><br />
<a href="http://www.microformats.org/blog/..." rel="bookmark" <br />
title="..."><ABBR CLASS="PUBLISHED" TITLE="2005-10-10T14:07:00-07:00">October 10th, 2005</ABBR></a><br />
</li><br />
<li><br />
<address class="vcard"><a class="url fn" href="http://theryanking.com">Ryan King</a></address><br />
</li><br />
<li><br />
<a href="http://www.microformats.org/blog/...">4 Comments</a><br />
</li><br />
</ul><br />
</div><br />
<br />
<div class="entry" ID="post-59"><br />
....<br />
</div><br />
...<br />
</div><br />
</div><br />
</body><br />
</nowiki></pre><br />
<br />
Changes:<br />
* Added <code>class="feed"</code> to Feed<br />
* Moved <code>id="###"</code> from <code>&lt;h3></code> to Entry<br />
* Added <code>&lt;div class="content"></code>...<code>&lt;/div></code> around the Entry Content<br />
* Added <code>&lt;abbr class="PUBLISHED" title="YYYY-MM-DDThh:mm:ss+ZZ:ZZ"></code>...<code>&lt;/abbr></code> around the Entry Datetime<br />
<br />
Also note:<br />
* We did not need to add a <code>class="entry"</code> to each Entry<br />
* We did not need to add a <code>&lt;address></code> element<br />
* We did not need to add a <code>&lt;h#></code> element<br />
* We did not need to add a <code>rel="bookmark"</code> to Entry Permalinks<br />
<br />
=== Transformation 2 ===<br />
<br />
A not-so well behaved weblog (an older blogspot weblog)<br />
<br />
Original:<br />
<br />
<pre><nowiki><br />
<body bgcolor="..."><br />
<br />
<div class="posts"><br />
<a name="112993192128302715">&nbsp;</a><br><br />
<div style="clear:both;"></div><strong>Nelson's final prayer</strong> <br />
written on the night before Trafalgar:<blockquote>May the Great God, ... heart.<br />
<div style="clear:both; padding-bottom: 0.25em;"></div><br />
<br><br />
<span class="byline"><br />
posted by Natalie at <br />
<a href="2005_10_16_nataliesolent_archive.html#112993192128302715">9:49 PM</a><br />
</span><br />
</div><br />
<br />
<div class="posts"><br />
<a name="112993022840118939">&nbsp;</a><br />
<br><br />
<div style="clear:both;"></div><strong>I really, truly </strong>didn't go ... view.<br />
<div style="clear:both; padding-bottom: 0.25em;"></div><br />
<br><br />
<span class="byline"><br />
posted by Natalie at <br />
<a href="2005_10_16_nataliesolent_archive.html#112993022840118939">9:28 PM</a><br />
</span><br />
</div><br />
...<br />
<br />
</body><br />
</nowiki></pre><br />
<br />
Transformed to hAtom compliant (shown in UPPER CASE for visibility only):<br />
<br />
<pre><nowiki><br />
<body bgcolor="..."><br />
<br />
<DIV CLASS="FEED"><br />
<div class="ENTRY posts" ID="112993192128302715"><br />
<strong CLASS="TITLE CONTENT"><br />
Nelson's final prayer<br />
</strong> <br />
<SPAN CLASS="CONTENT"><br />
written on the night before Trafalgar:<blockquote>May the Great God, ... heart.<br />
</SPAN><br />
<DIV><br />
<span class="byline">posted by <address>Natalie</address> at <br />
<a REL="BOOKMARK" href="HTTP://NATALIESOLENT.BLOGSPOT.COM/2005_10_16_nataliesolent_archive.html#112993192128302715"><br />
<ABBR CLASS="PUBLISHED" TITLE="2005-10-24T09:49:00-00:00">9:49 PM</ABBR></a><br />
</span><br />
</DIV><br />
</div><br />
<br />
<div class="ENTRY posts" ID="112993022840118939"><br />
<strong CLASS="TITLE CONTENT">I really, truly </strong><br />
<SPAN CLASS="CONTENT"><br />
didn't go ... view.<br />
</SPAN><br />
<DIV><br />
<span class="byline"><br />
posted by <address>Natalie</address> at <br />
<a REL="BOOKMARK" href="HTTP://NATALIESOLENT.BLOGSPOT.COM/2005_10_16_nataliesolent_archive.html#112993022840118939"><br />
<ABBR CLASS="PUBLISHED" TITLE="2005-10-24T09:49:00-00:00">9:28 PM</ABBR></a><br />
</span><br />
</DIV><br />
</div><br />
...<br />
</DIV><br />
<br />
</body><br />
</nowiki></pre><br />
<br />
Changes:<br />
* Added <code>class="feed"</code> to Feed<br />
* Added <code>class="entry"</code> to each Entry<br />
* Moved <code>id="###"</code> up to the Entry (and deleted the empty anchor block)<br />
* Added <code>rel="bookmark"</code> to the Entry Permalinks<br />
* Made the Entry Permalink non-relative<br />
* Added <code>&lt;span class="title"></code>...<code>&lt;/div></code> around the Entry Title<br />
* Added <code>&lt;span class="content"></code>...<code>&lt;/div></code> around the Entry Title (!)<br />
* Added <code>&lt;span class="content"></code>...<code>&lt;/div></code> around the Entry Content<br />
* Added <code>&lt;abbr class="published" title="YYYY-MM-DDThh:mm:ss+ZZZZ"></code>...<code>&lt;/abbr></code> around the Entry Datetime<br />
* Added <code>&lt;address></code> to the poster's name<br />
<br />
Also note:<br />
* there are multiple content blocks, because Natalie Solent embeds the title in the content<br />
* cleaned up lots of crap HTML presentation stuff, with the assumption it would be fixed in the stylesheet<br />
* this is one of the uglier transformations you're likely to see<br />
* we've respected the poster's poster apparent wish for anonimity by not adding an hCard<br />
<br />
=== Transformation 3 ===<br />
<br />
A media page (from [http://www.cbc.ca/story/world/national/2005/11/22/birdlfu051122.html CBC Newsworld]).<br />
<br />
Original:<br />
<br />
<pre><nowiki><br />
<div class="news"><br />
<div class="story"><br />
<h1>China confirms new bird flu outbreaks</h1><br />
<span class="byline">Last Updated Tue, 22 Nov 2005 23:26:18 EST</span><br />
<div class="text"><a href="/news/credit.html">CBC News</a></div><br />
<br />
<div class="text"><br />
<p><br />
China has confirmed three new outbreaks of bird flu, ...<br />
<p><br />
<ul><br />
<li><font SIZE="1">INDEPTH: </font><font SIZE="2"> <br />
<a href="http://www.cbc.ca/news/background/avianflu/">Avian Flu</a></font><br />
</ul><br />
</p><br />
<table align="right" cellpadding="0" cellspacing="4" hspace="4" width="220"><br />
<tr><br />
<td align="center"><br />
<img src="http://www.cbc.ca/gfx/pix/birdflu_china_cp_7707271.jpg" width="220" height="223" hspace="3" border="0"><br />
</td><br />
</tr><br />
<tr><br />
<td align="center"><br />
<div class="caption"><br />
<font size="1" face="verdana,arial"><i></i></font><br />
</div><br />
</td><br />
</tr><br />
</table><br />
<p>State media says the new outbreaks are in...</p><br />
<p>The news comes a day after China announced the ...</p><br />
<p>In China's eastern Anhui province, authorities have ...</p><br />
<p>The province says the measure will prevent domestic ...</p><br />
<p>Vietnamese health officials have confirmed that a ...</p><br />
<p>Doctors from the health department in the northern ...</p><br />
<p>Bird flu has killed 42 people in Vietnam since December ...</p><br />
<p>The World Health Organization fears the H5N1 strain of ...</p><br />
</div><br />
<br />
<p><font face="Verdana,Arial" size="1">with files from the Australian Broadcasting Corporation</font></p><br />
</div><br />
...<br />
</div><br />
</nowiki></pre><br />
<br />
Transformed to hAtom compliant (shown in UPPER CASE for visibility only):<br />
<br />
<pre><nowiki><br />
<div class="news"><br />
<div class="FEED ENTRY story"><br />
<h1>China confirms new bird flu outbreaks</h1><br />
<span class="byline">Last Updated<br />
<ABBR CLASS="POSTED" TITLE="2005-11-23T04:26:18Z">Tue, 22 Nov 2005 23:26:18 EST</ABBR><br />
</span><br />
<ADDRESS CLASS="VCARD"><div class="text"><a CLASS="URL" href="/news/credit.html">CBC News</a></div></ADDRESS><br />
<br />
<div class="text"><br />
<p CLASS="CONTENT"><br />
China has confirmed three new outbreaks of bird flu, ...<br />
</p><br />
<p><br />
<ul><br />
<li><font SIZE="1">INDEPTH: </font><font SIZE="2"> <br />
<a href="http://www.cbc.ca/news/background/avianflu/">Avian Flu</a></font><br />
</ul><br />
</p><br />
<table align="right" cellpadding="0" cellspacing="4" hspace="4" width="220"><br />
<tr><br />
<td align="center"><br />
<img src="http://www.cbc.ca/gfx/pix/birdflu_china_cp_7707271.jpg" width="220" height="223" hspace="3" border="0"><br />
</td><br />
</tr><br />
<tr><br />
<td align="center"><br />
<div class="caption"><br />
<font size="1" face="verdana,arial"><i></i></font><br />
</div><br />
</td><br />
</tr><br />
</table><br />
<p CLASS="CONTENT">State media says the new outbreaks are in...</p><br />
<p CLASS="CONTENT">The news comes a day after China announced the ...</p><br />
<p CLASS="CONTENT">In China's eastern Anhui province, authorities have ...</p><br />
<p CLASS="CONTENT">The province says the measure will prevent domestic ...</p><br />
<p CLASS="CONTENT">Vietnamese health officials have confirmed that a ...</p><br />
<p CLASS="CONTENT">Doctors from the health department in the northern ...</p><br />
<p CLASS="CONTENT">Bird flu has killed 42 people in Vietnam since December ...</p><br />
<p CLASS="CONTENT">The World Health Organization fears the H5N1 strain of ...</p><br />
</div><br />
<br />
<p><font face="Verdana,Arial" size="1">with files from the <ADDRESS CLASS="CONTRIBUTOR">Australian Broadcasting Corporation</ADDRESS></font></p><br />
</div><br />
...<br />
</div><br />
</nowiki></pre><br />
<br />
Changes:<br />
* Added <code>&lt;div class="feed entry"></code> around the single entry on the page<br />
: ''We have to make sure the nesting rules reflect nesting at the same level''<br />
* Added <code>&lt;span class="content"></code>...<code>&lt;/div></code> around every single paragraph -- this looks pathological but it may be the way this would need be produced from a template. The latter part of the document could be enclosed in a single "content" div but note that we did this so the "INDEPTH" part would not be marked as content,<br />
* Added <code>&lt;abbr class="published" title="YYYYMMDDThh:mm:ss+ZZZZ"></code>...<code>&lt;/abbr></code> around the Entry Datetime<br />
* Added <code>&lt;address></code> to the CBC Newsroom<br />
* Added <code>&lt;address class="contributor"></code> to a contributor's name<br />
<br />
Also note:<br />
* We may the document more XHTML compliant<br />
* There is no <code>rel="bookmark"</code> so it is assumed to be the URI of the page<br />
* The Entry Title was correctly marked with a <code>&lt;h1></code> element<br />
<br />
=== Transformation 4 ===<br />
<br />
A bulletin board ([http://forums.punbb.org/viewtopic.php?id=9135 PunBB])<br />
<br />
Original:<br />
<br />
<pre><nowiki><br />
<body><br />
<div id="punwrap"><br />
<div id="punviewtopic" class="pun"><br />
<br />
<div id="brdheader" class="block"><br />
... header stuff ...<br />
</div><br />
<br />
<div id="announce" class="block"><br />
... announcement stuff ...<br />
</div><br />
<br />
<div class="linkst"><br />
... controls for the blog<br />
</div><br />
<br />
<div id="p54390" class="blockpost rowodd firstpost"><br />
<h2><br />
<span><span class="conr">#1&nbsp;</span><br />
<a href="viewtopic.php?pid=54390#p54390">2005-10-16 10:36:24</a></span><br />
</h2><br />
<div class="box"><br />
<div class="inbox"><br />
<div class="postleft"><br />
<dl><br />
<dt><strong><a href="profile.php?id=2">Rickard</a></strong></dt><br />
<br />
<dd class="usertitle"><strong>PunBB Developer</strong></dd><br />
<dd class="postavatar"><img src="img/avatars/2.png" width="60" height="60" alt="" /></dd><br />
<dd>From: 127.0.0.1</dd><br />
<dd>Registered: 2001-11-02</dd><br />
<dd>Posts: 7806</dd><br />
<dd class="usercontacts"><a href="http://www.punbb.org/">Website</a></dd><br />
<br />
</dl><br />
</div><br />
<div class="postright"><br />
<h3>PunBB 1.2.9</h3><br />
<div class="postmsg"><br />
<p>Just a quick note this time....</p><br />
<br />
</div><br />
<div class="postsignature"><hr />&quot;Programming is like sex: ...</div><br />
</div><br />
<div class="clearer"></div><br />
<div class="postfootleft"><p>Offline</p></div><br />
<div class="postfootright"><div>&nbsp;</div></div><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div id="p54392" class="blockpost roweven"><br />
<h2><span><span class="conr">#2&nbsp;</span><a href="viewtopic.php?pid=54392#p54392">2005-10-16 10:54:41</a></span></h2><br />
<div class="box"><br />
<div class="inbox"><br />
<div class="postleft"><br />
<dl><br />
<dt><strong><a href="profile.php?id=5298">IdleFire</a></strong></dt><br />
<br />
<dd class="usertitle"><strong>Member</strong></dd><br />
<dd class="postavatar"></dd><br />
<dd>Registered: 2005-10-14</dd><br />
<dd>Posts: 27</dd><br />
</dl><br />
</div><br />
<div class="postright"><br />
<br />
<h3> Re: PunBB 1.2.9</h3><br />
<div class="postmsg"><br />
<p>...</p><br />
</div><br />
</div><br />
<div class="clearer"></div><br />
<div class="postfootleft"><p>Offline</p></div><br />
<br />
<div class="postfootright"><div>&nbsp;</div></div><br />
</div><br />
</div><br />
</div><br />
<br />
... more entries ...<br />
<br />
<div id="brdfooter" class="block"><br />
... footer stuff ...<br />
</div><br />
<br />
</div><br />
</div><br />
</body><br />
</nowiki></pre><br />
<br />
Transformed to hAtom compliant (changes shown in UPPER CASE for visibility only):<br />
<br />
<pre><nowiki><br />
<body><br />
<div id="punwrap"><br />
<div id="punviewtopic" class="pun"><br />
<br />
<div id="brdheader" class="block"><br />
... header stuff ...<br />
</div><br />
<br />
<div id="announce" class="block"><br />
... announcement stuff ...<br />
</div><br />
<br />
<div class="linkst"><br />
... controls for the blog<br />
</div><br />
<br />
<DIV CLASS="FEED"><br />
<div id="p54390" class="ENTRY blockpost rowodd firstpost"><br />
<h2><br />
<span><span class="conr">#1&nbsp;</span><br />
<a REL="BOOKMARK" href="HTTP://FORUMS.PUNBB.ORG/viewtopic.php?pid=54390#p54390"><br />
<ABBR CLASS="POSTED" TITLE="20051016T103624-0500">2005-10-16 10:36:24</ABBR><br />
</a></span><br />
</h2><br />
<div class="box"><br />
<div class="inbox"><br />
<div class="postleft"><br />
<dl><br />
<dt><strong><ADDRESS><a href="profile.php?id=2">Rickard</a></ADDRESS></strong></dt><br />
<br />
<dd class="usertitle"><strong>PunBB Developer</strong></dd><br />
<dd class="postavatar"><img src="img/avatars/2.png" width="60" height="60" alt="" /></dd><br />
<dd>From: 127.0.0.1</dd><br />
<dd>Registered: 2001-11-02</dd><br />
<dd>Posts: 7806</dd><br />
<dd class="usercontacts"><a href="http://www.punbb.org/">Website</a></dd><br />
<br />
</dl><br />
</div><br />
<div class="postright"><br />
<h3>PunBB 1.2.9</h3><br />
<div class="CONTENT postmsg"><br />
<p>Just a quick note this time....</p><br />
<br />
</div><br />
<div class="postsignature"><hr />&quot;Programming is like sex: ...</div><br />
</div><br />
<div class="clearer"></div><br />
<div class="postfootleft"><p>Offline</p></div><br />
<div class="postfootright"><div>&nbsp;</div></div><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div id="p54392" class="ENTRY blockpost roweven"><br />
<h2><br />
<span><span class="conr">#2&nbsp;</span><br />
<a REL="BOOKMARK" href="HTTP://FORUMS.PUNBB.ORG/viewtopic.php?pid=54392#p54392"><br />
<ABBR CLASS="POSTED" TITLE="20051016T1105441-0500">2005-10-16 10:54:41</ABBR><br />
</a></span><br />
</h2><br />
<div class="box"><br />
<div class="inbox"><br />
<div class="postleft"><br />
<dl><br />
<dt><strong><ADDRESS CLASS="VCARD"><a CLASS="URL" href="profile.php?id=5298">IdleFire</a></ADDRESS></strong></dt><br />
<br />
<dd class="usertitle"><strong>Member</strong></dd><br />
<dd class="postavatar"></dd><br />
<dd>Registered: 2005-10-14</dd><br />
<dd>Posts: 27</dd><br />
</dl><br />
</div><br />
<div class="postright"><br />
<br />
<h3> Re: PunBB 1.2.9</h3><br />
<div class="CONTENT postmsg"><br />
<p>...</p><br />
</div><br />
</div><br />
<div class="clearer"></div><br />
<div class="postfootleft"><p>Offline</p></div><br />
<br />
<div class="postfootright"><div>&nbsp;</div></div><br />
</div><br />
</div><br />
</div><br />
<br />
... more entries ...<br />
</DIV><br />
<br />
<div id="brdfooter" class="block"><br />
... footer stuff ...<br />
</div><br />
<br />
</div><br />
</div><br />
</body><br />
</nowiki></pre><br />
<br />
<br />
Changes:<br />
* Added <code>&lt;div class="feed"></code> around the entries (as opposed to an existing <code>&lt;div</code> that enclosed more than entries.<br />
* Added <code>class="entry"</code> to each Entry<br />
* Added <code>rel="bookmark"</code> to the Entry Permalinks<br />
* Made the Entry Permalink non-relative<br />
* Added <code>&lt;span class="title"></code>...<code>&lt;/div></code> around the Entry Title<br />
* Added <code>&lt;span class="content"></code>...<code>&lt;/div></code> around the Entry Content<br />
* Added <code>&lt;abbr class="posted" title="YYYYMMDDThh:mm:ss+ZZZZ"></code>...<code>&lt;/abbr></code> around the Entry Datetime<br />
* Added <code>&lt;address></code> to the poster's name<br />
<br />
Also note:<br />
* We did not need to add <code>id="###"</code> to the Entry<br />
<br />
=== More Examples ===<br />
<br />
See [[hatom-examples]].<br />
<br />
== Examples in the wild ==<br />
This section is '''informative'''.<br />
<br />
* [http://blog.davidjanes.com Ranting and Roaring] (David Janes)<br />
* [http://www.myelin.co.nz/post/ Second p0st] (Phil Pearson)<br />
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Sound Advice] (Benjamin Carlyle)<br />
* [http://sedna.spip.org/sedna/ Sedna RSS] (a feed aggregator based on SPIP, by Fil, IZO and others; GPLd sources are available at [http://zone.spip.org/trac/spip-zone/browser/_squelettes_/sedna SPIP-Zone])<br />
<br />
== Implementations ==<br />
<br />
This section is '''informative'''.<br />
<br />
<br />
* the [http://www.trinityanne.com/tools/extract/ Almost Universal Microformat Parser] can extract hAtom content from webpages ([http://www.trinityanne.com/tools/extract/?uri=http%3A%2F%2Fblog.davidjanes.com&microformat=hatom&submit=Submit example])<br />
* the [http://www.trinityanne.com/tools/greasemonkey/microformat-action.user.js microformat-action] [[greasemonkey|Greasemonkey]] script detects hAtom content on webpages and will call the [http://www.trinityanne.com/tools/extract/ Almost Universal Microformat Parser]<br />
* the [http://www.blogmatrix.com/tools/rewrite/ hAtom Template Rewriter] converts Blogger, MovableType and Wordpress templates into hAtom compatible ones -- (hopefully) without presentation impact<br />
* An [http://lukearno.com/projects/hAtom/ hAtom-2-Atom] XSLT is available. (This version is currently broken but a working version is [http://rbach.priv.at/repos/hatom/hatom2atom.xsl/trunk/ available])<br />
<br />
== References ==<br />
=== Normative References ===<br />
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]<br />
* [http://www.atomenabled.org/ Atom]<br />
<br />
=== Informative References ===<br />
<br />
==== Specifications That Use hAtom ====<br />
<br />
==== Similar Work ====<br />
<br />
* [http://rdfs.org/sioc/ Semantically-Interlinked Online Communities (SIOC) RDF Ontology]<br />
<br />
== Work in progress ==<br />
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. There is a separate document where we are keeping our brainstorms and other explorations relating to hAtom:<br />
<br />
* [[blog-post-brainstorming|blog-post Brainstorming]]<br />
<br />
== Hints and Tips ==<br />
<br />
=== CSS tips ===<br />
HTML typically styles <code>address</code> as a block level element in an italic font. This will make it inline and plain within hAtom elements:<br />
<br />
<pre><nowiki><br />
.entry address {<br />
display: inline;<br />
font-weight: normal;<br />
font-style: normal;<br />
} <br />
</nowiki></pre><br />
<br />
HTML typically puts a dotted line under <code>&lt;abbr></code> elements. This will put postage paid to that for Entry Updated and Entry Posted:<br />
<br />
<pre><nowiki><br />
.entry abbr.updated, .entry abbr.posted {<br />
font-style: normal;<br />
border: none;<br />
}<br />
</nowiki></pre><br />
<br />
=== MovableType Template ===<br />
<br />
A datetime encoded in an ABBR element can be produced with the following template code:<br />
<br />
<pre><nowiki><br />
<abbr <br />
class="posted" <br />
title="<$MTEntryDate format="%Y%m%dT%H%M%S"$><$MTBlogTimezone<br />
no_colon="1"$>"><$MTEntryDate format="%X"$></abbr><br />
</nowiki></pre><br />
<br />
== Discussions ==<br />
<br />
* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].<br />
<br />
=== Q&A ===<br />
* If you have any questions about hAtom, check the [[hatom-faq|hAtom FAQ]], and if you don't find answers, add your questions!<br />
<br />
=== Issues ===<br />
* Please add any issues with the specification to the separate [[hatom-issues|hAtom issues]] document.<br />
<br />
== Recent Changes ==<br />
<br />
''Most recent at top please. This section will eventually be removed but should be helpful for people tracking changes during specing.''<br />
<br />
* Entry Permalink now SHOULD (as opposed to MUST) be a complete URI<br />
* Entry Title now preferentially uses class="title"<br />
* Entry Author most explicitly be marked class="author"<br />
* using an <code>&lt;address</code> around Entry Author and Entry Contributor is no longer required<br />
<br />
==See Also==<br />
* [[hatom|hAtom]] - the draft proposal<br />
* [[hatom-issues]] - problems? complaints? ideas? Put them here<br />
* [[hatom-faq]] - knowledge base<br />
* [[blog-post-brainstorming]]<br />
* [[blog-post-formats]]<br />
* [[blog-post-examples]]<br />
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)</div>Filhttps://microformats.org/wiki/index.php?title=hatom&diff=3942hatom2006-01-06T01:08:39Z<p>Fil: add Sedna RSS to the "Examples in the wild" section</p>
<hr />
<div>= hAtom =<br />
<br />
hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is a strongly based on a subset of the [http://www.atomenabled.org/ Atom] syndication format; every concept in hAtom has a corresponding definition in Atom. <br />
<br />
This microformat is a draft; please address your concerns, issues, comments, etc. in [[hatom-issues]].<br />
<br />
__TOC__<br />
<br />
== Draft Specification ==<br />
<br />
=== Editor ===<br />
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix.com BlogMatrix, Inc.]<br />
<br />
=== Authors ===<br />
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix.com BlogMatrix, Inc]<br />
<br />
=== Contributors ===<br />
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]<br />
<br />
=== Copyright ===<br />
{{MicroFormatCopyrightStatement2005}}<br />
<br />
=== Patents ===<br />
{{MicroFormatPatentStatement}}<br />
<br />
== Introduction ==<br />
<br />
== Semantic XHTML Design Principles ==<br />
{{semantic-xhtml-design-principles}}<br />
<br />
== Format ==<br />
=== In General ===<br />
The [http://atomenabled.org/developers/syndication/#person Atom Syndication Format] provides the conceptual basis for this microformat, with the following caveats:<br />
<br />
* Atom provides a lot more functionality that we need for a "blog post" microformat, so we've taken the minimal number of elements needed. This can (and probably should) be expanded.<br />
* the "logical" model of hAtom is that of Atom. If there is a conflict, Atom should be taken as correct.<br />
* the "physical" model of hAtom -- the actual writing of elements -- is a lot more varied than Atom provides for, due to the variety of ways weblogs are actually produced in the wild. The hAtom microformat provides a number of rules for "briding the gap"<br />
:: ''for example, if an entry is missing an author (required by Atom), it is assumed to be that of the XHTML page''<br />
<br />
=== Schema ===<br />
Schema elements are based on the Atom nomenclature and follow the microformat pattern of prefixing a unique identifier (in this case, <code>atom</code>) on the outermost container elements -- the Feed or Entry. The parts of this microformat are based on analysis of many weblog, bulletin board and media posts and can be read [[blog-post-brainstorming#Discovered_Elements]]. Note the renaming of 'EntryGroup' to 'Feed' to be more consistent with Atom ternminology.<br />
<br />
==== Nomenclature ====<br />
<br />
{| width="100%" border="1" cellspacing="0" <br />
|-<br />
! width="150" | Concept<br />
! Atom Identifier<br />
! hAtom Microformat Usage<br />
|-<br />
| Feed<br />
| <code>atom:feed</code><br />
| add <code>class="feed"</code><br />
|-<br />
| Entry<br />
| <code>atom:entry</code><br />
| Add <code>class="entry"</code>; if practical, also define <code>id="unique-identifier"</code> to the Entry.<br />
|-<br />
| Entry Title<br />
| <code>atom:title</code><br />
| Add <code>class="title"</code>, alternately by <code>&lt;h#></code>.<br />
|-<br />
| Entry Content<br />
| <code>atom:content</code><br />
| Add <code>class="content"</code> to all appropriate blocks. Multiple Entry Content blocks are logically considered one concatenated <code>atom:content</code> equivalent.<br />
|-<br />
| Entry Summary<br />
| <code>atom:summary</code><br />
| Add <code>class="summary"</code> to all appropriate blocks. Multiple Entry Summary blocks are logically considered one concatenated <code>atom:summary</code> equivalent.<br />
|-<br />
| Entry Permalink<br />
| <code>atom:link</code><br />
| Add <code>rel="bookmark"</code>.<br />
|-<br />
| Entry Published<br />
| <code>atom:published</code><br />
| Use <code>&lt;abbr class="published" title="YYYYMMYYThh:mm:ss&plusmn;ZZ:ZZ"></code>...<code>&lt;/abbr></code>, following the [[datetime-design-pattern]].<br />
|-<br />
| Entry Updated<br />
| <code>atom:updated</code><br />
| Use <code>&lt;abbr class="updated" title="YYYYMMYYThh:mm:ss&plusmn;ZZ:ZZ"></code>...<code>&lt;/abbr></code>, following the [[datetime-design-pattern]].<br />
|-<br />
| Entry Author<br />
| <code>atom:author</code><br />
| Add <code>class="author"</code> to appropriate blocks. Using <code><address class="author"></code>...<code></address></code> is recommended. Adding a [[hcard|hCard]] is highly recommended.<br />
|-<br />
| Entry Contributor<br />
| Add <code>atom:contibutor</code> to appropriate blocks.<br />
| Add <code>class="contributor"</code> to appropriate blocks. Using <code><address class="contributor"></code>...<code></address></code> is recommended. Adding a [[hcard|hCard]] is highly recommended.<br />
|}<br />
<br />
==== Nesting Rules ====<br />
<br />
{| width="100%" border="1" cellspacing="0" <br />
|-<br />
! Concept<br />
! Nests In<br />
! hAtom Opaque<br />
! Cardinality<br />
! Logical Cardinality<br />
|-<br />
| Feed<br />
| HTML document<br />
| No<br />
| 1-N<br />
| 1-N<br />
|-<br />
| Entry<br />
| Feed<br />
| No<br />
| 0-N<br />
| 0-N<br />
|-<br />
| Entry Title<br />
| Entry<br />Entry Permalink<br />
| No<br />
| 0-N<br />
| 0-1<br />
|-<br />
| Entry Content<br />
| Entry<br />
| Yes<br />
| 0-N<br />
| 0-1<br />
|-<br />
| Entry Summary<br />
| Entry<br />
| Yes<br />
| 0-N<br />
| 0-1<br />
|-<br />
| Entry Permalink<br />
| Entry<br />Entry Title<br />Entry Published<br />
| No<br />
| 0-N<br />
| 1<br />
|-<br />
| Entry Published<br />
| Entry<br />Entry Permalink<br />
| No<br />
| 0-N<br />
| 0-1<br />
|-<br />
| Entry Updated<br />
| Entry<br />Entry Permalink<br />
| No<br />
| 0-N<br />
| 1<br />
|-<br />
| Entry Author<br />
| Entry<br />
| Yes<br />
| 0-N<br />
| 1-N<br />
|-<br />
| Entry Contibutor<br />
| Entry<br />
| Yes<br />
| 0-N<br />
| 0-N<br />
|}<br />
<br />
===== hAtom Opaque =====<br />
<br />
"hAtom Opaque" specifies whether a hAtom parser should "look inside" the element for further hAtom content. If there are multiple rules applied to the same element take the OR of the two (i.e. "Yes" always wins)<br />
<br />
: ''hAtom Opaque is designed to make parsing rules less ambiguous. In particular, it allows "quoted" hAtom elements (from another blog being blockquoted, for example) ti be ignored. It also allows 'embedded' hAtom to be potentially delivered within hAtom itself, and to prevent accidental 'leaking' of other microformat information up into the hAtom container.''<br />
<br />
===== Cardinality =====<br />
<br />
How many times can an element of the given type appear in it's nesting/parent element.<br />
<br />
===== Logical Cardinality =====<br />
<br />
From a modeling/logical perspective, the number of times can an element appear.<br />
<br />
: ''This is all rule dependent, see below. For example, an Entry Permalink may appear 6 times, but each one must be the same value; an Entry Content element may appear 3 times, but they are all concatenated together to make a single logical element.''<br />
<br />
==== Rules and Definitions ====<br />
See the [[#Nesting_Rules|Nesting Rules]] section above for placement of these elements.<br />
<br />
===== Feed =====<br />
* an XHTML Feed element is identified by <code>class="feed"</code><br />
* a Feed element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1 atom feed]<br />
: ''In particular, as a container for Entrys.''<br />
* the Feed element is required, even if there is a single Entry<br />
: ''This is for disambiguation''<br />
* hAtom documents MAY have multiple, non-nested Feed elements<br />
: ''This may happen on news pages, or weblogs with "mini-blogs" on the sidebar.''<br />
<br />
===== Entry =====<br />
* an Entry element is identified by <code>class="entry"</code><br />
* an Entry element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 atom entry]<br />
* a weblog entry MUST be enclosed in a single Entry element<br />
: ''That's what it's for, after all.''<br />
* an Entry MUST have an enclosing Feed element<br />
* ''This enclosing element can be the same as the Entry -- i.e. class="feed entry" is OK for feeds with a single entry.''<br />
<br />
===== Entry Title =====<br />
* an Entry Title element is identified by <code>class="title"</code><br />
* an Entry Title element alternately be identified by <code>&lt;h#></code><br />
* an Entry Title element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.14 atom entry title]<br />
<br />
====== Disambiguation ======<br />
<br />
* the first hAtom valid element with a <code>class="title"</code> is the Entry Title<br />
: ''hAtom valid meaning somewhere where we expect it (like not inside Entry Content, for example).''<br />
* otherwise, the first hAtom valid <code>&lt;h#></code> element to appear in an hAtom document is the Entry Title<br />
* otherwise, the Entry Title is the empty string<br />
: ''Atom does not allow for an entry not to have a title.''<br />
<br />
===== Entry Content =====<br />
* an Entry Content element is identified by <code>class="content"</code><br />
* an Entry Content element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#atomContent atom content]<br />
* an Entry MAY have 0 or more Entry Content elements<br />
: ''We recognize this varies from the Atom spec: see the next rule.''<br />
* the "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry<br />
: ''Many weblogs split content into multiple sections with a "Read More" link and javascript tricks. This is also needed in cases where Entry Titles are coded inline and are considered part of the content.''<br />
* the "logical Entry Content" MUST be complete; that is, contain the entire content of the Entry<br />
: ''Otherwise it should be marked as Entry Summary.''<br />
<br />
===== Entry Summary =====<br />
* an Entry Summary element is identified by <code>class="summary"</code><br />
* an Entry Summary element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.13 atom summary]<br />
* an Entry MAY have 0 or more Entry Summary elements<br />
: ''We recognize this varies from the Atom spec: see the next rule.''<br />
* the "logical Entry Summary" of an Entry is the concatenation, in order of appearance, of all the Entry Summarys within the Entry<br />
<br />
===== Entry Permalink =====<br />
<br />
* an Entry Permalink element is identified by <code>rel="bookmark"</code><br />
: ''We recognize that we have broken from Atom terminology at this point. See [[hatom-issues]] for discussion.''<br />
: ''This may be a microformat in itself: [[rel-bookmark]].''<br />
* an Entry Permalink element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7 atom link in an entry]<br />
* Entry Permalinks SHOULD be absolute URIs<br />
* Entry Permalinks MUST be the same as the <code>atom:link</code> (or <code>rss:link</code>) used in syndication feeds<br />
: ''The intention of the previous two rules to gently force people to use strings that can be byte compared for equivalence. In general, the canonical URI should be the link used in an Atom entry.''<br />
: ''Is there a problem with FeedBurner?''<br />
* if an Entry has multiple elements marked as the Entry Permalink, they MUST have exactly the same URI<br />
* an Entry SHOULD have an Entry Permalink<br />
: ''There are circumstances (such as media pages) where this won't happen. See the next rule.''<br />
* there can be at most 1 Entry in an XHTML document without an Entry Permalink; the Entry Permalink of this Entry is the URI of the page<br />
: ''This rule is needed for media pages (i.e. a news article on cnn.com). There is some ugliness of with this because the URI could be non-canonical.''<br />
<br />
====== Disambiguation ======<br />
<br />
* The first valid element in an Entry marked as an Entry Permalink is the Entry Permalink<br />
<br />
===== Entry Published =====<br />
<br />
* an Entry Published element is identified by <code>class="published"</code><br />
* a Entry Published element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9 atom published]<br />
* the machine readable datetime should be encoded with an <code>&lt;abbr></code> element using the [[datetime-design-pattern]]; the machine readable datetime should be complete, that is, specified to the second with the timezone included<br />
: ''This is to be consistent with the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.3.3 Atom Datetime Construct].<br />
* optionally, this can be specified by an HTML element with the ISO datetime in the text.<br />
: ''This is a little uglier for the reader, but it's possible.''<br />
<br />
====== Disambiguation ======<br />
<br />
* The first valid element in an Entry marked as an Entry Published is the Entry Published element<br />
<br />
===== Entry Updated =====<br />
<br />
* an Entry Updated element is identified by <code>class="updated"</code><br />
* a Entry Updated element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15 atom updated]<br />
* the machine readable datetime should be encoded with an <code>&lt;abbr></code> element using the [[datetime-design-pattern]]; the machine readable datetime should be complete, that is, specified to the second with the timezone included<br />
: ''This is to be consistent with the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.3.3 Atom Datetime Construct].<br />
* if there is no Entry Updated element, the value is assumed to be that of Entry Published<br />
: ''Entry Published is more often available in weblog templates, so we're going with that.''<br />
* if there is no Entry Updated and Entry Published elements, transformation to Atom is problematic<br />
: ''This is because a published element is required. Suggestions would be appreciated here.''<br />
* optionally, this can be specified by an HTML element with the ISO datetime in the text.<br />
: ''This is a little uglier for the reader, but it's possible.''<br />
<br />
====== Disambiguation ======<br />
<br />
* The first valid element in an Entry marked as an Entry Updated is the Entry Updated element<br />
<br />
===== Entry Author =====<br />
<br />
* an Entry Author element is represented by <code>class="author"</code><br />
* an Entry Author element SHOULD use an XHTML <code>&lt;address></code> element<br />
* an Entry Author element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.1 atom author]<br />
* an Entry Author element SHOULD contain an [[hcard|hCard]]<br />
: ''If it does not, just consider the text to effectively be the FN''<br />
* an Entry MAY have 0 or more Entry Author elements<br />
* if an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page<br />
: ''Atom requires at least one Author''<br />
<br />
===== Entry Contibutor =====<br />
<br />
* an Entry Contibutor element is represented by <code>class="contributor"</code><br />
* an Entry Contibutor element SHOULD use an XHTML <code>&lt;address></code> element<br />
* an Entry Contibutor element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.3 atom contributor]<br />
* an Entry Contibutor element SHOULD contain an [[hcard|hCard]]<br />
: ''If it does not, just consider the text to be the FN''<br />
* an Entry MAY have 0 or more Entry Contibutor elements<br />
<br />
=== XMDP Profile ===<br />
<pre><br />
<dl class="profile"><br />
<dt>class</dt><br />
<dd><p><br />
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class"><br />
HTML4 definition of the 'class' attribute.</a><br />
This meta data profile defines some 'class' attribute values (class names) <br />
and their meanings as suggested by a <br />
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile"><br />
draft of "Hypertext Links in HTML"</a>.<br />
<dl><br />
<dt>feed</dt><br />
<dd><br />
The concept of atom:feed from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>entry</dt><br />
<dd><br />
The concept of atom:entry from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>content</dt><br />
<dd><br />
The concept of atom:content from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>summary</dt><br />
<dd><br />
The concept of atom:summary from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>bookmark</dt><br />
<dd><br />
The concept of atom:link (without any "rel") with an atom:entry from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>published</dt><br />
<dd><br />
The concept of atom:published from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>updated</dt><br />
<dd><br />
The concept of atom:updatedfrom <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
<dt>author</dt><br />
<dd><br />
The concept of atom:author from <br />
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>, <br />
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.<br />
</dd><br />
</dl><br />
</dd><br />
</dl><br />
</pre><br />
<br />
=== Parsing Details ===<br />
<br />
== Examples ==<br />
<br />
This section is informative.<br />
<br />
=== Transformation 1 ===<br />
<br />
A well behaved weblog.<br />
<br />
Original:<br />
<br />
<pre><nowiki><br />
<body><br />
<div id="wrap"><br />
<div id="content"><br />
...<br />
<div class="entry"><br />
<h3 id="post-60"><br />
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a><br />
</h3><br />
<p>We had a bit of trouble with ...</p><br />
<p>We&#8217;ve restored the wiki and ...</p><br />
<p>If anyone is working to combat said spammers ...</p><br />
<br />
<h4 class="tags">Technorati Tags:</h4><br />
<ul class="tags"><br />
<li><a href="http://technorati.com/tag/mediawiki" rel="tag">mediawiki</a></li><br />
<li><a href="http://technorati.com/tag/microformats" rel="tag">microformats</a></li><br />
<li><a href="http://technorati.com/tag/spam" rel="tag">spam</a></li><br />
</ul><br />
<br />
<ul class="post-info"><br />
<li><br />
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">October 10th, 2005</a><br />
</li><br />
<li><br />
<address class="vcard"><a class="url fn" href="http://theryanking.com">Ryan King</a></address><br />
</li><br />
<li><br />
<a href="http://www.microformats.org/blog/...">4 Comments</a><br />
</li><br />
</ul><br />
</div><br />
<br />
<div class="entry"><br />
....<br />
</div><br />
...<br />
</div><br />
</div><br />
</body><br />
</nowiki></pre><br />
<br />
Transformed to hAtom compliant (shown in UPPER CASE for visibility only):<br />
<br />
<pre><nowiki><br />
<body><br />
<div id="wrap"><br />
<div CLASS="FEED" id="content"><br />
...<br />
<div class="entry" ID="post-60"><br />
<h3><br />
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a><br />
</h3><br />
<DIV CLASS="CONTENT"><br />
<p>We had a bit of trouble with ...</p><br />
<p>We&#8217;ve restored the wiki and ...</p><br />
<p>If anyone is working to combat said spammers ...</p><br />
</DIV><br />
<br />
<h4 class="tags">Technorati Tags:</h4><br />
<ul class="tags"><br />
<li><a href="http://technorati.com/tag/mediawiki" rel="tag">mediawiki</a></li><br />
<li><a href="http://technorati.com/tag/microformats" rel="tag">microformats</a></li><br />
<li><a href="http://technorati.com/tag/spam" rel="tag">spam</a></li><br />
</ul><br />
<br />
<ul class="post-info"><br />
<li><br />
<a href="http://www.microformats.org/blog/..." rel="bookmark" <br />
title="..."><ABBR CLASS="PUBLISHED" TITLE="2005-10-10T14:07:00-07:00">October 10th, 2005</ABBR></a><br />
</li><br />
<li><br />
<address class="vcard"><a class="url fn" href="http://theryanking.com">Ryan King</a></address><br />
</li><br />
<li><br />
<a href="http://www.microformats.org/blog/...">4 Comments</a><br />
</li><br />
</ul><br />
</div><br />
<br />
<div class="entry" ID="post-59"><br />
....<br />
</div><br />
...<br />
</div><br />
</div><br />
</body><br />
</nowiki></pre><br />
<br />
Changes:<br />
* Added <code>class="feed"</code> to Feed<br />
* Moved <code>id="###"</code> from <code>&lt;h3></code> to Entry<br />
* Added <code>&lt;div class="content"></code>...<code>&lt;/div></code> around the Entry Content<br />
* Added <code>&lt;abbr class="PUBLISHED" title="YYYY-MM-DDThh:mm:ss+ZZ:ZZ"></code>...<code>&lt;/abbr></code> around the Entry Datetime<br />
<br />
Also note:<br />
* We did not need to add a <code>class="entry"</code> to each Entry<br />
* We did not need to add a <code>&lt;address></code> element<br />
* We did not need to add a <code>&lt;h#></code> element<br />
* We did not need to add a <code>rel="bookmark"</code> to Entry Permalinks<br />
<br />
=== Transformation 2 ===<br />
<br />
A not-so well behaved weblog (an older blogspot weblog)<br />
<br />
Original:<br />
<br />
<pre><nowiki><br />
<body bgcolor="..."><br />
<br />
<div class="posts"><br />
<a name="112993192128302715">&nbsp;</a><br><br />
<div style="clear:both;"></div><strong>Nelson's final prayer</strong> <br />
written on the night before Trafalgar:<blockquote>May the Great God, ... heart.<br />
<div style="clear:both; padding-bottom: 0.25em;"></div><br />
<br><br />
<span class="byline"><br />
posted by Natalie at <br />
<a href="2005_10_16_nataliesolent_archive.html#112993192128302715">9:49 PM</a><br />
</span><br />
</div><br />
<br />
<div class="posts"><br />
<a name="112993022840118939">&nbsp;</a><br />
<br><br />
<div style="clear:both;"></div><strong>I really, truly </strong>didn't go ... view.<br />
<div style="clear:both; padding-bottom: 0.25em;"></div><br />
<br><br />
<span class="byline"><br />
posted by Natalie at <br />
<a href="2005_10_16_nataliesolent_archive.html#112993022840118939">9:28 PM</a><br />
</span><br />
</div><br />
...<br />
<br />
</body><br />
</nowiki></pre><br />
<br />
Transformed to hAtom compliant (shown in UPPER CASE for visibility only):<br />
<br />
<pre><nowiki><br />
<body bgcolor="..."><br />
<br />
<DIV CLASS="FEED"><br />
<div class="ENTRY posts" ID="112993192128302715"><br />
<strong CLASS="TITLE CONTENT"><br />
Nelson's final prayer<br />
</strong> <br />
<SPAN CLASS="CONTENT"><br />
written on the night before Trafalgar:<blockquote>May the Great God, ... heart.<br />
</SPAN><br />
<DIV><br />
<span class="byline">posted by <address>Natalie</address> at <br />
<a REL="BOOKMARK" href="HTTP://NATALIESOLENT.BLOGSPOT.COM/2005_10_16_nataliesolent_archive.html#112993192128302715"><br />
<ABBR CLASS="PUBLISHED" TITLE="2005-10-24T09:49:00-00:00">9:49 PM</ABBR></a><br />
</span><br />
</DIV><br />
</div><br />
<br />
<div class="ENTRY posts" ID="112993022840118939"><br />
<strong CLASS="TITLE CONTENT">I really, truly </strong><br />
<SPAN CLASS="CONTENT"><br />
didn't go ... view.<br />
</SPAN><br />
<DIV><br />
<span class="byline"><br />
posted by <address>Natalie</address> at <br />
<a REL="BOOKMARK" href="HTTP://NATALIESOLENT.BLOGSPOT.COM/2005_10_16_nataliesolent_archive.html#112993022840118939"><br />
<ABBR CLASS="PUBLISHED" TITLE="2005-10-24T09:49:00-00:00">9:28 PM</ABBR></a><br />
</span><br />
</DIV><br />
</div><br />
...<br />
</DIV><br />
<br />
</body><br />
</nowiki></pre><br />
<br />
Changes:<br />
* Added <code>class="feed"</code> to Feed<br />
* Added <code>class="entry"</code> to each Entry<br />
* Moved <code>id="###"</code> up to the Entry (and deleted the empty anchor block)<br />
* Added <code>rel="bookmark"</code> to the Entry Permalinks<br />
* Made the Entry Permalink non-relative<br />
* Added <code>&lt;span class="title"></code>...<code>&lt;/div></code> around the Entry Title<br />
* Added <code>&lt;span class="content"></code>...<code>&lt;/div></code> around the Entry Title (!)<br />
* Added <code>&lt;span class="content"></code>...<code>&lt;/div></code> around the Entry Content<br />
* Added <code>&lt;abbr class="published" title="YYYY-MM-DDThh:mm:ss+ZZZZ"></code>...<code>&lt;/abbr></code> around the Entry Datetime<br />
* Added <code>&lt;address></code> to the poster's name<br />
<br />
Also note:<br />
* there are multiple content blocks, because Natalie Solent embeds the title in the content<br />
* cleaned up lots of crap HTML presentation stuff, with the assumption it would be fixed in the stylesheet<br />
* this is one of the uglier transformations you're likely to see<br />
* we've respected the poster's poster apparent wish for anonimity by not adding an hCard<br />
<br />
=== Transformation 3 ===<br />
<br />
A media page (from [http://www.cbc.ca/story/world/national/2005/11/22/birdlfu051122.html CBC Newsworld]).<br />
<br />
Original:<br />
<br />
<pre><nowiki><br />
<div class="news"><br />
<div class="story"><br />
<h1>China confirms new bird flu outbreaks</h1><br />
<span class="byline">Last Updated Tue, 22 Nov 2005 23:26:18 EST</span><br />
<div class="text"><a href="/news/credit.html">CBC News</a></div><br />
<br />
<div class="text"><br />
<p><br />
China has confirmed three new outbreaks of bird flu, ...<br />
<p><br />
<ul><br />
<li><font SIZE="1">INDEPTH: </font><font SIZE="2"> <br />
<a href="http://www.cbc.ca/news/background/avianflu/">Avian Flu</a></font><br />
</ul><br />
</p><br />
<table align="right" cellpadding="0" cellspacing="4" hspace="4" width="220"><br />
<tr><br />
<td align="center"><br />
<img src="http://www.cbc.ca/gfx/pix/birdflu_china_cp_7707271.jpg" width="220" height="223" hspace="3" border="0"><br />
</td><br />
</tr><br />
<tr><br />
<td align="center"><br />
<div class="caption"><br />
<font size="1" face="verdana,arial"><i></i></font><br />
</div><br />
</td><br />
</tr><br />
</table><br />
<p>State media says the new outbreaks are in...</p><br />
<p>The news comes a day after China announced the ...</p><br />
<p>In China's eastern Anhui province, authorities have ...</p><br />
<p>The province says the measure will prevent domestic ...</p><br />
<p>Vietnamese health officials have confirmed that a ...</p><br />
<p>Doctors from the health department in the northern ...</p><br />
<p>Bird flu has killed 42 people in Vietnam since December ...</p><br />
<p>The World Health Organization fears the H5N1 strain of ...</p><br />
</div><br />
<br />
<p><font face="Verdana,Arial" size="1">with files from the Australian Broadcasting Corporation</font></p><br />
</div><br />
...<br />
</div><br />
</nowiki></pre><br />
<br />
Transformed to hAtom compliant (shown in UPPER CASE for visibility only):<br />
<br />
<pre><nowiki><br />
<div class="news"><br />
<div class="FEED ENTRY story"><br />
<h1>China confirms new bird flu outbreaks</h1><br />
<span class="byline">Last Updated<br />
<ABBR CLASS="POSTED" TITLE="2005-11-23T04:26:18Z">Tue, 22 Nov 2005 23:26:18 EST</ABBR><br />
</span><br />
<ADDRESS CLASS="VCARD"><div class="text"><a CLASS="URL" href="/news/credit.html">CBC News</a></div></ADDRESS><br />
<br />
<div class="text"><br />
<p CLASS="CONTENT"><br />
China has confirmed three new outbreaks of bird flu, ...<br />
</p><br />
<p><br />
<ul><br />
<li><font SIZE="1">INDEPTH: </font><font SIZE="2"> <br />
<a href="http://www.cbc.ca/news/background/avianflu/">Avian Flu</a></font><br />
</ul><br />
</p><br />
<table align="right" cellpadding="0" cellspacing="4" hspace="4" width="220"><br />
<tr><br />
<td align="center"><br />
<img src="http://www.cbc.ca/gfx/pix/birdflu_china_cp_7707271.jpg" width="220" height="223" hspace="3" border="0"><br />
</td><br />
</tr><br />
<tr><br />
<td align="center"><br />
<div class="caption"><br />
<font size="1" face="verdana,arial"><i></i></font><br />
</div><br />
</td><br />
</tr><br />
</table><br />
<p CLASS="CONTENT">State media says the new outbreaks are in...</p><br />
<p CLASS="CONTENT">The news comes a day after China announced the ...</p><br />
<p CLASS="CONTENT">In China's eastern Anhui province, authorities have ...</p><br />
<p CLASS="CONTENT">The province says the measure will prevent domestic ...</p><br />
<p CLASS="CONTENT">Vietnamese health officials have confirmed that a ...</p><br />
<p CLASS="CONTENT">Doctors from the health department in the northern ...</p><br />
<p CLASS="CONTENT">Bird flu has killed 42 people in Vietnam since December ...</p><br />
<p CLASS="CONTENT">The World Health Organization fears the H5N1 strain of ...</p><br />
</div><br />
<br />
<p><font face="Verdana,Arial" size="1">with files from the <ADDRESS CLASS="CONTRIBUTOR">Australian Broadcasting Corporation</ADDRESS></font></p><br />
</div><br />
...<br />
</div><br />
</nowiki></pre><br />
<br />
Changes:<br />
* Added <code>&lt;div class="feed entry"></code> around the single entry on the page<br />
: ''We have to make sure the nesting rules reflect nesting at the same level''<br />
* Added <code>&lt;span class="content"></code>...<code>&lt;/div></code> around every single paragraph -- this looks pathological but it may be the way this would need be produced from a template. The latter part of the document could be enclosed in a single "content" div but note that we did this so the "INDEPTH" part would not be marked as content,<br />
* Added <code>&lt;abbr class="published" title="YYYYMMDDThh:mm:ss+ZZZZ"></code>...<code>&lt;/abbr></code> around the Entry Datetime<br />
* Added <code>&lt;address></code> to the CBC Newsroom<br />
* Added <code>&lt;address class="contributor"></code> to a contributor's name<br />
<br />
Also note:<br />
* We may the document more XHTML compliant<br />
* There is no <code>rel="bookmark"</code> so it is assumed to be the URI of the page<br />
* The Entry Title was correctly marked with a <code>&lt;h1></code> element<br />
<br />
=== Transformation 4 ===<br />
<br />
A bulletin board ([http://forums.punbb.org/viewtopic.php?id=9135 PunBB])<br />
<br />
Original:<br />
<br />
<pre><nowiki><br />
<body><br />
<div id="punwrap"><br />
<div id="punviewtopic" class="pun"><br />
<br />
<div id="brdheader" class="block"><br />
... header stuff ...<br />
</div><br />
<br />
<div id="announce" class="block"><br />
... announcement stuff ...<br />
</div><br />
<br />
<div class="linkst"><br />
... controls for the blog<br />
</div><br />
<br />
<div id="p54390" class="blockpost rowodd firstpost"><br />
<h2><br />
<span><span class="conr">#1&nbsp;</span><br />
<a href="viewtopic.php?pid=54390#p54390">2005-10-16 10:36:24</a></span><br />
</h2><br />
<div class="box"><br />
<div class="inbox"><br />
<div class="postleft"><br />
<dl><br />
<dt><strong><a href="profile.php?id=2">Rickard</a></strong></dt><br />
<br />
<dd class="usertitle"><strong>PunBB Developer</strong></dd><br />
<dd class="postavatar"><img src="img/avatars/2.png" width="60" height="60" alt="" /></dd><br />
<dd>From: 127.0.0.1</dd><br />
<dd>Registered: 2001-11-02</dd><br />
<dd>Posts: 7806</dd><br />
<dd class="usercontacts"><a href="http://www.punbb.org/">Website</a></dd><br />
<br />
</dl><br />
</div><br />
<div class="postright"><br />
<h3>PunBB 1.2.9</h3><br />
<div class="postmsg"><br />
<p>Just a quick note this time....</p><br />
<br />
</div><br />
<div class="postsignature"><hr />&quot;Programming is like sex: ...</div><br />
</div><br />
<div class="clearer"></div><br />
<div class="postfootleft"><p>Offline</p></div><br />
<div class="postfootright"><div>&nbsp;</div></div><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div id="p54392" class="blockpost roweven"><br />
<h2><span><span class="conr">#2&nbsp;</span><a href="viewtopic.php?pid=54392#p54392">2005-10-16 10:54:41</a></span></h2><br />
<div class="box"><br />
<div class="inbox"><br />
<div class="postleft"><br />
<dl><br />
<dt><strong><a href="profile.php?id=5298">IdleFire</a></strong></dt><br />
<br />
<dd class="usertitle"><strong>Member</strong></dd><br />
<dd class="postavatar"></dd><br />
<dd>Registered: 2005-10-14</dd><br />
<dd>Posts: 27</dd><br />
</dl><br />
</div><br />
<div class="postright"><br />
<br />
<h3> Re: PunBB 1.2.9</h3><br />
<div class="postmsg"><br />
<p>...</p><br />
</div><br />
</div><br />
<div class="clearer"></div><br />
<div class="postfootleft"><p>Offline</p></div><br />
<br />
<div class="postfootright"><div>&nbsp;</div></div><br />
</div><br />
</div><br />
</div><br />
<br />
... more entries ...<br />
<br />
<div id="brdfooter" class="block"><br />
... footer stuff ...<br />
</div><br />
<br />
</div><br />
</div><br />
</body><br />
</nowiki></pre><br />
<br />
Transformed to hAtom compliant (changes shown in UPPER CASE for visibility only):<br />
<br />
<pre><nowiki><br />
<body><br />
<div id="punwrap"><br />
<div id="punviewtopic" class="pun"><br />
<br />
<div id="brdheader" class="block"><br />
... header stuff ...<br />
</div><br />
<br />
<div id="announce" class="block"><br />
... announcement stuff ...<br />
</div><br />
<br />
<div class="linkst"><br />
... controls for the blog<br />
</div><br />
<br />
<DIV CLASS="FEED"><br />
<div id="p54390" class="ENTRY blockpost rowodd firstpost"><br />
<h2><br />
<span><span class="conr">#1&nbsp;</span><br />
<a REL="BOOKMARK" href="HTTP://FORUMS.PUNBB.ORG/viewtopic.php?pid=54390#p54390"><br />
<ABBR CLASS="POSTED" TITLE="20051016T103624-0500">2005-10-16 10:36:24</ABBR><br />
</a></span><br />
</h2><br />
<div class="box"><br />
<div class="inbox"><br />
<div class="postleft"><br />
<dl><br />
<dt><strong><ADDRESS><a href="profile.php?id=2">Rickard</a></ADDRESS></strong></dt><br />
<br />
<dd class="usertitle"><strong>PunBB Developer</strong></dd><br />
<dd class="postavatar"><img src="img/avatars/2.png" width="60" height="60" alt="" /></dd><br />
<dd>From: 127.0.0.1</dd><br />
<dd>Registered: 2001-11-02</dd><br />
<dd>Posts: 7806</dd><br />
<dd class="usercontacts"><a href="http://www.punbb.org/">Website</a></dd><br />
<br />
</dl><br />
</div><br />
<div class="postright"><br />
<h3>PunBB 1.2.9</h3><br />
<div class="CONTENT postmsg"><br />
<p>Just a quick note this time....</p><br />
<br />
</div><br />
<div class="postsignature"><hr />&quot;Programming is like sex: ...</div><br />
</div><br />
<div class="clearer"></div><br />
<div class="postfootleft"><p>Offline</p></div><br />
<div class="postfootright"><div>&nbsp;</div></div><br />
</div><br />
</div><br />
<br />
</div><br />
<br />
<div id="p54392" class="ENTRY blockpost roweven"><br />
<h2><br />
<span><span class="conr">#2&nbsp;</span><br />
<a REL="BOOKMARK" href="HTTP://FORUMS.PUNBB.ORG/viewtopic.php?pid=54392#p54392"><br />
<ABBR CLASS="POSTED" TITLE="20051016T1105441-0500">2005-10-16 10:54:41</ABBR><br />
</a></span><br />
</h2><br />
<div class="box"><br />
<div class="inbox"><br />
<div class="postleft"><br />
<dl><br />
<dt><strong><ADDRESS CLASS="VCARD"><a CLASS="URL" href="profile.php?id=5298">IdleFire</a></ADDRESS></strong></dt><br />
<br />
<dd class="usertitle"><strong>Member</strong></dd><br />
<dd class="postavatar"></dd><br />
<dd>Registered: 2005-10-14</dd><br />
<dd>Posts: 27</dd><br />
</dl><br />
</div><br />
<div class="postright"><br />
<br />
<h3> Re: PunBB 1.2.9</h3><br />
<div class="CONTENT postmsg"><br />
<p>...</p><br />
</div><br />
</div><br />
<div class="clearer"></div><br />
<div class="postfootleft"><p>Offline</p></div><br />
<br />
<div class="postfootright"><div>&nbsp;</div></div><br />
</div><br />
</div><br />
</div><br />
<br />
... more entries ...<br />
</DIV><br />
<br />
<div id="brdfooter" class="block"><br />
... footer stuff ...<br />
</div><br />
<br />
</div><br />
</div><br />
</body><br />
</nowiki></pre><br />
<br />
<br />
Changes:<br />
* Added <code>&lt;div class="feed"></code> around the entries (as opposed to an existing <code>&lt;div</code> that enclosed more than entries.<br />
* Added <code>class="entry"</code> to each Entry<br />
* Added <code>rel="bookmark"</code> to the Entry Permalinks<br />
* Made the Entry Permalink non-relative<br />
* Added <code>&lt;span class="title"></code>...<code>&lt;/div></code> around the Entry Title<br />
* Added <code>&lt;span class="content"></code>...<code>&lt;/div></code> around the Entry Content<br />
* Added <code>&lt;abbr class="posted" title="YYYYMMDDThh:mm:ss+ZZZZ"></code>...<code>&lt;/abbr></code> around the Entry Datetime<br />
* Added <code>&lt;address></code> to the poster's name<br />
<br />
Also note:<br />
* We did not need to add <code>id="###"</code> to the Entry<br />
<br />
=== More Examples ===<br />
<br />
See [[hatom-examples]].<br />
<br />
== Examples in the wild ==<br />
This section is '''informative'''.<br />
<br />
* [http://blog.davidjanes.com Ranting and Roaring] (David Janes)<br />
* [http://www.myelin.co.nz/post/ Second p0st] (Phil Pearson)<br />
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Sound Advice] (Benjamin Carlyle)<br />
* [http://sedna.spip.org/sedna/ Sedna RSS] (a feed aggregator based on SPIP, by Fil, IZO and co)<br />
<br />
== Implementations ==<br />
<br />
This section is '''informative'''.<br />
<br />
<br />
* the [http://www.trinityanne.com/tools/extract/ Almost Universal Microformat Parser] can extract hAtom content from webpages ([http://www.trinityanne.com/tools/extract/?uri=http%3A%2F%2Fblog.davidjanes.com&microformat=hatom&submit=Submit example])<br />
* the [http://www.trinityanne.com/tools/greasemonkey/microformat-action.user.js microformat-action] [[greasemonkey|Greasemonkey]] script detects hAtom content on webpages and will call the [http://www.trinityanne.com/tools/extract/ Almost Universal Microformat Parser]<br />
* the [http://www.blogmatrix.com/tools/rewrite/ hAtom Template Rewriter] converts Blogger, MovableType and Wordpress templates into hAtom compatible ones -- (hopefully) without presentation impact<br />
* An [http://lukearno.com/projects/hAtom/ hAtom-2-Atom] XSLT is available. (This version is currently broken but a working version is [http://rbach.priv.at/repos/hatom/hatom2atom.xsl/trunk/ available])<br />
<br />
== References ==<br />
=== Normative References ===<br />
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]<br />
* [http://www.atomenabled.org/ Atom]<br />
<br />
=== Informative References ===<br />
<br />
==== Specifications That Use hAtom ====<br />
<br />
==== Similar Work ====<br />
<br />
* [http://rdfs.org/sioc/ Semantically-Interlinked Online Communities (SIOC) RDF Ontology]<br />
<br />
== Work in progress ==<br />
This specification is a work in progress. As additional aspects are discussed, understood, and written, they will be added. There is a separate document where we are keeping our brainstorms and other explorations relating to hAtom:<br />
<br />
* [[blog-post-brainstorming|blog-post Brainstorming]]<br />
<br />
== Hints and Tips ==<br />
<br />
=== CSS tips ===<br />
HTML typically styles <code>address</code> as a block level element in an italic font. This will make it inline and plain within hAtom elements:<br />
<br />
<pre><nowiki><br />
.entry address {<br />
display: inline;<br />
font-weight: normal;<br />
font-style: normal;<br />
} <br />
</nowiki></pre><br />
<br />
HTML typically puts a dotted line under <code>&lt;abbr></code> elements. This will put postage paid to that for Entry Updated and Entry Posted:<br />
<br />
<pre><nowiki><br />
.entry abbr.updated, .entry abbr.posted {<br />
font-style: normal;<br />
border: none;<br />
}<br />
</nowiki></pre><br />
<br />
=== MovableType Template ===<br />
<br />
A datetime encoded in an ABBR element can be produced with the following template code:<br />
<br />
<pre><nowiki><br />
<abbr <br />
class="posted" <br />
title="<$MTEntryDate format="%Y%m%dT%H%M%S"$><$MTBlogTimezone<br />
no_colon="1"$>"><$MTEntryDate format="%X"$></abbr><br />
</nowiki></pre><br />
<br />
== Discussions ==<br />
<br />
* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].<br />
<br />
=== Q&A ===<br />
* If you have any questions about hAtom, check the [[hatom-faq|hAtom FAQ]], and if you don't find answers, add your questions!<br />
<br />
=== Issues ===<br />
* Please add any issues with the specification to the separate [[hatom-issues|hAtom issues]] document.<br />
<br />
== Recent Changes ==<br />
<br />
''Most recent at top please. This section will eventually be removed but should be helpful for people tracking changes during specing.''<br />
<br />
* Entry Permalink now SHOULD (as opposed to MUST) be a complete URI<br />
* Entry Title now preferentially uses class="title"<br />
* Entry Author most explicitly be marked class="author"<br />
* using an <code>&lt;address</code> around Entry Author and Entry Contributor is no longer required<br />
<br />
==See Also==<br />
* [[hatom|hAtom]] - the draft proposal<br />
* [[hatom-issues]] - problems? complaints? ideas? Put them here<br />
* [[hatom-faq]] - knowledge base<br />
* [[blog-post-brainstorming]]<br />
* [[blog-post-formats]]<br />
* [[blog-post-examples]]<br />
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)</div>Filhttps://microformats.org/wiki/index.php?title=User:Fil&diff=5538User:Fil2006-01-06T00:20:21Z<p>Fil: correction in link</p>
<hr />
<div>Fil is fil * rezo.net, working on [http://www.spip.net/ SPIP] & microformats, like e.g. in the [http://sedna.spip.org/sedna/ Sedna RSS] aggregator project, and trolls on the [http://microformats.org/wiki/irc #microformats] irc channel.</div>Filhttps://microformats.org/wiki/index.php?title=User:Fil&diff=3940User:Fil2006-01-06T00:19:51Z<p>Fil: add troll</p>
<hr />
<div>Fil is fil * rezo.net, working on [http://www.spip.net/ SPIP] & microformats, like e.g. in the [http://sedna.spip.org/sedna/ Sedna RSS] aggregator project, and trolls on the [http://microformats.org/wiki/ #microformats irc channel].</div>Filhttps://microformats.org/wiki/index.php?title=User:Fil&diff=3939User:Fil2006-01-06T00:03:34Z<p>Fil: who's I</p>
<hr />
<div>Fil is fil * rezo.net, working on [http://www.spip.net/ SPIP] & microformats, like e.g. in the [http://sedna.spip.org/sedna/ Sedna RSS] aggregator project.</div>Filhttps://microformats.org/wiki/index.php?title=irc&diff=4059irc2006-01-06T00:01:38Z<p>Fil: add Fil</p>
<hr />
<div>__NOTOC__<br />
= Microformats IRC =<br />
<br />
We have an IRC channel, [irc://irc.freenode.net#microformats #microformats on the freenode network].<br />
<br />
There's typically someone there at any point during the day, though there isn't always active discussion. Sometimes, though this is the best place to discuss issues that need lots of back and forth discussion.<br />
<br />
== People on irc ==<br />
A list of IRC regulars and their normal timezones.<br />
<br />
* [[User:RyanKing|kingryan]] (-0800)<br />
* [[User:EdwardOConnor|hober]] (-0800)<br />
* [[User:RobertBachmann|RobertBachmann]] (+0100)<br />
* [[User:Tantek|Tantek]] (-0800)<br />
* [http://epeus.blogspot.com/ KevinMarks] (-0800)<br />
* [[User:DimitriGlazkov|dglazkov]] (-0600)<br />
* [[User:ChrisMessina|factoryjoe]] (-0800)<br />
* [[User:IanHickson|Hixie]] (-0800)<br />
* [[User:neuro|neuro`]]<br />
* [[User:JoeGregorio|jcgregorio]]<br />
* [[User:Cgriego|cgriego]] (-0600)<br />
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)<br />
* [[User:Izo|IZO]]<br />
* [[User:Fil|Fil]] (+0200)<br />
<br />
=== bots ===<br />
<br />
* [[mfbot]]<br />
* [[mflogbot]]<br />
* [[jibot]]<br />
<br />
== IRC meetups ==<br />
<br />
The idea of having IRC meetups (that is, a set time for meeting on IRC) has been suggested by [[User:RyanKing|Ryan King]], as it appears to work well for the WordPress community and may help us from time-to-time. As of yet, there are no plans to have meetups, though.</div>Fil