Microformats Wiki - User contributions [en]

uid-brainstorming

2006-05-05T02:16:28Z

BenjaminCarlyle: Fix formatting

= UID Brainstorming =

This page is for brainstorming about ideas, proposals, constraints, requirements for a UID microformat.

== Authors ==

* Tantek Çelik
* Ed Summers

== Experience ==

* a microformat for indicating something *is* an identifier rather than the solved problem of providing a microformat *for* identifiers ([http://www.ietf.org/rfc/rfc2396.txt RFC 2396])

* Tantek has had conversations with LiveClipboard folks and upcoming.org who have had questions about how to do UID properly in hCard and hCalendar. So a separate microformat that those two could call out to would serve a real need.

* It would be useful for autodiscovery puposes to be able to follow a network resolvabale UID and extract more metadata from the referenced UID. Having a well defined UID pattern would prevent an explosion of rel values: rel-vcard, rel-vevent, etc.

* Efforts such as [http://unapi.info unAPI] have a real need for marking up identifiers so that they can be used for retrieving identified objects.

* Greasemonkey and other browser based scripts could make real use of URIs found in pages as opposed to resorting to elaborate regexen. See Jon Udell's [http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html LibraryLookup] project.

* GoogleScholar embed identifiers in their citations and it would enable moving citations from the browser to a citation manager greatly if there were a way to mark them up.

== Goals Requirements ==

* a method of publishing an asserted globally unique identifier for a piece of content or a referenced item

== Thoughts ==

=== UID + SOURCE -> permalink? ===
URL is used in hcalendar examples to point not to the permalink of the vevent, but to the permalink for the event home page. If the event home page contains the authorative hcalendar entry, that's fine. Alternatively the source attribute could be borrowed from vcard to mean "microformat permalink" instead of "permalink of the thing the microformat is about".

There seems to be a conflict between iCalendar and vCard rfcs as to what a url is. iCalendar says permalink of iCalendar object. vCard says identifying url (eg home page) of the person or object the vCard is about. vCard uses "source" for iCalendar's "url".

=== UIDs that are URLs ===

It seems like in the 80% case (perhaps 99.99% case on the Web), a UID is going to be a URL, thus a common pattern will likely be things like:

<pre><nowiki>
<a class="url uid" href="http://example.com/contentspace/somenumber">the item</a>
</nowiki></pre>

=== SHOULD rather than MUST ===

A UID SHOULD be a URL rather than MUST. The UID microformat will ordinarily be a URL, but it should be flexible enough to allow it to contain non-network resolvable URIs.

=== UID + URL -> permalink? ===

Can you infer that if something is a URL and a UID that it is also a permalink? It seems so. I can't think of any semantic of "permalink" that isn't covered by the union of the semantics of URL and UID.

=== abbr pattern ===

Use the [[abbr-design-pattern]] to allow identifiers to be more fully described.
<pre>
<abbr class="uid" title="urn:isbn:0950788120">0 9507881-2-0</abbr>
</pre>

=== HTML ID attribute ===

How does/doesn't the ID attribute from HTML fit into all this? Can it be repurposed to help here?

== Proposals ==

=== Just use UID from hCard ===

* Tantek proposed that we see if we can reuse uid from [[hcard|hCard]], similar to how we have reused [[geo]] and [[adr]] from [[hcard|hCard]].
* In particular we should define per the RFC2426 and RFC2445 definitions of UID, and also state that UID identifies the singular thing which this microformat is about (primary reference). (Thanks Joe Andrieu for this wording).
* Since microformats are about things published on the *Web*, we can say:
** UIDs SHOULD be URLs and if you cannot use a URL (for whatever reason), then you SHOULD at least use a URI, thereby indicating our preference for UIDs which can be resolved to a network location, and barring that, UIDs which follow the URN registry.

=== Use rel-bookmark from hAtom ===
hAtom currently uses the HTML standard rel-bookmark to identify its bookmark. This appears to be precisely eqivalent to the class combination "uid url". This does not appear to permit non-url uids, but if we are identifying the authorative id of a piece of microformatted data that we already have in-hand a non-url uid may never be required. Non-url uids (eg isbn) can still appear in citation formats without affecting the development of this "identify myself" microformat.

If rel-bookmark is not appropriate for this format, we should consider retrofiting this format back to hAtom. It may be appropriate to replace rel-bookmark with the separate url and uid classes, or to allow either form to be used.

=== Create a URI microformat ===

* Xiaoming proposed leaving UID intact in hcalendar and hcard, because whatever written in rfc2426/rfc2445 and their examples cannot be easily changed, and they seem to work well with hcalendar/hcard. Instead a new "URI" microformat should be established for the purpose of indicating something *is* an identifier in general.In this case you can easily reference URI RFC and no further elaboration about persistence, resolvability or uniqueness will be necessary because these issues are addressed by various URI specifications.
** The problem with "just use URI" is that URI (or URL for that matter) merely is a *type* of data. What that data *means* to the microformat still needs additional semantics, and that's why we need a property name like UID (even if it is defined to be of type URI or URL) which specifies this particular semantic. Thanks to Joe Andrieu for asking the questions which lead to this clarification. - Tantek

== References ==
* [[adr]]
* [[geo]]
* [[hatom|hAtom]]
* [[hcard|hCard]]
* [[hcalendar|hCalendar]]
* [[abbr-design-pattern]]

== See Also ==
* [http://www.iana.org/assignments/urn-namespaces IANA URN Namespaces - RFC2141, RFC3406]
* [http://www.iana.org/assignments/uri-schemes.html IANA Uniform Resource Identifer (URI) Schemes]
* [http://ocoins.info COinS] for putting attaching openurl context objexts to a span.
* [http://unapi.info unAPI] has a technique for embedding IDs in html so that they can be retrieved from an unAPI service.
* [http://www.taguri.org/ Tag URI] an algorithm that lets people mint identifiers that no one else using the same algorithm could ever mint.

== Related Discussion ==
* [http://microformats.org/discuss/mail/microformats-discuss/2006-April/003726.html UID, URL, live microformats]
* [http://microformats.org/discuss/mail/microformats-discuss/2005-November/002046.html format for identifiers]

uid-brainstorming

2006-05-05T02:15:31Z

BenjaminCarlyle: Add UID + SOURCE option

= UID Brainstorming =

This page is for brainstorming about ideas, proposals, constraints, requirements for a UID microformat.

== Authors ==

* Tantek Çelik
* Ed Summers

== Experience ==

* a microformat for indicating something *is* an identifier rather than the solved problem of providing a microformat *for* identifiers ([http://www.ietf.org/rfc/rfc2396.txt RFC 2396])

* Tantek has had conversations with LiveClipboard folks and upcoming.org who have had questions about how to do UID properly in hCard and hCalendar. So a separate microformat that those two could call out to would serve a real need.

* It would be useful for autodiscovery puposes to be able to follow a network resolvabale UID and extract more metadata from the referenced UID. Having a well defined UID pattern would prevent an explosion of rel values: rel-vcard, rel-vevent, etc.

* Efforts such as [http://unapi.info unAPI] have a real need for marking up identifiers so that they can be used for retrieving identified objects.

* Greasemonkey and other browser based scripts could make real use of URIs found in pages as opposed to resorting to elaborate regexen. See Jon Udell's [http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html LibraryLookup] project.

* GoogleScholar embed identifiers in their citations and it would enable moving citations from the browser to a citation manager greatly if there were a way to mark them up.

== Goals Requirements ==

* a method of publishing an asserted globally unique identifier for a piece of content or a referenced item

== Thoughts ==

== UID + SOURCE -> permalink? ==
URL is used in hcalendar examples to point not to the permalink of the vevent, but to the permalink for the event home page. If the event home page contains the authorative hcalendar entry, that's fine. Alternatively the source attribute could be borrowed from vcard to mean "microformat permalink" instead of "permalink of the thing the microformat is about".

There seems to be a conflict between iCalendar and vCard rfcs as to what a url is. iCalendar says permalink of iCalendar object. vCard says identifying url (eg home page) of the person or object the vCard is about. vCard uses "source" for iCalendar's "url".

=== UIDs that are URLs ===

It seems like in the 80% case (perhaps 99.99% case on the Web), a UID is going to be a URL, thus a common pattern will likely be things like:

<pre><nowiki>
<a class="url uid" href="http://example.com/contentspace/somenumber">the item</a>
</nowiki></pre>

=== SHOULD rather than MUST ===

A UID SHOULD be a URL rather than MUST. The UID microformat will ordinarily be a URL, but it should be flexible enough to allow it to contain non-network resolvable URIs.

=== UID + URL -> permalink? ===

Can you infer that if something is a URL and a UID that it is also a permalink? It seems so. I can't think of any semantic of "permalink" that isn't covered by the union of the semantics of URL and UID.

=== abbr pattern ===

Use the [[abbr-design-pattern]] to allow identifiers to be more fully described.
<pre>
<abbr class="uid" title="urn:isbn:0950788120">0 9507881-2-0</abbr>
</pre>

=== HTML ID attribute ===

How does/doesn't the ID attribute from HTML fit into all this? Can it be repurposed to help here?

== Proposals ==

=== Just use UID from hCard ===

* Tantek proposed that we see if we can reuse uid from [[hcard|hCard]], similar to how we have reused [[geo]] and [[adr]] from [[hcard|hCard]].
* In particular we should define per the RFC2426 and RFC2445 definitions of UID, and also state that UID identifies the singular thing which this microformat is about (primary reference). (Thanks Joe Andrieu for this wording).
* Since microformats are about things published on the *Web*, we can say:
** UIDs SHOULD be URLs and if you cannot use a URL (for whatever reason), then you SHOULD at least use a URI, thereby indicating our preference for UIDs which can be resolved to a network location, and barring that, UIDs which follow the URN registry.

=== Use rel-bookmark from hAtom ===
hAtom currently uses the HTML standard rel-bookmark to identify its bookmark. This appears to be precisely eqivalent to the class combination "uid url". This does not appear to permit non-url uids, but if we are identifying the authorative id of a piece of microformatted data that we already have in-hand a non-url uid may never be required. Non-url uids (eg isbn) can still appear in citation formats without affecting the development of this "identify myself" microformat.

If rel-bookmark is not appropriate for this format, we should consider retrofiting this format back to hAtom. It may be appropriate to replace rel-bookmark with the separate url and uid classes, or to allow either form to be used.

=== Create a URI microformat ===

* Xiaoming proposed leaving UID intact in hcalendar and hcard, because whatever written in rfc2426/rfc2445 and their examples cannot be easily changed, and they seem to work well with hcalendar/hcard. Instead a new "URI" microformat should be established for the purpose of indicating something *is* an identifier in general.In this case you can easily reference URI RFC and no further elaboration about persistence, resolvability or uniqueness will be necessary because these issues are addressed by various URI specifications.
** The problem with "just use URI" is that URI (or URL for that matter) merely is a *type* of data. What that data *means* to the microformat still needs additional semantics, and that's why we need a property name like UID (even if it is defined to be of type URI or URL) which specifies this particular semantic. Thanks to Joe Andrieu for asking the questions which lead to this clarification. - Tantek

== References ==
* [[adr]]
* [[geo]]
* [[hatom|hAtom]]
* [[hcard|hCard]]
* [[hcalendar|hCalendar]]
* [[abbr-design-pattern]]

== See Also ==
* [http://www.iana.org/assignments/urn-namespaces IANA URN Namespaces - RFC2141, RFC3406]
* [http://www.iana.org/assignments/uri-schemes.html IANA Uniform Resource Identifer (URI) Schemes]
* [http://ocoins.info COinS] for putting attaching openurl context objexts to a span.
* [http://unapi.info unAPI] has a technique for embedding IDs in html so that they can be retrieved from an unAPI service.
* [http://www.taguri.org/ Tag URI] an algorithm that lets people mint identifiers that no one else using the same algorithm could ever mint.

== Related Discussion ==
* [http://microformats.org/discuss/mail/microformats-discuss/2006-April/003726.html UID, URL, live microformats]
* [http://microformats.org/discuss/mail/microformats-discuss/2005-November/002046.html format for identifiers]

hatom-issues

2006-05-01T01:40:21Z

BenjaminCarlyle: Add uid+url vs rel-bookmark conflict

__TOC__

= hAtom 0.2 =

This section is for discussing what you'd like to see in the next version of hAtom, i.e. 0.2.

== Relationship of rel-bookmark to url+uid ==
The concept of permalink is available in hCard and hCalendar as the classes url and uid. This combination matches the permalink semantics by indicating that the url should be derefenced to find a more dynamic or up-to-date version of the content, and that that url is a stable unique id that can be used to identify the content.

hAtom 0.1 uses rel-bookmark for the permalink concept. The current state of [[uid-brainstorming]] indicates that the hCard and hCalendar permalink concept is likely to be used in subsequent microformats. It may be important to reconcile hAtom with that trajectory. Possible reconcilliations include:

1) To leave things as they are. The two permalink concepts are to be kept separate.

2) Treat the two concepts as equivalent. Allow both in hAtom, and consider allowing both in other formats. eg <a rel="bookmark" href="http://example.com/"> would fill out uid and url values if they are not supplied explicitly.

3) Choose one over the other for hAtom and perhaps for future microformats also. "url uid" allows for some greater freedom (uid can be pointed at a non-url uid), but it is unclear at this stage whether that freedom is warranted or advisable to permit.

== Feed <i>XXX</i> (atom:<i>xxx</i>) ==

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.

== Feed <i>id</i> (atom:<i>id</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

atom:<i>id</i> is required for atom:feed. Thus it should be available in hAtom to.
The Feed permalink should be used as the feed id.

== Feed <i>permalink</i> (atom:<i>permalink</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

I'm proposing the following rules:

* a Feed Permalink element is identified by [[rel-bookmark]] at the feed level*
* a Feed <del>SHOULD</del><ins>MAY</ins> have a Feed Permalink
* a Feed Permalink element represents the concept of an Atom link in a feed.
* if the Feed Permalink is missing, use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI

<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

2006-04-03 [[User:ChrisCasciano|ChrisCasciano]] - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.

: 2006-04-03 [[User:RobertBachmann|Robert Bachmann]]: I've replaced "SHOULD" with "MAY".
: 2006-04-24 [[User:RobertBachmann|Robert Bachmann]]: Maybe we could simplify my proposal to:
: "''Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI''"
: IMO this would be good enough for at least 80% of the cases.

* 2006-04-12 [[User:DavidJanes]]: can we find an example of this in the wild and if so we should add it to the -examples page.

* [[User:Singpolyma|singpolyma]] 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't [[rel-home]] make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.

== Feed <i>updated</i> (atom:<i>updated</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

atom:<i>updated</i> is required for atom:feed. Thus it should be available in hAtom to.
I'm proposing the following rules:

* The Feed Updated element is identified by the class name <code>updated</code> at the feed level*
* If no element with the class name <code>updated</code> is present, use the youngest <code>updated</code> from the feed's entries.

Algorithm:

<pre>
$a = array();
for each $entry in $feed {
if ($entry.updated)
$a.add(pad_datetime($entry.updated))
else
$a.add(pad_datetime($entry.published))
}
$a.sort_by( datetime_to_utc($element) )
$feed_updated = $a[0];
</pre>

<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

* 2006-04-12 [[User:DavidJanes]] I like this. And the definition of "feed level"

== Feed <i>title</i> (atom:<i>title</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

atom:<i>title</i> is required for atom:feed. Thus it should be available in hAtom to.

I'm proposing the following rules:

* a Feed Title element is identified by the class name <code><del>entry</del><ins>feed</ins>-title</code>
* a Feed SHOULD have an Feed Title
* a Feed Title element represents the concept of an Atom feed title
* if the Feed Title is missing, use
** <del>the first <code><h#></code> element in the Feed, or</del>
** the <code><title></code> of the page, or
** assume it is the empty string

* 2006-04-01 [[User:ChrisCasciano|ChrisCasciano]] - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using <code><title></code> before h# would be prefered if not the most common desire of the page author.

:: 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code><h#></code> element in the Feed, or"
:: 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><h#></code> to encode the date for a group of postings

* 2006-04-12 [[User:DavidJanes]]: why <code>entry-title</code> for the feed title. Why not <code>fn</code> or <code>feed-title</code>?

: 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.

== Feed <i>author</i> and Entry author (atom:<i>author</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

I'm proposing the following rules for Feed author:

* a Feed Author element is represented by class name <code>author</code> at the feed level*
* a Feed Author element represents the concept of a Atom author
* a Feed Author element MUST be encoded in a [[hcard|hCard]]
* a Feed Author element SHOULD be encoded in a <code><address></code> element
* a Feed MAY have more than one Feed Author elements
* if the Feed Author is missing
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise <del>the Feed is invalid hAtom</del> <ins>there is no Feed Author</ins>

I'm proposing the following rules for entry author:

* an Entry Author element is represented by class name <code>author</code>
* an Entry Author element represents the concept of an Atom author
* an Entry Author element MUST be encoded in an [[hcard|hCard]]
* an Entry Author element SHOULD be encoded in an <code><address></code> element
*<del> If a Feed has no Feed author each Entry MUST have at least one Entry Author element</del>
* <ins>If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise the Entry is invalid hAtom
</ins>
* an Entry MAY have more than one Entry Author elements
<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element

* [[User:Singpolyma|singpolyma]] 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author. Also, one or more entries may be missing an author IF feed-level has an author.
: 2006-04-17 [[User:RobertBachmann|Robert Bachmann]]: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

== Entry <i>XXX</i> (atom:<i>xxx</i>) ==

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.

== Entry <i>id</i> (atom:<i>id</i>) ==
<small>2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>

atom:<i>id</i> is required for atom:entry. Thus it should be available in hAtom to.

The Entry permalink should be used as the entry id.

* --[[User:Federico|Federico]] 19:52, 25 Apr 2006 (PDT): I would add "Only if the id attribute is not defined for the element that contains the entry". The id attribute can be a tag uri. If you use always use the Entry permalink as the entry id and the Atom feed uses tag uris, you would end with two different ids for the same entry.

== Author ==

=== author as an hcard is too much to require ===

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]

* [[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 <div class="author"> element.
** [[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.
** [[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"
** [[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.

* [[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"
** [[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.
** [[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

* [[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
** [[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>

== Other Questions and Issues ==

General comments, modeling issues, algorithm issues, should have issues, etc. go here.

=== Entry Updated Required? -- Blogger Issue ===
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? -- [[User:Singpolyma|singpolyma]] 05:45, 28 Mar 2006 (PST)

* [[DavidJanes]]: I'm not sure if anything can be done. My thought right now is just to put "x-posted" (or whatever) as the semantic class name and eventually hope that they'll adopted something more flexible. A while back there was a proposal that ABBR be used to describe a parsable version of the date string (for example <code>title="day month-name year, hour12:minute ampm tz"</code>) but I think this is asking too much from creators and parsers.

** [[User:Singpolyma|singpolyma]] 00:15, 13 Apr 2006 (PDT) : I am currently just adding the appropriate classes even though the contents are not valid date formats. My parsers are more leniant anyway (using PHP's strtotime, so any format supported there will work), but that doesn't resolve the fact that my blogs ''cannot'' be parsed by other's hAtom parers as hAtom is now unless they too are so leniant.

= hAtom 0.1 =

'''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'''

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).

__TOC__

== Contributors ==
* Danny Ayers
* Robert Bachmann
* Paul Bryson
* Benjamin Carlyle
* Chris Casciano
* Tantek Çelik
* David Janes
* Ryan King
* Kevin Marks
* Scott Reynen
* Brian

== Feed (atom:feed)==

[[RyanKing]]: '''STATUS: RESOLVED - 'hfeed' and not required (a la [[hcalendar]])'''

=== Initial proposal ===

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

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

=== Alternatives ===

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

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

==== Discussion ====

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

== Entry (atom:entry) ==

[[RyanKing]]: '''STATUS - RESOLVED - 'hentry' '''

=== Initial Proposal ===

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

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

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

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

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

== Entry Title (atom:title) ==

[[RyanKing]]: '''STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content' '''

=== proposals ===

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

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

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

== Entry Content (atom:content) ==

'''STATUS - RESOLVED going with entry-content'''

* <code>content</code> (Atom consistency)
** -1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** -1 [[ChrisCasciano]]
** -1 KevinMarks - already too many in the wild
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion
** -1 Tantek - agreed with Ryan
** -1 KevinMarks
* <code>entry-content</code>
** +1 Niall Kennedy (proposed)
** +0.5 [[Tantek]]
** +1 KevinMarks
** +1 [[ChrisCasciano]]
* <code>atom-content</code>
** +0.5 [[Tantek]]
* <code>hcontent</code>
** -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.

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

== Entry Summary (atom:summary) ==

'''STATUS - RESOLVED - going with 'entry-summary''''

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

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

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

== Entry Permalink (atom:link) ==

'''STATUS - RESOLVED - 'bookmark' '''

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

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

== Entry Published (atom:published) ==
* <code>published</code> (Atom consistency)
** +0.5 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +0.5 [[Tantek]] (want to consider it, while we can)
* <code>VJOURNAL CREATED</code>

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

== Entry Updated (atom:updated) ==

'''STATUS - RESOLVED - 'updated''''

* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +½ Paul Bryson, Not as human readable
** +0.5 [[Tantek]] (want to consider it, while we can)
* <code>last-modified</code>
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)
** dtstamp
** dtupdated

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

== Entry Author (atom:author) ==

'''STATUS - RESOLVED - 'author' required, should use <code><address></code>'''

* <code>author</code> (Atom consistency)
** +1 [[Tantek]]
** +1 [[BenjaminCarlyle]]

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

== Entry Contributor (atom:contributor) ==
** -1 Tantek (see Discussion)
* <code>contributor</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes

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

== Entry Geo (geo:Point) ==
* [[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.

=== GeoRSS Resources ===
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]

== Questions and Comments ==

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

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

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

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

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

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

=== hCards ===

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

RESOLVED: MUST use hCard for author.

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

=== Comparisons ===

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

--[[Ernie Prabhakar]]

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

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

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

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

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

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

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

-- [[BenjaminCarlyle]]

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

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

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

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

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

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

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

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

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

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

=== Designating the page author ===

(2006-02-07 raised by [[User:RobertBachmann|Robert Bachmann]])

“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”

* How do I designate the page author(s)?
** <code>class="author"</code> outside of the hAtom entry?
** <code><address class="author"></code> outside of the hAtom entry?
** <code><address></code> outside of the hAtom feed (i.e. at the page level)?
* How do I designate the feed author(s)?

(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])
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.

==== Proposal ====
* 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)
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.

== Entry Updated Required? -- Blogger ==
* 2006-03-06 raised by [[User:Singpolyma|singpolyma]].
*# 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...

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

= Template =

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

faq

2006-04-30T22:43:17Z

BenjaminCarlyle: Add when and why question for microformats

<h1> Microformats FAQ </h1>

This page document frequently asked questions about microformats. For frequently asked questions from the [[press]], see [[press-faq]].

__TOC__

== wiki specific questions ==

Q: ''How do I create a username? Why won't it let me use my preferred username?''

A: First, read this: http://en.wikipedia.org/wiki/Wikipedia:Username . Second, real names are preferred to pseudonyms/handles etc. Real names encourage better transparency and accountability. Third, the most common problem creating a user name is forgetting to caplitalize the first letter of the user name. Try using a WikiCase version of your full name as username, e.g. RyanKing.

== Basic Microformat Questions ==

Q: ''When should I use a microformat? What are they for?"

A: You are writing some html that contains useful human-readable information. You say to yourself: I would like to mark this up with some classes now for styling. You look up the relevant microformat, and you
pull in the standard names. You don't have to make your own up, and now your page is machine-readable too. Bonus!

Microformats are designed to make the data you already publish for humans available to machines. It allows applications as simple as cut-and-paste or as complex as a seach engine to use your data effectively.

Q: ''Are microformats dependent upon (X)HTML?''

A: Microformats are made to be embeddable. They can be embedded in (X)HTML, RSS, Atom or anywhere (X)HTML is allowed.

Q: ''Microformats sound great. How can I help?''

A: First of all, take a look at http://microformats.org/discuss to see some ways to join the conversations about microformats.

Q: ''I'd like to make a donation to the microformat cause. How can I do this?''

A: Thank you for your willingness to support microformats. We've only recently started this site and have decided that while we are figuring out exactly how to accept donations, we will be passing along donations to other good causes. Please consider donating to another cause like Red Cross, perhaps directed to help victims of recent natural disasters.

Q: ''Which microformats have been implemented?''

See the [[implementations]] page.

Q: ''Which microformats should I implement?''

A: Chances are you that your website already has data very similar to several microformats. For example, you probably have people and/or their contact information somewhere. That information could be marked up with [[hcard]]. If you are publishing press releases, try using [[hatom]].

Q: ''Do you have any link badges I can add to my website/blog?''

A: Not yet, but we'll post them when we do...

Q. ''Are there any tools that support microformats?''

A. Yes... [[implementations]].

Q. ''What about using new URI schemes instead of class names, e.g. for geo information?''

A. In general, it is more work, and less content-publisher friendly, to ask them to use URI schemes instead of class names.

Authors aren't publishing links to geo information.

They're publishing *visible text* of [[geo]] information.

So the easiest thing to do, for the author, is to leave it as visible text.

Thus, it makes the most sense to do the simple thing of just wrapping that
visible text with a little bit of markup, rather than asking the author to
move (or copy) it into an attribute, which may or may not require a
reformatting of the data as well.

It would make sense from a usability persepective to hyperlink geo information to a maps page or something, so that clicking it actually does something. If you forced them to use a hypothetical "geo:" protocol instead, then that would interfere, since you can only hyperlink something to one destination.

Q: ''Who is the registrar for microformats?''

A: There is no central registry. Microformats are registered in a distributed manner using profiles. For more information on profiles see http://microformats.org/wiki/profile-uris and http://gmpg.org/xmdp/

Conflicts and interoperability are managed through social processes rather than a formal registry. Current microformat profiles can be found at http://gmpg.org, http://w3.org, and http://microformats.org.

Q: ''So multiple microformats with the same name can be valid?''

A: Yes. The community at microformats.org can hopefully play a role in determining which is preferred by bringing interested folks together in one place and helping them resolve that question. As long as each microformat maintains a valid profile, each can be used effectively.

== Specific Microformat Questions ==
If you have a question regarding a specific microformat, you may want to check the FAQ specific to that microformat.
* [[hatom-faq]]
* [[hcalendar-faq]]
* [[hcard-faq]]
* [[hreview-faq]]
* [[rel-faq]]
* [[rel-tag-faq]]
* [http://gmpg.org/xfn/faq xfn-faq]
* [[xfolk-faq]]
* [[xmdp-faq]]
* [[xoxo-faq]]

== Class interactions ==

Q. ''Are there issues with page styling when specific class values are used?''

A. There might be. However, any such issues can be easily (trivially) worked around by using contextual selectors.

Q. ''How does the use of class values for semantics interact with the use of class values for attaching CSS styles?''

A. The class attribute takes a space separated set of class names [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 HTML4 reference]. Thus both author and microformat defined class names may be used in the same class attribute. In addition, microformat class names provide the author with a consistent set of class names to use for styling. If the author is already using using specific class names, they can continue to do so, and include microformat class names. If the author is already using a class name that happens to also be a microformat class name, then the author may want to consider using contextual CSS class selectors to make sure that avoid any unintentional styling effects.

See also:
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]
* [http://tantek.com/log/2004/07.html#classmeaningnotshow Class For Meaning Not For Show]
* [http://www.meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competant Classing], by Eric Meyer for discussion of choosing class names in (X)HTML
* [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling] - Ryan King dispells common misconceptions about the ''HTML'' class attribute.

== <code><div></code> and <code><span></code> semantics ==

Q. Is it semantically meaningless to use divs?

A. Yes, both <code><div></code> and <code><span></code> have nearly no semantics. <code><div></code> can be used to represent a "division" of the page content. Similarly <code><span></code> can be used to reperesent that that "span" of text has some meaning, but the specifics of what that meaning is undefined by the <code><span></code>.

Q. Does the use of <code><div></code> and <code><span></code> elements add any semantics to web pages?

A. According to the [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.4 spec], <code><div></code> and <code><span></code> "offer a generic mechanism for adding structure to documents." Their only meaning is in dividing documents into sections, and as such, their presence implies that the content within has a specific, but undefined by the element markup, semantic. Thus they are nearly semantic-free.

Q. Why do the examples on the wiki use <code class="element"><span></code> and <code class="element"><div></code> for nearly everything?

A. <code class="element"><span></code> and <code class="element"><div></code> are generic elements in HTML. When you use microformats, you should pick the most specific semantic element available.

== Class semantics ==

Q. ''Do (X)HTML class names have semantics?''

A. The HTML4 specification does not define any particular class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], nor does it define any particular semantic for class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], except that they "may be used for general user agent processing" [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF]. However, the [http://www.w3.org/TR/WD-htmllink-970328#profile" draft of "Hypertext Links in HTML"], allows for a "profile" to define meanings for those classes. [http://gmpg.org/xmdp/ XMDP] is a format for defining meta data profiles for (X)HTML, and thus an XMDP profile can be used to define the meanings of class names.

See also:
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]
* [http://www.w3.org/TR/WD-htmllink-970328 Hypertext Links in HTML]

== Indicating a page contains microformat markup ==

Q. Is there a way to indicate that a given web page contains markup that conforms to one or more microformats?

A. The HTML HEAD element's '<code>profile</code>' attribute alerts applications to the potential presence of microformats. The [http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.4.4.3 W3C HTML Specification] describes more about the profile attribute, and the [http://gmpg.org/xmdp/description XMDP description] documents how it is used.

== Microformats and Spam ==

Q. Given that Google now looks at hidden content as potential spam, will microformats be considered spam?

A. Microformats aren't meant to disguise semantics -- only provide a mechanism for marking up the content you intend to make visible on a page, typically no more and no less. Where we embed semantic equivalents in the tags themselves (i.e. GMT times in abbr tags for times), it doesn't seem logical that such data could be considered spam.

uid-brainstorming

2006-04-30T22:28:02Z

BenjaminCarlyle: Add hAtom reference

= UID Brainstorming =

This page is for brainstorming about ideas, proposals, constraints, requirements for a UID microformat.

== Authors ==

* Tantek Çelik
* Ed Summers

== Experience ==

* a microformat for indicating something *is* an identifier rather than the solved problem of providing a microformat *for* identifiers ([http://www.ietf.org/rfc/rfc2396.txt RFC 2396])

* Tantek has had conversations with LiveClipboard folks and upcoming.org who have had questions about how to do UID properly in hCard and hCalendar. So a separate microformat that those two could call out to would serve a real need.

* It would be useful for autodiscovery puposes to be able to follow a network resolvabale UID and extract more metadata from the referenced UID. Having a well defined UID pattern would prevent an explosion of rel values: rel-vcard, rel-vevent, etc.

* Efforts such as [http://unapi.info unAPI] have a real need for marking up identifiers so that they can be used for retrieving identified objects.

* Greasemonkey and other browser based scripts could make real use of URIs found in pages as opposed to resorting to elaborate regexen. See Jon Udell's [http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html LibraryLookup] project.

* GoogleScholar embed identifiers in their citations and it would enable moving citations from the browser to a citation manager greatly if there were a way to mark them up.

== Goals Requirements ==

* a method of publishing an asserted globally unique identifier for a piece of content or a referenced item

== Thoughts ==

=== UIDs that are URLs ===

It seems like in the 80% case (perhaps 99.99% case on the Web), a UID is going to be a URL, thus a common pattern will likely be things like:

<pre><nowiki>
<a class="url uid" href="http://example.com/contentspace/somenumber">the item</a>
</nowiki></pre>

=== SHOULD rather than MUST ===

A UID SHOULD be a URL rather than MUST. The UID microformat will ordinarily be a URL, but it should be flexible enough to allow it to contain non-network resolvable URIs.

=== UID + URL -> permalink? ===

Can you infer that if something is a URL and a UID that it is also a permalink? It seems so. I can't think of any semantic of "permalink" that isn't covered by the union of the semantics of URL and UID.

=== abbr pattern ===

Use the [[abbr-design-pattern]] to allow identifiers to be more fully described.
<pre>
<abbr class="uid" title="urn:isbn:0950788120">0 9507881-2-0</abbr>
</pre>

=== HTML ID attribute ===

How does/doesn't the ID attribute from HTML fit into all this? Can it be repurposed to help here?

== Proposals ==

=== Just use UID from hCard ===

* Tantek proposed that we see if we can reuse uid from [[hcard|hCard]], similar to how we have reused [[geo]] and [[adr]] from [[hcard|hCard]].
* In particular we should define per the RFC2426 and RFC2445 definitions of UID, and also state that UID identifies the singular thing which this microformat is about (primary reference). (Thanks Joe Andrieu for this wording).
* Since microformats are about things published on the *Web*, we can say:
** UIDs SHOULD be URLs and if you cannot use a URL (for whatever reason), then you SHOULD at least use a URI, thereby indicating our preference for UIDs which can be resolved to a network location, and barring that, UIDs which follow the URN registry.

=== Use rel-bookmark from hAtom ===
hAtom currently uses the HTML standard rel-bookmark to identify its bookmark. This appears to be precisely eqivalent to the class combination "uid url". This does not appear to permit non-url uids, but if we are identifying the authorative id of a piece of microformatted data that we already have in-hand a non-url uid may never be required. Non-url uids (eg isbn) can still appear in citation formats without affecting the development of this "identify myself" microformat.

If rel-bookmark is not appropriate for this format, we should consider retrofiting this format back to hAtom. It may be appropriate to replace rel-bookmark with the separate url and uid classes, or to allow either form to be used.

=== Create a URI microformat ===

* Xiaoming proposed leaving UID intact in hcalendar and hcard, because whatever written in rfc2426/rfc2445 and their examples cannot be easily changed, and they seem to work well with hcalendar/hcard. Instead a new "URI" microformat should be established for the purpose of indicating something *is* an identifier in general.In this case you can easily reference URI RFC and no further elaboration about persistence, resolvability or uniqueness will be necessary because these issues are addressed by various URI specifications.
** The problem with "just use URI" is that URI (or URL for that matter) merely is a *type* of data. What that data *means* to the microformat still needs additional semantics, and that's why we need a property name like UID (even if it is defined to be of type URI or URL) which specifies this particular semantic. Thanks to Joe Andrieu for asking the questions which lead to this clarification. - Tantek

== References ==
* [[adr]]
* [[geo]]
* [[hatom|hAtom]]
* [[hcard|hCard]]
* [[hcalendar|hCalendar]]
* [[abbr-design-pattern]]

== See Also ==
* [http://www.iana.org/assignments/urn-namespaces IANA URN Namespaces - RFC2141, RFC3406]
* [http://www.iana.org/assignments/uri-schemes.html IANA Uniform Resource Identifer (URI) Schemes]
* [http://ocoins.info COinS] for putting attaching openurl context objexts to a span.
* [http://unapi.info unAPI] has a technique for embedding IDs in html so that they can be retrieved from an unAPI service.
* [http://www.taguri.org/ Tag URI] an algorithm that lets people mint identifiers that no one else using the same algorithm could ever mint.

== Related Discussion ==
* [http://microformats.org/discuss/mail/microformats-discuss/2006-April/003726.html UID, URL, live microformats]
* [http://microformats.org/discuss/mail/microformats-discuss/2005-November/002046.html format for identifiers]

uid-brainstorming

2006-04-30T22:26:59Z

BenjaminCarlyle: Add rel-bookmark proposal

= UID Brainstorming =

This page is for brainstorming about ideas, proposals, constraints, requirements for a UID microformat.

== Authors ==

* Tantek Çelik
* Ed Summers

== Experience ==

* a microformat for indicating something *is* an identifier rather than the solved problem of providing a microformat *for* identifiers ([http://www.ietf.org/rfc/rfc2396.txt RFC 2396])

* Tantek has had conversations with LiveClipboard folks and upcoming.org who have had questions about how to do UID properly in hCard and hCalendar. So a separate microformat that those two could call out to would serve a real need.

* It would be useful for autodiscovery puposes to be able to follow a network resolvabale UID and extract more metadata from the referenced UID. Having a well defined UID pattern would prevent an explosion of rel values: rel-vcard, rel-vevent, etc.

* Efforts such as [http://unapi.info unAPI] have a real need for marking up identifiers so that they can be used for retrieving identified objects.

* Greasemonkey and other browser based scripts could make real use of URIs found in pages as opposed to resorting to elaborate regexen. See Jon Udell's [http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html LibraryLookup] project.

* GoogleScholar embed identifiers in their citations and it would enable moving citations from the browser to a citation manager greatly if there were a way to mark them up.

== Goals Requirements ==

* a method of publishing an asserted globally unique identifier for a piece of content or a referenced item

== Thoughts ==

=== UIDs that are URLs ===

It seems like in the 80% case (perhaps 99.99% case on the Web), a UID is going to be a URL, thus a common pattern will likely be things like:

<pre><nowiki>
<a class="url uid" href="http://example.com/contentspace/somenumber">the item</a>
</nowiki></pre>

=== SHOULD rather than MUST ===

A UID SHOULD be a URL rather than MUST. The UID microformat will ordinarily be a URL, but it should be flexible enough to allow it to contain non-network resolvable URIs.

=== UID + URL -> permalink? ===

Can you infer that if something is a URL and a UID that it is also a permalink? It seems so. I can't think of any semantic of "permalink" that isn't covered by the union of the semantics of URL and UID.

=== abbr pattern ===

Use the [[abbr-design-pattern]] to allow identifiers to be more fully described.
<pre>
<abbr class="uid" title="urn:isbn:0950788120">0 9507881-2-0</abbr>
</pre>

=== HTML ID attribute ===

How does/doesn't the ID attribute from HTML fit into all this? Can it be repurposed to help here?

== Proposals ==

=== Just use UID from hCard ===

* Tantek proposed that we see if we can reuse uid from [[hcard|hCard]], similar to how we have reused [[geo]] and [[adr]] from [[hcard|hCard]].
* In particular we should define per the RFC2426 and RFC2445 definitions of UID, and also state that UID identifies the singular thing which this microformat is about (primary reference). (Thanks Joe Andrieu for this wording).
* Since microformats are about things published on the *Web*, we can say:
** UIDs SHOULD be URLs and if you cannot use a URL (for whatever reason), then you SHOULD at least use a URI, thereby indicating our preference for UIDs which can be resolved to a network location, and barring that, UIDs which follow the URN registry.

=== Use rel-bookmark from hAtom ===
hAtom currently uses the HTML standard rel-bookmark to identify its bookmark. This appears to be precisely eqivalent to the class combination "uid url". This does not appear to permit non-url uids, but if we are identifying the authorative id of a piece of microformatted data that we already have in-hand a non-url uid may never be required. Non-url uids (eg isbn) can still appear in citation formats without affecting the development of this "identify myself" microformat.

If rel-bookmark is not appropriate for this format, we should consider retrofiting this format back to hAtom. It may be appropriate to replace rel-bookmark with the separate url and uid classes, or to allow either form to be used.

=== Create a URI microformat ===

* Xiaoming proposed leaving UID intact in hcalendar and hcard, because whatever written in rfc2426/rfc2445 and their examples cannot be easily changed, and they seem to work well with hcalendar/hcard. Instead a new "URI" microformat should be established for the purpose of indicating something *is* an identifier in general.In this case you can easily reference URI RFC and no further elaboration about persistence, resolvability or uniqueness will be necessary because these issues are addressed by various URI specifications.
** The problem with "just use URI" is that URI (or URL for that matter) merely is a *type* of data. What that data *means* to the microformat still needs additional semantics, and that's why we need a property name like UID (even if it is defined to be of type URI or URL) which specifies this particular semantic. Thanks to Joe Andrieu for asking the questions which lead to this clarification. - Tantek

== References ==
* [[adr]]
* [[geo]]
* [[hcard|hCard]]
* [[hcalendar|hCalendar]]
* [[abbr-design-pattern]]

== See Also ==
* [http://www.iana.org/assignments/urn-namespaces IANA URN Namespaces - RFC2141, RFC3406]
* [http://www.iana.org/assignments/uri-schemes.html IANA Uniform Resource Identifer (URI) Schemes]
* [http://ocoins.info COinS] for putting attaching openurl context objexts to a span.
* [http://unapi.info unAPI] has a technique for embedding IDs in html so that they can be retrieved from an unAPI service.
* [http://www.taguri.org/ Tag URI] an algorithm that lets people mint identifiers that no one else using the same algorithm could ever mint.

== Related Discussion ==
* [http://microformats.org/discuss/mail/microformats-discuss/2006-April/003726.html UID, URL, live microformats]
* [http://microformats.org/discuss/mail/microformats-discuss/2005-November/002046.html format for identifiers]

faq

2006-04-29T22:11:25Z

BenjaminCarlyle: Fix broken profile-uris link

<h1> Microformats FAQ </h1>

This page document frequently asked questions about microformats. For frequently asked questions from the [[press]], see [[press-faq]].

__TOC__

== wiki specific questions ==

Q: ''How do I create a username? Why won't it let me use my preferred username?''

A: First, read this: http://en.wikipedia.org/wiki/Wikipedia:Username . Second, real names are preferred to pseudonyms/handles etc. Real names encourage better transparency and accountability. Third, the most common problem creating a user name is forgetting to caplitalize the first letter of the user name. Try using a WikiCase version of your full name as username, e.g. RyanKing.

== Basic Microformat Questions ==

Q: ''Are microformats dependent upon (X)HTML?''

A: Microformats are made to be embeddable. They can be embedded in (X)HTML, RSS, Atom or anywhere (X)HTML is allowed.

Q: ''Microformats sound great. How can I help?''

A: First of all, take a look at http://microformats.org/discuss to see some ways to join the conversations about microformats.

Q: ''I'd like to make a donation to the microformat cause. How can I do this?''

A: Thank you for your willingness to support microformats. We've only recently started this site and have decided that while we are figuring out exactly how to accept donations, we will be passing along donations to other good causes. Please consider donating to another cause like Red Cross, perhaps directed to help victims of recent natural disasters.

Q: ''Which microformats have been implemented?''

See the [[implementations]] page.

Q: ''Which microformats should I implement?''

A: Chances are you that your website already has data very similar to several microformats. For example, you probably have people and/or their contact information somewhere. That information could be marked up with [[hcard]]. If you are publishing press releases, try using [[hatom]].

Q: ''Do you have any link badges I can add to my website/blog?''

A: Not yet, but we'll post them when we do...

Q. ''Are there any tools that support microformats?''

A. Yes... [[implementations]].

Q. ''What about using new URI schemes instead of class names, e.g. for geo information?''

A. In general, it is more work, and less content-publisher friendly, to ask them to use URI schemes instead of class names.

Authors aren't publishing links to geo information.

They're publishing *visible text* of [[geo]] information.

So the easiest thing to do, for the author, is to leave it as visible text.

Thus, it makes the most sense to do the simple thing of just wrapping that
visible text with a little bit of markup, rather than asking the author to
move (or copy) it into an attribute, which may or may not require a
reformatting of the data as well.

It would make sense from a usability persepective to hyperlink geo information to a maps page or something, so that clicking it actually does something. If you forced them to use a hypothetical "geo:" protocol instead, then that would interfere, since you can only hyperlink something to one destination.

Q: ''Who is the registrar for microformats?''

A: There is no central registry. Microformats are registered in a distributed manner using profiles. For more information on profiles see http://microformats.org/wiki/profile-uris and http://gmpg.org/xmdp/

Conflicts and interoperability are managed through social processes rather than a formal registry. Current microformat profiles can be found at http://gmpg.org, http://w3.org, and http://microformats.org.

Q: ''So multiple microformats with the same name can be valid?''

A: Yes. The community at microformats.org can hopefully play a role in determining which is preferred by bringing interested folks together in one place and helping them resolve that question. As long as each microformat maintains a valid profile, each can be used effectively.

== Specific Microformat Questions ==
If you have a question regarding a specific microformat, you may want to check the FAQ specific to that microformat.
* [[hatom-faq]]
* [[hcalendar-faq]]
* [[hcard-faq]]
* [[hreview-faq]]
* [[rel-faq]]
* [[rel-tag-faq]]
* [http://gmpg.org/xfn/faq xfn-faq]
* [[xfolk-faq]]
* [[xmdp-faq]]
* [[xoxo-faq]]

== Class interactions ==

Q. ''Are there issues with page styling when specific class values are used?''

A. There might be. However, any such issues can be easily (trivially) worked around by using contextual selectors.

Q. ''How does the use of class values for semantics interact with the use of class values for attaching CSS styles?''

A. The class attribute takes a space separated set of class names [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 HTML4 reference]. Thus both author and microformat defined class names may be used in the same class attribute. In addition, microformat class names provide the author with a consistent set of class names to use for styling. If the author is already using using specific class names, they can continue to do so, and include microformat class names. If the author is already using a class name that happens to also be a microformat class name, then the author may want to consider using contextual CSS class selectors to make sure that avoid any unintentional styling effects.

See also:
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]
* [http://tantek.com/log/2004/07.html#classmeaningnotshow Class For Meaning Not For Show]
* [http://www.meyerweb.com/eric/thoughts/2004/07/18/competent-classing Competant Classing], by Eric Meyer for discussion of choosing class names in (X)HTML
* [http://www.microformats.org/blog/2005/10/19/more-than-styling/ Class attributes are about more than styling] - Ryan King dispells common misconceptions about the ''HTML'' class attribute.

== <code><div></code> and <code><span></code> semantics ==

Q. Is it semantically meaningless to use divs?

A. Yes, both <code><div></code> and <code><span></code> have nearly no semantics. <code><div></code> can be used to represent a "division" of the page content. Similarly <code><span></code> can be used to reperesent that that "span" of text has some meaning, but the specifics of what that meaning is undefined by the <code><span></code>.

Q. Does the use of <code><div></code> and <code><span></code> elements add any semantics to web pages?

A. According to the [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.4 spec], <code><div></code> and <code><span></code> "offer a generic mechanism for adding structure to documents." Their only meaning is in dividing documents into sections, and as such, their presence implies that the content within has a specific, but undefined by the element markup, semantic. Thus they are nearly semantic-free.

Q. Why do the examples on the wiki use <code class="element"><span></code> and <code class="element"><div></code> for nearly everything?

A. <code class="element"><span></code> and <code class="element"><div></code> are generic elements in HTML. When you use microformats, you should pick the most specific semantic element available.

== Class semantics ==

Q. ''Do (X)HTML class names have semantics?''

A. The HTML4 specification does not define any particular class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], nor does it define any particular semantic for class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], except that they "may be used for general user agent processing" [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF]. However, the [http://www.w3.org/TR/WD-htmllink-970328#profile" draft of "Hypertext Links in HTML"], allows for a "profile" to define meanings for those classes. [http://gmpg.org/xmdp/ XMDP] is a format for defining meta data profiles for (X)HTML, and thus an XMDP profile can be used to define the meanings of class names.

See also:
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]
* [http://www.w3.org/TR/WD-htmllink-970328 Hypertext Links in HTML]

== Indicating a page contains microformat markup ==

Q. Is there a way to indicate that a given web page contains markup that conforms to one or more microformats?

A. The HTML HEAD element's '<code>profile</code>' attribute alerts applications to the potential presence of microformats. The [http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.4.4.3 W3C HTML Specification] describes more about the profile attribute, and the [http://gmpg.org/xmdp/description XMDP description] documents how it is used.

== Microformats and Spam ==

Q. Given that Google now looks at hidden content as potential spam, will microformats be considered spam?

A. Microformats aren't meant to disguise semantics -- only provide a mechanism for marking up the content you intend to make visible on a page, typically no more and no less. Where we embed semantic equivalents in the tags themselves (i.e. GMT times in abbr tags for times), it doesn't seem logical that such data could be considered spam.

hatom

2006-03-29T03:01:46Z

BenjaminCarlyle: Sound Advice is now hAtom 0.1

<h1> hAtom 0.1 </h1>

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.

__TOC__
== Draft Specification ==

=== Editor/Author ===
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix.com BlogMatrix, Inc.]

=== Contributors ===
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati, Inc.]

=== Copyright ===
{{MicroFormatCopyrightStatement2005}}

=== Patents ===
{{MicroFormatPatentStatement}}

== Introduction ==

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.

== Semantic XHTML Design Principles ==
{{semantic-xhtml-design-principles}}

== Format ==
=== In General ===
The [http://atomenabled.org/developers/syndication/#person Atom Syndication Format] provides the conceptual basis for this microformat, with the following caveats:

* Atom provides a lot more functionality that we need for a "blog post" microformat, so we've taken the minimal number of elements needed.
* the "logical" model of hAtom is that of Atom. If there is a conflict, Atom should be taken as correct.
* 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"

=== Schema ===
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]].

The hAtom schema consists of the following:

* hfeed ('''<code>hfeed</code>'''). optional.
* hentry ('''<code>hentry</code>''').
** '''<code>entry-title</code>'''. required. text.
** '''<code>entry-content</code>'''. required. text.
** '''<code>entry-summary</code>'''. optional. text.
** '''<code>updated</code>'''. required using [[datetime-design-pattern]].
** '''<code>published</code>'''. optional using [[datetime-design-pattern]].
** '''<code>author</code>'''. required using '''[[hcard|hCard]]'''.
** '''<code>bookmark</code>''' (permalink). optional, using '''[[rel-bookmark]]'''.
** tags. optional. keywords or phrases, using '''[[rel-tag]]'''.

Some required elements have defaults if missing, see below.

=== Field and Element Details ===

===== Feed =====
* a Feed element is identified by the class name <code>hfeed</code>
* 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]
* the Feed element is optional and, if missing, is assumed to be the page
* hAtom documents MAY have multiple Feed elements

===== Feed Category =====
* a Feed Category element is identified by [[rel-tag]]
* a Feed MAY have a Feed Category
* 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]
* Feed Category elements MUST appear inside a Feed element but not inside an Entry element
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code>

===== Entry =====
* an Entry element is identified by class name <code>hentry</code>
* 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]
* any microformat content inside a <code><blockquote></code> or <code><q></code> element within the Entry is should not be considered part of the Entry.
: ''This allows quoting other microformated data without worry of corrupting the model''

===== Entry Category =====
* an Entry Category element is identified by [[rel-tag]]
* an Entry MAY have an Entry Category
* 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]
* the [[rel-tag]] <code>href</code> encodes the atom <code>category:term</code>; the link text defines the atom <code>category:label</code>

===== Entry Title =====
* an Entry Title element is identified by the class name <code>entry-title</code>
* an Entry SHOULD have an Entry Title
* 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]
* if the Entry Title is missing, use
** the first <code><h#></code> element in the Entry, or
** the <code><title></code> of the page, if there is no enclosing Feed element, or
** assume it is the empty string

===== Entry Content =====
* an Entry Content element is identified by class name <code>entry-content</code>
* an Entry SHOULD have Entry Content
* an Entry Content element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#atomContent Atom content]
* 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
: ''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.''
* if the Entry Content is missing, assume it is the empty string

===== Entry Summary =====
* an Entry Summary element is identified by class name <code>entry-summary</code>
* 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]
* 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

===== Entry Permalink =====
* an Entry Permalink element is identified by [[rel-bookmark]]
* an Entry SHOULD have an Entry Permalink
* 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]
* 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

===== Entry Updated =====
* an Entry Updated element is identified by class name <code>updated</code>
* 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]
* an Entry SHOULD have an Entry Updated element
* use the [[datetime-design-pattern]] to encode the updated datetime
* if there is no Entry Updated element,
** use the Entry Published element, if present
** otherwise the page is invalid hAtom

===== Entry Published =====
* an Entry Published element is identified by the class name <code>published</code>
* 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]
* use the [[datetime-design-pattern]] to encode the published datetime

===== Entry Author =====
* an Entry Author element is represented by class name <code>author</code>
* 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]
* an Entry Author element MUST be encoded in an [[hcard|hCard]]
* an Entry Author element SHOULD be encoded in an <code><address></code> element
* an Entry SHOULD have at least one Entry Author element
* an Entry MAY have more than one Entry Author elements
* if the Entry Author is missing
** find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
** otherwise the entry is invalid hAtom

=== XMDP Profile ===
<pre>
<dl class="profile">
<dt>class</dt>
<dd><p>
<a rel="help" href="http://www.w3.org/TR/html401/struct/global.html#adef-class">
HTML4 definition of the 'class' attribute.</a>
This meta data profile defines some 'class' attribute values (class names)
and their meanings as suggested by a
<a href="http://www.w3.org/TR/WD-htmllink-970328#profile">
draft of "Hypertext Links in HTML"</a>.
<dl>
<dt>hfeed</dt>
<dd>
The concept of atom:feed from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>hentry</dt>
<dd>
The concept of atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-title</dt>
<dd>
The concept of atom:title inside of an atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-content</dt>
<dd>
The concept of atom:content from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>entry-summary</dt>
<dd>
The concept of atom:summary from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>bookmark</dt>
<dd>
The concept of atom:link (without any "rel") with an atom:entry from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>published</dt>
<dd>
The concept of atom:published from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>updated</dt>
<dd>
The concept of atom:updatedfrom
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
<dt>author</dt>
<dd>
The concept of atom:author from
<a href="http://www.atomenabled.org/developers/syndication/atom-format-spec.php">The Atom Syndication Format</a>,
constrained and modified as per the <a href="http://microformats.org/wiki/hatom">hAtom microformat spec</a>.
</dd>
</dl>
</dd>
</dl>
</pre>

== Examples ==

See [[hatom-examples]].

== Examples in the wild ==
This section is '''informative'''.

=== 0.1 hAtom implementations ===

* [http://ChunkySoup.net/ ChunkySoup.net] has redesigned using hAtom 0.1 and hCards on the entire site -- by [[User:ChrisCasciano|Chris Casciano]]
* [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])
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Sound Advice] (Benjamin Carlyle)

=== Pre 0.1 hAtom implementations ===
These pages conform to an older draft standard and need to be updated.

* [http://blog.davidjanes.com Ranting and Roaring] (David Janes)
* [http://www.myelin.co.nz/post/ Second p0st] (Phil Pearson)
* [http://rbach.priv.at/hAtom2Atom/Changelog/ hAtom2Atom.xsl’s Changelog] is published as hAtom and Atom.

== Implementations ==

This section is '''informative'''.

* [http://rbach.priv.at/hAtom2Atom/ hAtom2Atom.xsl] transforms hAtom to Atom (as the name suggests.)
* There is now an [http://www.lukearno.com/projects/hatom2atom/ hatom2atom proxy] that uses hAtom2Atom.xsl.
* [http://placenamehere.com/article/185/SubscribingTohAtomFeedsWithNetNewsWire Subscribe To hAtom] is a script that provides [http://ranchero.com/netnewswire/ NetNewsWire 2.x] users with the ability to subscribe to hAtom documents as they would any other feed. by [[User:ChrisCasciano|Chris Casciano]].

These pages are awaiting updating to 0.1:

* 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])
* 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]
* the [http://www.blogmatrix.com/tools/rewrite/ hAtom Template Rewriter] converts Blogger, MovableType and Wordpress templates into hAtom compatible ones -- (hopefully) without presentation impact

== References ==
=== Normative References ===
* [http://www.w3.org/TR/2002/REC-xhtml1-20020801/ XHTML 1.0 SE]
* [http://www.atomenabled.org/ Atom]
* [[hcard-parsing]]

=== Informative References ===

==== Specifications That Use hAtom ====

==== Similar Work ====

* [http://rdfs.org/sioc/ Semantically-Interlinked Online Communities (SIOC) RDF Ontology]

== Work in progress ==
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:

* [[blog-post-brainstorming|blog-post Brainstorming]]

=== Version 0.1 ===

Version 0.1 was released 28 February 2006.

== Discussions ==

* See [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

=== Q&A ===
* If you have any questions about hAtom, check the [[hatom-faq|hAtom FAQ]], and if you don't find answers, add your questions!

=== Issues ===
* Please add any issues with the specification to the separate [[hatom-issues|hAtom issues]] document.

==See Also==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-hints|hAtom Hints]] - help for implementors
* [[hatom-issues]] - problems? complaints? ideas? Put them here
* [[hatom-faq]] - knowledge base
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)

distributed-conversation-examples

2006-02-10T23:59:09Z

BenjaminCarlyle: href and quote example

= Distributed Conversation Examples=

This is an exploratory page to document various methods used to anotate online conversations both distributed and not. The purpose of the studies on this page is to serve as background for the design of a microformat to anotate distributed conversations on blogs and other online media.

see [[distributed-conversation-brainstorming]] for more discussion on this topic.
see [[distributed-conversation-formats]] for formats.

== Authors ==

* [[User:EranGloben|Eran Globen]]
* [[User:BenjaminCarlyle|Benjamin Carlyle]]
* ...

== Web Examples ==

=== Author, href and blockquote ===
<p>His column was picked up all over the web, including by Danny Ayers. He
dives into discussion about
<a href="http://dannyayers.com/archives/2006/01/10/new-data-languages-harmful/">
how to build an RDF model
</a>
,rather than an XML language:
</p>
<blockquote>
<p>
When working with RDF, my current feeling (could be wrong ;-) is that in most cases it’s probably best to initially make up
afresh a new representation that matches the domain model as closely as possible(/appropriate). Only then start looking to
replacing the new terms with established ones with matching semantics. But don’t see reusing things as more important than getting
an (appropriately) accurate model. (Different approaches are likely to be better for different cases, but as a loose guide I think
this works.)
</p>
</blockquote>

[http://www.soundadvice.id.au/blog/2006/01/15/#xmlLanguages source]

Danny Ayers is the author of the pieces being referenced. The href identifies an article the blockquote comes from. "How to build an RDF model" may be considered a short description of the link, however sometimes this text is as short as "writes".

=== Cite attribute in blockquote or quote ===
From <cite>[http://decafbad.com/blog/2006/01/19/use-delicious-to-build-share-reading-lists Les Orcahrd's 0xdecafbad]</cite>:
<blockquote cite="http://vrypan.net/log/archives/2006/01/19/delicious-as-fedd-manager/">As far as I know, the most popular link
managment tool is del.icio.us, a tool I love for its power and simplicity. del.icio.us allow you to export all your links in RSS
which is cool. So, I wrote a quick and dirty PHP script that converts this RSS export to an OPML list (see at the end of this
post).</blockquote>

<p><small style="text-align: right; display: block;">
Source: <a href="http://vrypan.net/log/archives/2006/01/19/delicious-as-fedd-manager/">
vrypan|net|log » del.icio.us as feed manager
</a>
</small></p>
The cite attribute of the blockquote tag is defined in many standards but is not well supported by browsers and is therefore hidden from the user. This requires the author to repeat its value later, in the form of a link.

A similar example from [http://theryanking.com/blog/archives/2006/01/25/blogging-as-religion/ Ryan King's blog]:
Intuitively, we’d expect a group to balance each other out, but
<q cite="http://en.wikipedia.org/wiki/Risky_shift">
people with relatively moderate viewpoints tend to assume that their groupmates hold more extreme views,
and to alter their own views in compensation
</q>
[<a href="http://en.wikipedia.org/wiki/Risky_shift">source</a>]

=== cite href ===
Another one from [http://theryanking.com/blog/archives/2005/01/31/things-to-say-when-you-are-losing-a-tech-argument/ Ryan King] (hopefully this is from before he discovered Tantek's presentation about markup).

<div class="entry">
<p>From <cite><a href="http://www.skirsch.com/humor/techarg.htm">
Things to say when you are losing a tech argument</a>
</cite>:</p>
<blockquote><p>
2.That’s been proven to be O(N^2) and we need a solution that’s O(NlogN).<br>
15. Oh, I played with that approach back as an undergrad. Got a D, too.<br>
18.That’s totally inefficient on modern hardware.<br>
26. No, no, no. It’s fairly important that the database be in THIRD NORMAL FORM.<br>
28. I don’t think that’s altogether clear. Please write it up in UML for me.<br>
39.This is all covered in Knuth, and we don’t have time to go over it again.<br>
65.Yes, but we’re standardizing on XML.
</p>
</blockquote>
</div>

Ryan uses the <CITE><A href="source">source name</A></CITE> structure.

=== href inside blockquote ===
From [http://www.stoweboyd.com/message/2006/01/umair_haque_on_.html Stowe Boyd]
<p>Umair Haque is worried that a steady diet of tech.memeorandum is making him stupid:</p>
<blockquote>
[from <a title="Bubblegeneration Strategy Lab" href="http://www.bubblegeneration.com/2006/01/problems-with-2.cfm">
The Problems with 2.0, pt 34514
</a>]
<p>
I luv Memeorandum and all it's reconstructor cousins. It's one of the first things of my reading list.
It's hugely slashed my search costs in finding new stuff.But there's a problem. Ever since I've started using
it to the point where it replaces many of my other sources, I have gotten stupider.I can feel it - I don't
think as fast, flexibly, or freely.
</p>
</blockquote>

The link to the quote's source is embedded inside the BLOCKQUOTE element as part of the text of the quote.

=== href and quote ===
<p>It is incorrect to say that software is
<a href="http://www.groklaw.net/article.php?story=20060111223959235"><q>just maths</q></a>,
and is therefore
not patentable...</p>

distributed-conversation-examples

2006-01-25T21:31:47Z

BenjaminCarlyle: Add examples from my blog

= Distributed Conversation =

This is an exploratory page to document various methods used to anotate online conversations both distributed and not. The purpose of the studies on this page is to serve as background for the design of a microformat to anotate distributed conversations on blogs and other online media.

see [[citation-brainstorming]] for more discussion on this topic.

== Authors ==

* [[User:EranGloben|Eran Globen]]
* [[User:BenjaminCarlyle|Benjamin Carlyle]]

== Examples of Related Solutions==
===Email/Usenet===
Email and Usenet both keep track of discussion threads in a non-central manner using headers and references to message IDs. Some common headers and their use are highlighted in [http://www.faqs.org/rfcs/rfc2076.html RFC2076 - Common Internet Message Headers] section 3.6:
* In-Reply-To - Reference to message which this message is a reply to.
* References - In e-mail: reference to other related messages, in Usenet News reference to replied-to-articles.
* See-Also - References to other related articles in Usenet News.
* Obsoletes - Reference to previous message being corrected and replaced.
* Supersedes - Commonly used in Usenet News in similar ways to the "Obsoletes" header described above. In Usenet News, however, Supersedes causes a full deletion of the replaced article in the server, while "Supersedes" and "Obsoletes" in e-mail is implemented in the client and often does not remove the old version of the text.
* Article-Updates - Only in Usenet News, similar to "Supersedes:" but does not cause the referenced article to be physically deleted.
* Article-Names - Reference to specially important articles for a particular Usenet Newsgroup.

===Thread Description Language===
Thread Description Language - TDL is an RDF vocabulary for describing threaded discussions, such as Usenet, weblogs, bulletin boards, and e-mail conversations.
* http://www.eyrie.org/~zednenem/2002/web-threads/
* http://www.eyrie.org/~zednenem/2002/wtprofile/
TDL v3 defines the following properties:
* Property tdl:discusses - Relates a Post to a resource it talks about
* Property tdl:follows - Indicates that this resource comes no earlier than the specified resource
* Property tdl:inThread - Relates a post to a thread which includes it
* Property tdl:mentions - Indicates that this resource refers to the specified resource
* Property tdl:respondsTo - Relates a post to its parent(s) in a discussion
* Property tdl:respondsNegativelyTo - Relates a post to a parent post which it dissents from or corrects
* Property tdl:respondsPositivelyTo - Relates a post to a parent post with which it concurs

'''Discussion of TDL'''

# respondsNegativelyTo, respondsPositivelyTo are beyond the scope of this spec. They can both be implemented using vote-links.
# Without those, respondsTo remains the main connector between posts in a thread.
# mentions and discusses seem to be splitting hairs. It appears that both of them can be replaced by using the CITE tag.
# follows seems to be designed for use in a central registry that tracks threads and therefore is useless for a distributed solution.

===IBIS - Issues Based Information Systems===
Kunz's Issue Based Information Systems (IBIS) provide a framework for collaborative understanding of the major issues and implications surrounding what are described as ``wicked problems'' (problems that lack a definitive formulation). Understanding is achieved by using hypertext components to create structured arguments surrounding the issues. (<cite>[http://www.weblogkitchen.com/wiki.cgi?GraphicalIbis Weblog Kitchen]</cite>)
* [http://dannyayers.com/xmlns/ibis/ IBIS vocabulary]
* [http://collab.blueoxen.net/forums/yak/2003-12/threads.html#00191 How to start an IBIS discussion in Email]
* [http://www.weblogkitchen.com/wiki.cgi?GraphicalIbis graphical IBIS (gIBIS)]
The hypertext model of IBIS consists of three node types:
1. issues
2. positions
3. arguments

Eight link types represent the allowable relationships between these nodes:
1. generalises
2. specialises
3. replaces
4. questions
5. is_suggested_by
6. responds_to
7. objects_to
8. supports

'''Discussion of IBIS'''

Similar to TDL, IBIS seems to tackle a bigger problem than the one discussed here.
* The different node types are not necessary for tracking a discussion thread. Tracking the flow of the conversation, the arguments and flow of ideas is a wider more complex issue than just gluing together disparate pieces of an online discussion.
* Link type such as "generalises" and "specialises" might be useful but seem to require a lot from the user. If we allow for inheritance of link type they could be used as optional parts of the format but it appears that we can do well enough without them.

== Examples of Use ==
From Email we get two basic relations between message:
* Reply - This message is a reply to the referenced message.
* Forward - This message forwards the referenced message to additional recipients.

From various publications (often of standards) we get:
* Updates/Obsoletes - This documents contains updates or even replaces the referenced document.

Citation of resources comes in several flavors:
* Quote
* Citing a reference
* Via link/Hat tip (mainly in blogs)

== Web Examples ==

=== Author, href and blockquote ===
<p>His column was picked up all over the web, including by Danny Ayers. He
dives into discussion about <a href="http://dannyayers.com/archives/2006/01/10/new-data-languages-harmful/">how to build an RDF model</a>,
rather than an XML language:
</p>

<blockquote>
<p>When working with RDF, my current feeling (could be wrong ;-) is that in most cases it’s probably best to initially make up afresh a new representation that matches the domain model as closely as possible(/appropriate). Only then start looking to replacing the new terms with established ones with matching semantics. But don’t see reusing things as more important than getting an (appropriately) accurate model. (Different approaches are likely to be better for different cases, but as a loose guide I think this works.)
</p>
</blockquote>

[http://www.soundadvice.id.au/blog/2006/01/15/#xmlLanguages source]

Danny Ayers is the author of the pieces being referenced. The href identifies an article the blockquote comes from. "How to build an RDF model" may be considered a short description of the link, however sometimes this text is as short as "writes".

distributed-conversation-brainstorming

2006-01-21T00:24:17Z

BenjaminCarlyle: When is a bare href (not) a citation?

=citeRel brainstorming=
Various parties have proposed microformats related to citations and distributed conversations. Ryan King and Eran Globen started with hVia (which became citeVia and later citeRel :-)). You can see the conversation in these blog posts:

People already cite their sources in their blog posts and it would be great (and shouldn't be too difficult) to track that information. In that vein, read [http://theryanking.com/blog/archives/2005/05/06/hvia/ this post] which covers the initial thinking on the topic. ([http://theryanking.com/blog/archives/2005/05/09/citevia/ This] was a followup post).

Later, [http://hellononline.com Eran] [http://hellonline.com/blog/?p=18 expanded the idea] to encompass not just via citations, but replies and updates as well. Follow up post [http://hellonline.com/blog/?p=19 here].

==Problem==
The basic idea we're trying to solve here is the tracking of distributed conversation- more specifically, distributed conversation between blog posts– the scope is intentionally limited here, though other aspects of distributed conversation are certainly important and related.

:A smaller portion of the problem is in identifying the most authoritative sources in a web-wide thread. In researching anything, the ability to identify a primary source is invaluable. Adding this kind of ordinality would add value to any list of related links such as a tag page.

::Finding an authoritative source is not a smaller problem, but a larger problem- you have to have the whole conversation graph in order to find the root nodes. --RyanKing

:Citing (quoting or refering to as an authoritative source or precedent) and hat-tipping (giving credit to a non-primary source for calling attention to a primary [authoritative] source) are certainly two different animals. Common etiquette suggests use of anchor tags because they can be actuated by the user.

:I dug around at [http://www.w3.org WC3] and found rel="cite" is ''already defined'' in the [http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-metaAttributes.html XHTML Metainformation Attributes Module]. In the [http://www.w3.org/TR/2005/WD-xhtml2-20050527/mod-hyperAttributes.html XHTML 2.0 Hypertext Attribute Collection], href and cite attributes are defined and may coexist but they behave differently: The href attribute "specifies a URI that is actuated when the element is activated." For the cite attribute, "User Agents MUST provide a means for the user to actuate the link."

::This has already been covered in the above blog posts. Admitedly, it needs to be brought into this document, though. --RyanKing

:Whereas authors in general like their work to be cited with hyperlinks, and whereas users can be counted upon to cite primary and non-primary sources simultaneously without differentiating them, and whereas the only difference between a primary citation and a non-primary citation is the potential for skipped vias when considered across a distributed conversation, and whereas the use of existing specifications is preferred to the creation of redundant systems, and whereas increasing attributes is less severe than increasing nested elements, I propose that good definition and use of rel="cite" will resolve the problem of crediting sources via anchors. <cite>Andy Skelton</cite>

::I see the conclusion as quite the opposite. Because rel="cite" *is* defined in XHTML2 drafts, and microformats allow you add rel values to HTML4/XHTML1 *now*, adopting the same convention makes a lot of sense.

::If anything it bolsters the case for rel="cite" (as opposed to some other value like rel="source").

::In a relCite microformat, you would define the "cite" value by normatively referencing XHTML2, rather than redefining it (even copy/pasting the definition from the XHTML2 spec -- though one could do so "informatively"), just like in [[hcard|hCard]], we define the properties by normatively referencing vCard. <cite>Tantek</cite>

:::[http://www.w3.org/TR/2005/WD-xhtml2-20050527/ XHTML 2.0] states that it "should in no way be considered stable, and should not be normatively referenced for any purposes whatsoever." <cite>Andy Skelton</cite>

:There is a related problem which is not exactly the same. Let's say that you have a bit of microformatted data which implies an assertion, and the asserter is the containing page. For example a relTag might have semantic value like "I claim that this object is a FOO." When that assertion is copied over to a new page, the identity of the asserter has to be made explicit: "according to the original containing page at BAR, this object is a FOO." Now let's say somebody copies over the copy. This might happen if there was a B-lister who had an entry picked up by an A-lister, and the A-lister's entry was then copied by a vast number of C-listers. (That's a typical pattern for data diffusion). For the data to keep its integrity, the source of the citation would always have to be the original containing page (the B-lister) rather than the containing page that the copy was fetched from (the A-lister). <cite>Lucas Gonze</cite>

::Lucas- that's why God invented <blockquote>. Content ''copied'' from one site to another should be quoted. --RyanKing

::The question isn't about whether something was copied but what the cite source is. This is a case where the difference between a primary citation and a non-primary citation affects the meaning of the data. <cite>Lucas Gonze</cite>

:I have a related problem that may shed some light on this one. I came to this page because I was just looking at a scientific journal citation and thought "that could be a microformat." There are already standard formats for citations of all sorts, including websites (e.g. [http://owl.english.purdue.edu/handouts/research/r_mla.html Modern Language Association]), so maybe converting these into microformats would solve the problem stated here, and more. -- Scott Reynen

== Nested cite/anchor tags ==

== rel="cite" / rev="cite" ==

This could be a way to indicate a citation of linked content, typically web pages (or portions thereof, like blog posts) but inclusive of any kind of resource with a URL. "Cite" is defined as "to quote or refer to as a precedent or authority."

By adding <code>rel="cite"</code> to a hyperlink, an author could indicate that the destination of that hyperlink is an authoritative source or a precedent to the current page. rel="cite" would be used whether an author cites by quotation:
<pre><blockquote>Our liberty depends on the freedom of the
press, and that cannot be limited without being lost.
<a href="http://en.wikiquote.org/wiki/Thomas_Jefferson" rel="cite">
Thomas Jefferson</a></blockquote></pre>
or by reference only:
<pre><a href="http://example.com/joeschmoe/article/99/" rel="cite">
Joe Schmoe's latest rant</a> is wrong, wrong, wrong...</pre>

<code>rel="cite"</code> hyperlinks are intended to be visible links on pages and posts. Note that other markup may be used to indicate citation:
<pre><blockquote cite="http://en.wikiquote.org/wiki/Thomas_Jefferson">
Our liberty depends on the freedom of the press, and that cannot be
limited without being lost.<cite>Thomas Jefferson</cite></blockquote></pre>
but User Agents are not compelled to expose a link to the cited resource. Hyperlinks are preferred by most authors because they afford the user easy access to the cited resource.

== citeRel vs. relCite ==
For basic structure and markup of citations it has been suggested that we use the following:
<pre>

<a rel="cite" href="source.url">source.title</a>
</pre>
instead of
<pre>

<cite><a href="source.url">source.title</a></cite>
</pre>

There are several reasons to prefer the citeRel form over the relCite form of markup:
# citeRel uses only existing XHTML elements and values where relCite uses a new rel value.
# citeRel is easily extensible without breaking it's existing meaning.

==When is a bare href (not) a citation==
A href is a citation when:
* A blog entry refers to another entry or to a presentation, then talks about that entry or presentation. eg "I believe it was more or less the same <a href="...">presentation</a> he gave at SxSW this year" [http://theryanking.com/blog/archives/2005/05/06/hvia/ Ryan King].

A href is not a citation when:
* A blog entry refers to the author of an entry or presentation using the author's homepage url, then talks about the entry or presentation. eg "For my Internet Systems Research class last night, we had <a href="...">Tantek Çelik</a> come speak on microformats" [http://theryanking.com/blog/archives/2005/05/06/hvia/ Ryan King]
* A blog provides a blog-roll, or "recent bookmarks" panel

==Additional Resources==
* Thread Description Language - TDL is an RDF vocabulary for describing threaded discussions, such as Usenet, weblogs, bulletin boards, and e-mail conversations.
** http://www.eyrie.org/~zednenem/2002/web-threads/
** http://www.eyrie.org/~zednenem/2002/wtprofile/

hatom-issues

2006-01-10T21:15:07Z

BenjaminCarlyle: Update votes

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]
* [http://www.dannyayers.com Danny Ayers]
* [http://tantek.com/ Tantek Çelik]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# <em>Not</em> to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave <em>identically</em> to what they before hAtom was applied.

= New Nomenclature =

[[User:DavidJanes|David Janes]] added this on 2006.01.03. Since we've decided that correspondence to Atom nomenclature is not going to happen, let's just decide on it here. I tried but probably haven't succeeded in pulling all the info from below up so feel free to add new things. Also feel free to change your vote if you see a consensus happening.

'''How to use this'''. If you like a particular use, place something like '<code>: +1 YourName</code>' following the name. Feel free to make as make negative votes. If you have something compelling to say, add it to the Discussion section that follows. Let's settle this out by, say the 10th of January 2006?

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

=== Discussion ===

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

== Entry (atom:entry) ==
* <code>class="entry</code> (Atom consistency)
: +1 MarkRickerby
* <code>class="atom-entry</code> (Atom consistency with prefix)
* <code>class="hentry</code> (h* uF consistency)
: +1 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])

=== Discussion ===

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]].

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.

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.

-Tantek

== Entry Title (atom:title) ==
* <code>class="title"</code> (Atom consistency)
: -1 Tantek. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>class="entry-title"</code> (Atom consistency, avoid hCard conflict)
: +½ Paul Bryson, clear=good / hyphenating=bad
* <code>class="heading"</code> (HTML)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (re-use from and consistency with vCalendar, iCalendar, hCalendar, hReview)
: -1 KevinMarks (clashes with atom)
* <code>class="headline"</code> what they're called in the News/Journalism industry
: +1 Tantek
: +1 KevinMarks
: +1 BenjaminCarlyle, atom:entry/title only
: +½ David Janes, atom:entry/title only
: +½ Paul Bryson, redundant?
* <code>class="fn"</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
: ±0 DavidJanes see my note below
: -1 Tantek (does not mean the "name" of the post/entry)
: +1 BenjaminCarlyle, atom:feed/title only

=== Discussion ===
BenjaminCarlyle: If one were to review a blog entry with hReview we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.

BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.

DavidJanes: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.

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].

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.

Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.

- Tantek

DavidJanes: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.

DavidJanes: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.

BenjaminCarlyle: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print.

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.

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.

DavidJanes: 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.

Paul Bryson: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse. Headline feels redundant with "heading", which is what the element should be. Regardless, this is probably the best of the available choices.

== Entry Content (atom:content) ==
* <code>class="content"</code> (Atom consistency)
: +1 Tantek
: +1 DavidJanes
: +1 BenjaminCarlyle
* <code>class="description"</code> (vCalendar, hCalendar, xFolk, hReview consistency)

=== Discussion ===
It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture. - Tantek

BenjaminCarlyle: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

== Entry Summary (atom:summary) ==
* <code>class="summary"</code> (re-use from and consistency with Atom)
* <code>class="content-summary"</code> (Atom consistency avoiding hCalendar conflict)
* <code>class="partial-description"</code>
* <code>class="excerpt"</code>
: +1 Tantek
: +1 BenjaminCarlyle
: +1 DavidJanes, my only concern being that they're not always excerpts
* <code>class="abstract"</code>
: +1 KevinMarks

=== Discussion ===
Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such. - Tantek

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 cna convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content' [[User:Kevin Marks|Kevin Marks]]

BenjaminCarlyle: I have been trying to convince meyself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com 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.

Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts.

In addition:
* WordPress user interface calls it "excerpt"
* MovableType user interface calls it "excerpt"
Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone. - Tantek

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

=== Discussion ===
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.

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

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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.

published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely. - Tantek

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>)" - BenjaminCarlyle

Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.

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.

- Tantek

DavidJanes: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards

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

=== Discussion ===
Paul Bryson: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.

BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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. -Tantek

From [[last-modified-brainstorming]] semantics:
"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."
- BenjaminCarlyle

They are both user defined values but *different* user defined values.

It is VERY important to note this distinction because Atom chose to note it.

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.

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.

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.

-Tantek

DavidJanes: we can make [[last-modified-brainstorming|last-modified]] consistent afterwards

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

=== Discussion ===
BenjaminCarlyle: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?

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. -Tantek

== Entry Contributor (atom:contributor) ==
: -1 Tantek
* <code>class="contibutor"</code> (Atom consistency)
: +1 Tantek
: +1 DavidJanes

=== Discussion ===
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"). -Tantek

DavidJanes: deferred

= Questions and Comments =

==Limitations==
There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl).
There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections.
The microformat would be much more useful with these capabilities added.
-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)

* We've deliberately restricted this to being a "blog post" microformat at this point to make the problem managable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detrement to this standard. -- DavidJanes
** You brought this microformat to my attention because you disagreed in priciple with the XOXO Blog Format (http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html)... yet the only tool that currently works with that format works with comments. note also that at ''least'' comment counts and links to comment sections are part of posts. If you don't want to encapsulate comments I suppose I understand that and can easily create my own format meant to be embedded in yours to facilitate this purpose :) -- [[User:Singpolyma|singpolyma]] 22:13, 3 Jan 2006 (PST)
** Where did I disagree in principle? A: I told you about the existence of hAtom. B: I mentioned several of the design goals for hAtom

In addition, note that frankly we don't care about invisible metadata, because most humans don't care about invisible metadata.

The info about a blog which is *visible* will likely be represented in hAtom if they pass the 80%+ test. To that extent, many blogs have visible title, description, author, and updated information. See [[blog-post-brainstorming]] for more on this. -Tantek

== Nomenclature ==

'''THIS SECTION IS CLOSED. ALL DISCUSSION OF NOMENCLATURE IS NOW MOVED [[hatom-issues#New_Nomenclature|HERE]].'''

Note: microformats [[naming-principles]] include a precise means for coming up with names which should work in the 90% case.

One point to raise for hAtom in particular - we don't simply omit spaces from multiword property names, we use hyphens. E.g. "given-name" and many others in [[hcard|hCard]].

=== Why atomentry? ===
;class="atomentry" (or rather, "atom-entry")
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

'''STATUS - RESOLVED'''. We're going with "entry".

:: Tantek: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
* atom-entry
* hentry
* vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Why atomfeed? ===
;class="atomfeed" (or rather, "atom-entry")
:As above on the atomprefix. But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

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

'''STATUS - PARTIALLY RESOLVED'''. We're going with "feed" IF and when the Feed element is used. When and where Feed is used at all is still under discussion in the mailing list as of 2005-12-26.

: Tantek: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
* atom-feed
* hfeed

=== Why rel="link" ? ===
I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
[[KevinMarks]]
* I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion -- [[DavidJanes]]
* Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom -- [[DavidJanes]]
* Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file. - Tantek
* OK, I'm happy with this -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.

* Tantek: agreed.

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

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'
* 'headline'
** as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]

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

* description, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. [[User:Kevin Marks|Kevin Marks]] 15:51, 31 Dec 2005 (PST)
** Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]]. See below for where to use "description". We must NOT use "description" to mean summary. - Tantek

* Depending on your interpretation, atom:summary could still be summary. Here is another option: subject (atom:title) -> summary (atom:summary) -> content (atom:content).

* atom:summary is described as abstract in

Tantek: We may want to avoid the use of 'summary' entirely within hAtom. Here are some alternatives:
* excerpt - in practice this is what most people provide instead of full text.
** +1 Tantek
* partial-description
* abstract - Rarely do bloggers actually provide abstracts different from the full text of their posts - this is so NOT the 80% (and thus should be rejected for microformat consideration), but see [http://microformats.org/wiki/blog-post-examples#Entry_contains_summary_content_only blog-post-examples] for some examples.
* content-summary

=== Why content? ===
The concept behind atom:content has precedent in earlier microformats derived from the iCalendar standard as "description".

=== Date and time names alternatives ===
* atom:updated
** VJOURNAL LAST-MODIFIED
*** (also used by HTTP -[[User:RobertBachmann|Robert Bachmann]])
** dtstamp
** dtupdated
* atom:published
** VJOURNAL CREATED
** dtpublished

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

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

"Pushed back" is the wrong direction here.

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

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

- Tantek

== hCards ==

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

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as “The "atom:author" element is a Person construct that indicates the author of the entry or feed.” and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><addr class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI

'''STATUS - OPEN'''. "MAY" is the answer.

Tantek: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.

DavidJanes: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:

<pre><nowiki>
<div class="author">bonehead</div>
</nowiki></pre>

has an assumed defined mapping to

<pre><nowiki>
<div class="author vcard"><span class="fn">bonehead</div></div>
</nowiki></pre>

Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmicly.

== Comparisons ==

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

-- [[Ernie Prabhakar]]

* See the [[#Purpose]] section above. Basically that drove the design decision for the naming [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We're sticking with atom terminology (entry, content, summary).

See above as David says. The atom terminology is both problematic, and doesn't make sufficient reuse of existing microformat terminology. As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience. - Tantek

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

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

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

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

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

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

-- BenjaminCarlyle

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

See the [[mfo-examples]] document, and add further thoughts on this matter there. -- Tantek

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

IMHO yes. -- Tantek

A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.

rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.

rel-tag permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

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

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

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

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

=== last-modified ===
Does this specification depend on acceptance of a hAtom-compatible last-modified?

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

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

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

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

hatom-issues

2006-01-09T21:07:24Z

BenjaminCarlyle: Fix url formatting

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]
* [http://www.dannyayers.com Danny Ayers]
* [http://tantek.com/ Tantek Çelik]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# <em>Not</em> to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave <em>identically</em> to what they before hAtom was applied.

= New Nomenclature =

[[User:DavidJanes|David Janes]] added this on 2006.01.03. Since we've decided that correspondence to Atom nomenclature is not going to happen, let's just decide on it here. I tried but probably haven't succeeded in pulling all the info from below up so feel free to add new things. Also feel free to change your vote if you see a consensus happening.

'''How to use this'''. If you like a particular use, place something like '<code>: +1 YourName</code>' following the name. Feel free to make as make negative votes. If you have something compelling to say, add it to the Discussion section that follows. Let's settle this out by, say the 10th of January 2006?

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

=== Discussion ===

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

== Entry (atom:entry) ==
* <code>class="entry</code> (Atom consistency)
: +1 MarkRickerby
* <code>class="atom-entry</code> (Atom consistency with prefix)
* <code>class="hentry</code> (h* uF consistency)
: +1 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])

=== Discussion ===

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]].

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.

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.

-Tantek

== Entry Title (atom:title) ==
* <code>class="title"</code> (Atom consistency)
: -1 Tantek. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>class="entry-title"</code> (Atom consistency, avoid hCard conflict)
* <code>class="heading"</code> (HTML)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (re-use from and consistency with vCalendar, iCalendar, hCalendar, hReview)
: -1 KevinMarks (clashes with atom)
* <code>class="headline"</code> what they're called in the News/Journalism industry
: +1 Tantek
: +1 KevinMarks
: +1 BenjaminCarlyle, atom:entry/title only
* <code>class="fn"</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
: ±0 DavidJanes see my note below
: -1 Tantek (does not mean the "name" of the post/entry)
: +1 BenjaminCarlyle, atom:feed/title only

=== Discussion ===
BenjaminCarlyle: If one were to review a blog entry with hReview we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.

BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.

DavidJanes: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.

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].

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.

Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.

- Tantek

DavidJanes: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.

DavidJanes: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.

BenjaminCarlyle: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print.

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.

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.

== Entry Content (atom:content) ==
* <code>class="content"</code> (Atom consistency)
: +1 Tantek
: +1 DavidJanes
* <code>class="description"</code> (vCalendar, hCalendar, xFolk, hReview consistency)

=== Discussion ===
It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture. - Tantek

BenjaminCarlyle: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

== Entry Summary (atom:summary) ==
* <code>class="summary"</code> (re-use from and consistency with Atom)
* <code>class="content-summary"</code> (Atom consistency avoiding hCalendar conflict)
* <code>class="partial-description"</code>
* <code>class="excerpt"</code>
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="abstract"</code>
: +1 KevinMarks

=== Discussion ===
Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such. - Tantek

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 cna convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content' [[User:Kevin Marks|Kevin Marks]]

BenjaminCarlyle: I have been trying to convince meyself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com 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.

Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts.

In addition:
* WordPress user interface calls it "excerpt"
* MovableType user interface calls it "excerpt"
Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone. - Tantek

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

=== Discussion ===
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.

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

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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.

published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely. - Tantek

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>)" - BenjaminCarlyle

Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.

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.

- Tantek

== Entry Updated (atom:updated) ==
* <code>class="updated"</code> (Atom consistency)
: +1 Tantek
* <code>class="dtupdated"</code> (Atom consistency with "dt" unofficial pattern)
* <code>class="last-modified"</code>

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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. -Tantek

From [[last-modified-brainstorming]] semantics:
"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."
- BenjaminCarlyle

They are both user defined values but *different* user defined values.

It is VERY important to note this distinction because Atom chose to note it.

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.

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.

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.

-Tantek

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

=== Discussion ===
BenjaminCarlyle: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?

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. -Tantek

== Entry Contributor (atom:contributor) ==
: -1 Tantek
* <code>class="contibutor"</code> (Atom consistency)
: +1 Tantek

=== Discussion ===
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"). -Tantek

= Questions and Comments =

==Limitations==
There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl).
There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections.
The microformat would be much more useful with these capabilities added.
-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)

* We've deliberately restricted this to being a "blog post" microformat at this point to make the problem managable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detrement to this standard. -- DavidJanes
** You brought this microformat to my attention because you disagreed in priciple with the XOXO Blog Format (http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html)... yet the only tool that currently works with that format works with comments. note also that at ''least'' comment counts and links to comment sections are part of posts. If you don't want to encapsulate comments I suppose I understand that and can easily create my own format meant to be embedded in yours to facilitate this purpose :) -- [[User:Singpolyma|singpolyma]] 22:13, 3 Jan 2006 (PST)
** Where did I disagree in principle? A: I told you about the existence of hAtom. B: I mentioned several of the design goals for hAtom

In addition, note that frankly we don't care about invisible metadata, because most humans don't care about invisible metadata.

The info about a blog which is *visible* will likely be represented in hAtom if they pass the 80%+ test. To that extent, many blogs have visible title, description, author, and updated information. See [[blog-post-brainstorming]] for more on this. -Tantek

== Nomenclature ==

Note: microformats [[naming-principles]] include a precise means for coming up with names which should work in the 90% case.

One point to raise for hAtom in particular - we don't simply omit spaces from multiword property names, we use hyphens. E.g. "given-name" and many others in [[hcard|hCard]].

=== Why atomentry? ===
;class="atomentry" (or rather, "atom-entry")
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

'''STATUS - RESOLVED'''. We're going with "entry".

:: Tantek: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
* atom-entry
* hentry
* vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Why atomfeed? ===
;class="atomfeed" (or rather, "atom-entry")
:As above on the atomprefix. But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

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

'''STATUS - PARTIALLY RESOLVED'''. We're going with "feed" IF and when the Feed element is used. When and where Feed is used at all is still under discussion in the mailing list as of 2005-12-26.

: Tantek: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
* atom-feed
* hfeed

=== Why rel="link" ? ===
I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
[[KevinMarks]]
* I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion -- [[DavidJanes]]
* Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom -- [[DavidJanes]]
* Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file. - Tantek
* OK, I'm happy with this -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.

* Tantek: agreed.

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

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'
* 'headline'
** as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]

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

* description, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. [[User:Kevin Marks|Kevin Marks]] 15:51, 31 Dec 2005 (PST)
** Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]]. See below for where to use "description". We must NOT use "description" to mean summary. - Tantek

* Depending on your interpretation, atom:summary could still be summary. Here is another option: subject (atom:title) -> summary (atom:summary) -> content (atom:content).

* atom:summary is described as abstract in

Tantek: We may want to avoid the use of 'summary' entirely within hAtom. Here are some alternatives:
* excerpt - in practice this is what most people provide instead of full text.
** +1 Tantek
* partial-description
* abstract - Rarely do bloggers actually provide abstracts different from the full text of their posts - this is so NOT the 80% (and thus should be rejected for microformat consideration), but see [http://microformats.org/wiki/blog-post-examples#Entry_contains_summary_content_only blog-post-examples] for some examples.
* content-summary

=== Why content? ===
The concept behind atom:content has precedent in earlier microformats derived from the iCalendar standard as "description".

=== Date and time names alternatives ===
* atom:updated
** VJOURNAL LAST-MODIFIED
*** (also used by HTTP -[[User:RobertBachmann|Robert Bachmann]])
** dtstamp
** dtupdated
* atom:published
** VJOURNAL CREATED
** dtpublished

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

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

"Pushed back" is the wrong direction here.

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

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

- Tantek

== hCards ==

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

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as “The "atom:author" element is a Person construct that indicates the author of the entry or feed.” and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><addr class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI

'''STATUS - OPEN'''. "MAY" is the answer.

Tantek: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.

DavidJanes: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:

<pre><nowiki>
<div class="author">bonehead</div>
</nowiki></pre>

has an assumed defined mapping to

<pre><nowiki>
<div class="author vcard"><span class="fn">bonehead</div></div>
</nowiki></pre>

Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmicly.

== Comparisons ==

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

-- [[Ernie Prabhakar]]

* See the [[#Purpose]] section above. Basically that drove the design decision for the naming [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We're sticking with atom terminology (entry, content, summary).

See above as David says. The atom terminology is both problematic, and doesn't make sufficient reuse of existing microformat terminology. As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience. - Tantek

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

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

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

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

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

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

-- BenjaminCarlyle

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

See the [[mfo-examples]] document, and add further thoughts on this matter there. -- Tantek

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

IMHO yes. -- Tantek

A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.

rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.

rel-tag permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

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

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

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

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

=== last-modified ===
Does this specification depend on acceptance of a hAtom-compatible last-modified?

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

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

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

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

hatom-issues

2006-01-09T21:04:33Z

BenjaminCarlyle: Atom and entry titles should be different things

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]
* [http://www.dannyayers.com Danny Ayers]
* [http://tantek.com/ Tantek Çelik]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# <em>Not</em> to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave <em>identically</em> to what they before hAtom was applied.

= New Nomenclature =

[[User:DavidJanes|David Janes]] added this on 2006.01.03. Since we've decided that correspondence to Atom nomenclature is not going to happen, let's just decide on it here. I tried but probably haven't succeeded in pulling all the info from below up so feel free to add new things. Also feel free to change your vote if you see a consensus happening.

'''How to use this'''. If you like a particular use, place something like '<code>: +1 YourName</code>' following the name. Feel free to make as make negative votes. If you have something compelling to say, add it to the Discussion section that follows. Let's settle this out by, say the 10th of January 2006?

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

=== Discussion ===

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

== Entry (atom:entry) ==
* <code>class="entry</code> (Atom consistency)
: +1 MarkRickerby
* <code>class="atom-entry</code> (Atom consistency with prefix)
* <code>class="hentry</code> (h* uF consistency)
: +1 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])

=== Discussion ===

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]].

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.

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.

-Tantek

== Entry Title (atom:title) ==
* <code>class="title"</code> (Atom consistency)
: -1 Tantek. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>class="entry-title"</code> (Atom consistency, avoid hCard conflict)
* <code>class="heading"</code> (HTML)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (re-use from and consistency with vCalendar, iCalendar, hCalendar, hReview)
: -1 KevinMarks (clashes with atom)
* <code>class="headline"</code> what they're called in the News/Journalism industry
: +1 Tantek
: +1 KevinMarks
: +1 BenjaminCarlyle, atom:entry/title only
* <code>class="fn"</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
: ±0 DavidJanes see my note below
: -1 Tantek (does not mean the "name" of the post/entry)
: +1 BenjaminCarlyle, atom:feed/title only

=== Discussion ===
BenjaminCarlyle: If one were to review a blog entry with hReview we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.

BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.

DavidJanes: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.

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].

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.

Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.

- Tantek

DavidJanes: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.

DavidJanes: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.

BenjaminCarlyle: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/|changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/|date]). Headline is a good substitute at the entry level, and has a clear analogue in print.

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.

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.

== Entry Content (atom:content) ==
* <code>class="content"</code> (Atom consistency)
: +1 Tantek
: +1 DavidJanes
* <code>class="description"</code> (vCalendar, hCalendar, xFolk, hReview consistency)

=== Discussion ===
It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture. - Tantek

BenjaminCarlyle: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

== Entry Summary (atom:summary) ==
* <code>class="summary"</code> (re-use from and consistency with Atom)
* <code>class="content-summary"</code> (Atom consistency avoiding hCalendar conflict)
* <code>class="partial-description"</code>
* <code>class="excerpt"</code>
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="abstract"</code>
: +1 KevinMarks

=== Discussion ===
Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such. - Tantek

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 cna convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content' [[User:Kevin Marks|Kevin Marks]]

BenjaminCarlyle: I have been trying to convince meyself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com 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.

Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts.

In addition:
* WordPress user interface calls it "excerpt"
* MovableType user interface calls it "excerpt"
Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone. - Tantek

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

=== Discussion ===
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.

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

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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.

published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely. - Tantek

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>)" - BenjaminCarlyle

Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.

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.

- Tantek

== Entry Updated (atom:updated) ==
* <code>class="updated"</code> (Atom consistency)
: +1 Tantek
* <code>class="dtupdated"</code> (Atom consistency with "dt" unofficial pattern)
* <code>class="last-modified"</code>

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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. -Tantek

From [[last-modified-brainstorming]] semantics:
"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."
- BenjaminCarlyle

They are both user defined values but *different* user defined values.

It is VERY important to note this distinction because Atom chose to note it.

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.

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.

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.

-Tantek

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

=== Discussion ===
BenjaminCarlyle: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?

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. -Tantek

== Entry Contributor (atom:contributor) ==
: -1 Tantek
* <code>class="contibutor"</code> (Atom consistency)
: +1 Tantek

=== Discussion ===
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"). -Tantek

= Questions and Comments =

==Limitations==
There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl).
There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections.
The microformat would be much more useful with these capabilities added.
-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)

* We've deliberately restricted this to being a "blog post" microformat at this point to make the problem managable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detrement to this standard. -- DavidJanes
** You brought this microformat to my attention because you disagreed in priciple with the XOXO Blog Format (http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html)... yet the only tool that currently works with that format works with comments. note also that at ''least'' comment counts and links to comment sections are part of posts. If you don't want to encapsulate comments I suppose I understand that and can easily create my own format meant to be embedded in yours to facilitate this purpose :) -- [[User:Singpolyma|singpolyma]] 22:13, 3 Jan 2006 (PST)
** Where did I disagree in principle? A: I told you about the existence of hAtom. B: I mentioned several of the design goals for hAtom

In addition, note that frankly we don't care about invisible metadata, because most humans don't care about invisible metadata.

The info about a blog which is *visible* will likely be represented in hAtom if they pass the 80%+ test. To that extent, many blogs have visible title, description, author, and updated information. See [[blog-post-brainstorming]] for more on this. -Tantek

== Nomenclature ==

Note: microformats [[naming-principles]] include a precise means for coming up with names which should work in the 90% case.

One point to raise for hAtom in particular - we don't simply omit spaces from multiword property names, we use hyphens. E.g. "given-name" and many others in [[hcard|hCard]].

=== Why atomentry? ===
;class="atomentry" (or rather, "atom-entry")
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

'''STATUS - RESOLVED'''. We're going with "entry".

:: Tantek: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
* atom-entry
* hentry
* vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Why atomfeed? ===
;class="atomfeed" (or rather, "atom-entry")
:As above on the atomprefix. But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

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

'''STATUS - PARTIALLY RESOLVED'''. We're going with "feed" IF and when the Feed element is used. When and where Feed is used at all is still under discussion in the mailing list as of 2005-12-26.

: Tantek: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
* atom-feed
* hfeed

=== Why rel="link" ? ===
I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
[[KevinMarks]]
* I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion -- [[DavidJanes]]
* Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom -- [[DavidJanes]]
* Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file. - Tantek
* OK, I'm happy with this -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.

* Tantek: agreed.

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

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'
* 'headline'
** as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]

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

* description, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. [[User:Kevin Marks|Kevin Marks]] 15:51, 31 Dec 2005 (PST)
** Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]]. See below for where to use "description". We must NOT use "description" to mean summary. - Tantek

* Depending on your interpretation, atom:summary could still be summary. Here is another option: subject (atom:title) -> summary (atom:summary) -> content (atom:content).

* atom:summary is described as abstract in

Tantek: We may want to avoid the use of 'summary' entirely within hAtom. Here are some alternatives:
* excerpt - in practice this is what most people provide instead of full text.
** +1 Tantek
* partial-description
* abstract - Rarely do bloggers actually provide abstracts different from the full text of their posts - this is so NOT the 80% (and thus should be rejected for microformat consideration), but see [http://microformats.org/wiki/blog-post-examples#Entry_contains_summary_content_only blog-post-examples] for some examples.
* content-summary

=== Why content? ===
The concept behind atom:content has precedent in earlier microformats derived from the iCalendar standard as "description".

=== Date and time names alternatives ===
* atom:updated
** VJOURNAL LAST-MODIFIED
*** (also used by HTTP -[[User:RobertBachmann|Robert Bachmann]])
** dtstamp
** dtupdated
* atom:published
** VJOURNAL CREATED
** dtpublished

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

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

"Pushed back" is the wrong direction here.

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

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

- Tantek

== hCards ==

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

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as “The "atom:author" element is a Person construct that indicates the author of the entry or feed.” and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><addr class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI

'''STATUS - OPEN'''. "MAY" is the answer.

Tantek: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.

DavidJanes: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:

<pre><nowiki>
<div class="author">bonehead</div>
</nowiki></pre>

has an assumed defined mapping to

<pre><nowiki>
<div class="author vcard"><span class="fn">bonehead</div></div>
</nowiki></pre>

Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmicly.

== Comparisons ==

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

-- [[Ernie Prabhakar]]

* See the [[#Purpose]] section above. Basically that drove the design decision for the naming [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We're sticking with atom terminology (entry, content, summary).

See above as David says. The atom terminology is both problematic, and doesn't make sufficient reuse of existing microformat terminology. As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience. - Tantek

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

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

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

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

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

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

-- BenjaminCarlyle

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

See the [[mfo-examples]] document, and add further thoughts on this matter there. -- Tantek

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

IMHO yes. -- Tantek

A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.

rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.

rel-tag permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

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

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

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

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

=== last-modified ===
Does this specification depend on acceptance of a hAtom-compatible last-modified?

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

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

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

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

last-modified-brainstorming

2006-01-09T07:00:32Z

BenjaminCarlyle: last-modified is used by hCalendar

= "Last-modified" Brainstorming =

== Purpose ==
To specify the date of publication and the date of modification of a web page (or a part thereof) in a way that is both readable for humans and machines.

== Authors ==
* [[User:RobertBachmann|Robert Bachmann]]
* [[User:RyanKing|Ryan King]]

== Semantics ==
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. --RyanKing

== Possible class names ==

=== Class name considerations ===
==== Class names for the date of publication ====
* “date”: Dublin Core
* “published”: Atom
* “dtpublished”: As suggested by Paul Bryson for [[hatom|hAtom]]. See http://microformats.org/discuss/mail/microformats-discuss/2005-December/002520.html

==== Class names for the date of the last modification ====
* “last-modified”: “Last-Modified” used by HTTP 1.0 and 1.1, hCalendar
* “modified”: Dublin Core
* “updated”: Atom 1.0 syndication specification

=== Different class name for page specific and item specific dates? ===

For example “page-last-modified” is used to indicate the last modification date of a page and “last-modified” for the last modification date of a specific item*.
However, this seems to be not a good idea. Other microformats leave it to the parser to pick the scope of the element, e.g. [[rel-tag]].

See http://microformats.org/discuss/mail/microformats-discuss/2005-August/000726.html for a related discussion.

<nowiki>*</nowiki> This specific item is marked-up with a microformat, e.g: a microformat to describe blog posts may use “last-modified” to indicate when a blog post was last modified.

== Possible date formats ==

See [[datetime-design-pattern]].


<span id="proposal"> </span>

= Proposal (2nd, strawman) =
== Purpose ==

Many web pages (and parts thereof) state their publication and/or modification date in a human readable way. This proposed microformat specifies how this can be done in a fashion that is both human- and machine-readable.

=== Specifying the date of publication ===

The date of publication is enclosed by <code><abbr class="date-published<sup>[[#footnote1|1]]</sup>" title="''Date in ISO format''">''Date in arbitrary format''</abbr></code>, e.g:

<code><p>Published on <abbr class="date-published<sup>[[#footnote1|1]]</sup>" title="2005-12-29T14:39:12+0100">Thursday, December 29, 2005 02:39:12 a.m.</abbr>.</p></code>.

=== Specifying the date of modification ===

The date of modification is enclosed by <code><abbr class="date-modified<sup>[[#footnote1|1]]</sup>" title="''Date in ISO format''">''Date in arbitary format''</abbr></code>, e.g:

<code><p>Last modified on <abbr class="date-modified<sup>[[#footnote1|1]]</sup>" title="2005-12-29T14:39:12+0100">Thursday, December 29, 2005 02:39:12 a.m.</abbr>.</p></code>.

If no date of modification is present the parsers MAY use the date of publication as the date of the last modification.

==== <del> and <ins> ====
Authors MAY also use <code><del></code> and <code><ins></code> to denote the date of
modification, e.g:
<code><del class="date-modified<sup>[[#footnote1|1]]</sup>" datetime="2005-12-29T14:39:12+0100">wrong words</del></code>.
The class value "date-modified<sup>[[#footnote1|1]]</sup>" is implied for every <code><del></code> and <code><ins></code>
element which has a <code>datetime</code> attribute.

=== Multiple dates in a page (or a part thereof) ===

If multiple dates of publication are present on a page (or a part thereof)
the ''youngest'' date SHOULD be interpreted as the date of publication.

If multiple dates of modification are present on a page (or a part thereof)
the ''oldest'' date SHOULD be interpreted as the date of modification.

<sup id="footnote1">1</sup> This class name is just a placeholder which will be replaced once we know a suitable name.

== Related ==
* ←[[last-modified-formats]]
* [[datetime-design-pattern]]

hatom-issues

2006-01-09T06:51:10Z

BenjaminCarlyle: last-updated aspires to cover atom:updated

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]
* [http://www.dannyayers.com Danny Ayers]
* [http://tantek.com/ Tantek Çelik]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# <em>Not</em> to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave <em>identically</em> to what they before hAtom was applied.

= New Nomenclature =

[[User:DavidJanes|David Janes]] added this on 2006.01.03. Since we've decided that correspondence to Atom nomenclature is not going to happen, let's just decide on it here. I tried but probably haven't succeeded in pulling all the info from below up so feel free to add new things. Also feel free to change your vote if you see a consensus happening.

'''How to use this'''. If you like a particular use, place something like '<code>: +1 YourName</code>' following the name. Feel free to make as make negative votes. If you have something compelling to say, add it to the Discussion section that follows. Let's settle this out by, say the 10th of January 2006?

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

=== Discussion ===

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

== Entry (atom:entry) ==
* <code>class="entry</code> (Atom consistency)
: +1 MarkRickerby
* <code>class="atom-entry</code> (Atom consistency with prefix)
* <code>class="hentry</code> (h* uF consistency)
: +1 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])

=== Discussion ===

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]].

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.

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.

-Tantek

== Entry Title (atom:title) ==
* <code>class="title"</code> (Atom consistency)
: -1 Tantek. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>class="entry-title"</code> (Atom consistency, avoid hCard conflict)
* <code>class="heading"</code> (HTML)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (hReview consistency)
: -1 KevinMarks (clashes with atom)
* <code>class="headline"</code> what they're called in the News/Journalism industry
: +1 Tantek
: +1 KevinMarks
* <code>class="fn"</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
: ±0 DavidJanes see my note below
: -1 Tantek (does not mean the "name" of the post/entry)

=== Discussion ===
BenjaminCarlyle: If one were to review a blog entry with hReview we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.

BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.

DavidJanes: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.

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].

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.

Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.

- Tantek

DavidJanes: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.

DavidJanes: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.

== Entry Content (atom:content) ==
* <code>class="content"</code> (Atom consistency)
: +1 Tantek
: +1 DavidJanes
* <code>class="description"</code> (vCalendar, hCalendar, xFolk, hReview consistency)

=== Discussion ===
It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture. - Tantek

BenjaminCarlyle: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

== Entry Summary (atom:summary) ==
* <code>class="summary"</code> (Atom consistency)
* <code>class="content-summary"</code> (Atom consistency avoiding hCalendar conflict)
* <code>class="partial-description"</code>
* <code>class="excerpt"</code>
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="abstract"</code>
: +1 KevinMarks

=== Discussion ===
Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such. - Tantek

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 cna convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content' [[User:Kevin Marks|Kevin Marks]]

BenjaminCarlyle: I have been trying to convince meyself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com 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.

Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts.

In addition:
* WordPress user interface calls it "excerpt"
* MovableType user interface calls it "excerpt"
Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone. - Tantek

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

=== Discussion ===
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.

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

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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.

published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely. - Tantek

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>)" - BenjaminCarlyle

== Entry Updated (atom:updated) ==
* <code>class="updated"</code> (Atom consistency)
: +1 Tantek
* <code>class="dtupdated"</code> (Atom consistency with "dt" unofficial pattern)
* <code>class="last-modified"</code>

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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. -Tantek

From [[last-modified-brainstorming]] semantics:
"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."
- BenjaminCarlyle

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

=== Discussion ===
BenjaminCarlyle: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?

My point is that in practice (>80% case again), contributor is not used. Thus we should consider excluding 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. -Tantek

== Entry Contributor (atom:contributor) ==
: -1 Tantek
* <code>class="contibutor"</code> (Atom consistency)
: +1 Tantek

=== Discussion ===
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"). -Tantek

= Questions and Comments =

==Limitations==
There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl).
There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections.
The microformat would be much more useful with these capabilities added.
-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)

* We've deliberately restricted this to being a "blog post" microformat at this point to make the problem managable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detrement to this standard. -- DavidJanes
** You brought this microformat to my attention because you disagreed in priciple with the XOXO Blog Format (http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html)... yet the only tool that currently works with that format works with comments. note also that at ''least'' comment counts and links to comment sections are part of posts. If you don't want to encapsulate comments I suppose I understand that and can easily create my own format meant to be embedded in yours to facilitate this purpose :) -- [[User:Singpolyma|singpolyma]] 22:13, 3 Jan 2006 (PST)
** Where did I disagree in principle? A: I told you about the existence of hAtom. B: I mentioned several of the design goals for hAtom

In addition, note that frankly we don't care about invisible metadata, because most humans don't care about invisible metadata.

The info about a blog which is *visible* will likely be represented in hAtom if they pass the 80%+ test. To that extent, many blogs have visible title, description, author, and updated information. See [[blog-post-brainstorming]] for more on this. -Tantek

== Nomenclature ==

Note: microformats [[naming-principles]] include a precise means for coming up with names which should work in the 90% case.

One point to raise for hAtom in particular - we don't simply omit spaces from multiword property names, we use hyphens. E.g. "given-name" and many others in [[hcard|hCard]].

=== Why atomentry? ===
;class="atomentry" (or rather, "atom-entry")
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

'''STATUS - RESOLVED'''. We're going with "entry".

:: Tantek: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
* atom-entry
* hentry
* vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Why atomfeed? ===
;class="atomfeed" (or rather, "atom-entry")
:As above on the atomprefix. But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

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

'''STATUS - PARTIALLY RESOLVED'''. We're going with "feed" IF and when the Feed element is used. When and where Feed is used at all is still under discussion in the mailing list as of 2005-12-26.

: Tantek: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
* atom-feed
* hfeed

=== Why rel="link" ? ===
I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
[[KevinMarks]]
* I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion -- [[DavidJanes]]
* Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom -- [[DavidJanes]]
* Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file. - Tantek
* OK, I'm happy with this -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.

* Tantek: agreed.

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

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'
* 'headline'
** as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]

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

* description, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. [[User:Kevin Marks|Kevin Marks]] 15:51, 31 Dec 2005 (PST)
** Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]]. See below for where to use "description". We must NOT use "description" to mean summary. - Tantek

* Depending on your interpretation, atom:summary could still be summary. Here is another option: subject (atom:title) -> summary (atom:summary) -> content (atom:content).

* atom:summary is described as abstract in

Tantek: We may want to avoid the use of 'summary' entirely within hAtom. Here are some alternatives:
* excerpt - in practice this is what most people provide instead of full text.
** +1 Tantek
* partial-description
* abstract - Rarely do bloggers actually provide abstracts different from the full text of their posts - this is so NOT the 80% (and thus should be rejected for microformat consideration), but see [http://microformats.org/wiki/blog-post-examples#Entry_contains_summary_content_only blog-post-examples] for some examples.
* content-summary

=== Why content? ===
The concept behind atom:content has precedent in earlier microformats derived from the iCalendar standard as "description".

=== Date and time names alternatives ===
* atom:updated
** VJOURNAL LAST-MODIFIED
*** (also used by HTTP -[[User:RobertBachmann|Robert Bachmann]])
** dtstamp
** dtupdated
* atom:published
** VJOURNAL CREATED
** dtpublished

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

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

"Pushed back" is the wrong direction here.

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

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

- Tantek

== hCards ==

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

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as “The "atom:author" element is a Person construct that indicates the author of the entry or feed.” and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><addr class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI

'''STATUS - OPEN'''. "MAY" is the answer.

Tantek: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.

DavidJanes: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:

<pre><nowiki>
<div class="author">bonehead</div>
</nowiki></pre>

has an assumed defined mapping to

<pre><nowiki>
<div class="author vcard"><span class="fn">bonehead</div></div>
</nowiki></pre>

Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmicly.

== Comparisons ==

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

-- [[Ernie Prabhakar]]

* See the [[#Purpose]] section above. Basically that drove the design decision for the naming [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We're sticking with atom terminology (entry, content, summary).

See above as David says. The atom terminology is both problematic, and doesn't make sufficient reuse of existing microformat terminology. As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience. - Tantek

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

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

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

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

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

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

-- BenjaminCarlyle

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

See the [[mfo-examples]] document, and add further thoughts on this matter there. -- Tantek

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

IMHO yes. -- Tantek

A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.

rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.

rel-tag permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

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

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

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

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

=== last-modified ===
Does this specification depend on acceptance of a hAtom-compatible last-modified?

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

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

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

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

hatom-issues

2006-01-09T06:49:40Z

BenjaminCarlyle: Add name

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]
* [http://www.dannyayers.com Danny Ayers]
* [http://tantek.com/ Tantek Çelik]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# <em>Not</em> to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave <em>identically</em> to what they before hAtom was applied.

= New Nomenclature =

[[User:DavidJanes|David Janes]] added this on 2006.01.03. Since we've decided that correspondence to Atom nomenclature is not going to happen, let's just decide on it here. I tried but probably haven't succeeded in pulling all the info from below up so feel free to add new things. Also feel free to change your vote if you see a consensus happening.

'''How to use this'''. If you like a particular use, place something like '<code>: +1 YourName</code>' following the name. Feel free to make as make negative votes. If you have something compelling to say, add it to the Discussion section that follows. Let's settle this out by, say the 10th of January 2006?

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

=== Discussion ===

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

== Entry (atom:entry) ==
* <code>class="entry</code> (Atom consistency)
: +1 MarkRickerby
* <code>class="atom-entry</code> (Atom consistency with prefix)
* <code>class="hentry</code> (h* uF consistency)
: +1 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])

=== Discussion ===

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]].

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.

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.

-Tantek

== Entry Title (atom:title) ==
* <code>class="title"</code> (Atom consistency)
: -1 Tantek. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>class="entry-title"</code> (Atom consistency, avoid hCard conflict)
* <code>class="heading"</code> (HTML)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (hReview consistency)
: -1 KevinMarks (clashes with atom)
* <code>class="headline"</code> what they're called in the News/Journalism industry
: +1 Tantek
: +1 KevinMarks
* <code>class="fn"</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
: ±0 DavidJanes see my note below
: -1 Tantek (does not mean the "name" of the post/entry)

=== Discussion ===
BenjaminCarlyle: If one were to review a blog entry with hReview we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.

BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.

DavidJanes: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.

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].

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.

Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.

- Tantek

DavidJanes: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.

DavidJanes: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.

== Entry Content (atom:content) ==
* <code>class="content"</code> (Atom consistency)
: +1 Tantek
: +1 DavidJanes
* <code>class="description"</code> (vCalendar, hCalendar, xFolk, hReview consistency)

=== Discussion ===
It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture. - Tantek

BenjaminCarlyle: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

== Entry Summary (atom:summary) ==
* <code>class="summary"</code> (Atom consistency)
* <code>class="content-summary"</code> (Atom consistency avoiding hCalendar conflict)
* <code>class="partial-description"</code>
* <code>class="excerpt"</code>
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="abstract"</code>
: +1 KevinMarks

=== Discussion ===
Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such. - Tantek

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 cna convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content' [[User:Kevin Marks|Kevin Marks]]

BenjaminCarlyle: I have been trying to convince meyself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com 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.

Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts.

In addition:
* WordPress user interface calls it "excerpt"
* MovableType user interface calls it "excerpt"
Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone. - Tantek

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

=== Discussion ===
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.

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

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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.

published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely. - Tantek

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>)" - BenjaminCarlyle

== Entry Updated (atom:updated) ==
* <code>class="updated"</code> (Atom consistency)
: +1 Tantek
* <code>class="dtupdated"</code> (Atom consistency with "dt" unofficial pattern)
* <code>class="last-modified"</code>

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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. -Tantek

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

=== Discussion ===
BenjaminCarlyle: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?

My point is that in practice (>80% case again), contributor is not used. Thus we should consider excluding 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. -Tantek

== Entry Contributor (atom:contributor) ==
: -1 Tantek
* <code>class="contibutor"</code> (Atom consistency)
: +1 Tantek

=== Discussion ===
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"). -Tantek

= Questions and Comments =

==Limitations==
There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl).
There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections.
The microformat would be much more useful with these capabilities added.
-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)

* We've deliberately restricted this to being a "blog post" microformat at this point to make the problem managable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detrement to this standard. -- DavidJanes
** You brought this microformat to my attention because you disagreed in priciple with the XOXO Blog Format (http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html)... yet the only tool that currently works with that format works with comments. note also that at ''least'' comment counts and links to comment sections are part of posts. If you don't want to encapsulate comments I suppose I understand that and can easily create my own format meant to be embedded in yours to facilitate this purpose :) -- [[User:Singpolyma|singpolyma]] 22:13, 3 Jan 2006 (PST)
** Where did I disagree in principle? A: I told you about the existence of hAtom. B: I mentioned several of the design goals for hAtom

In addition, note that frankly we don't care about invisible metadata, because most humans don't care about invisible metadata.

The info about a blog which is *visible* will likely be represented in hAtom if they pass the 80%+ test. To that extent, many blogs have visible title, description, author, and updated information. See [[blog-post-brainstorming]] for more on this. -Tantek

== Nomenclature ==

Note: microformats [[naming-principles]] include a precise means for coming up with names which should work in the 90% case.

One point to raise for hAtom in particular - we don't simply omit spaces from multiword property names, we use hyphens. E.g. "given-name" and many others in [[hcard|hCard]].

=== Why atomentry? ===
;class="atomentry" (or rather, "atom-entry")
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

'''STATUS - RESOLVED'''. We're going with "entry".

:: Tantek: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
* atom-entry
* hentry
* vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Why atomfeed? ===
;class="atomfeed" (or rather, "atom-entry")
:As above on the atomprefix. But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

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

'''STATUS - PARTIALLY RESOLVED'''. We're going with "feed" IF and when the Feed element is used. When and where Feed is used at all is still under discussion in the mailing list as of 2005-12-26.

: Tantek: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
* atom-feed
* hfeed

=== Why rel="link" ? ===
I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
[[KevinMarks]]
* I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion -- [[DavidJanes]]
* Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom -- [[DavidJanes]]
* Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file. - Tantek
* OK, I'm happy with this -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.

* Tantek: agreed.

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

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'
* 'headline'
** as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]

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

* description, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. [[User:Kevin Marks|Kevin Marks]] 15:51, 31 Dec 2005 (PST)
** Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]]. See below for where to use "description". We must NOT use "description" to mean summary. - Tantek

* Depending on your interpretation, atom:summary could still be summary. Here is another option: subject (atom:title) -> summary (atom:summary) -> content (atom:content).

* atom:summary is described as abstract in

Tantek: We may want to avoid the use of 'summary' entirely within hAtom. Here are some alternatives:
* excerpt - in practice this is what most people provide instead of full text.
** +1 Tantek
* partial-description
* abstract - Rarely do bloggers actually provide abstracts different from the full text of their posts - this is so NOT the 80% (and thus should be rejected for microformat consideration), but see [http://microformats.org/wiki/blog-post-examples#Entry_contains_summary_content_only blog-post-examples] for some examples.
* content-summary

=== Why content? ===
The concept behind atom:content has precedent in earlier microformats derived from the iCalendar standard as "description".

=== Date and time names alternatives ===
* atom:updated
** VJOURNAL LAST-MODIFIED
*** (also used by HTTP -[[User:RobertBachmann|Robert Bachmann]])
** dtstamp
** dtupdated
* atom:published
** VJOURNAL CREATED
** dtpublished

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

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

"Pushed back" is the wrong direction here.

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

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

- Tantek

== hCards ==

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

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as “The "atom:author" element is a Person construct that indicates the author of the entry or feed.” and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><addr class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI

'''STATUS - OPEN'''. "MAY" is the answer.

Tantek: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.

DavidJanes: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:

<pre><nowiki>
<div class="author">bonehead</div>
</nowiki></pre>

has an assumed defined mapping to

<pre><nowiki>
<div class="author vcard"><span class="fn">bonehead</div></div>
</nowiki></pre>

Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmicly.

== Comparisons ==

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

-- [[Ernie Prabhakar]]

* See the [[#Purpose]] section above. Basically that drove the design decision for the naming [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We're sticking with atom terminology (entry, content, summary).

See above as David says. The atom terminology is both problematic, and doesn't make sufficient reuse of existing microformat terminology. As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience. - Tantek

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

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

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

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

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

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

-- BenjaminCarlyle

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

See the [[mfo-examples]] document, and add further thoughts on this matter there. -- Tantek

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

IMHO yes. -- Tantek

A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.

rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.

rel-tag permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

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

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

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

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

=== last-modified ===
Does this specification depend on acceptance of a hAtom-compatible last-modified?

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

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

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

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

hatom-issues

2006-01-09T06:49:19Z

BenjaminCarlyle: last-modified currently aspires to partial page update

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]
* [http://www.dannyayers.com Danny Ayers]
* [http://tantek.com/ Tantek Çelik]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# <em>Not</em> to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave <em>identically</em> to what they before hAtom was applied.

= New Nomenclature =

[[User:DavidJanes|David Janes]] added this on 2006.01.03. Since we've decided that correspondence to Atom nomenclature is not going to happen, let's just decide on it here. I tried but probably haven't succeeded in pulling all the info from below up so feel free to add new things. Also feel free to change your vote if you see a consensus happening.

'''How to use this'''. If you like a particular use, place something like '<code>: +1 YourName</code>' following the name. Feel free to make as make negative votes. If you have something compelling to say, add it to the Discussion section that follows. Let's settle this out by, say the 10th of January 2006?

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

=== Discussion ===

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

== Entry (atom:entry) ==
* <code>class="entry</code> (Atom consistency)
: +1 MarkRickerby
* <code>class="atom-entry</code> (Atom consistency with prefix)
* <code>class="hentry</code> (h* uF consistency)
: +1 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])

=== Discussion ===

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]].

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.

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.

-Tantek

== Entry Title (atom:title) ==
* <code>class="title"</code> (Atom consistency)
: -1 Tantek. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>class="entry-title"</code> (Atom consistency, avoid hCard conflict)
* <code>class="heading"</code> (HTML)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (hReview consistency)
: -1 KevinMarks (clashes with atom)
* <code>class="headline"</code> what they're called in the News/Journalism industry
: +1 Tantek
: +1 KevinMarks
* <code>class="fn"</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
: ±0 DavidJanes see my note below
: -1 Tantek (does not mean the "name" of the post/entry)

=== Discussion ===
BenjaminCarlyle: If one were to review a blog entry with hReview we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.

BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.

DavidJanes: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.

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].

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.

Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.

- Tantek

DavidJanes: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.

DavidJanes: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.

== Entry Content (atom:content) ==
* <code>class="content"</code> (Atom consistency)
: +1 Tantek
: +1 DavidJanes
* <code>class="description"</code> (vCalendar, hCalendar, xFolk, hReview consistency)

=== Discussion ===
It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture. - Tantek

BenjaminCarlyle: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

== Entry Summary (atom:summary) ==
* <code>class="summary"</code> (Atom consistency)
* <code>class="content-summary"</code> (Atom consistency avoiding hCalendar conflict)
* <code>class="partial-description"</code>
* <code>class="excerpt"</code>
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="abstract"</code>
: +1 KevinMarks

=== Discussion ===
Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such. - Tantek

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 cna convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content' [[User:Kevin Marks|Kevin Marks]]

BenjaminCarlyle: I have been trying to convince meyself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com 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.

Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts.

In addition:
* WordPress user interface calls it "excerpt"
* MovableType user interface calls it "excerpt"
Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone. - Tantek

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

=== Discussion ===
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.

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

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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.

published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely. - Tantek

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>)"

== Entry Updated (atom:updated) ==
* <code>class="updated"</code> (Atom consistency)
: +1 Tantek
* <code>class="dtupdated"</code> (Atom consistency with "dt" unofficial pattern)
* <code>class="last-modified"</code>

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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. -Tantek

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

=== Discussion ===
BenjaminCarlyle: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?

My point is that in practice (>80% case again), contributor is not used. Thus we should consider excluding 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. -Tantek

== Entry Contributor (atom:contributor) ==
: -1 Tantek
* <code>class="contibutor"</code> (Atom consistency)
: +1 Tantek

=== Discussion ===
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"). -Tantek

= Questions and Comments =

==Limitations==
There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl).
There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections.
The microformat would be much more useful with these capabilities added.
-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)

* We've deliberately restricted this to being a "blog post" microformat at this point to make the problem managable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detrement to this standard. -- DavidJanes
** You brought this microformat to my attention because you disagreed in priciple with the XOXO Blog Format (http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html)... yet the only tool that currently works with that format works with comments. note also that at ''least'' comment counts and links to comment sections are part of posts. If you don't want to encapsulate comments I suppose I understand that and can easily create my own format meant to be embedded in yours to facilitate this purpose :) -- [[User:Singpolyma|singpolyma]] 22:13, 3 Jan 2006 (PST)
** Where did I disagree in principle? A: I told you about the existence of hAtom. B: I mentioned several of the design goals for hAtom

In addition, note that frankly we don't care about invisible metadata, because most humans don't care about invisible metadata.

The info about a blog which is *visible* will likely be represented in hAtom if they pass the 80%+ test. To that extent, many blogs have visible title, description, author, and updated information. See [[blog-post-brainstorming]] for more on this. -Tantek

== Nomenclature ==

Note: microformats [[naming-principles]] include a precise means for coming up with names which should work in the 90% case.

One point to raise for hAtom in particular - we don't simply omit spaces from multiword property names, we use hyphens. E.g. "given-name" and many others in [[hcard|hCard]].

=== Why atomentry? ===
;class="atomentry" (or rather, "atom-entry")
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

'''STATUS - RESOLVED'''. We're going with "entry".

:: Tantek: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
* atom-entry
* hentry
* vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Why atomfeed? ===
;class="atomfeed" (or rather, "atom-entry")
:As above on the atomprefix. But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

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

'''STATUS - PARTIALLY RESOLVED'''. We're going with "feed" IF and when the Feed element is used. When and where Feed is used at all is still under discussion in the mailing list as of 2005-12-26.

: Tantek: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
* atom-feed
* hfeed

=== Why rel="link" ? ===
I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
[[KevinMarks]]
* I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion -- [[DavidJanes]]
* Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom -- [[DavidJanes]]
* Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file. - Tantek
* OK, I'm happy with this -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.

* Tantek: agreed.

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

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'
* 'headline'
** as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]

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

* description, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. [[User:Kevin Marks|Kevin Marks]] 15:51, 31 Dec 2005 (PST)
** Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]]. See below for where to use "description". We must NOT use "description" to mean summary. - Tantek

* Depending on your interpretation, atom:summary could still be summary. Here is another option: subject (atom:title) -> summary (atom:summary) -> content (atom:content).

* atom:summary is described as abstract in

Tantek: We may want to avoid the use of 'summary' entirely within hAtom. Here are some alternatives:
* excerpt - in practice this is what most people provide instead of full text.
** +1 Tantek
* partial-description
* abstract - Rarely do bloggers actually provide abstracts different from the full text of their posts - this is so NOT the 80% (and thus should be rejected for microformat consideration), but see [http://microformats.org/wiki/blog-post-examples#Entry_contains_summary_content_only blog-post-examples] for some examples.
* content-summary

=== Why content? ===
The concept behind atom:content has precedent in earlier microformats derived from the iCalendar standard as "description".

=== Date and time names alternatives ===
* atom:updated
** VJOURNAL LAST-MODIFIED
*** (also used by HTTP -[[User:RobertBachmann|Robert Bachmann]])
** dtstamp
** dtupdated
* atom:published
** VJOURNAL CREATED
** dtpublished

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

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

"Pushed back" is the wrong direction here.

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

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

- Tantek

== hCards ==

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

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as “The "atom:author" element is a Person construct that indicates the author of the entry or feed.” and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><addr class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI

'''STATUS - OPEN'''. "MAY" is the answer.

Tantek: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.

DavidJanes: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:

<pre><nowiki>
<div class="author">bonehead</div>
</nowiki></pre>

has an assumed defined mapping to

<pre><nowiki>
<div class="author vcard"><span class="fn">bonehead</div></div>
</nowiki></pre>

Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmicly.

== Comparisons ==

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

-- [[Ernie Prabhakar]]

* See the [[#Purpose]] section above. Basically that drove the design decision for the naming [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We're sticking with atom terminology (entry, content, summary).

See above as David says. The atom terminology is both problematic, and doesn't make sufficient reuse of existing microformat terminology. As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience. - Tantek

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

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

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

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

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

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

-- BenjaminCarlyle

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

See the [[mfo-examples]] document, and add further thoughts on this matter there. -- Tantek

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

IMHO yes. -- Tantek

A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.

rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.

rel-tag permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

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

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

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

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

=== last-modified ===
Does this specification depend on acceptance of a hAtom-compatible last-modified?

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

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

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

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

hatom-issues

2006-01-06T20:50:26Z

BenjaminCarlyle: Remove premature headline vote

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]
* [http://www.dannyayers.com Danny Ayers]
* [http://tantek.com/ Tantek Çelik]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# <em>Not</em> to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave <em>identically</em> to what they before hAtom was applied.

= New Nomenclature =

[[User:DavidJanes|David Janes]] added this on 2006.01.03. Since we've decided that correspondence to Atom nomenclature is not going to happen, let's just decide on it here. I tried but probably haven't succeeded in pulling all the info from below up so feel free to add new things. Also feel free to change your vote if you see a consensus happening.

'''How to use this'''. If you like a particular use, place something like '<code>: +1 YourName</code>' following the name. Feel free to make as make negative votes. If you have something compelling to say, add it to the Discussion section that follows. Let's settle this out by, say the 10th of January 2006?

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

=== Discussion ===

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

== Entry (atom:entry) ==
* <code>class="entry</code> (Atom consistency)
: +1 MarkRickerby
* <code>class="atom-entry</code> (Atom consistency with prefix)
* <code>class="hentry</code> (h* uF consistency)
: +1 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])

=== Discussion ===

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]].

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.

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.

-Tantek

== Entry Title (atom:title) ==
* <code>class="title"</code> (Atom consistency)
: -1 Tantek. Already defined to mean something else in [[hcard|hCard]]. The same term should not be used to mean different things.
* <code>class="entry-title"</code> (Atom consistency, avoid hCard conflict)
* <code>class="heading"</code> (HTML)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (hReview consistency)
: -1 KevinMarks (clashes with atom)
* <code>class="headline"</code> what they're called in the News/Journalism industry
: +1 Tantek
: +1 KevinMarks
* <code>class="fn"</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
: ±0 DavidJanes see my note below
: -1 Tantek (does not mean the "name" of the post/entry)

=== Discussion ===
BenjaminCarlyle: If one were to review a blog entry with hReview we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.

BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.

DavidJanes: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.

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].

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.

Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.

- Tantek

DavidJanes: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.

DavidJanes: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.

== Entry Content (atom:content) ==
* <code>class="content"</code> (Atom consistency)
: +1 Tantek
: +1 DavidJanes
* <code>class="description"</code> (vCalendar, hCalendar, xFolk, hReview consistency)

=== Discussion ===
It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture. - Tantek

BenjaminCarlyle: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

== Entry Summary (atom:summary) ==
* <code>class="summary"</code> (Atom consistency)
* <code>class="content-summary"</code> (Atom consistency avoiding hCalendar conflict)
* <code>class="partial-description"</code>
* <code>class="excerpt"</code>
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="abstract"</code>
: +1 KevinMarks

=== Discussion ===
Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such. - Tantek

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 cna convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content' [[User:Kevin Marks|Kevin Marks]]

BenjaminCarlyle: I have been trying to convince meyself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com 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.

Benjamin is correct. The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts.

In addition:
* WordPress user interface calls it "excerpt"
* MovableType user interface calls it "excerpt"
Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter. Atom should have chosen "excerpt" as well based on this reason alone. - Tantek

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

=== Discussion ===
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.

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

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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.

published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely. - Tantek

== Entry Updated (atom:updated) ==
* <code>class="updated"</code> (Atom consistency)
: +1 Tantek
* <code>class="dtupdated"</code> (Atom consistency with "dt" unofficial pattern)
* <code>class="last-modified"</code>

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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. -Tantek

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

=== Discussion ===
BenjaminCarlyle: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?

My point is that in practice (>80% case again), contributor is not used. Thus we should consider excluding 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. -Tantek

== Entry Contributor (atom:contributor) ==
: -1 Tantek
* <code>class="contibutor"</code> (Atom consistency)
: +1 Tantek

=== Discussion ===
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"). -Tantek

= Questions and Comments =

==Limitations==
There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl).
There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections.
The microformat would be much more useful with these capabilities added.
-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)

* We've deliberately restricted this to being a "blog post" microformat at this point to make the problem managable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detrement to this standard. -- DavidJanes
** You brought this microformat to my attention because you disagreed in priciple with the XOXO Blog Format (http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html)... yet the only tool that currently works with that format works with comments. note also that at ''least'' comment counts and links to comment sections are part of posts. If you don't want to encapsulate comments I suppose I understand that and can easily create my own format meant to be embedded in yours to facilitate this purpose :) -- [[User:Singpolyma|singpolyma]] 22:13, 3 Jan 2006 (PST)
** Where did I disagree in principle? A: I told you about the existence of hAtom. B: I mentioned several of the design goals for hAtom

In addition, note that frankly we don't care about invisible metadata, because most humans don't care about invisible metadata.

The info about a blog which is *visible* will likely be represented in hAtom if they pass the 80%+ test. To that extent, many blogs have visible title, description, author, and updated information. See [[blog-post-brainstorming]] for more on this. -Tantek

== Nomenclature ==

Note: microformats [[naming-principles]] include a precise means for coming up with names which should work in the 90% case.

One point to raise for hAtom in particular - we don't simply omit spaces from multiword property names, we use hyphens. E.g. "given-name" and many others in [[hcard|hCard]].

=== Why atomentry? ===
;class="atomentry" (or rather, "atom-entry")
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

'''STATUS - RESOLVED'''. We're going with "entry".

:: Tantek: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
* atom-entry
* hentry
* vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Why atomfeed? ===
;class="atomfeed" (or rather, "atom-entry")
:As above on the atomprefix. But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

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

'''STATUS - PARTIALLY RESOLVED'''. We're going with "feed" IF and when the Feed element is used. When and where Feed is used at all is still under discussion in the mailing list as of 2005-12-26.

: Tantek: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
* atom-feed
* hfeed

=== Why rel="link" ? ===
I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
[[KevinMarks]]
* I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion -- [[DavidJanes]]
* Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom -- [[DavidJanes]]
* Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file. - Tantek
* OK, I'm happy with this -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.

* Tantek: agreed.

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

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'
* 'headline'
** as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]

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

* description, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. [[User:Kevin Marks|Kevin Marks]] 15:51, 31 Dec 2005 (PST)
** Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]]. See below for where to use "description". We must NOT use "description" to mean summary. - Tantek

* Depending on your interpretation, atom:summary could still be summary. Here is another option: subject (atom:title) -> summary (atom:summary) -> content (atom:content).

* atom:summary is described as abstract in

Tantek: We may want to avoid the use of 'summary' entirely within hAtom. Here are some alternatives:
* excerpt - in practice this is what most people provide instead of full text.
** +1 Tantek
* partial-description
* abstract - Rarely do bloggers actually provide abstracts different from the full text of their posts - this is so NOT the 80% (and thus should be rejected for microformat consideration), but see [http://microformats.org/wiki/blog-post-examples#Entry_contains_summary_content_only blog-post-examples] for some examples.
* content-summary

=== Why content? ===
The concept behind atom:content has precedent in earlier microformats derived from the iCalendar standard as "description".

=== Date and time names alternatives ===
* atom:updated
** VJOURNAL LAST-MODIFIED
*** (also used by HTTP -[[User:RobertBachmann|Robert Bachmann]])
** dtstamp
** dtupdated
* atom:published
** VJOURNAL CREATED
** dtpublished

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

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

"Pushed back" is the wrong direction here.

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

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

- Tantek

== hCards ==

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

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as “The "atom:author" element is a Person construct that indicates the author of the entry or feed.” and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><addr class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI

'''STATUS - OPEN'''. "MAY" is the answer.

Tantek: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.

DavidJanes: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:

<pre><nowiki>
<div class="author">bonehead</div>
</nowiki></pre>

has an assumed defined mapping to

<pre><nowiki>
<div class="author vcard"><span class="fn">bonehead</div></div>
</nowiki></pre>

Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmicly.

== Comparisons ==

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

-- [[Ernie Prabhakar]]

* See the [[#Purpose]] section above. Basically that drove the design decision for the naming [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We're sticking with atom terminology (entry, content, summary).

See above as David says. The atom terminology is both problematic, and doesn't make sufficient reuse of existing microformat terminology. As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience. - Tantek

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

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

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

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

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

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

-- BenjaminCarlyle

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

See the [[mfo-examples]] document, and add further thoughts on this matter there. -- Tantek

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

IMHO yes. -- Tantek

A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.

rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.

rel-tag permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

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

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

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

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

=== last-modified ===
Does this specification depend on acceptance of a hAtom-compatible last-modified?

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

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

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

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

hatom-issues

2006-01-06T10:32:01Z

BenjaminCarlyle: Add coverage of abstract to discussion

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]
* [http://www.dannyayers.com Danny Ayers]
* [http://tantek.com/ Tantek Çelik]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# <em>Not</em> to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave <em>identically</em> to what they before hAtom was applied.

= New Nomenclature =

[[User:DavidJanes|David Janes]] added this on 2006.01.03. Since we've decided that correspondence to Atom nomenclature is not going to happen, let's just decide on it here. I tried but probably haven't succeeded in pulling all the info from below up so feel free to add new things. Also feel free to change your vote if you see a consensus happening.

'''How to use this'''. If you like a particular use, place something like '<code>: +1 YourName</code>' following the name. Feel free to make as make negative votes. If you have something compelling to say, add it to the Discussion section that follows. Let's settle this out by, say the 10th of January 2006?

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

=== Discussion ===

== Entry (atom:entry) ==
* <code>class="entry</code> (Atom consistency)
: +1 MarkRickerby
* <code>class="atom-entry</code> (Atom consistency with prefix)
* <code>class="hentry</code> (h* uF consistency)
: +1 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle

=== Discussion ===

== Entry Title (atom:title) ==
* <code>class="title"</code> (Atom consistency)
* <code>class="entry-title"</code> (Atom consistency, avoid hCard conflict)
* <code>class="heading"</code> (HTML)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (hReview consistency)
: -1 KevinMarks (clashes with atom)
* <code>class="headline"</code> what they're called in the News/Journalism industry
: +1 Tantek
: +1 BenjaminCarlyle
: +1 KevinMarks
* <code>class="fn"</code> hReview item consistency

=== Discussion ===
BenjaminCarlyle: If one were to review a blog entry with hReview we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.

BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.

== Entry Content (atom:content) ==
* <code>class="content"</code> (Atom consistency)
: +1 Tantek
: +1 DavidJanes
* <code>class="description"</code> (vCalendar, hCalendar, xFolk, hReview consistency)

=== Discussion ===
It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture. - Tantek

BenjaminCarlyle: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

== Entry Summary (atom:summary) ==
* <code>class="summary"</code> (Atom consistency)
* <code>class="content-summary"</code> (Atom consistency avoiding hCalendar conflict)
* <code>class="partial-description"</code>
* <code>class="excerpt"</code>
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="abstract"</code>
: +1 KevinMarks

=== Discussion ===
Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such. - Tantek

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 cna convey an excerpt by making it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content' [[User:Kevin Marks|Kevin Marks]]

BenjaminCarlyle: I have been trying to convince meyself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com 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.

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

=== Discussion ===
BenjaminCarlyle: No real contraversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.

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

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

== Entry Updated (atom:updated) ==
* <code>class="updated"</code> (Atom consistency)
: +1 Tantek
* <code>class="dtupdated"</code> (Atom consistency with "dt" unofficial pattern)
* <code>class="last-modified"</code>

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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

=== Discussion ===
BenjaminCarlyle: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?

== Entry Contributor (atom:author) ==
* <code>class="contibutor"</code> (Atom consistency)
: -1 Tantek - recommend postpone from hAtom first version, since the 80% case does not need "contributor". We can always add it later if we need it.

=== Discussion ===

= Questions and Comments =

==Limitations==
There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl).
There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections.
The microformat would be much more useful with these capabilities added.
-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)

* We've deliberately restricted this to being a "blog post" microformat at this point to make the problem managable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detrement to this standard. -- DavidJanes
** You brought this microformat to my attention because you disagreed in priciple with the XOXO Blog Format (http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html)... yet the only tool that currently works with that format works with comments. note also that at ''least'' comment counts and links to comment sections are part of posts. If you don't want to encapsulate comments I suppose I understand that and can easily create my own format meant to be embedded in yours to facilitate this purpose :) -- [[User:Singpolyma|singpolyma]] 22:13, 3 Jan 2006 (PST)
** Where did I disagree in principle? A: I told you about the existence of hAtom. B: I mentioned several of the design goals for hAtom

== Nomenclature ==

Note: microformats [[naming-principles]] include a precise means for coming up with names which should work in the 90% case.

One point to raise for hAtom in particular - we don't simply omit spaces from multiword property names, we use hyphens. E.g. "given-name" and many others in [[hcard|hCard]].

=== Why atomentry? ===
;class="atomentry" (or rather, "atom-entry")
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

'''STATUS - RESOLVED'''. We're going with "entry".

:: Tantek: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
* atom-entry
* hentry
* vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Why atomfeed? ===
;class="atomfeed" (or rather, "atom-entry")
:As above on the atomprefix. But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

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

'''STATUS - PARTIALLY RESOLVED'''. We're going with "feed" IF and when the Feed element is used. When and where Feed is used at all is still under discussion in the mailing list as of 2005-12-26.

: Tantek: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
* atom-feed
* hfeed

=== Why rel="link" ? ===
I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
[[KevinMarks]]
* I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion -- [[DavidJanes]]
* Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom -- [[DavidJanes]]
* Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file. - Tantek
* OK, I'm happy with this -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.

* Tantek: agreed.

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

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'
* 'headline'
** as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]

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

* description, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. [[User:Kevin Marks|Kevin Marks]] 15:51, 31 Dec 2005 (PST)
** Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]]. See below for where to use "description". We must NOT use "description" to mean summary. - Tantek

* Depending on your interpretation, atom:summary could still be summary. Here is another option: subject (atom:title) -> summary (atom:summary) -> content (atom:content).

* atom:summary is described as abstract in

Tantek: We may want to avoid the use of 'summary' entirely within hAtom. Here are some alternatives:
* excerpt - in practice this is what most people provide instead of full text.
** +1 Tantek
* partial-description
* abstract - Rarely do bloggers actually provide abstracts different from the full text of their posts - this is so NOT the 80% (and thus should be rejected for microformat consideration), but see [http://microformats.org/wiki/blog-post-examples#Entry_contains_summary_content_only blog-post-examples] for some examples.
* content-summary

=== Why content? ===
The concept behind atom:content has precedent in earlier microformats derived from the iCalendar standard as "description".

=== Date and time names alternatives ===
* atom:updated
** VJOURNAL LAST-MODIFIED
*** (also used by HTTP -[[User:RobertBachmann|Robert Bachmann]])
** dtstamp
** dtupdated
* atom:published
** VJOURNAL CREATED
** dtpublished

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

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

"Pushed back" is the wrong direction here.

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

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

- Tantek

== hCards ==

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

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as “The "atom:author" element is a Person construct that indicates the author of the entry or feed.” and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><addr class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI

'''STATUS - OPEN'''. "MAY" is the answer.

Tantek: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.

DavidJanes: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:

<pre><nowiki>
<div class="author">bonehead</div>
</nowiki></pre>

has an assumed defined mapping to

<pre><nowiki>
<div class="author vcard"><span class="fn">bonehead</div></div>
</nowiki></pre>

Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmicly.

== Comparisons ==

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

-- [[Ernie Prabhakar]]

* See the [[#Purpose]] section above. Basically that drove the design decision for the naming [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We're sticking with atom terminology (entry, content, summary).

See above as David says. The atom terminology is both problematic, and doesn't make sufficient reuse of existing microformat terminology. As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience. - Tantek

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

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

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

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

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

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

-- BenjaminCarlyle

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

See the [[mfo-examples]] document, and add further thoughts on this matter there. -- Tantek

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

IMHO yes. -- Tantek

A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.

rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.

rel-tag permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

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

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

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

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

=== last-modified ===
Does this specification depend on acceptance of a hAtom-compatible last-modified?

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

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

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

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

hatom-issues

2006-01-05T22:36:37Z

BenjaminCarlyle: Vote mass-edit

= Discussion Participants =

== Editors ==
* [http://www.blogmatrix.com David Janes]

== Authors ==
* [http://www.blogmatrix.com David Janes]
* [http://www.dannyayers.com Danny Ayers]
* [http://tantek.com/ Tantek Çelik]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

= Purpose =
Questions or comments about [[hatom|hAtom]] go here. Please add your name
to the [http://microformats.org/wiki?title=hatom-issues&action=edit&section=4 Contributors] section above.

== Goals for hAtom ==
# to provide a blog-post microformat, based on how people actually produce weblogs
# based on (1), use Atom as it provides the most suitable data model for doing so
# based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
# provide a baseline envelope format for similar {title|link|content|summary} web pages

== Anti-Goals for hAtom ==
# <em>Not</em> to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave <em>identically</em> to what they before hAtom was applied.

= New Nomenclature =

[[User:DavidJanes|David Janes]] added this on 2006.01.03. Since we've decided that correspondence to Atom nomenclature is not going to happen, let's just decide on it here. I tried but probably haven't succeeded in pulling all the info from below up so feel free to add new things. Also feel free to change your vote if you see a consensus happening.

'''How to use this'''. If you like a particular use, place something like '<code>: +1 YourName</code>' following the name. Feel free to make as make negative votes. If you have something compelling to say, add it to the Discussion section that follows. Let's settle this out by, say the 10th of January 2006?

== Feed (atom:feed)==
* <code>class="feed"</code> (Atom consistency)
* <code>class="atom-feed"</code> (Atom consistency with prefix)
* <code>class="hfeed"</code> (h* uF consistency)
: +1 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle

=== Discussion ===

== Entry (atom:entry) ==
* <code>class="entry</code> (Atom consistency)
: +1 MarkRickerby
* <code>class="atom-entry</code> (Atom consistency with prefix)
* <code>class="hentry</code> (h* uF consistency)
: +1 DavidJanes
: +1 Tantek
: +1 BenjaminCarlyle

=== Discussion ===

== Entry Title (atom:title) ==
* <code>class="title"</code> (Atom consistency)
* <code>class="entry-title"</code> (Atom consistency, avoid hCard conflict)
* <code>class="heading"</code> (HTML)
* <code>class="subject"</code> (RFC822)
* <code>class="summary"</code> (hReview consistency)
* <code>class="headline"</code> what they're called in the News/Journalism industry
: +1 Tantek
: +1 BenjaminCarlyle
* <code>class="fn"</code> hReview item consistency

=== Discussion ===
BenjaminCarlyle: If one were to review a blog entry with hReview we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.

BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.

== Entry Content (atom:content) ==
* <code>class="content"</code> (Atom consistency)
: +1 Tantek
: +1 DavidJanes
* <code>class="description"</code> (vCalendar, hCalendar, xFolk, hReview consistency)

=== Discussion ===
It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture. - Tantek

BenjaminCarlyle: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.

== Entry Summary (atom:summary) ==
* <code>class="summary"</code> (Atom consistency)
* <code>class="content-summary"</code> (Atom consistency avoiding hCalendar conflict)
* <code>class="partial-description"</code>
* <code>class="excerpt"</code>
: +1 Tantek
: +1 BenjaminCarlyle

=== Discussion ===
Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such. - Tantek

BenjaminCarlyle: I have been trying to convince meyself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com describes summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt.

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

=== Discussion ===
BenjaminCarlyle: No real contraversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.

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

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

== Entry Updated (atom:updated) ==
* <code>class="updated"</code> (Atom consistency)
: +1 Tantek
* <code>class="dtupdated"</code> (Atom consistency with "dt" unofficial pattern)
* <code>class="last-modified"</code>

=== Discussion ===
BenjaminCarlyle: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.

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

=== Discussion ===
BenjaminCarlyle: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?

== Entry Contributor (atom:author) ==
* <code>class="contibutor"</code> (Atom consistency)
: -1 Tantek - recommend postpone from hAtom first version, since the 80% case does not need "contributor". We can always add it later if we need it.

=== Discussion ===

= Questions and Comments =

==Limitations==
There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl).
There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections.
The microformat would be much more useful with these capabilities added.
-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)

* We've deliberately restricted this to being a "blog post" microformat at this point to make the problem managable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detrement to this standard. -- DavidJanes
** You brought this microformat to my attention because you disagreed in priciple with the XOXO Blog Format (http://blogxoxo.blogspot.com/2006/01/xoxo-blog-format.html)... yet the only tool that currently works with that format works with comments. note also that at ''least'' comment counts and links to comment sections are part of posts. If you don't want to encapsulate comments I suppose I understand that and can easily create my own format meant to be embedded in yours to facilitate this purpose :) -- [[User:Singpolyma|singpolyma]] 22:13, 3 Jan 2006 (PST)
** Where did I disagree in principle? A: I told you about the existence of hAtom. B: I mentioned several of the design goals for hAtom

== Nomenclature ==

Note: microformats [[naming-principles]] include a precise means for coming up with names which should work in the 90% case.

One point to raise for hAtom in particular - we don't simply omit spaces from multiword property names, we use hyphens. E.g. "given-name" and many others in [[hcard|hCard]].

=== Why atomentry? ===
;class="atomentry" (or rather, "atom-entry")
:Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want
to try for something approaching a string that won't get confused, my
feeling is: forget it. Stick to the local semantics and let the
doc-level (or HTML5 div level?) profile attribute disambiguate. Or to
put it another way, it's premature to see a need at that point.
-- [[DannyAyers]]

* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
::I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)

:: [[DannyAyers]] My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...

'''STATUS - RESOLVED'''. We're going with "entry".

:: Tantek: This is actually difficult to consider outside the following issue. In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
* atom-entry
* hentry
* vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])

=== Why atomfeed? ===
;class="atomfeed" (or rather, "atom-entry")
:As above on the atomprefix. But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- [[DannyAyers]]

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

'''STATUS - PARTIALLY RESOLVED'''. We're going with "feed" IF and when the Feed element is used. When and where Feed is used at all is still under discussion in the mailing list as of 2005-12-26.

: Tantek: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
* atom-feed
* hfeed

=== Why rel="link" ? ===
I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
[[KevinMarks]]
* I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion -- [[DavidJanes]]
* Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom -- [[DavidJanes]]
* Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]]. The destination of the link is not really a "link" itself with respect to the current document/file. - Tantek
* OK, I'm happy with this -- [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.

* Tantek: agreed.

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

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'

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

* description, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly. [[User:Kevin Marks|Kevin Marks]] 15:51, 31 Dec 2005 (PST)
** Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]]. See below for where to use "description". We must NOT use "description" to mean summary. - Tantek

* Depending on your interpretation, atom:summary could still be summary. Here is another option: subject (atom:title) -> summary (atom:summary) -> content (atom:content).

* atom:summary is described as abstract in

Tantek: We may want to avoid the use of 'summary' entirely within hAtom. Here are some alternatives:
* excerpt - in practice this is what most people provide instead of full text.
** +1 Tantek
* partial-description
* abstract - Rarely do bloggers actually provide abstracts different from the full text of their posts - this is so NOT the 80% (and thus should be rejected for microformat consideration), but see [http://microformats.org/wiki/blog-post-examples#Entry_contains_summary_content_only blog-post-examples] for some examples.
* content-summary

=== Why content? ===
The concept behind atom:content has precedent in earlier microformats derived from the iCalendar standard as "description".

=== Date and time names alternatives ===
* atom:updated
** VJOURNAL LAST-MODIFIED
*** (also used by HTTP -[[User:RobertBachmann|Robert Bachmann]])
** dtstamp
** dtupdated
* atom:published
** VJOURNAL CREATED
** dtpublished

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

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

"Pushed back" is the wrong direction here.

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

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

- Tantek

== hCards ==

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

* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as “The "atom:author" element is a Person construct that indicates the author of the entry or feed.” and <code><address></code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code><addr class="vcard"></code> we would have pretty good 1:1 mappings:
** atom:name ↔ hCard’s FN
** atom:email ↔ hCard’s EMAIL
** atom:uri ↔ hCard’s URI

'''STATUS - OPEN'''. "MAY" is the answer.

Tantek: I think this should be MUST. Atom should have referenced vCard for these semantics and made the mistake of making up their own terms. Let's undo that mistake with hAtom. Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]]. Thus we may want to just follow suit with hAtom as well.

DavidJanes: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:

<pre><nowiki>
<div class="author">bonehead</div>
</nowiki></pre>

has an assumed defined mapping to

<pre><nowiki>
<div class="author vcard"><span class="fn">bonehead</div></div>
</nowiki></pre>

Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmicly.

== Comparisons ==

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

-- [[Ernie Prabhakar]]

* See the [[#Purpose]] section above. Basically that drove the design decision for the naming [[User:DavidJanes|David Janes]]

'''STATUS - RESOLVED'''. We're sticking with atom terminology (entry, content, summary).

See above as David says. The atom terminology is both problematic, and doesn't make sufficient reuse of existing microformat terminology. As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same. The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not. Note that you can overlay hAtom and S5 in the same markup. Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience. - Tantek

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

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

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

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

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

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

-- BenjaminCarlyle

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

See the [[mfo-examples]] document, and add further thoughts on this matter there. -- Tantek

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

IMHO yes. -- Tantek

A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.

rel-tag uses the last path segment of a URI as its tag, for example <code><a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)

hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.

rel-tag permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

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

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

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

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

=== last-modified ===
Does this specification depend on acceptance of a hAtom-compatible last-modified?

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

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

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

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

hatom-issues

2006-01-05T22:05:16Z

BenjaminCarlyle: +1 atom:feed = hfeed

irc

2006-01-04T22:51:52Z

BenjaminCarlyle: /* People on irc */

__NOTOC__
= Microformats IRC =

We have an IRC channel, [irc://irc.freenode.net#microformats #microformats on the freenode network].

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.

== People on irc ==
A list of IRC regulars and their normal timezones.

* [[User:RyanKing|kingryan]] (-0800)
* [[User:EdwardOConnor|hober]] (-0800)
* [[User:RobertBachmann|RobertBachmann]] (+0100)
* [[User:Tantek|Tantek]] (-0800)
* [http://epeus.blogspot.com/ KevinMarks] (-0800)
* [[User:DimitriGlazkov|dglazkov]] (-0600)
* [[User:ChrisMessina|factoryjoe]] (-0800)
* [[User:IanHickson|Hixie]] (-0800)
* [[User:neuro|neuro`]]
* [[User:JoeGregorio|jcgregorio]]
* [[User:Cgriego|cgriego]] (-0600)
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)

=== bots ===

* [[mfbot]]
* [[mflogbot]]
* [[jibot]]

== IRC meetups ==

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.

User:FuzzyBSc

2006-01-04T16:20:18Z

BenjaminCarlyle: Note username change

Changed username to BenjaminCarlyle.