Microformats Wiki - User contributions [en]

hatom-issues

2006-01-03T17:55:30Z

FuzzyBSc: Add Published vs Updated commentary

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

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

== Nomenclature ==

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

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

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

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

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

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

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

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

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

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

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

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

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

* Tantek: agreed.

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

* 'summary', as used by hReview, hCalendar, VJOURNAL
** Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification. We may want to avoid the use of 'summary' entirely within hAtom. - Tantek
* 'Subject', as used by SMTP email
* 'heading'
* 'entry-title'

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

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

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

* atom:summary is described as abstract in

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

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

* Tantek: 'content' is a terrible name to use for this sort of thing. The term is far too ambiguous and overloaded, and nearly anything can be considered to be "content".
* Using 'description' is well established by vCalendar, iCalendar (RFC 2445), hCalendar, xFolk, hReview etc. - Tantek

Proposals/alternatives:
* description - re-use it as it is already used by vCalendar, iCalendar (RFC 2445), hCalendar, xFolk, hReview etc.
** +1 Tantek

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

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

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

"Pushed back" is the wrong direction here.

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

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

- Tantek

== hCards ==

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

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

'''STATUS - RESOLVED'''. "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.

== 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-01T20:31:21Z

FuzzyBSc: Why not use whole atom:entry as content?

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):

* Summary, as used by hReview, hCalendar, VJOURNAL
* Subject, as used by SMTP email

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document 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)

* 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 could be described as partial-description
* atom:summary could be described as excerpt
* atom:summary is described as abstract in [http://microformats.org/wiki/blog-post-examples#Entry_contains_summary_content_only blog-post-examples]

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

=== Date and time names have precedent ===
* atom:updated -> VJOURNAL LAST-MODIFIED
* atom:published -> VJOURNAL CREATED

=== 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 (Please add more):

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

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

=== 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? 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?

=== 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?

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

hatom-issues

2006-01-01T19:10:12Z

FuzzyBSc: Add abstract as option for summary

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):

* Summary, as used by hReview, hCalendar, VJOURNAL
* Subject, as used by SMTP email

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document 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)

* 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 could be described as partial-description
* atom:summary could be described as excerpt
* atom:summary is described as abstract in [http://microformats.org/wiki/blog-post-examples#Entry_contains_summary_content_only blog-post-examples]

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

=== Date and time names have precedent ===
* atom:updated -> VJOURNAL LAST-MODIFIED
* atom:published -> VJOURNAL CREATED

=== 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 (Please add more):

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

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

=== 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? 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?

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

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

hatom-issues

2006-01-01T18:57:30Z

FuzzyBSc: Add _fil_'s rel-tag-in-content usage

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):

* Summary, as used by hReview, hCalendar, VJOURNAL
* Subject, as used by SMTP email

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document 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)

* 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 could be described as partial-description
* atom:summary could be described as excerpt

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

=== Date and time names have precedent ===
* atom:updated -> VJOURNAL LAST-MODIFIED
* atom:published -> VJOURNAL CREATED

=== 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 (Please add more):

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

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

=== 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? 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?

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

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

blog-post-brainstorming

2006-01-01T18:23:30Z

FuzzyBSc: Add partial-content blog use case

= Discussion Participants =

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

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

== Contributors ==
* [http://www.oreillynet.com Justin Watt]
* [[MikeTaylor|Mike Taylor]]

= Purpose =
The 'blog-post-microformat' proposes a codification of how blog posts are indentifies within weblogs. It is hoped that this should be considered to be 'expansive': for example, the proposal could be used on [http://www.cnn.com CNN.com] to mark up news articles and summary pages.

= Terminology =

This section explores the terminology that should used to discuss a blog post microformat. To make it easier to talk about the various different types of teminology, We're using a XML-like namespace version so we can make statements like <code>atom:entry</code> is roughly equivalent to <code>rss20:feed</code>, <code>atom:feed/atom:link@relalternate</code> is roughly equivalent to <code>rss20:channel/rss20:link</code> or <code>atom:author</code> is '''not''' equivalent to <code>rss:entry/rss:author</code> (because RSS 2.0 is only the definition of an email address).

== Common terminology in weblogs ==

Reviewing [[blog-post-formats#Tools]], one can see that there's little standardization amongst tools or even within a individual tool (such as 'blogger') for names of elements of blog posts. There are however many common elements, including:

* a container for all posts/entries
* a container for individual posts
* the post content, which can be complete, summarized with a link to the complete link, or a couple of paragraphs with javascript/CSS tricks to reveal the remainder of the content
* the name of the author
* the posting date (in many many formats)

Although this looks like a bit of a dog's breakfast, there is usually a fair amount of rigour behind the presentation, as Atom and/or RSS feeds can be produced also from the same tools.

Furthermore, in developing a microformat for weblog posts, we want to be careful not to break any (or many) templates. Note that many weblog templates will have to be updated as they produce somewhat crufty HTML rather than shiny XHTML.

== Atom Terminology ==

See [http://www.atomenabled.org/ here] for the spec and [[blog-post-formats#Atom]] for analysis.

* <code>atom:feed</code> - (composite) a collection of entries plus information about them
** <code>atom:author</code> - (composite) the author of a feed (may contain atom:email, atom:name, atom:uri)
** <code>atom:id</code> - a permament identifier for a feed
** <code>atom:title</code> - the title of an atom:entry or a atom:feed
** <code>atom:updated</code> - the last time the feed was updated
** <code>atom:link@relalternate</code> - the home page of a feed
** <code>atom:link@relself</code> - the URI of the feed (where it can be downloaded)
** <code>atom:entry</code> - (composite) an entry within the feed
*** <code>atom:content</code> - the feed's content
*** <code>atom:summary</code> - a summary of the feed's content
*** <code>atom:entry/link</code> - the permament URI of the entry
*** <code>atom:published</code> - the time of the initial creation or first availability of the entry

== RSS 2.0 Terminology ==

See [http://blogs.law.harvard.edu/tech/rss here] for the spec and [[blog-post-formats#RSS]] for analysis. There are a lot more elements in RSS but this covers the most commonly used ones.

* <code>rss2:channel</code> - (composite) a collection of entries plus information about them
** <code>rss2:author</code> - (composite) the author of a feed (may contain atom:email, atom:name, atom:uri)
** <code>rss2:link</code> - The URL to the HTML website corresponding to the channel (compare to atom:link@relalternate)
** <code>rss2:title</code> - the title of an rss2:channel or a rss2:item
** <code>rss2:pubDate</code> - The publication date for the content in the channel.
** <code>rss2:item</code> - (composite) an entry within the feed
*** <code>rss2:item/link</code> - The URL of the item. Note that this may not be a permalink for the item; it may be a link to some other page on the Internet that the rss2:item is about
*** <code>rss2:description</code> - The item synopsis [sic]. There is no special indication whether this is the full content of an entry, a summary, or a precis of what the rss2:item/link is pointing to
*** <code>rss2:author</code> - email address of the author of the item

== Recommendation ==

Atom has a much more precise mechanism for defining syndication feeds and weblog data. A mechanical transformation from Atom -> RSS will always lead to a correct RSS feed; a RSS -> Atom translation would have to make a decision amongst multiple definitions that may not always be correct. For example, the format of markup, the role of an author, or the meaning of a link.

IMPORTANT: we shall talk about things such as 'marking elements <code>atom:feed</code>'; consider this a purely conceptual thing. The text 'atom:feed' will not appear in the XHTML microformat -- we may decide later to use the actual phrase 'atom_feed', 'feed', 'items' or 'googlybear'. In the case where there is no clear or applicable atom terminology, we shall use 'weblog:xxx'.

= Discovered Elements =

This section explores the information discovered from [[blog-post-formats]] using the terminology discussed above. We will only focus on the major elements of weblog posts:

* the EntryGroup
* the individual Entry
* the Entry Title
* the Entry Content
* the Entry Permalink
* the Entry Datetimes

For now, the codification of the following major elements will be deferred as there is/may be overlap with other microformats that should be explored further

* the EntryGroup Title
* the EntryGroup Permalink
* the Entry Poster/Author - in particular, should hcard be used?

Further input from the community would be appreciated here

== EntryGroup ==

Roughly speaking, this corresponds to 'atom:feed' or 'rss2:channel' (in particular, the items within those XML elements). See [[blog-post-examples#EntryGroup]] for the various forms seen in the wild.

=== Microformat Recommendation ===

* weblog pages (including home pages, archives, category pages, tag pages and so forth) that may container multiple entries MUST enclose the entries in a <code>atom:feed</code> element
* weblog pages MAY have multiple <code>atom:feed</code> element enclosing different groups of entries
* <code>atom:feed</code> elements MUST NOT be nested
* weblog pages that have exactly one entry MAY use the <code>atom:feed</code>

=== Example Transformation ===

''Note that the string 'atom:feed' is a placeholder for something to be decided later.''

Original (obviously, if there is no existing EntryGroup block element, one can be added):

<pre><nowiki>
<div id="content">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div id="content" class="atom:feed">
<h2 id="home-title">
Latest microformats news
<a href="http://www.microformats.org/feed/" title="link to RSS feed" id="feed-link">
<img src="/img/xml.gif" width="23" height="13" alt="XML" />
</a>
</h2>

<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
...
</div>

...
</div>
</nowiki></pre>

== EntryGroup Title ==
Not covered by this proposal yet.

== EntryGroup Permalink ==
Not covered by this proposal yet.

== Individual Entry ==

This corresponds almost exactly to the <code>atom:entry</code> or <code>rss2:item</code> elements. See [[blog-post-examples#Individual_Entry]] for the various forms seen in the wild.

=== Microformat Recommendation ===

* weblog entries MUST be enclosed in a single <code>atom:entry</code> element
* <code>atom:entry</code> elements MUST NOT be nested
* <code>atom:entry</code> MUST NOT belong to more than one <code>atom:feed</code> element

=== Example Transformation ===
''Note that the string 'atom:entry' is a placeholder for something to be decided later.''

==== Entries in existing block ====

Original:

<pre><nowiki>
<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
... rest of entry ...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:feed">
<div class="atom:entry entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/2005/...">Wiki Attack</a>
</h3>
... rest of entry ...
</div>
... additional entries ...
</div>
</nowiki></pre>

==== Entries not in an existing block ====

Original:

<pre><nowiki>
<a name="112877372228959075">&nbsp;</a>
<br>
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:feed">
<div class="atom:entry" id="112877372228959075">
<br />
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
... additional entries ...
</div>
</nowiki></pre>

Note the additional changes were also made:
* <code><br></code> was made XHTML compliant
* <code><a name="..."></code> was converted to a <code>id="..."</code> (''confirm this is OK'')

==== Disjointed entries ====

Ignore any existing blocks and treat as the previous case of no block.

== Entry Title ==

This corresponds almost exactly to the <code>atom:title</code> or <code>rss2:title</code> elements. See [[blog-post-formats#Titles]] for examples from which we see that there are two fundemental ways titles are used in the wild: at the block level and inline. Our proposal must be capable of handling both forms.

=== Microformat Recommendation ===

* <code>atom:entry</code>s SHOULD have at most one title
* block level titles SHOULD be represented using <code><h#></code>, the first such element in a <code>atom:entry</code> should be considered the title; this need not be marked up or identified in any other way as the title
* inline titles MUST be marked as <code>atom:title</code>; it is also possible to do this using block level formatting such as <code><div></code>, but this is discouraged

=== Discussion: why not always <code><h#></code>? ===

Using CSS <code>display: inline</code>, block level elements can be converted to inline elements. Unfortunately, we cannot nest <code><h#></code> inside of a <code><p></code> block to achieve the correct effect. I.e. we cannot convert ...

<pre><nowiki>
<p><strong>The Title</strong>: The Text...</p>
</nowiki></pre>

... into ...

<pre><nowiki>
<p><h3 style="display: inline">The Title</h3>: The Text ...</p>
</nowiki></pre>

... because the XHTML will not validate. Also...

<pre><nowiki>
<h3 style="display: inline">The Title</h3><p>: The Text ...</p>
</nowiki></pre>

... will not work because presentation effect will be different than what the user intends (because the <code><p></code> will introduce a line break).

=== Example Transformation ===

''Note that the string 'atom:title' is a placeholder for something to be decided later.''

==== Header in <code><h#></code> block ====
Original (and Final):

<pre>
<div class="atom:entry">
<h2 id="post-59">Web Essentials Audio</h2>
... reset of entry ...
</div>
</pre>

No transformation is needed -- the blog-post microformat will recognize this as the <code>atom:title</code>.

==== Header in other block element ====

Original:

<pre>
<div class="atom:entry">
<div class"header">Web Essentials Audio</div>
</div>
</pre>

Transformed (the header level is to taste):

<pre>
<div class="atom:entry">
<h3>Web Essentials Audio</h3>
</div>
</pre>

It is possible to add <code>class"atom:title"</code> to the <code>div</code> but we recommend against it. However, we recognize that there may be certain [http://microformats.org/wiki/blog-post-formats#Discussion_Forum_.2F_Bulletin_Board_Formats BB Tools] that making this change may be too difficult.

==== Header in inline element ====

Original:

<pre><nowiki>
<div class="atom:entry" id="112877372228959075">
<br />
<strong>Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
</nowiki></pre>

Transformed:

<pre><nowiki>
<div class="atom:entry" id="112877372228959075">
<br />
<strong class="atom:title">Just one problem, Minister.</strong> Last week, Bill Rammell,
<br />
... rest of entry ...
</div>
</nowiki></pre>

== Entry Content ==

This roughly corresponds to <code>atom:content</code> and/or <code>atom:summary</code> elements. See [[blog-post-examples#Entry_Content]] for the various forms seen in the wild.

=== Discussion: the split content problem ===

The last item above (content broken into multiple sections) introduces a few unique problems. It is not sufficient to enclose all the different content sections in a <code>atom:content</code> element, as the following example illustrates:

<pre><nowiki>
<div class="atom:entry">
<div class="atom:content">
... first part of the content ...
"Read More"
... second part of the content ...
</div>
</div>
</nowiki></pre>

"Read More" is not part of the content! Therefore, we propose that ''multiple'' content sections be allowed in a single <code>atom:entry</code>. The concatenation of all these content blocks will define the complete content:

<pre><nowiki>
<div class="atom:entry">
<div class="atom:content">
... first part of the content ...
</div>
"Read More"
<div class="atom:content">
... second part of the content ...
</div>
</div>
</nowiki></pre>

The same argument is applicable to <code>atom:summary</code>.

=== Microformat Recommendation ===

* an <code>atom:entry</code> MAY have zero or more <code>atom:summary</code> sections. There is no requirement that different representations of the same entry (on different URIs) use the same summaries.
* an <code>atom:entry</code> MAY have zero or more <code>atom:content</code> sections. The serial concatenation of all the <code>atom:content</code> sections within the entry MUST represent the complete content of the entry. Note that the rule here is slightly different than [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.2 Atom] which only allows one <code>atom:content</code>.

=== Example Transformation ===

''Note that the strings 'atom:summary' and 'atom:content' (etc.) are placeholders for something to be decided later.''

==== Entry with summary content ====
Original:

<pre><nowiki>
<div class="inlineBlog">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
... some tag and category stuff ...
<p>
The folks at ... the rest of the content
</p>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="inlineBlog atom:entry">
<h3 id="a003068">
<a href="http://thecommunityengine.com/h.../xfolk_vegomatic.html" class="taggedlink atom:permalink">xFolk Veg-o-matic Alpha</a>
</h3>
<p class="abstract extended">
We provide a way to surf the web and slice and dice information you find there into your own custom output stream.
</p>
... some tag and category stuff ...
<div class="atom:summary">
<p>
The folks at ... the rest of the content
</p>
</div>
<p class="extended">
<a href="http://thecommunityengine.com/.../xfolk_vegomatic.html#more">Continue reading "xFolk Veg-o-matic Alpha"</a>
</p>
...
</div>
</nowiki></pre>

Notes:
* we didn't do anything with the "abstract" section -- this is a discussion for another day
* we didn't include the tag stuff in the summary, and probably wouldn't if this was the complete content

==== Entry with complete content ====
Original:

<pre><nowiki>
<div class="entry single">
<h2 id="post-61">Class attributes are about more than styling</h2>

<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="entry single atom:entry">
<h2 id="post-61">Class attributes are about more than styling</h2>

<div class="atom:content">
<p>When people talk about microformats, ... </p>

<blockquote cite="http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2">
... quoted text from elsewhere
</blockquote>

<p>There’s a couple of points I’d like to highlight here:</p>

... more content ...
</div>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://www.technorati.com/tag/css" rel="tag">css</a></li>
...
</ul>

<ul class="post-info">
... footer stuff ...
</ul>
</div>
</nowiki></pre>

Notes:
* the only thing that really needed to be done is enclose the content
* my preference would be to move the post <code>id</code> to the <code>atom:entry</code>

==== Entry with split content (multiple sections) ====
Original:

<pre><nowiki>
<div class="blogbody">
<a name="008148"></a>

<div class="title">
Face to face: why places will continue to exist
</div>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="blogbody atom:entry" id="008148">
<h3>
Face to face: why places will continue to exist
</h3>

<div class="posted">
<strong>Brian Micklethwait (London)</strong>
  
<a href="...">Science & Technology</a>
</div>

<div class="atom:content">
<p>It is not just that I dislike filling in forms....</p>
... the first section of the content ...
</div>

... this link makes the extended section show ...
<span id="varP8148">
<img src="http://www.samizdata.net/blog/img/bullet_tri.gif" width="16" height="10" alt="" />
<a href="..." onclick="showMore(8148,'...');return false;">
Read more.
</a>
</span>

<div id="varXYZ8148" style="display: none">
<div class="atom:content">
<p>The very gadgets – computers linked...</p>
... the rest of the extended content ...
</div>

... this link makes the extended section hide ...
<img src="..." width="16" height="10" alt="" />
<a href="#008148" onclick="showMore(8148,0);return true;">
Read less.
</a>
</div>
</div>
</div>
</nowiki></pre>

Note:
* <code>atom:content</code> <code>div</code>s were created for each the of the text sections, so that non-content coded would not be incorrectly marked
* there are '''two''' <code>atom:content</code> sections; together they make the complete content
* the conversion of <code><div class="header"></code> to <code><h3></code>
* the addition of <code>atom:entry</code> as needed
* the removal of the <code><a name="008148"></code> in favor of placing an <code>id</code> on the <code>atom:entry</code>
* further manipulation of the author could be done
* further manipulation of the category could be done

== Entry Permalink ==

Permalinks roughly correspond to <code>atom:link</code>. See [[blog-post-examples#Entry_Permalinks]] for examples.

A permalink is called '''canonical''' if it is the best representation of the URI for that entry; the definition of what 'best representation' is is entirely at the discretion of the weblog's publisher. We recommend that weblogs use canonical URIs because it allows "threading" together multiple posts and sources with byte-level comparisons. In general, the canonical URI should be the link used in an Atom entry.

=== Microformat Recommendation ===

* an Entry MUST NOT have more than one permalink marked as <code>atom:link</code>
* permalinks SHOULD be absolute URIs
* permalinks SHOULD be canonical
* permalinks SHOULD be the same as the <code>atom:link</code> used in syndication feeds

=== Example Transformations ===

Original:

<pre><nowiki>
<div class="entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="atom:entry entry">
<h3 id="post-45">
<a
href="http://www.microformats.org/blog/2005/08/21/foobar-microformats/"
rel="atom:link bookmark"
title="Permanent Link to FooBar Microformats">FooBar Microformats</a>
</h3>
...
</div>
</nowiki></pre>

Original:

<pre><nowiki>
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

Transformation:

<pre><nowiki>
<div class="atom:entry">
<h3>YET ANOTHER INSTANCE OF THE WORLD FINALLY CATCHING UP TO THE BLOG</h3>
<p>Today's news: Neuticles win ... award.</p>
<p class="posted">
Posted by judi on October 7, 2005 at 05:00 PM |
<a rel="atom:link" href="http://blogs.herald.com/dave_barrys_blog/2005/10/yet_another_ins.html">Permalink</a>
</p>
</nowiki></pre>

== Entry Datetimes - Creation and Modified ==
Weblogs typically display (in HTML) the creation time of their posts (roughly but not exactly corresponding to <code>atom:published</code>) and not so much the last modified time (<code>atom:updated</code>).

Also see [[datetime-design-pattern]] for more information on specifying datetimes. The recommendation here is styled after datetimes in [[hcalendar]].

=== Forms seen in the wild ===
See [[blog-post-formats#Datetimes]]

=== Microformat Recommendation ===

* date headers between weblog entries are outside of this microformat
* <code>atom:published</code> SHOULD be indicated by an <code>abbr</code> element around the human readable version of the date or datetime.
** the 'class' attribute MUST indicate <code>atom:published</code>
** the 'title' attribute MUST be a complete datetime, in the format of [[datetime-design-pattern]]
* likewise for <code>atom:updated</code>, if present

=== Example transformation ===

''Note that the string 'atom:published' is a placeholder for something to be decided later.''

Original:

<pre>
<a href"...">Friday, September 30th, 2005 at 12:31 pm</a>
</pre>

Transformed:

<pre>
<a href"..."><abbr
class"atom:published"
title"200050930T12:31:01-0500">Friday, September 30th, 2005 at 12:31 pm</abbr></a>
</pre>

== Entry Author ==
A work in progress

=== Microformat Recommendation ===

* Entry Authors SHOULD be inside a <code><address></code> block

= Possible Uses =

This section describes potential applications for a blog post microformat

== Transformational Uses ==

By transformational, we mean feeding a weblog post to some sort of transformation tool (such as XSLT) to produce a different version of the post fit for a different use.

=== Printing Weblog Posts ===
=== Reblogging ===

* [http://blogs.zdnet.com/BTL/?p=2052&part=rss&tag=feed&subj=zdblog ZDNet] has a reblog button that would be made obsolete (or could be substantially improved) by use of this microformat
* [http://reblg.com/ Reblog.com] was the inspiration for this idea. This may be renamed [http://redirectthis.com/ RedirectThis]?

== Archival Uses ==

By 'archival', we mean taking weblog entries and placing them in a database for later analysis, searching, aggregation and so forth.

=== Personal Database ===
=== Search Engines ===

=== Partial Text Blogs ===
Partial content blogs can be created by producing the full html content of a blog entry but not marking it up as such. The atom:summary portion of that entry can be marked up as summary, or could be written up and placed in a hidden block element within the html. hAtom parsers would ignore the unannotated content and produce summary information only.

=Obstacles=

==Header Tag for Entry Title?==
--[[User:Bryan|Bryan]] 14:55, 14 Aug 2005 (PDT)

Many weblog CMSes allow for concurrent publishing of entries in the following ways:

* multiple entries on a page (an "Index," monthly archive, category archive, etc. see [http://re-run.com/category/creative/comedy/ Example])
* one entry on a page (see [http://re-run.com/2005/02/11/nickels-worth-of-free-advice/ Example])

Early attempts at [[blog-post-formats]] have set the title of the blog post to use the h3 tag.

At least where individual entry pages are concerned (and possible including indexes and archives), I recommend using h1 for the entry title, given that the entry is by far the most important chunk of information on the page, and it's what we'd want search engines to recognize as such. In the case where the h1 was used for the site title, fears about "losing" this information should be allayed by simply including the site name in the title tag, <strong>after</strong> the title of the article / entry / post.

:Whether an h3 or h1 is used is irrelevant, the semantics will be applied with classnames. This is a non-issue. --[[User:RyanKing|RyanKing]] 22:35, 18 Aug 2005 (PDT)

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

* [http://blogs.oreillynet.com/beasts/archives/2005/10/blog_post_microformat_proposal.html Blog Post Microformat Proposal] Some thoughts on the topic with useful illustrations.
* [http://dannyayers.com/archives/2005/08/27/hatom-no-seriously/ Danny Ayers] proposes the name hAtom and some applications
* [http://torrez.us/archives/2005/10/07/404 Elias Torres] says we need 'hAtom'

hatom-issues

2006-01-01T18:02:42Z

FuzzyBSc: Add "read more" summary nested in content example for opaqueness

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):

* Summary, as used by hReview, hCalendar, VJOURNAL
* Subject, as used by SMTP email

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document 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)

* 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 could be described as partial-description
* atom:summary could be described as excerpt

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

=== Date and time names have precedent ===
* atom:updated -> VJOURNAL LAST-MODIFIED
* atom:published -> VJOURNAL CREATED

=== 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 (Please add more):

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

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

== 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? 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?

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

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

hatom-issues

2006-01-01T17:58:26Z

FuzzyBSc: Add partial-description and excerpt as options for atom:summary

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):

* Summary, as used by hReview, hCalendar, VJOURNAL
* Subject, as used by SMTP email

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document 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)

* 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 could be described as partial-description
* atom:summary could be described as excerpt

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

=== Date and time names have precedent ===
* atom:updated -> VJOURNAL LAST-MODIFIED
* atom:published -> VJOURNAL CREATED

=== 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 (Please add more):

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

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

== 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? 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?

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

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

hatom-issues

2006-01-01T15:49:06Z

FuzzyBSc: Add subject-based alternative

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):

* Summary, as used by hReview, hCalendar, VJOURNAL
* Subject, as used by SMTP email

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document 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)

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

=== Date and time names have precedent ===
* atom:updated -> VJOURNAL LAST-MODIFIED
* atom:published -> VJOURNAL CREATED

=== 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 (Please add more):

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

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

== 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? 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?

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

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

hatom-issues

2006-01-01T15:27:22Z

FuzzyBSc: Add subject as alternative to atom:title

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):

* Summary, as used by hReview, hCalendar, VJOURNAL
* Subject, as used by SMTP email

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document 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)

=== Date and time names have precedent ===
* atom:updated -> VJOURNAL LAST-MODIFIED
* atom:published -> VJOURNAL CREATED

=== 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 (Please add more):

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

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

== 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? 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?

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

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

hatom-issues

2006-01-01T15:21:55Z

FuzzyBSc: Add hReview and date-time question

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):

* Summary, as used by hReview, hCalendar, VJOURNAL

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document 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)

=== Date and time names have precedent ===
* atom:updated -> VJOURNAL LAST-MODIFIED
* atom:published -> VJOURNAL CREATED

=== 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 (Please add more):

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

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

== 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? 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?

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

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

hatom-issues

2006-01-01T14:33:32Z

FuzzyBSc: Clarify current suggestion

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):

* Summary, as used by hReview, hCalendar, VJOURNAL

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document 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)

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

== 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? 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?

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

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

hatom-issues

2005-12-31T23:15:31Z

FuzzyBSc: Suggest description as nomenclature for atom:summary

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):

* Summary, as used by hReview, hCalendar, VJOURNAL

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document 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 title -> description -> content

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

== 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? 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?

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

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

hatom-issues

2005-12-31T23:11:55Z

FuzzyBSc: Create title suggestion list

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):

* Summary, as used by hReview, hCalendar, VJOURNAL

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document title". It seems this is the right term to use for <atom:title>.

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

== 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? 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?

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

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

hatom-issues

2005-12-31T22:30:24Z

FuzzyBSc: Add Dependancies section

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". It is unclear what term should replace it.

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document title". It seems this is the right term to use for <atom:title>.

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

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

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

== 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?

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

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

blog-post-formats

2005-12-31T21:13:35Z

FuzzyBSc: Expand VJOURNAL data

= Current Blog Formats =

There is a need for developing standard classes for blog posts (i.e. a microformat!).

This page serves to document the current list of individual blog post schemas, formats, and efforts as background for the design of a simple blog post MicroFormat.

== Discussion Participants ==

=== Editor ===
* [http://blog.factoryjoe.com/ Chris Messina], [http://flock.com Flock, Inc.]

=== Authors ===
* [http://tantek.com/log/ Tantek Çelik], [http://technorati.com/ Technorati]
* [http://blog.factoryjoe.com/ Chris Messina], [http://flock.com Flock, Inc.]
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix BlogMatrix, Inc.]
* [http://www.geof.net/ Geof Glass]

=== Interested Folks ===
* [http://theryanking.com/blog/ Ryan King], [http://technorati.com/ Technorati]

== Tools ==

=== Blogger ===
* http://www.blogger.com/home

Blogger is one the earliest, best known and probably most widely used blogging platform. Blogger was bought by [http://www.google.com Google] in February of 2003. Blogger allows users to create and edit their own templates and also provides a large number of (more or less) attractive templates from which the user can select. Unfortunately, you must log into a blogger account to see the template selection.

Here are several Blogger templates, randomly selected from the presets. More recent templates seem to be converging on a vocabulary for identifying parts of posts. This may because they share an evolutionary history from a common template. I've included three examples here:

<pre><nowiki>
<body>
<div id="content">
<div id="main">
ENTRIES
</div>
</div>
</body>

<h2 class="date-header">POST DATE</h2>
<div class="post">
<a name="POST #"></a>
<h3 class="post-title">
<a href="POST URI" title="external link">POST TITLE</a>
</h3>
<p>POST CONTENT</p>
<p class="post-footer">
<em>posted by AUTHOR @ <a href="POST URI" title="permanent link">POST DATETIME</a></em>
</p>
</div>
</nowiki></pre>

<pre><nowiki>
<body>
<div id="main">
<div id="main2">
ENTRIES
</div>
</div>
</body>

<div class="post">
<a name="POST #"></a>
<h3 class="post-title">
<a href="sample_post.html" title="permanent link">POST TITLE</a>
</h3>
<div class="post-body">
POST CONTENT
</div>
<p class="post-footer">
<em>posted by AUTHOR @ <a href="POST URI" title="permanent link">POST TIME</a></em>
</p>
</div>
</nowiki></pre>

<pre><nowiki>
<body>
<div id="leftcontent">
ENTRIES
</div>
</body>

<div class="Post">
<a name="POST #"></a>
POST CONTENT
<span class="PostFooter">
<a href="POST URI">POST TIME</a>
</span>
</div>
</nowiki></pre>

==== Key Class Names ====
* newer templates seem to use "main" to identify a enclosure for all entries
* newer templates use "post" to identify a weblog entry
* newer templates use "post-title" to identify the entry's title
* beyond this there is little standardization

==== Template Concepts ====
* all posts
* an individual post
* post title
* post author
* post posting time
* post content
* post URI (permalink)

=== Blosxom===
* http://www.blosxom.com/
* http://pyblosxom.sourceforge.net/

=== Drupal ===
* http://drupal.org
* varies per theme

=== LiveJournal ===
* http://www.livejournal.com/

=== MovableType ===
* http://www.sixapart.com/movabletype/

MovableType is a perl-based blogging platform. Note that the MT is old and widely deployed and there are very many different variants on the templates in the wild.

The standard template for the weblog's main page (the "[http://www.sixapart.com/movabletype/default_templates#main_index main index]") has the following structure:

<pre><nowiki>
<body>
<div class="content">
<h2>DATE HEADER</h2>
<h3 id="a####">POST TITLE</h3>
POST CONTENT
[ OPTIONAL LINK TO MORE POST CONTENT ]
<p class="posted">Posted by AUTHOR at <a href="POST URI">POST DATE</a>
</div>
</div>

<div class="content">
<p align="right">
<h2>POST DATE</h2>
</p>
<h3>POST TITLE</h3>
POST CONTENT
<div id="more">
MORE POST CONTENT (optional)
</div>
<p class="posted">Posted by AUTHOR at DATE</p>
</div>
</nowiki></pre>

==== Key Class Names ====

* "content" can enclose an individual entry or all entries, depending on the context
* "h2" encloses the post date (literally: the time is not included)
* "h3" encloses the title
* there is no standard enclosure for all the content
* there is no clear identification of "here's all the entries"
* there is no clear identification of the post's author
* the permalink is not necessarily on the page anywhere

==== Template Concepts ====
* all posts
* an individual post
* post title
* post author
* post posting time
* post content, which includes the next two
* post content (first part)
* post content (expended part)
* post URI (permalink)

=== TypePad ===
* http://www.sixapart.com/typepad/

Typepad is a MovableType hosting service. It provides a list of [http://help.typepad.com/tags/default_templates.html default templates] and [ "template modules"] from which users can construct or modify their own templates. Looking at several Typepad blogs, most or all of them following the nomenclature and struct defined by these templates.

The standard structure is as follows:

<pre><nowiki>
<body class="layout-two-column-right">
<div id="container">
<div id="container-inner" class="pkg">
<div id="pagebody">
<div id="pagebody-inner" class="pkg">
<div id="alpha">
<div id="alpha-inner" class="pkg">
INDIVIDUAL ENTRY
</div>
</div>
</div>
</div>
</div>
</div>
</body>

<div class="entry" id="entry-#####">
<h3 class="entry-header">POST TITLE</h3>
<div class="entry-content">
<div class="entry-body">
POST CONTENT
</div>
<a id="more"></a>
<div class="entry-more">
MORE POST CONTENT
</div>
</div>
<p class="entry-footer">
POST FOOTER
</p>
</div>
</nowiki></pre>

I cannot seem to track down in the templates where the POST FOOTER is defined. However, we can see the results from a [http://www.bluedogbob.com/ sample blog]:

<pre><nowiki>
<span class="post-footers">Posted by AUTHOR_NAME in CATEGORY</span>
<span class="separator">|</span>
<a class="permalink" href="ENTRY_URI">Permalink</a>
| <a href="COMMENT_URI">Comments (2)</a>
| <a href="TRACKBACKS_URI">TrackBack (0)</a>
</nowiki></pre>

==== Key Class Names ====
* "entry" encloses all elements within an entry
* "entry-content" contains all the entry text, plus additional text saying "here's more"
* "entry-header" contains the title of the post
* "permalink" contains the post's URI
* there is no clear identification of "here's all the entries"
* there is no clear identification of the post's author

==== Template Concepts ====
* all posts
* an individual post
* post title
* post author
* post posting time
* post content, which includes the next two
* post content (first part)
* post content (expended part)
* post URI (permalink)

=== WordPress ===
* http://wordpress.org

WordPress is a popular GPLed blogging system based on PHP and MySQL. WordPress calls their templates "themes" -- [http://wordpress.org/extend/themes/ more information]. Wordpress does not have a standardized set of class names for identifying parts of the weblog content. I've included a number of examples of what is seen in the wild (move to [[http://microformats.org/wiki/blog-post-examples examples]]?)

Example 1: [http://nokrev.com/older/ Fresh Bananas]

<pre><nowiki>
<body id="blog">
<div id="wrap">
<div id="content" class="two_column">
<div class="left">
ENTRIES
</div>
</div>
</div>
</body>

<h2>POST TITLE</h2>
POST CONTENT (PARTIAL)
<p>
<a href="POST URRI" title="Contiue reading this post">Continue reading</a>
</p>
</nowiki></pre>

Example 2: [http://www.vanillamist.com/blog/ VanillaMist]

<pre><nowiki>
<body>
<div id="main">
<div id="content">
ENTRIES
</div>
</div>
</body>

<div class="post">
<p class="post-date">Wed 6 Jul 2005
</p>
<div class="post-info">
<h2 class="post-title">
<a href="http://vanillamist.com/blog/?p=89" rel="bookmark" title="Permanent Link: Podcasts and a new version of Connections soon">Podcasts and a new version of Connections soon</a>
</h2>
Posted by AUTHOR under <a href="POST URI" title="View all posts in Blogs and Blogging" rel="category tag">CATEGORY</a>

<div class="post-content">
POST CONTENT
</div>

<div class="post-footer"> </div>
</div>
</div>
</nowiki></pre>

Example 3: [http://www.aamukaste.org/wpthemes/ Boredom]

<pre><nowiki>
<body>
<div id="content">
</div>
</body>

<div class="post">
<h2 id="post-5">
<a href="POST URI" rel="bookmark" title="Permanent Link to POST TITLE">POST TITLE</a>
</h2>
<small>POST DATE</small>
<div class="entry">
POST CONTENT
</div>
<p class="postmetadata">
</p>
</div>
</nowiki></pre>

==== Key Class Names ====
There is very little reuse amongst the various templates selected.

==== Template Concepts ====
* Post
* Title
* Author
* Date
* Content (partial)
* Content (full)

A list of all the template elemenents is [http://codex.wordpress.org/Template_Tags available here].

=== Xanga ===
* http://www.xanga.com/

== Journal Formats ==
Before blogs there were journals. Many journals were kept merely on people's computers and not necessarily published.

=== VJOURNAL ===

RFC2445 (iCalendar) defines the VJOURNAL object for storing journal entries which are essentially the same as blog posts. Note that [[hcalendar|hCalendar]] by virtue of referencing all of RFC 2445, could be said to define VJOURNAL class names.

The basic structure of a series of VJOURNAL entries:

<pre><nowiki>
VJOURNAL - 1
class - 0-1
classparam - 0-N
classvalue - 1; PUBLIC/PRIVATE/CONFIDENTIAL
created - 0-1
description - 0-1
altrepparm - 0-1
languageparam - 0-1
text - 1
dtstart - 0-1
dtstamp - 0-1
last-mod - 0-1
organizer - 0-1
cnparam - 0-1
dirparam - 0-1
sentbyparam - 0-1
languageparam - 0-1
caladdress - 1
recurid - 0-1
seq - 0-1
status - 0-1
statvalue - 1 DRAFT/FINAL/CANCELLED
summary - 0-1
altrepparm - 0-1
languageparam - 0-1
text - 1
uid - 0-1
url - 0-1
attach - 0-N
fmttype - 0-1; mime type
url - 1; url
attendee - 0-N
cutypeparam - 0-1
memberparam - 0-1
roleparam - 0-1
partstatparam - 0-1
rsvpparam - 0-1
deltoparam - 0-1
delfromparam - 0-1
sentbyparam - 0-1
cnparam - 0-1
dirparam - 0-1
languageparam - 0-1
caladdress - 1
categories - 0-N
languageparam - 0-1
text - 1-N; text
comment - 0-N
altrepparam - 0-1
language-param- 0-1
text - 1; text
contact - 0-N
altrepparam - 0-1
language-param- 0-1
text - 1; text
exdate - 0-N
xrule - 0-N
related - 0-N
reltypeparam - 0-1
text - other iCalendar component
rdate - 0-N
rrule - 0-N
rstatus - 0-N
</nowiki></pre>

Here are some example VJOURNAL entries from the rfc:

<pre><nowiki>
BEGIN:VJOURNAL
UID:19970901T130000Z-123405@host.com
DTSTAMP:19970901T1300Z
DTSTART;VALUE=DATE:19970317
SUMMARY:Staff meeting minutes
DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa
and Bob. Aurora project plans were reviewed. There is currently
no budget reserves for this project. Lisa will escalate to
management. Next meeting on Tuesday.\n
2. Telephone Conference: ABC Corp. sales representative called
to discuss new printer. Promised to get us a demo by Friday.\n
3. Henry Miller (Handsoff Insurance): Car was totaled by tree.
Is looking into a loaner car. 654-2323 (tel).
END:VJOURNAL

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ABC Corporation//NONSGML My Product//EN
BEGIN:VJOURNAL
DTSTAMP:19970324T120000Z
UID:uid5@host1.com
ORGANIZER:MAILTO:jsmith@host.com
STATUS:DRAFT
CLASS:PUBLIC
CATEGORY:Project Report, XYZ, Weekly Meeting
DESCRIPTION:Project xyz Review Meeting Minutes\n
Agenda\n1. Review of project version 1.0 requirements.\n2.
Definition
of project processes.\n3. Review of project schedule.\n
Participants: John Smith, Jane Doe, Jim Dandy\n-It was
decided that the requirements need to be signed off by
product marketing.\n-Project processes were accepted.\n
-Project schedule needs to account for scheduled holidays
and employee vacation time. Check with HR for specific
dates.\n-New schedule will be distributed by Friday.\n-
Next weeks meeting is cancelled. No meeting until 3/23.
END:VJOURNAL
END:VCALENDAR
</nowiki></pre>

== Syndication Feed Formats ==
All of the blogging tools above can produce syndication feeds from the same underlying content and thus prossibly worth discussing here.

[http://www.downes.ca/ Stephen Downes] postulates a [http://microformats.org/discuss/mail/microformats-discuss/2005-August/000670.html syndication/weblog equivalency rule], that RSS + XSLT = XHTML and XHTML + XSLT = RSS. In practice, this may not be exactly true due to syndication feeds often only provide summaries of the entry text and the definition of certain elements of syndications feeds may have ambiguous meaning or interpretation.

''This section may be moved elsewhere.''

=== Atom ===
* http://www.atomenabled.org/

Here is the basic structure of an Atom document, showing only required and recommended elements and the number of them that may appear (the rules are little more complicated than shown here, as some elements become optional or required depending on what else is included).

<pre><nowiki>
feed - 1
id - 1
title - 1; type "text"
updated - 1
link - 0-1 recommended; type "link"
author - 0-N recommended; type "person"
name - 1
email - 0-1 recommended
uri - 0-1 recommended
entry - 0-N
id - 1
title - 1; type "text"
updated - 1
published - 0-1
author - 0-N recommended; type "person"
content - 0-1 recommended; type "text";
"contains or links to the complete content of the entry"
link - 0-N recommended; type "link"
summary - 0-1 recommended; type "text"
</nowiki></pre>

A note about Atom types

* [http://www.atomenabled.org/developers/syndication/#person person] - describes a person, corporation, or similar entity
* [http://www.atomenabled.org/developers/syndication/#text text] - contains human-readable text; @text defines the encoding of the text itself: "text" (default), "html", "xhtml"
* [http://www.atomenabled.org/developers/syndication/#link link] - is patterned after html's [http://www.w3.org/TR/1999/REC-html401-19991224/struct/links.html#h-12.3 link element]; @href is required; @rel, @type, @hreflang, @title, and @length are optional.
* published and updated are datetimes

Here's an example Atom feed

<pre><nowiki>
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

<title>Example Feed</title>
<link href="http://example.org/"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>

<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
</entry>

</feed>
</nowiki></pre>

=== RSS 2.0 ===
* http://blogs.law.harvard.edu/tech/rss

RSS 2.0 is not to be confused with [http://web.resource.org/rss/1.0/ RSS 1.0] is based on RDF. More about the various versions of RSS and the reason for their existance can be read on [http://en.wikipedia.org/w/index.php?title=RSS_%28protocol%29 Wikipedia]

Here is the basic structure of an RSS document, showing only required and recommended elements and the number of them that may appear:

<pre><nowiki>
channel - 1
title - 1; type "text"
link - 1; type "link"
description - 1; type "text"
language - 0-1; type lang
copyright - 0-1; type text
managingEditor - 0-1; type email
webMaster - 0-1; type email
pubDate - 0-1; type rfc822
lastBuildDate - 0-1; type rfc822
category - 0-N; type text
@domain - 0-1; type uri
generator - 0-1; type text
docs - 0-1; type url
cloud - 0-1
@domain - 1; type url domain
@port - 1; type url port
@path - 1; type url path
@registerProcedure - 1; type token
@protocol - 1; type {http-post,xml-rpc,soap}
ttl - 0-1; type minutes
image - 0-1
url - 1; type url
title - 1; type text
link - 1; type url
width - 0-1; type pixels
description - 0-1; type text
rating - 0-1;
textInput - 0-1;
title 1
description 1
name 1
link 1
skipHours - 0-1;
skipDays - 0-1;
item - 0-N
title - 0-1*; type text
link - 0-1; type url
description - 0-1*; type text(?)
author - 0-1; type email
category - 0-N; type text
@domain - 0-1; type uri
comments - 0-1; type url
enclosure - 0-N;
@url - 1; type url
@length - 1; type bytes
@type - 1; type mime
guid - 0-1; type text
@isPermalink - 0-1; if true, text is a url
pubDate - 0-1; type rfc822
source - 0-1; type text
@url - 1; type url

* One of title or description must be present
</nowiki></pre>

Here's an example RSS 2.0 feed [''some editing needed internally to make entities show the correct way'']:

<pre><nowiki>
<?xml version="1.0"?>
<rss version="2.0">
<channel>
<title>Liftoff News</title>
<link>http://liftoff.msfc.nasa.gov/</link>
<description>Liftoff to Space Exploration.</description>
<language>en-us</language>
<pubDate>Tue, 10 Jun 2003 04:00:00 GMT</pubDate>
<item>

<title>Star City</title>
<link>http://liftoff.msfc.nasa.gov/news/2003/news-starcity.asp</link>
<description>How do Americans ...
<a href="http://howe.iki.rssi.ru/GCTC/gctc_e.htm">Star City</a>.
</description>
<pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
<guid>http://liftoff.msfc.nasa.gov/2003/06/03.html#item573</guid>

</item>
</channel>
</rss>
</nowiki></pre>

=== An XHTML profile for RDF Site Summaries ===
See [http://www.w3.org/2000/08/w3c-synd/ Site Summaries in XHTML], used in production for the W3C RSS feed for several years now.
* TODO: fill this out

== Discussion Forum / Bulletin Board Formats ==

Discussion forum posts are similar to blog posts, so may be relevant. Due to the complexity of table-based layouts, much of the mark-up in the following examples has been stripped. The mark-up and analysis also excludes controls (such as reply buttons).

=== Moodle ===
* http://moodle.org/

Moodle is an open source course management system used in education. It includes a discussion forum. The forum does not support templating.

<pre><nowiki>
<body class="mod-forum" id="mod-forum-discuss">
<div id="page">
<div id="header">
<div class="headermain">COURSE TITLE</div>
<div class="headermenu">(controls)</div>
</div>
<table class="navbar">
<tr>
<td>
<div class="breadcrumb">
<a href="BREADCRUMB LINK">BREADCRUMB TITLE</a>+
</div>
(controls)
</td>
</tr>
</table>
<div id="content">
(controls)
ENTRIES
</div>
</div>
</body>

<table class="forumpost">
<tr>
<td>
<img src="AVATAR"/>
</td>
<td class="topic">
<div class="subject">POST TITLE</div>
<div class="author">by <a>AUTHOR</a> - POST DATE</div>
</td>
</tr>
<tr>
<td class="content">
POST CONTENT
<div class="commands"><a>Show Parent</a> | <a>Reply</a></div>
</td>
</tr>
</table>
</nowiki></pre>

==== Key Class Names ====

* "headermain" identifies the course title
* "breadcrumb" identifies breadcrumbs
* "forumpost" identifies a post
* "subject" identifies the post subject
* "author" identifies the author, but also includes the date and other text
* "content" identifies the content area, but includes some controls also

==== Concepts ====

* course title
* breadcrumb titles and links
* post title
* post author
* post date
* post content
* original post (to which this is a reply)
* author avatar

=== phpBB ===
* http://www.phpbb.com/

phpBB is a popular GPL discussion forum system. This is based on the forum on the [http://www.phpbb.com/phpBB/ phpBB] website.

<pre><nowiki>
<body>
<table>
<tr>
<td class="bodyline" bgcolor="white">
<table width="100%" cellspacing="0" cellpadding="10" border="0">
<tr>
<td>
<table>
<tr>
<td>
<a class="maintitle" href="FORUM LINK">FORUM TITLE</a>
</td>
</tr>
</table>
<table width="100%" cellspacing="2" cellpadding="2" border="0">
<tr>
(controls)
<td align="left" valign="middle" width="100%">
<span class="nav"><a href="BREADCRUMB LINK" class="nav">BREADCRUMB TITLE</a>+</span>
</td>
</tr>
</table>

ENTRIES
(controls)
(repeat of controls and navigation)
...
</table>
</body>

<table class="forumline">
<tr>
<td class="catHead">(controls)</td>
</tr>
<tr>
<td class="row1">
<span class="name">
<a name="###"></a>
<b>AUTHOR</b>
</span>
<span class="postdetails">
AUTHOR STATUS (registered etc.)
<img src="AVATAR"/>
Joined: AUTHOR JOIN DATE
Posts: AUTHOR POST COUNT
Location: etc.
</span>
</td>
<td class="row1">
<table>
<tr>
<td>
<span class="postdetails">Posted: POST DATE Post subject: POST TITLE</span>
</td>
<td>(controls)</td>
</tr>
<tr>
<td>
<span class="postbody">
CONTENT
</span>
</td>
</tr>
</table>
</td>
</tr>
(controls)
</table>
</nowiki></pre>

==== Key Class Names ====

* "maintitle" identifies the forum title and link
* "nav" is used for breadcrumbs
* "forumline" encloses the post
* "name" identifies the author
* "postdetails" occurs twice, once providing information about the author, once enclosing the post date and title
* "postbody" identifies the post content

==== Concepts ====

* forum title and link
* breadcrumb titles and links
* post title
* post author
* post date
* post content
* author status
* author join date
* author avatar
* author post count
* author location

=== PunBB ===

* http://punbb.org/

PunBB is GPL forum software. This structure is from the [http://forums.punbb.org/ forum] on their web site.

<pre><nowiki>
<body>
<div id="punwrap">
<div id="punviewtopic" class="pun">
<div id="brdheader" class="block">
<div class="box">
<div id="brdtitle" class="inbox">
<h1><span>SITE SECTION TITLE</span></h1>
<p><span>SITE SECTION BYLINE</span></p>
</div>
(controls)
</div>
</div>
<div id="announce" class="block">
<h2><span>ANNOUNCEMENT TITLE</span></h2>
<div class="box">
<div class="inbox">
<div><span class="warntext">ANNOUNCEMENT CONTENT</span></div>
</div>
</div>
</div>
<div class="linkst">
<div class="inbox">
(controls)
<ul>
<li><a href="BREADCRUMB LINK">BREADCRUMB TITLE</a></li>+
</ul>
</div>
</div>
ENTRIES
</div>
</body>

<div id="HTML-ID" class="blockpost">
<h2>
<span class="conr">POST NUMBER</span>
<a href="PERMALINK">POST DATE</a></h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><a href="AUTHOR PROFILE LINK">AUTHOR NAME</a></strong></dt>
<dd class="usertitle"><strong>AUTHOR STATUS (e.g. Moderator)</strong></dd>
<dd class="postavatar"><img src="AVATAR"/></dd>
<dd>From: AUTHOR LOCATION</dd>
<dd>Registered: AUTHOR REGISTRATION DATE</dd>
<dd>Posts: AUTHOR POST COUNT</dd>
<dd class="usercontacts"><a href="AUTHOR URL">Website</a></dd>
</dl>
</div>
<div class="postright">
<h3>POST TITLE</h3>
<div class="postmsg">
POST CONTENT
</div>
<div class="postsignature">AUTHOR SIGNATURE</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>AUTHOR STATE (online, offline)</p></div>
<div class="postfootright"><div></div></div>
</div>
</div>
</div>
</nowiki></pre>

==== Key Class Names ====

* "blockpost" encloses a post; the element also has an HTML id
* "conr" is the post number within the discussion thread
* h1 indicates the site section title
* "announce" and "warntext" indicate the announcement title and content
* ul inside "linkst" identifies breadcrumbs
* h2 encloses the post number, post date, and permalink, distinguishable by HTML a and span elements
* h3 identifies the post title
* "postmsg" identifies the post content
* the author name and URL are in dl dt a
* additional author information is in dl dd
* "usertitle" identifies the author status
* "postavatar" indentifies the author's avatar
* "usercontacts" identifies author contact information

==== Concepts ====

* site section title and byline
* announcement title and content
* breadcrumb titles and links
* post title
* post author
* post date
* permalink
* post sequence number
* author status
* author avatar
* author location
* author registration date
* author post count
* author URL
* author profile link
* author signature
* author contact information (website)

=== YaBB ===
* http://www.yabbforum.com/

YaBB is a popular commercial/free forum system. This example is based on the [http://www.yabbforum.com/community/ forum] on the YaBB site. I have stripped some presentational class names.

<pre><nowiki>
<body>
<div class="container">
<div class="maincontent">
<div class="seperator">
<table>
(controls, login)
<tr>
<td>
<span id="fscroller">FORUM WELCOME</span>
(controls)
</td>
</tr>
</table>
</div>
<div class="navbarcontainer">
<table>
<tr>
<td>
<span>
<b><a href="BREADCRUMB LINK" class="nav">BREADCRUMB TITLE</a>+</b>
(Moderators: <a href="MODERATOR LINK">MODERATOR NAME</a>+)
<div class="seperator">
<table>
<tr>
<td>
<span>FORUM DESCRIPTION.</span>
</td>
</tr>
</table>
</div>
</span>
</td>
(controls)
</tr>
</table>
</div>
ENTRIES
</div>
(repeat of navigation)
</div>
</body>

<div class="displaycontainer">
<table>
<tr>
<td>
<a><b>POST TITLE</b></a>
AUTHOR STATUS (junior member, senior, etc.)<br />
<img src="<AVATAR>" />
AUTHOR BYLINE
Posts: ###
Gender: <img/>
</td>
<td>
<div>
<b>POST TITLE</b>
<span><b>Reply #nnn on:</b> POST DATE</span>
</div>
<div>
<span class="message">
CONTENT
</span>
</div>
</td>
</tr>
<tr>(controls)</tr>
</table>
</div>
</nowiki></pre>

==== Key Class Names ====

* "displaycontainer" encloses a post
* "message" identifies post content
* no other fields are identified by meaningful mark-up

==== Concepts ====

* forum welcome message
* forum description
* forum moderators (names and links)
* breadcrumbs (titles and links)
* post title
* post author
* post date
* post content
* original post (to which this is a reply)
* author status
* author byline
* author avatar
* author gender
* author post count

== Examples from the wild ==

* Early work on extending standardized nodes in Drupal: http://factorycity.net/demos/drupal/event_system/microformats/
* Microformat-style hooks in forum posts for Javascript annotation: http://www.geof.net/code/annotation/technical.html#microformats

=See Also=
* [[hatom|hAtom]] - the draft proposal based on this information
* [[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)

blog-post-formats

2005-12-31T20:40:11Z

FuzzyBSc: Fill out VJOURNAL structure and example

= Current Blog Formats =

There is a need for developing standard classes for blog posts (i.e. a microformat!).

This page serves to document the current list of individual blog post schemas, formats, and efforts as background for the design of a simple blog post MicroFormat.

== Discussion Participants ==

=== Editor ===
* [http://blog.factoryjoe.com/ Chris Messina], [http://flock.com Flock, Inc.]

=== Authors ===
* [http://tantek.com/log/ Tantek Çelik], [http://technorati.com/ Technorati]
* [http://blog.factoryjoe.com/ Chris Messina], [http://flock.com Flock, Inc.]
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix BlogMatrix, Inc.]
* [http://www.geof.net/ Geof Glass]

=== Interested Folks ===
* [http://theryanking.com/blog/ Ryan King], [http://technorati.com/ Technorati]

== Tools ==

=== Blogger ===
* http://www.blogger.com/home

Blogger is one the earliest, best known and probably most widely used blogging platform. Blogger was bought by [http://www.google.com Google] in February of 2003. Blogger allows users to create and edit their own templates and also provides a large number of (more or less) attractive templates from which the user can select. Unfortunately, you must log into a blogger account to see the template selection.

Here are several Blogger templates, randomly selected from the presets. More recent templates seem to be converging on a vocabulary for identifying parts of posts. This may because they share an evolutionary history from a common template. I've included three examples here:

<pre><nowiki>
<body>
<div id="content">
<div id="main">
ENTRIES
</div>
</div>
</body>

<h2 class="date-header">POST DATE</h2>
<div class="post">
<a name="POST #"></a>
<h3 class="post-title">
<a href="POST URI" title="external link">POST TITLE</a>
</h3>
<p>POST CONTENT</p>
<p class="post-footer">
<em>posted by AUTHOR @ <a href="POST URI" title="permanent link">POST DATETIME</a></em>
</p>
</div>
</nowiki></pre>

<pre><nowiki>
<body>
<div id="main">
<div id="main2">
ENTRIES
</div>
</div>
</body>

<div class="post">
<a name="POST #"></a>
<h3 class="post-title">
<a href="sample_post.html" title="permanent link">POST TITLE</a>
</h3>
<div class="post-body">
POST CONTENT
</div>
<p class="post-footer">
<em>posted by AUTHOR @ <a href="POST URI" title="permanent link">POST TIME</a></em>
</p>
</div>
</nowiki></pre>

<pre><nowiki>
<body>
<div id="leftcontent">
ENTRIES
</div>
</body>

<div class="Post">
<a name="POST #"></a>
POST CONTENT
<span class="PostFooter">
<a href="POST URI">POST TIME</a>
</span>
</div>
</nowiki></pre>

==== Key Class Names ====
* newer templates seem to use "main" to identify a enclosure for all entries
* newer templates use "post" to identify a weblog entry
* newer templates use "post-title" to identify the entry's title
* beyond this there is little standardization

==== Template Concepts ====
* all posts
* an individual post
* post title
* post author
* post posting time
* post content
* post URI (permalink)

=== Blosxom===
* http://www.blosxom.com/
* http://pyblosxom.sourceforge.net/

=== Drupal ===
* http://drupal.org
* varies per theme

=== LiveJournal ===
* http://www.livejournal.com/

=== MovableType ===
* http://www.sixapart.com/movabletype/

MovableType is a perl-based blogging platform. Note that the MT is old and widely deployed and there are very many different variants on the templates in the wild.

The standard template for the weblog's main page (the "[http://www.sixapart.com/movabletype/default_templates#main_index main index]") has the following structure:

<pre><nowiki>
<body>
<div class="content">
<h2>DATE HEADER</h2>
<h3 id="a####">POST TITLE</h3>
POST CONTENT
[ OPTIONAL LINK TO MORE POST CONTENT ]
<p class="posted">Posted by AUTHOR at <a href="POST URI">POST DATE</a>
</div>
</div>

<div class="content">
<p align="right">
<h2>POST DATE</h2>
</p>
<h3>POST TITLE</h3>
POST CONTENT
<div id="more">
MORE POST CONTENT (optional)
</div>
<p class="posted">Posted by AUTHOR at DATE</p>
</div>
</nowiki></pre>

==== Key Class Names ====

* "content" can enclose an individual entry or all entries, depending on the context
* "h2" encloses the post date (literally: the time is not included)
* "h3" encloses the title
* there is no standard enclosure for all the content
* there is no clear identification of "here's all the entries"
* there is no clear identification of the post's author
* the permalink is not necessarily on the page anywhere

==== Template Concepts ====
* all posts
* an individual post
* post title
* post author
* post posting time
* post content, which includes the next two
* post content (first part)
* post content (expended part)
* post URI (permalink)

=== TypePad ===
* http://www.sixapart.com/typepad/

Typepad is a MovableType hosting service. It provides a list of [http://help.typepad.com/tags/default_templates.html default templates] and [ "template modules"] from which users can construct or modify their own templates. Looking at several Typepad blogs, most or all of them following the nomenclature and struct defined by these templates.

The standard structure is as follows:

<pre><nowiki>
<body class="layout-two-column-right">
<div id="container">
<div id="container-inner" class="pkg">
<div id="pagebody">
<div id="pagebody-inner" class="pkg">
<div id="alpha">
<div id="alpha-inner" class="pkg">
INDIVIDUAL ENTRY
</div>
</div>
</div>
</div>
</div>
</div>
</body>

<div class="entry" id="entry-#####">
<h3 class="entry-header">POST TITLE</h3>
<div class="entry-content">
<div class="entry-body">
POST CONTENT
</div>
<a id="more"></a>
<div class="entry-more">
MORE POST CONTENT
</div>
</div>
<p class="entry-footer">
POST FOOTER
</p>
</div>
</nowiki></pre>

I cannot seem to track down in the templates where the POST FOOTER is defined. However, we can see the results from a [http://www.bluedogbob.com/ sample blog]:

<pre><nowiki>
<span class="post-footers">Posted by AUTHOR_NAME in CATEGORY</span>
<span class="separator">|</span>
<a class="permalink" href="ENTRY_URI">Permalink</a>
| <a href="COMMENT_URI">Comments (2)</a>
| <a href="TRACKBACKS_URI">TrackBack (0)</a>
</nowiki></pre>

==== Key Class Names ====
* "entry" encloses all elements within an entry
* "entry-content" contains all the entry text, plus additional text saying "here's more"
* "entry-header" contains the title of the post
* "permalink" contains the post's URI
* there is no clear identification of "here's all the entries"
* there is no clear identification of the post's author

==== Template Concepts ====
* all posts
* an individual post
* post title
* post author
* post posting time
* post content, which includes the next two
* post content (first part)
* post content (expended part)
* post URI (permalink)

=== WordPress ===
* http://wordpress.org

WordPress is a popular GPLed blogging system based on PHP and MySQL. WordPress calls their templates "themes" -- [http://wordpress.org/extend/themes/ more information]. Wordpress does not have a standardized set of class names for identifying parts of the weblog content. I've included a number of examples of what is seen in the wild (move to [[http://microformats.org/wiki/blog-post-examples examples]]?)

Example 1: [http://nokrev.com/older/ Fresh Bananas]

<pre><nowiki>
<body id="blog">
<div id="wrap">
<div id="content" class="two_column">
<div class="left">
ENTRIES
</div>
</div>
</div>
</body>

<h2>POST TITLE</h2>
POST CONTENT (PARTIAL)
<p>
<a href="POST URRI" title="Contiue reading this post">Continue reading</a>
</p>
</nowiki></pre>

Example 2: [http://www.vanillamist.com/blog/ VanillaMist]

<pre><nowiki>
<body>
<div id="main">
<div id="content">
ENTRIES
</div>
</div>
</body>

<div class="post">
<p class="post-date">Wed 6 Jul 2005
</p>
<div class="post-info">
<h2 class="post-title">
<a href="http://vanillamist.com/blog/?p=89" rel="bookmark" title="Permanent Link: Podcasts and a new version of Connections soon">Podcasts and a new version of Connections soon</a>
</h2>
Posted by AUTHOR under <a href="POST URI" title="View all posts in Blogs and Blogging" rel="category tag">CATEGORY</a>

<div class="post-content">
POST CONTENT
</div>

<div class="post-footer"> </div>
</div>
</div>
</nowiki></pre>

Example 3: [http://www.aamukaste.org/wpthemes/ Boredom]

<pre><nowiki>
<body>
<div id="content">
</div>
</body>

<div class="post">
<h2 id="post-5">
<a href="POST URI" rel="bookmark" title="Permanent Link to POST TITLE">POST TITLE</a>
</h2>
<small>POST DATE</small>
<div class="entry">
POST CONTENT
</div>
<p class="postmetadata">
</p>
</div>
</nowiki></pre>

==== Key Class Names ====
There is very little reuse amongst the various templates selected.

==== Template Concepts ====
* Post
* Title
* Author
* Date
* Content (partial)
* Content (full)

A list of all the template elemenents is [http://codex.wordpress.org/Template_Tags available here].

=== Xanga ===
* http://www.xanga.com/

== Journal Formats ==
Before blogs there were journals. Many journals were kept merely on people's computers and not necessarily published.

=== VJOURNAL ===

RFC2445 (iCalendar) defines the VJOURNAL object for storing journal entries which are essentially the same as blog posts. Note that [[hcalendar|hCalendar]] by virtue of referencing all of RFC 2445, could be said to define VJOURNAL class names.

The basic structure of a series of VJOURNAL entries:

<pre><nowiki>
VJOURNAL - 1
class - 0-1
created - 0-1
description - 0-1
dtstart - 0-1
dtstamp - 0-1
last-mod - 0-1
organizer - 0-1
recurid - 0-1
seq - 0-1
status - 0-1
summary - 0-1
uid - 0-1
url - 0-1
attach - 0-N
attendee - 0-N
categories - 0-N
comment - 0-N
contract - 0-N
exdate - 0-N
xrule - 0-N
related - 0-N
rdate - 0-N
rrule - 0-N
rstatus - 0-N
x-prop - 0-N
</nowiki></pre>

Here's an example VJOURNAL entry from the rfc:

<pre><nowiki>
BEGIN:VJOURNAL
UID:19970901T130000Z-123405@host.com
DTSTAMP:19970901T1300Z
DTSTART;VALUE=DATE:19970317
SUMMARY:Staff meeting minutes
DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa
and Bob. Aurora project plans were reviewed. There is currently
no budget reserves for this project. Lisa will escalate to
management. Next meeting on Tuesday.\n
2. Telephone Conference: ABC Corp. sales representative called
to discuss new printer. Promised to get us a demo by Friday.\n
3. Henry Miller (Handsoff Insurance): Car was totaled by tree.
Is looking into a loaner car. 654-2323 (tel).
END:VJOURNAL
</nowiki></pre>

== Syndication Feed Formats ==
All of the blogging tools above can produce syndication feeds from the same underlying content and thus prossibly worth discussing here.

[http://www.downes.ca/ Stephen Downes] postulates a [http://microformats.org/discuss/mail/microformats-discuss/2005-August/000670.html syndication/weblog equivalency rule], that RSS + XSLT = XHTML and XHTML + XSLT = RSS. In practice, this may not be exactly true due to syndication feeds often only provide summaries of the entry text and the definition of certain elements of syndications feeds may have ambiguous meaning or interpretation.

''This section may be moved elsewhere.''

=== Atom ===
* http://www.atomenabled.org/

Here is the basic structure of an Atom document, showing only required and recommended elements and the number of them that may appear (the rules are little more complicated than shown here, as some elements become optional or required depending on what else is included).

<pre><nowiki>
feed - 1
id - 1
title - 1; type "text"
updated - 1
link - 0-1 recommended; type "link"
author - 0-N recommended; type "person"
name - 1
email - 0-1 recommended
uri - 0-1 recommended
entry - 0-N
id - 1
title - 1; type "text"
updated - 1
published - 0-1
author - 0-N recommended; type "person"
content - 0-1 recommended; type "text";
"contains or links to the complete content of the entry"
link - 0-N recommended; type "link"
summary - 0-1 recommended; type "text"
</nowiki></pre>

A note about Atom types

* [http://www.atomenabled.org/developers/syndication/#person person] - describes a person, corporation, or similar entity
* [http://www.atomenabled.org/developers/syndication/#text text] - contains human-readable text; @text defines the encoding of the text itself: "text" (default), "html", "xhtml"
* [http://www.atomenabled.org/developers/syndication/#link link] - is patterned after html's [http://www.w3.org/TR/1999/REC-html401-19991224/struct/links.html#h-12.3 link element]; @href is required; @rel, @type, @hreflang, @title, and @length are optional.
* published and updated are datetimes

Here's an example Atom feed

<pre><nowiki>
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

<title>Example Feed</title>
<link href="http://example.org/"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>

<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
</entry>

</feed>
</nowiki></pre>

=== RSS 2.0 ===
* http://blogs.law.harvard.edu/tech/rss

RSS 2.0 is not to be confused with [http://web.resource.org/rss/1.0/ RSS 1.0] is based on RDF. More about the various versions of RSS and the reason for their existance can be read on [http://en.wikipedia.org/w/index.php?title=RSS_%28protocol%29 Wikipedia]

Here is the basic structure of an RSS document, showing only required and recommended elements and the number of them that may appear:

<pre><nowiki>
channel - 1
title - 1; type "text"
link - 1; type "link"
description - 1; type "text"
language - 0-1; type lang
copyright - 0-1; type text
managingEditor - 0-1; type email
webMaster - 0-1; type email
pubDate - 0-1; type rfc822
lastBuildDate - 0-1; type rfc822
category - 0-N; type text
@domain - 0-1; type uri
generator - 0-1; type text
docs - 0-1; type url
cloud - 0-1
@domain - 1; type url domain
@port - 1; type url port
@path - 1; type url path
@registerProcedure - 1; type token
@protocol - 1; type {http-post,xml-rpc,soap}
ttl - 0-1; type minutes
image - 0-1
url - 1; type url
title - 1; type text
link - 1; type url
width - 0-1; type pixels
description - 0-1; type text
rating - 0-1;
textInput - 0-1;
title 1
description 1
name 1
link 1
skipHours - 0-1;
skipDays - 0-1;
item - 0-N
title - 0-1*; type text
link - 0-1; type url
description - 0-1*; type text(?)
author - 0-1; type email
category - 0-N; type text
@domain - 0-1; type uri
comments - 0-1; type url
enclosure - 0-N;
@url - 1; type url
@length - 1; type bytes
@type - 1; type mime
guid - 0-1; type text
@isPermalink - 0-1; if true, text is a url
pubDate - 0-1; type rfc822
source - 0-1; type text
@url - 1; type url

* One of title or description must be present
</nowiki></pre>

Here's an example RSS 2.0 feed [''some editing needed internally to make entities show the correct way'']:

<pre><nowiki>
<?xml version="1.0"?>
<rss version="2.0">
<channel>
<title>Liftoff News</title>
<link>http://liftoff.msfc.nasa.gov/</link>
<description>Liftoff to Space Exploration.</description>
<language>en-us</language>
<pubDate>Tue, 10 Jun 2003 04:00:00 GMT</pubDate>
<item>

<title>Star City</title>
<link>http://liftoff.msfc.nasa.gov/news/2003/news-starcity.asp</link>
<description>How do Americans ...
<a href="http://howe.iki.rssi.ru/GCTC/gctc_e.htm">Star City</a>.
</description>
<pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
<guid>http://liftoff.msfc.nasa.gov/2003/06/03.html#item573</guid>

</item>
</channel>
</rss>
</nowiki></pre>

=== An XHTML profile for RDF Site Summaries ===
See [http://www.w3.org/2000/08/w3c-synd/ Site Summaries in XHTML], used in production for the W3C RSS feed for several years now.
* TODO: fill this out

== Discussion Forum / Bulletin Board Formats ==

Discussion forum posts are similar to blog posts, so may be relevant. Due to the complexity of table-based layouts, much of the mark-up in the following examples has been stripped. The mark-up and analysis also excludes controls (such as reply buttons).

=== Moodle ===
* http://moodle.org/

Moodle is an open source course management system used in education. It includes a discussion forum. The forum does not support templating.

<pre><nowiki>
<body class="mod-forum" id="mod-forum-discuss">
<div id="page">
<div id="header">
<div class="headermain">COURSE TITLE</div>
<div class="headermenu">(controls)</div>
</div>
<table class="navbar">
<tr>
<td>
<div class="breadcrumb">
<a href="BREADCRUMB LINK">BREADCRUMB TITLE</a>+
</div>
(controls)
</td>
</tr>
</table>
<div id="content">
(controls)
ENTRIES
</div>
</div>
</body>

<table class="forumpost">
<tr>
<td>
<img src="AVATAR"/>
</td>
<td class="topic">
<div class="subject">POST TITLE</div>
<div class="author">by <a>AUTHOR</a> - POST DATE</div>
</td>
</tr>
<tr>
<td class="content">
POST CONTENT
<div class="commands"><a>Show Parent</a> | <a>Reply</a></div>
</td>
</tr>
</table>
</nowiki></pre>

==== Key Class Names ====

* "headermain" identifies the course title
* "breadcrumb" identifies breadcrumbs
* "forumpost" identifies a post
* "subject" identifies the post subject
* "author" identifies the author, but also includes the date and other text
* "content" identifies the content area, but includes some controls also

==== Concepts ====

* course title
* breadcrumb titles and links
* post title
* post author
* post date
* post content
* original post (to which this is a reply)
* author avatar

=== phpBB ===
* http://www.phpbb.com/

phpBB is a popular GPL discussion forum system. This is based on the forum on the [http://www.phpbb.com/phpBB/ phpBB] website.

<pre><nowiki>
<body>
<table>
<tr>
<td class="bodyline" bgcolor="white">
<table width="100%" cellspacing="0" cellpadding="10" border="0">
<tr>
<td>
<table>
<tr>
<td>
<a class="maintitle" href="FORUM LINK">FORUM TITLE</a>
</td>
</tr>
</table>
<table width="100%" cellspacing="2" cellpadding="2" border="0">
<tr>
(controls)
<td align="left" valign="middle" width="100%">
<span class="nav"><a href="BREADCRUMB LINK" class="nav">BREADCRUMB TITLE</a>+</span>
</td>
</tr>
</table>

ENTRIES
(controls)
(repeat of controls and navigation)
...
</table>
</body>

<table class="forumline">
<tr>
<td class="catHead">(controls)</td>
</tr>
<tr>
<td class="row1">
<span class="name">
<a name="###"></a>
<b>AUTHOR</b>
</span>
<span class="postdetails">
AUTHOR STATUS (registered etc.)
<img src="AVATAR"/>
Joined: AUTHOR JOIN DATE
Posts: AUTHOR POST COUNT
Location: etc.
</span>
</td>
<td class="row1">
<table>
<tr>
<td>
<span class="postdetails">Posted: POST DATE Post subject: POST TITLE</span>
</td>
<td>(controls)</td>
</tr>
<tr>
<td>
<span class="postbody">
CONTENT
</span>
</td>
</tr>
</table>
</td>
</tr>
(controls)
</table>
</nowiki></pre>

==== Key Class Names ====

* "maintitle" identifies the forum title and link
* "nav" is used for breadcrumbs
* "forumline" encloses the post
* "name" identifies the author
* "postdetails" occurs twice, once providing information about the author, once enclosing the post date and title
* "postbody" identifies the post content

==== Concepts ====

* forum title and link
* breadcrumb titles and links
* post title
* post author
* post date
* post content
* author status
* author join date
* author avatar
* author post count
* author location

=== PunBB ===

* http://punbb.org/

PunBB is GPL forum software. This structure is from the [http://forums.punbb.org/ forum] on their web site.

<pre><nowiki>
<body>
<div id="punwrap">
<div id="punviewtopic" class="pun">
<div id="brdheader" class="block">
<div class="box">
<div id="brdtitle" class="inbox">
<h1><span>SITE SECTION TITLE</span></h1>
<p><span>SITE SECTION BYLINE</span></p>
</div>
(controls)
</div>
</div>
<div id="announce" class="block">
<h2><span>ANNOUNCEMENT TITLE</span></h2>
<div class="box">
<div class="inbox">
<div><span class="warntext">ANNOUNCEMENT CONTENT</span></div>
</div>
</div>
</div>
<div class="linkst">
<div class="inbox">
(controls)
<ul>
<li><a href="BREADCRUMB LINK">BREADCRUMB TITLE</a></li>+
</ul>
</div>
</div>
ENTRIES
</div>
</body>

<div id="HTML-ID" class="blockpost">
<h2>
<span class="conr">POST NUMBER</span>
<a href="PERMALINK">POST DATE</a></h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><a href="AUTHOR PROFILE LINK">AUTHOR NAME</a></strong></dt>
<dd class="usertitle"><strong>AUTHOR STATUS (e.g. Moderator)</strong></dd>
<dd class="postavatar"><img src="AVATAR"/></dd>
<dd>From: AUTHOR LOCATION</dd>
<dd>Registered: AUTHOR REGISTRATION DATE</dd>
<dd>Posts: AUTHOR POST COUNT</dd>
<dd class="usercontacts"><a href="AUTHOR URL">Website</a></dd>
</dl>
</div>
<div class="postright">
<h3>POST TITLE</h3>
<div class="postmsg">
POST CONTENT
</div>
<div class="postsignature">AUTHOR SIGNATURE</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>AUTHOR STATE (online, offline)</p></div>
<div class="postfootright"><div></div></div>
</div>
</div>
</div>
</nowiki></pre>

==== Key Class Names ====

* "blockpost" encloses a post; the element also has an HTML id
* "conr" is the post number within the discussion thread
* h1 indicates the site section title
* "announce" and "warntext" indicate the announcement title and content
* ul inside "linkst" identifies breadcrumbs
* h2 encloses the post number, post date, and permalink, distinguishable by HTML a and span elements
* h3 identifies the post title
* "postmsg" identifies the post content
* the author name and URL are in dl dt a
* additional author information is in dl dd
* "usertitle" identifies the author status
* "postavatar" indentifies the author's avatar
* "usercontacts" identifies author contact information

==== Concepts ====

* site section title and byline
* announcement title and content
* breadcrumb titles and links
* post title
* post author
* post date
* permalink
* post sequence number
* author status
* author avatar
* author location
* author registration date
* author post count
* author URL
* author profile link
* author signature
* author contact information (website)

=== YaBB ===
* http://www.yabbforum.com/

YaBB is a popular commercial/free forum system. This example is based on the [http://www.yabbforum.com/community/ forum] on the YaBB site. I have stripped some presentational class names.

<pre><nowiki>
<body>
<div class="container">
<div class="maincontent">
<div class="seperator">
<table>
(controls, login)
<tr>
<td>
<span id="fscroller">FORUM WELCOME</span>
(controls)
</td>
</tr>
</table>
</div>
<div class="navbarcontainer">
<table>
<tr>
<td>
<span>
<b><a href="BREADCRUMB LINK" class="nav">BREADCRUMB TITLE</a>+</b>
(Moderators: <a href="MODERATOR LINK">MODERATOR NAME</a>+)
<div class="seperator">
<table>
<tr>
<td>
<span>FORUM DESCRIPTION.</span>
</td>
</tr>
</table>
</div>
</span>
</td>
(controls)
</tr>
</table>
</div>
ENTRIES
</div>
(repeat of navigation)
</div>
</body>

<div class="displaycontainer">
<table>
<tr>
<td>
<a><b>POST TITLE</b></a>
AUTHOR STATUS (junior member, senior, etc.)<br />
<img src="<AVATAR>" />
AUTHOR BYLINE
Posts: ###
Gender: <img/>
</td>
<td>
<div>
<b>POST TITLE</b>
<span><b>Reply #nnn on:</b> POST DATE</span>
</div>
<div>
<span class="message">
CONTENT
</span>
</div>
</td>
</tr>
<tr>(controls)</tr>
</table>
</div>
</nowiki></pre>

==== Key Class Names ====

* "displaycontainer" encloses a post
* "message" identifies post content
* no other fields are identified by meaningful mark-up

==== Concepts ====

* forum welcome message
* forum description
* forum moderators (names and links)
* breadcrumbs (titles and links)
* post title
* post author
* post date
* post content
* original post (to which this is a reply)
* author status
* author byline
* author avatar
* author gender
* author post count

== Examples from the wild ==

* Early work on extending standardized nodes in Drupal: http://factorycity.net/demos/drupal/event_system/microformats/
* Microformat-style hooks in forum posts for Javascript annotation: http://www.geof.net/code/annotation/technical.html#microformats

=See Also=
* [[hatom|hAtom]] - the draft proposal based on this information
* [[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)

blog-post-formats

2005-12-31T20:20:14Z

FuzzyBSc: Add RSS 2.0 structure

= Current Blog Formats =

There is a need for developing standard classes for blog posts (i.e. a microformat!).

This page serves to document the current list of individual blog post schemas, formats, and efforts as background for the design of a simple blog post MicroFormat.

== Discussion Participants ==

=== Editor ===
* [http://blog.factoryjoe.com/ Chris Messina], [http://flock.com Flock, Inc.]

=== Authors ===
* [http://tantek.com/log/ Tantek Çelik], [http://technorati.com/ Technorati]
* [http://blog.factoryjoe.com/ Chris Messina], [http://flock.com Flock, Inc.]
* [http://blogmatrix.blogmatrix.com/ David Janes], [http://www.blogmatrix BlogMatrix, Inc.]
* [http://www.geof.net/ Geof Glass]

=== Interested Folks ===
* [http://theryanking.com/blog/ Ryan King], [http://technorati.com/ Technorati]

== Tools ==

=== Blogger ===
* http://www.blogger.com/home

Blogger is one the earliest, best known and probably most widely used blogging platform. Blogger was bought by [http://www.google.com Google] in February of 2003. Blogger allows users to create and edit their own templates and also provides a large number of (more or less) attractive templates from which the user can select. Unfortunately, you must log into a blogger account to see the template selection.

Here are several Blogger templates, randomly selected from the presets. More recent templates seem to be converging on a vocabulary for identifying parts of posts. This may because they share an evolutionary history from a common template. I've included three examples here:

<pre><nowiki>
<body>
<div id="content">
<div id="main">
ENTRIES
</div>
</div>
</body>

<h2 class="date-header">POST DATE</h2>
<div class="post">
<a name="POST #"></a>
<h3 class="post-title">
<a href="POST URI" title="external link">POST TITLE</a>
</h3>
<p>POST CONTENT</p>
<p class="post-footer">
<em>posted by AUTHOR @ <a href="POST URI" title="permanent link">POST DATETIME</a></em>
</p>
</div>
</nowiki></pre>

<pre><nowiki>
<body>
<div id="main">
<div id="main2">
ENTRIES
</div>
</div>
</body>

<div class="post">
<a name="POST #"></a>
<h3 class="post-title">
<a href="sample_post.html" title="permanent link">POST TITLE</a>
</h3>
<div class="post-body">
POST CONTENT
</div>
<p class="post-footer">
<em>posted by AUTHOR @ <a href="POST URI" title="permanent link">POST TIME</a></em>
</p>
</div>
</nowiki></pre>

<pre><nowiki>
<body>
<div id="leftcontent">
ENTRIES
</div>
</body>

<div class="Post">
<a name="POST #"></a>
POST CONTENT
<span class="PostFooter">
<a href="POST URI">POST TIME</a>
</span>
</div>
</nowiki></pre>

==== Key Class Names ====
* newer templates seem to use "main" to identify a enclosure for all entries
* newer templates use "post" to identify a weblog entry
* newer templates use "post-title" to identify the entry's title
* beyond this there is little standardization

==== Template Concepts ====
* all posts
* an individual post
* post title
* post author
* post posting time
* post content
* post URI (permalink)

=== Blosxom===
* http://www.blosxom.com/
* http://pyblosxom.sourceforge.net/

=== Drupal ===
* http://drupal.org
* varies per theme

=== LiveJournal ===
* http://www.livejournal.com/

=== MovableType ===
* http://www.sixapart.com/movabletype/

MovableType is a perl-based blogging platform. Note that the MT is old and widely deployed and there are very many different variants on the templates in the wild.

The standard template for the weblog's main page (the "[http://www.sixapart.com/movabletype/default_templates#main_index main index]") has the following structure:

<pre><nowiki>
<body>
<div class="content">
<h2>DATE HEADER</h2>
<h3 id="a####">POST TITLE</h3>
POST CONTENT
[ OPTIONAL LINK TO MORE POST CONTENT ]
<p class="posted">Posted by AUTHOR at <a href="POST URI">POST DATE</a>
</div>
</div>

<div class="content">
<p align="right">
<h2>POST DATE</h2>
</p>
<h3>POST TITLE</h3>
POST CONTENT
<div id="more">
MORE POST CONTENT (optional)
</div>
<p class="posted">Posted by AUTHOR at DATE</p>
</div>
</nowiki></pre>

==== Key Class Names ====

* "content" can enclose an individual entry or all entries, depending on the context
* "h2" encloses the post date (literally: the time is not included)
* "h3" encloses the title
* there is no standard enclosure for all the content
* there is no clear identification of "here's all the entries"
* there is no clear identification of the post's author
* the permalink is not necessarily on the page anywhere

==== Template Concepts ====
* all posts
* an individual post
* post title
* post author
* post posting time
* post content, which includes the next two
* post content (first part)
* post content (expended part)
* post URI (permalink)

=== TypePad ===
* http://www.sixapart.com/typepad/

Typepad is a MovableType hosting service. It provides a list of [http://help.typepad.com/tags/default_templates.html default templates] and [ "template modules"] from which users can construct or modify their own templates. Looking at several Typepad blogs, most or all of them following the nomenclature and struct defined by these templates.

The standard structure is as follows:

<pre><nowiki>
<body class="layout-two-column-right">
<div id="container">
<div id="container-inner" class="pkg">
<div id="pagebody">
<div id="pagebody-inner" class="pkg">
<div id="alpha">
<div id="alpha-inner" class="pkg">
INDIVIDUAL ENTRY
</div>
</div>
</div>
</div>
</div>
</div>
</body>

<div class="entry" id="entry-#####">
<h3 class="entry-header">POST TITLE</h3>
<div class="entry-content">
<div class="entry-body">
POST CONTENT
</div>
<a id="more"></a>
<div class="entry-more">
MORE POST CONTENT
</div>
</div>
<p class="entry-footer">
POST FOOTER
</p>
</div>
</nowiki></pre>

I cannot seem to track down in the templates where the POST FOOTER is defined. However, we can see the results from a [http://www.bluedogbob.com/ sample blog]:

<pre><nowiki>
<span class="post-footers">Posted by AUTHOR_NAME in CATEGORY</span>
<span class="separator">|</span>
<a class="permalink" href="ENTRY_URI">Permalink</a>
| <a href="COMMENT_URI">Comments (2)</a>
| <a href="TRACKBACKS_URI">TrackBack (0)</a>
</nowiki></pre>

==== Key Class Names ====
* "entry" encloses all elements within an entry
* "entry-content" contains all the entry text, plus additional text saying "here's more"
* "entry-header" contains the title of the post
* "permalink" contains the post's URI
* there is no clear identification of "here's all the entries"
* there is no clear identification of the post's author

==== Template Concepts ====
* all posts
* an individual post
* post title
* post author
* post posting time
* post content, which includes the next two
* post content (first part)
* post content (expended part)
* post URI (permalink)

=== WordPress ===
* http://wordpress.org

WordPress is a popular GPLed blogging system based on PHP and MySQL. WordPress calls their templates "themes" -- [http://wordpress.org/extend/themes/ more information]. Wordpress does not have a standardized set of class names for identifying parts of the weblog content. I've included a number of examples of what is seen in the wild (move to [[http://microformats.org/wiki/blog-post-examples examples]]?)

Example 1: [http://nokrev.com/older/ Fresh Bananas]

<pre><nowiki>
<body id="blog">
<div id="wrap">
<div id="content" class="two_column">
<div class="left">
ENTRIES
</div>
</div>
</div>
</body>

<h2>POST TITLE</h2>
POST CONTENT (PARTIAL)
<p>
<a href="POST URRI" title="Contiue reading this post">Continue reading</a>
</p>
</nowiki></pre>

Example 2: [http://www.vanillamist.com/blog/ VanillaMist]

<pre><nowiki>
<body>
<div id="main">
<div id="content">
ENTRIES
</div>
</div>
</body>

<div class="post">
<p class="post-date">Wed 6 Jul 2005
</p>
<div class="post-info">
<h2 class="post-title">
<a href="http://vanillamist.com/blog/?p=89" rel="bookmark" title="Permanent Link: Podcasts and a new version of Connections soon">Podcasts and a new version of Connections soon</a>
</h2>
Posted by AUTHOR under <a href="POST URI" title="View all posts in Blogs and Blogging" rel="category tag">CATEGORY</a>

<div class="post-content">
POST CONTENT
</div>

<div class="post-footer"> </div>
</div>
</div>
</nowiki></pre>

Example 3: [http://www.aamukaste.org/wpthemes/ Boredom]

<pre><nowiki>
<body>
<div id="content">
</div>
</body>

<div class="post">
<h2 id="post-5">
<a href="POST URI" rel="bookmark" title="Permanent Link to POST TITLE">POST TITLE</a>
</h2>
<small>POST DATE</small>
<div class="entry">
POST CONTENT
</div>
<p class="postmetadata">
</p>
</div>
</nowiki></pre>

==== Key Class Names ====
There is very little reuse amongst the various templates selected.

==== Template Concepts ====
* Post
* Title
* Author
* Date
* Content (partial)
* Content (full)

A list of all the template elemenents is [http://codex.wordpress.org/Template_Tags available here].

=== Xanga ===
* http://www.xanga.com/

== Journal Formats ==
Before blogs there were journals. Many journals were kept merely on people's computers and not necessarily published.

=== VJOURNAL ===

RFC2445 (iCalendar) defines the VJOURNAL object for storing journal entries which are essentially the same as blog posts. Note that [[hcalendar|hCalendar]] by virtue of referencing all of RFC 2445, could be said to define VJOURNAL class names.

The basic structure of a series of VJOURNAL entries:

TO BE FILLED IN.

Here's an example series of VJOURNAL entries:

TO BE FILLED IN.

== Syndication Feed Formats ==
All of the blogging tools above can produce syndication feeds from the same underlying content and thus prossibly worth discussing here.

[http://www.downes.ca/ Stephen Downes] postulates a [http://microformats.org/discuss/mail/microformats-discuss/2005-August/000670.html syndication/weblog equivalency rule], that RSS + XSLT = XHTML and XHTML + XSLT = RSS. In practice, this may not be exactly true due to syndication feeds often only provide summaries of the entry text and the definition of certain elements of syndications feeds may have ambiguous meaning or interpretation.

''This section may be moved elsewhere.''

=== Atom ===
* http://www.atomenabled.org/

Here is the basic structure of an Atom document, showing only required and recommended elements and the number of them that may appear (the rules are little more complicated than shown here, as some elements become optional or required depending on what else is included).

<pre><nowiki>
feed - 1
id - 1
title - 1; type "text"
updated - 1
link - 0-1 recommended; type "link"
author - 0-N recommended; type "person"
name - 1
email - 0-1 recommended
uri - 0-1 recommended
entry - 0-N
id - 1
title - 1; type "text"
updated - 1
published - 0-1
author - 0-N recommended; type "person"
content - 0-1 recommended; type "text";
"contains or links to the complete content of the entry"
link - 0-N recommended; type "link"
summary - 0-1 recommended; type "text"
</nowiki></pre>

A note about Atom types

* [http://www.atomenabled.org/developers/syndication/#person person] - describes a person, corporation, or similar entity
* [http://www.atomenabled.org/developers/syndication/#text text] - contains human-readable text; @text defines the encoding of the text itself: "text" (default), "html", "xhtml"
* [http://www.atomenabled.org/developers/syndication/#link link] - is patterned after html's [http://www.w3.org/TR/1999/REC-html401-19991224/struct/links.html#h-12.3 link element]; @href is required; @rel, @type, @hreflang, @title, and @length are optional.
* published and updated are datetimes

Here's an example Atom feed

<pre><nowiki>
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

<title>Example Feed</title>
<link href="http://example.org/"/>
<updated>2003-12-13T18:30:02Z</updated>
<author>
<name>John Doe</name>
</author>
<id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>

<entry>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03"/>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<summary>Some text.</summary>
</entry>

</feed>
</nowiki></pre>

=== RSS 2.0 ===
* http://blogs.law.harvard.edu/tech/rss

RSS 2.0 is not to be confused with [http://web.resource.org/rss/1.0/ RSS 1.0] is based on RDF. More about the various versions of RSS and the reason for their existance can be read on [http://en.wikipedia.org/w/index.php?title=RSS_%28protocol%29 Wikipedia]

Here is the basic structure of an RSS document, showing only required and recommended elements and the number of them that may appear:

<pre><nowiki>
channel - 1
title - 1; type "text"
link - 1; type "link"
description - 1; type "text"
language - 0-1; type lang
copyright - 0-1; type text
managingEditor - 0-1; type email
webMaster - 0-1; type email
pubDate - 0-1; type rfc822
lastBuildDate - 0-1; type rfc822
category - 0-N; type text
@domain - 0-1; type uri
generator - 0-1; type text
docs - 0-1; type url
cloud - 0-1
@domain - 1; type url domain
@port - 1; type url port
@path - 1; type url path
@registerProcedure - 1; type token
@protocol - 1; type {http-post,xml-rpc,soap}
ttl - 0-1; type minutes
image - 0-1
url - 1; type url
title - 1; type text
link - 1; type url
width - 0-1; type pixels
description - 0-1; type text
rating - 0-1;
textInput - 0-1;
title 1
description 1
name 1
link 1
skipHours - 0-1;
skipDays - 0-1;
item - 0-N
title - 0-1*; type text
link - 0-1; type url
description - 0-1*; type text(?)
author - 0-1; type email
category - 0-N; type text
@domain - 0-1; type uri
comments - 0-1; type url
enclosure - 0-N;
@url - 1; type url
@length - 1; type bytes
@type - 1; type mime
guid - 0-1; type text
@isPermalink - 0-1; if true, text is a url
pubDate - 0-1; type rfc822
source - 0-1; type text
@url - 1; type url

* One of title or description must be present
</nowiki></pre>

Here's an example RSS 2.0 feed [''some editing needed internally to make entities show the correct way'']:

<pre><nowiki>
<?xml version="1.0"?>
<rss version="2.0">
<channel>
<title>Liftoff News</title>
<link>http://liftoff.msfc.nasa.gov/</link>
<description>Liftoff to Space Exploration.</description>
<language>en-us</language>
<pubDate>Tue, 10 Jun 2003 04:00:00 GMT</pubDate>
<item>

<title>Star City</title>
<link>http://liftoff.msfc.nasa.gov/news/2003/news-starcity.asp</link>
<description>How do Americans ...
<a href="http://howe.iki.rssi.ru/GCTC/gctc_e.htm">Star City</a>.
</description>
<pubDate>Tue, 03 Jun 2003 09:39:21 GMT</pubDate>
<guid>http://liftoff.msfc.nasa.gov/2003/06/03.html#item573</guid>

</item>
</channel>
</rss>
</nowiki></pre>

=== An XHTML profile for RDF Site Summaries ===
See [http://www.w3.org/2000/08/w3c-synd/ Site Summaries in XHTML], used in production for the W3C RSS feed for several years now.
* TODO: fill this out

== Discussion Forum / Bulletin Board Formats ==

Discussion forum posts are similar to blog posts, so may be relevant. Due to the complexity of table-based layouts, much of the mark-up in the following examples has been stripped. The mark-up and analysis also excludes controls (such as reply buttons).

=== Moodle ===
* http://moodle.org/

Moodle is an open source course management system used in education. It includes a discussion forum. The forum does not support templating.

<pre><nowiki>
<body class="mod-forum" id="mod-forum-discuss">
<div id="page">
<div id="header">
<div class="headermain">COURSE TITLE</div>
<div class="headermenu">(controls)</div>
</div>
<table class="navbar">
<tr>
<td>
<div class="breadcrumb">
<a href="BREADCRUMB LINK">BREADCRUMB TITLE</a>+
</div>
(controls)
</td>
</tr>
</table>
<div id="content">
(controls)
ENTRIES
</div>
</div>
</body>

<table class="forumpost">
<tr>
<td>
<img src="AVATAR"/>
</td>
<td class="topic">
<div class="subject">POST TITLE</div>
<div class="author">by <a>AUTHOR</a> - POST DATE</div>
</td>
</tr>
<tr>
<td class="content">
POST CONTENT
<div class="commands"><a>Show Parent</a> | <a>Reply</a></div>
</td>
</tr>
</table>
</nowiki></pre>

==== Key Class Names ====

* "headermain" identifies the course title
* "breadcrumb" identifies breadcrumbs
* "forumpost" identifies a post
* "subject" identifies the post subject
* "author" identifies the author, but also includes the date and other text
* "content" identifies the content area, but includes some controls also

==== Concepts ====

* course title
* breadcrumb titles and links
* post title
* post author
* post date
* post content
* original post (to which this is a reply)
* author avatar

=== phpBB ===
* http://www.phpbb.com/

phpBB is a popular GPL discussion forum system. This is based on the forum on the [http://www.phpbb.com/phpBB/ phpBB] website.

<pre><nowiki>
<body>
<table>
<tr>
<td class="bodyline" bgcolor="white">
<table width="100%" cellspacing="0" cellpadding="10" border="0">
<tr>
<td>
<table>
<tr>
<td>
<a class="maintitle" href="FORUM LINK">FORUM TITLE</a>
</td>
</tr>
</table>
<table width="100%" cellspacing="2" cellpadding="2" border="0">
<tr>
(controls)
<td align="left" valign="middle" width="100%">
<span class="nav"><a href="BREADCRUMB LINK" class="nav">BREADCRUMB TITLE</a>+</span>
</td>
</tr>
</table>

ENTRIES
(controls)
(repeat of controls and navigation)
...
</table>
</body>

<table class="forumline">
<tr>
<td class="catHead">(controls)</td>
</tr>
<tr>
<td class="row1">
<span class="name">
<a name="###"></a>
<b>AUTHOR</b>
</span>
<span class="postdetails">
AUTHOR STATUS (registered etc.)
<img src="AVATAR"/>
Joined: AUTHOR JOIN DATE
Posts: AUTHOR POST COUNT
Location: etc.
</span>
</td>
<td class="row1">
<table>
<tr>
<td>
<span class="postdetails">Posted: POST DATE Post subject: POST TITLE</span>
</td>
<td>(controls)</td>
</tr>
<tr>
<td>
<span class="postbody">
CONTENT
</span>
</td>
</tr>
</table>
</td>
</tr>
(controls)
</table>
</nowiki></pre>

==== Key Class Names ====

* "maintitle" identifies the forum title and link
* "nav" is used for breadcrumbs
* "forumline" encloses the post
* "name" identifies the author
* "postdetails" occurs twice, once providing information about the author, once enclosing the post date and title
* "postbody" identifies the post content

==== Concepts ====

* forum title and link
* breadcrumb titles and links
* post title
* post author
* post date
* post content
* author status
* author join date
* author avatar
* author post count
* author location

=== PunBB ===

* http://punbb.org/

PunBB is GPL forum software. This structure is from the [http://forums.punbb.org/ forum] on their web site.

<pre><nowiki>
<body>
<div id="punwrap">
<div id="punviewtopic" class="pun">
<div id="brdheader" class="block">
<div class="box">
<div id="brdtitle" class="inbox">
<h1><span>SITE SECTION TITLE</span></h1>
<p><span>SITE SECTION BYLINE</span></p>
</div>
(controls)
</div>
</div>
<div id="announce" class="block">
<h2><span>ANNOUNCEMENT TITLE</span></h2>
<div class="box">
<div class="inbox">
<div><span class="warntext">ANNOUNCEMENT CONTENT</span></div>
</div>
</div>
</div>
<div class="linkst">
<div class="inbox">
(controls)
<ul>
<li><a href="BREADCRUMB LINK">BREADCRUMB TITLE</a></li>+
</ul>
</div>
</div>
ENTRIES
</div>
</body>

<div id="HTML-ID" class="blockpost">
<h2>
<span class="conr">POST NUMBER</span>
<a href="PERMALINK">POST DATE</a></h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><a href="AUTHOR PROFILE LINK">AUTHOR NAME</a></strong></dt>
<dd class="usertitle"><strong>AUTHOR STATUS (e.g. Moderator)</strong></dd>
<dd class="postavatar"><img src="AVATAR"/></dd>
<dd>From: AUTHOR LOCATION</dd>
<dd>Registered: AUTHOR REGISTRATION DATE</dd>
<dd>Posts: AUTHOR POST COUNT</dd>
<dd class="usercontacts"><a href="AUTHOR URL">Website</a></dd>
</dl>
</div>
<div class="postright">
<h3>POST TITLE</h3>
<div class="postmsg">
POST CONTENT
</div>
<div class="postsignature">AUTHOR SIGNATURE</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>AUTHOR STATE (online, offline)</p></div>
<div class="postfootright"><div></div></div>
</div>
</div>
</div>
</nowiki></pre>

==== Key Class Names ====

* "blockpost" encloses a post; the element also has an HTML id
* "conr" is the post number within the discussion thread
* h1 indicates the site section title
* "announce" and "warntext" indicate the announcement title and content
* ul inside "linkst" identifies breadcrumbs
* h2 encloses the post number, post date, and permalink, distinguishable by HTML a and span elements
* h3 identifies the post title
* "postmsg" identifies the post content
* the author name and URL are in dl dt a
* additional author information is in dl dd
* "usertitle" identifies the author status
* "postavatar" indentifies the author's avatar
* "usercontacts" identifies author contact information

==== Concepts ====

* site section title and byline
* announcement title and content
* breadcrumb titles and links
* post title
* post author
* post date
* permalink
* post sequence number
* author status
* author avatar
* author location
* author registration date
* author post count
* author URL
* author profile link
* author signature
* author contact information (website)

=== YaBB ===
* http://www.yabbforum.com/

YaBB is a popular commercial/free forum system. This example is based on the [http://www.yabbforum.com/community/ forum] on the YaBB site. I have stripped some presentational class names.

<pre><nowiki>
<body>
<div class="container">
<div class="maincontent">
<div class="seperator">
<table>
(controls, login)
<tr>
<td>
<span id="fscroller">FORUM WELCOME</span>
(controls)
</td>
</tr>
</table>
</div>
<div class="navbarcontainer">
<table>
<tr>
<td>
<span>
<b><a href="BREADCRUMB LINK" class="nav">BREADCRUMB TITLE</a>+</b>
(Moderators: <a href="MODERATOR LINK">MODERATOR NAME</a>+)
<div class="seperator">
<table>
<tr>
<td>
<span>FORUM DESCRIPTION.</span>
</td>
</tr>
</table>
</div>
</span>
</td>
(controls)
</tr>
</table>
</div>
ENTRIES
</div>
(repeat of navigation)
</div>
</body>

<div class="displaycontainer">
<table>
<tr>
<td>
<a><b>POST TITLE</b></a>
AUTHOR STATUS (junior member, senior, etc.)<br />
<img src="<AVATAR>" />
AUTHOR BYLINE
Posts: ###
Gender: <img/>
</td>
<td>
<div>
<b>POST TITLE</b>
<span><b>Reply #nnn on:</b> POST DATE</span>
</div>
<div>
<span class="message">
CONTENT
</span>
</div>
</td>
</tr>
<tr>(controls)</tr>
</table>
</div>
</nowiki></pre>

==== Key Class Names ====

* "displaycontainer" encloses a post
* "message" identifies post content
* no other fields are identified by meaningful mark-up

==== Concepts ====

* forum welcome message
* forum description
* forum moderators (names and links)
* breadcrumbs (titles and links)
* post title
* post author
* post date
* post content
* original post (to which this is a reply)
* author status
* author byline
* author avatar
* author gender
* author post count

== Examples from the wild ==

* Early work on extending standardized nodes in Drupal: http://factorycity.net/demos/drupal/event_system/microformats/
* Microformat-style hooks in forum posts for Javascript annotation: http://www.geof.net/code/annotation/technical.html#microformats

=See Also=
* [[hatom|hAtom]] - the draft proposal based on this information
* [[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)

hatom-issues

2005-12-31T19:37:26Z

FuzzyBSc: Add title and summary reservation issues

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

=== title reserved by hCard ===
The title class is reserved by hCard to mean "job title". It is unclear what term should replace it.

=== summary reserved by hReview ===
The summary class is reserved by hReview to mean "document title". It seems this is the right term to use for <atom:title>.

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

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

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

== 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?

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

hatom-issues

2005-12-31T18:17:07Z

FuzzyBSc: Update rel-tag issue with current hAtom2Atom.xsl findings

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

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

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

== 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?

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

hatom-issues

2005-12-31T16:29:51Z

FuzzyBSc: Make previous update understandable by native english speakers...

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

== 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? A version of this is currently implemented in hAtom2Atom.xsl, but is not conformant with the rel-tag specification. It uses the human-readable text of the link rather than the last path segment of the href URI.

== 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?

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

hatom-issues

2005-12-31T16:27:30Z

FuzzyBSc: Content and summary opaqueness

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

=== Opaqueness of summary and content ===
What one person considers the entry may differ from another person'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 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.

== 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? A version of this is currently implemented in hAtom2Atom.xsl, but is not conformant with the rel-tag specification. It uses the human-readable text of the link rather than the last path segment of the href URI.

== 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?

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

hatom-issues

2005-12-31T15:49:38Z

FuzzyBSc: Add excess disambiguation rules

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

== 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? A version of this is currently implemented in hAtom2Atom.xsl, but is not conformant with the rel-tag specification. It uses the human-readable text of the link rather than the last path segment of the href URI.

== 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?

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

last-modified-brainstorming

2005-12-29T07:17:17Z

FuzzyBSc: Add atom updated terminology

= "Last-modified" Brainstorming =

== Purpose ==
To specify the date when the logical content of a page was last modfied in a visible form which is also machine-readable.

== Authors ==
* [[User:RobertBachmann|Robert Bachmann]]

== Possible class names ==

=== General class name considerations ===
* “last-modified”
** + “paveing the cowpaths” (“Last-Modified” used by HTTP 1.0 and 1.1)
** - HTTP’s “Last-Modified” Header has a slightly different meaning. (Last modification date of the resource, ''not'' the last modification date of the resource’s logical content)

* “last-updated”
** + New name for a “new” semantic.

* "updated"
** + atom 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-modfied”
for the last modfication date of a specific item*.

* Pro
** Easy parsing
* Contra
** See http://microformats.org/discuss/mail/microformats-discuss/2005-August/000726.html

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

Every date format which can be used with [[datetime-design-pattern]] can be used with “last-modified”

== Theoretical example ==
This page was last modified 13:26 UTC, 15 Aug 2005.
could be written as
This page was last modified
<abbr class="<em>some-class-name</em>" title="2005-08-15T13:26Z">13:26 UTC, 15 Aug 2005</abbr>.

= Proposal (strawman) =
== Purpose ==
Many web pages are changed after they have been published. Some of them denote the date of the last update of theire logical way in a human readable way (e.g: „Last updated: October 17th, 2005“). The purpose of „last-updated“ microformat is to provide this data in a way which is also machine-readable.

== Usage ==
The date is enclosed by <code><abbr class="last-updated" title="''Date in machine-readable format"></code>.
The machine-readable format is described at http://microformats.org/wiki/datetime-design-pattern.

=== Example ===

<code>Last updated: <abbr class="last-updated" title="2005-10-17">October 17th, 2005</abbr></code>

== Determining the date of the last update of a page ==

If one <abbr> element with the class value “last-updated” is present on a webpage the value of the title attribute is to be interpreted as the time the page was last updated.

If multiple <abbr> elements with the class value “last-updated” are present on a webpage the value of the title attribute which represents the most recent date is to be interpreted as the time the page was last updated.

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

hatom-issues

2005-12-29T05:45:42Z

FuzzyBSc: Add html title and rel-tag issues

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

== 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? A version of this is currently implemented in hAtom2Atom.xsl, but is not conformant with the rel-tag specification. It uses the human-readable text of the link rather than the last path segment of the href URI.

=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

2005-12-29T04:12:08Z

FuzzyBSc: Describe current hAtom experience

= MFO examples =

Microformat Object or Microformat Opacity or Microformat Opaque

== Contributors ==

* Tantek Çelik

== The Problem ==

Both recent discussions around hAtom, and earlier discussions from June of 2005 have indicated that there may be a need for a generic microformat to indicate that a specific element is a wrapper, container, or layer of abstraction, that should be opaque to something parsing the microformats that may be further up the hierarchy.

E.g. you might put a <code><span class="vcard mfo"> deep inside a <span class="vevent">, and not want the categories/tags of the [[hcard|hCard]] accidentally parsed into the hCalendar event.

Note: the use of "mfo" is only for the purpose of illustration is by no means a proposed name for this microformat. We expect research/discussion to reveal a much better name. We use "mfo" only as a temporary name for the sake of discussion and example illustration. We may even want to commit to deliberately using a class name different from "mfo" just to make this clear in the end.

== Forward Compatibility for Parsers ==

Part of the point of this is to help with forward compatibility for parsers.

Thus an hCalendar parser might need not know about hCard (even though in practice they probably will). As the number of microformats grows, the chances that a new microformat may confuse an old parser due to the scenario outlined above increases. Thus we are considering making it explicit when a new "root" microformat is established.

== To Do ==

In order:

# fill out the real world examples below
# create [[mfo-formats]] page for researching/describing how other data formats indicate this kind of "abstraction", including the various terms they use like "object", "container", etc.
# create [[mfo-brainstorming]] page where we discuss how this should work, and candidate names. Some candidate names that have been offered to date: u, uf, object, container, root, mfo...

== Examples ==

Here are some real world examples where folks have encountered the need to explicitly indicate that an embedded microformat does not introduce properties to its container.

=== hAtom ===

Container microformats use context in a similar way to that of conventional XML. When an atom document includes the element <author> it is context that determines whether the author of a feed or the author of an entry is being specified. However, contrary to convetional XML microformats support forwards compatibility with must-ignore semantics for intervening elements between the context and data. This introduces a problem of identifying contexts that may have been ignored in parsing. If hAtom finds an author element belonging a new microformat that it does not recognise, it may incorrectly summise that the author element belongs to it and refers to it. In fact, it refers to the unknown microformat. Any other inference is invalid.

Elements that have different meanings in different microformats also pose a problem. hCard includes a title element meaning approximately "a person's job title". Atom and various other specifications use title to mean "the title of this document or sub-document". hReview avoided the use of title by introducing a summary element, however this also clashes with the atom namespace. hReview uses summary to mean "review title", while atom uses summary to mean "abbreviated content, both longer than title and shorter than content".

hAtom currently attempts to resolve both the context problem and the nomenclature problem by explicitly naming child elements as opaque. Currently "content" and "summary" are considered completely opaque, while "author" and "contributor" are only scanned for vcard content. This may be an incomplete solution if vcards or other context microformats are included outside of these nodes.

hatom-issues

2005-12-27T14:56:17Z

FuzzyBSc: Add: Opaqueness of other microformat elements

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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".

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

=== 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>class="bookmark"</code>.

== 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 - RESOLVED'''. "MAY" is the answer.

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

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

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

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

hatom

2005-12-26T12:59:32Z

FuzzyBSc: Update to reflect explicit class=author and class=contributor attributes

= hAtom =

hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is a strongly based on a subset of the [http://www.atomenabled.org/ Atom] syndication format; every concept in hAtom has a corresponding definition in Atom.

This microformat is a draft; please address your concerns, issues, comments, etc. in [[hatom-issues]].

__TOC__

== Draft Specification ==

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

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

=== Contributors ===
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

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

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

== Introduction ==

== 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. This can (and probably should) be expanded.
* 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 "briding the gap"
:: ''for example, if an entry is missing an author (required by Atom), it is assumed to be that of the XHTML page''

=== Schema ===
Schema elements are based on the Atom nomenclature and follow the microformat pattern of prefixing a unique identifier (in this case, <code>atom</code>) on the outermost container elements -- the Feed or Entry. The parts of this microformat are based on analysis of many weblog, bulletin board and media posts and can be read [[blog-post-brainstorming#Discovered_Elements]]. Note the renaming of 'EntryGroup' to 'Feed' to be more consistent with Atom ternminology.

==== Nomenclature ====

{| width="100%" border="1" cellspacing="0"
|-
! width="150" | Concept
! Atom Identifier
! hAtom Microformat Usage
|-
| Feed
| <code>atom:feed</code>
| add <code>class="feed"</code>
|-
| Entry
| <code>atom:entry</code>
| Add <code>class="entry"</code>; if practical, also define <code>id="unique-identifier"</code> to the Entry.
|-
| Entry Title
| <code>atom:title</code>
| Add <code>class="title"</code>, alternately by <code><h#></code>.
|-
| Entry Content
| <code>atom:content</code>
| Add <code>class="content"</code> to all appropriate blocks. Multiple Entry Content blocks are logically considered one concatenated <code>atom:content</code> equivalent.
|-
| Entry Summary
| <code>atom:summary</code>
| Add <code>class="summary"</code> to all appropriate blocks. Multiple Entry Summary blocks are logically considered one concatenated <code>atom:summary</code> equivalent.
|-
| Entry Permalink
| <code>atom:link</code>
| Add <code>rel="bookmark"</code>.
|-
| Entry Published
| <code>atom:published</code>
| Use <code><abbr class="published" title="YYYYMMYYThh:mm:ss±ZZ:ZZ"></code>...<code></abbr></code>, following the [[datetime-design-pattern]].
|-
| Entry Updated
| <code>atom:updated</code>
| Use <code><abbr class="updated" title="YYYYMMYYThh:mm:ss±ZZ:ZZ"></code>...<code></abbr></code>, following the [[datetime-design-pattern]].
|-
| Entry Author
| <code>atom:author</code>
| Add <code>class="author"</code> to appropriate blocks. Using <code><address class="author"></code>...<code></address></code> is recommended. Adding a [[hcard|hCard]] is highly recommended.
|-
| Entry Contributor
| Add <code>atom:contibutor</code> to appropriate blocks.
| Add <code>class="contributor"</code> to appropriate blocks. Using <code><address class="contributor"></code>...<code></address></code> is recommended. Adding a [[hcard|hCard]] is highly recommended.
|}

==== Nesting Rules ====

{| width="100%" border="1" cellspacing="0"
|-
! Concept
! Nests In
! hAtom Opaque
! Cardinality
! Logical Cardinality
|-
| Feed
| HTML document
| No
| 1-N
| 1-N
|-
| Entry
| Feed
| No
| 0-N
| 0-N
|-
| Entry Title
| Entry<br />Entry Permalink
| No
| 0-N
| 0-1
|-
| Entry Content
| Entry
| Yes
| 0-N
| 0-1
|-
| Entry Summary
| Entry
| Yes
| 0-N
| 0-1
|-
| Entry Permalink
| Entry<br />Entry Title<br />Entry Published
| No
| 0-N
| 1
|-
| Entry Published
| Entry<br />Entry Permalink
| No
| 0-N
| 0-1
|-
| Entry Updated
| Entry<br />Entry Permalink
| No
| 0-N
| 1
|-
| Entry Author
| Entry
| Yes
| 0-N
| 1-N
|-
| Entry Contibutor
| Entry
| Yes
| 0-N
| 0-N
|}

===== hAtom Opaque =====

"hAtom Opaque" specifies whether a hAtom parser should "look inside" the element for further hAtom content. If there are multiple rules applied to the same element take the OR of the two (i.e. "Yes" always wins)

: ''hAtom Opaque is designed to make parsing rules less ambiguous. In particular, it allows "quoted" hAtom elements (from another blog being blockquoted, for example) ti be ignored. It also allows 'embedded' hAtom to be potentially delivered within hAtom itself, and to prevent accidental 'leaking' of other microformat information up into the hAtom container.''

===== Cardinality =====

How many times can an element of the given type appear in it's nesting/parent element.

===== Logical Cardinality =====

From a modeling/logical perspective, the number of times can an element appear.

: ''This is all rule dependent, see below. For example, an Entry Permalink may appear 6 times, but each one must be the same value; an Entry Content element may appear 3 times, but they are all concatenated together to make a single logical element.''

==== Rules and Definitions ====
See the [[#Nesting_Rules|Nesting Rules]] section above for placement of these elements.

===== Feed =====
* an XHTML Feed element is identified by <code>class="feed"</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]
: ''In particular, as a container for Entrys.''
* the Feed element is required, even if there is a single Entry
: ''This is for disambiguation''
* hAtom documents MAY have multiple, non-nested Feed elements
: ''This may happen on news pages, or weblogs with "mini-blogs" on the sidebar.''

===== Entry =====
* an Entry element is identified by <code>class="entry"</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]
* a weblog entry MUST be enclosed in a single Entry element
: ''That's what it's for, after all.''
* an Entry MUST have an enclosing Feed element
* ''This enclosing element can be the same as the Entry -- i.e. class="feed entry" is OK for feeds with a single entry.''

===== Entry Title =====
* an Entry Title element is identified by <code>class="title"</code>
* an Entry Title element alternately be identified by <code><h#></code>
* 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]

====== Disambiguation ======

* the first hAtom valid element with a <code>class="title"</code> is the Entry Title
: ''hAtom valid meaning somewhere where we expect it (like not inside Entry Content, for example).''
* otherwise, the first hAtom valid <code><h#></code> element to appear in an hAtom document is the Entry Title
* otherwise, the Entry Title is the empty string
: ''Atom does not allow for an entry not to have a title.''

===== Entry Content =====
* an Entry Content element is identified by <code>class="content"</code>
* 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
: ''We recognize this varies from the Atom spec: see the next rule.''
* 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.''
* the "logical Entry Content" MUST be complete; that is, contain the entire content of the Entry
: ''Otherwise it should be marked as Entry Summary.''

===== Entry Summary =====
* an Entry Summary element is identified by <code>class="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
: ''We recognize this varies from the Atom spec: see the next rule.''
* 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 <code>rel="bookmark"</code>
: ''We recognize that we have broken from Atom terminology at this point. See [[hatom-issues]] for discussion.''
: ''This may be a microformat in itself: [[rel-bookmark]].''
* 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]
* Entry Permalinks SHOULD be absolute URIs
* Entry Permalinks MUST be the same as the <code>atom:link</code> (or <code>rss:link</code>) used in syndication feeds
: ''The intention of the previous two rules to gently force people to use strings that can be byte compared for equivalence. In general, the canonical URI should be the link used in an Atom entry.''
: ''Is there a problem with FeedBurner?''
* if an Entry has multiple elements marked as the Entry Permalink, they MUST have exactly the same URI
* an Entry SHOULD have an Entry Permalink
: ''There are circumstances (such as media pages) where this won't happen. See the next rule.''
* there can be at most 1 Entry in an XHTML document without an Entry Permalink; the Entry Permalink of this Entry is the URI of the page
: ''This rule is needed for media pages (i.e. a news article on cnn.com). There is some ugliness of with this because the URI could be non-canonical.''

====== Disambiguation ======

* The first valid element in an Entry marked as an Entry Permalink is the Entry Permalink

===== Entry Published =====

* an Entry Published element is identified by <code>class="published"</code>
* a Entry Published element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9 atom published]
* the machine readable datetime should be encoded with an <code><abbr></code> element using the [[datetime-design-pattern]]; the machine readable datetime should be complete, that is, specified to the second with the timezone included
: ''This is to be consistent with the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.3.3 Atom Datetime Construct].
* optionally, this can be specified by an HTML element with the ISO datetime in the text.
: ''This is a little uglier for the reader, but it's possible.''

====== Disambiguation ======

* The first valid element in an Entry marked as an Entry Published is the Entry Published element

===== Entry Updated =====

* an Entry Updated element is identified by <code>class="updated"</code>
* a Entry Updated element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15 atom updated]
* the machine readable datetime should be encoded with an <code><abbr></code> element using the [[datetime-design-pattern]]; the machine readable datetime should be complete, that is, specified to the second with the timezone included
: ''This is to be consistent with the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.3.3 Atom Datetime Construct].
* if there is no Entry Updated element, the value is assumed to be that of Entry Published
: ''Entry Published is more often available in weblog templates, so we're going with that.''
* if there is no Entry Updated and Entry Published elements, transformation to Atom is problematic
: ''This is because a published element is required. Suggestions would be appreciated here.''
* optionally, this can be specified by an HTML element with the ISO datetime in the text.
: ''This is a little uglier for the reader, but it's possible.''

====== Disambiguation ======

* The first valid element in an Entry marked as an Entry Updated is the Entry Updated element

===== Entry Author =====

* an Entry Author element is represented by <code>class="author"</code>
* an Entry Author element SHOULD use an XHTML <code><address></code> element
* 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 SHOULD contain an [[hcard|hCard]]
: ''If it does not, just consider the text to effectively be the FN''
* an Entry MAY have 0 or more Entry Author elements
* if an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page
: ''Atom requires at least one Author''

===== Entry Contibutor =====

* an Entry Contibutor element is represented by <code>class="contributor"</code>
* an Entry Contibutor element SHOULD use an XHTML <code><address></code> element
* an Entry Contibutor element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.3 atom contributor]
* an Entry Contibutor element SHOULD contain an [[hcard|hCard]]
: ''If it does not, just consider the text to be the FN''
* an Entry MAY have 0 or more Entry Contibutor elements

=== 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>feed</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>entry</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>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>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>

=== Parsing Details ===

== Examples ==

This section is informative.

=== Transformation 1 ===

A well behaved weblog.

Original:

<pre><nowiki>
<body>
<div id="wrap">
<div id="content">
...
<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a>
</h3>
<p>We had a bit of trouble with ...</p>
<p>We’ve restored the wiki and ...</p>
<p>If anyone is working to combat said spammers ...</p>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://technorati.com/tag/mediawiki" rel="tag">mediawiki</a></li>
<li><a href="http://technorati.com/tag/microformats" rel="tag">microformats</a></li>
<li><a href="http://technorati.com/tag/spam" rel="tag">spam</a></li>
</ul>

<ul class="post-info">
<li>
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">October 10th, 2005</a>
</li>
<li>
<address class="vcard"><a class="url fn" href="http://theryanking.com">Ryan King</a></address>
</li>
<li>
<a href="http://www.microformats.org/blog/...">4 Comments</a>
</li>
</ul>
</div>

<div class="entry">
....
</div>
...
</div>
</div>
</body>
</nowiki></pre>

Transformed to hAtom compliant (shown in UPPER CASE for visibility only):

<pre><nowiki>
<body>
<div id="wrap">
<div CLASS="FEED" id="content">
...
<div class="entry" ID="post-60">
<h3>
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a>
</h3>
<DIV CLASS="CONTENT">
<p>We had a bit of trouble with ...</p>
<p>We’ve restored the wiki and ...</p>
<p>If anyone is working to combat said spammers ...</p>
</DIV>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://technorati.com/tag/mediawiki" rel="tag">mediawiki</a></li>
<li><a href="http://technorati.com/tag/microformats" rel="tag">microformats</a></li>
<li><a href="http://technorati.com/tag/spam" rel="tag">spam</a></li>
</ul>

<ul class="post-info">
<li>
<a href="http://www.microformats.org/blog/..." rel="bookmark"
title="..."><ABBR CLASS="PUBLISHED" TITLE="2005-10-10T14:07:00-07:00">October 10th, 2005</ABBR></a>
</li>
<li>
<address class="vcard"><a class="url fn" href="http://theryanking.com">Ryan King</a></address>
</li>
<li>
<a href="http://www.microformats.org/blog/...">4 Comments</a>
</li>
</ul>
</div>

<div class="entry" ID="post-59">
....
</div>
...
</div>
</div>
</body>
</nowiki></pre>

Changes:
* Added <code>class="feed"</code> to Feed
* Moved <code>id="###"</code> from <code><h3></code> to Entry
* Added <code><div class="content"></code>...<code></div></code> around the Entry Content
* Added <code><abbr class="PUBLISHED" title="YYYY-MM-DDThh:mm:ss+ZZ:ZZ"></code>...<code></abbr></code> around the Entry Datetime

Also note:
* We did not need to add a <code>class="entry"</code> to each Entry
* We did not need to add a <code><address></code> element
* We did not need to add a <code><h#></code> element
* We did not need to add a <code>rel="bookmark"</code> to Entry Permalinks

=== Transformation 2 ===

A not-so well behaved weblog (an older blogspot weblog)

Original:

<pre><nowiki>
<body bgcolor="...">

<div class="posts">
<a name="112993192128302715"> </a><br>
<div style="clear:both;"></div><strong>Nelson's final prayer</strong>
written on the night before Trafalgar:<blockquote>May the Great God, ... heart.
<div style="clear:both; padding-bottom: 0.25em;"></div>
<br>
<span class="byline">
posted by Natalie at
<a href="2005_10_16_nataliesolent_archive.html#112993192128302715">9:49 PM</a>
</span>
</div>

<div class="posts">
<a name="112993022840118939"> </a>
<br>
<div style="clear:both;"></div><strong>I really, truly </strong>didn't go ... view.
<div style="clear:both; padding-bottom: 0.25em;"></div>
<br>
<span class="byline">
posted by Natalie at
<a href="2005_10_16_nataliesolent_archive.html#112993022840118939">9:28 PM</a>
</span>
</div>
...

</body>
</nowiki></pre>

Transformed to hAtom compliant (shown in UPPER CASE for visibility only):

<pre><nowiki>
<body bgcolor="...">

<DIV CLASS="FEED">
<div class="ENTRY posts" ID="112993192128302715">
<strong CLASS="TITLE CONTENT">
Nelson's final prayer
</strong>
<SPAN CLASS="CONTENT">
written on the night before Trafalgar:<blockquote>May the Great God, ... heart.
</SPAN>
<DIV>
<span class="byline">posted by <address>Natalie</address> at
<a REL="BOOKMARK" href="HTTP://NATALIESOLENT.BLOGSPOT.COM/2005_10_16_nataliesolent_archive.html#112993192128302715">
<ABBR CLASS="PUBLISHED" TITLE="2005-10-24T09:49:00-00:00">9:49 PM</ABBR></a>
</span>
</DIV>
</div>

<div class="ENTRY posts" ID="112993022840118939">
<strong CLASS="TITLE CONTENT">I really, truly </strong>
<SPAN CLASS="CONTENT">
didn't go ... view.
</SPAN>
<DIV>
<span class="byline">
posted by <address>Natalie</address> at
<a REL="BOOKMARK" href="HTTP://NATALIESOLENT.BLOGSPOT.COM/2005_10_16_nataliesolent_archive.html#112993022840118939">
<ABBR CLASS="PUBLISHED" TITLE="2005-10-24T09:49:00-00:00">9:28 PM</ABBR></a>
</span>
</DIV>
</div>
...
</DIV>

</body>
</nowiki></pre>

Changes:
* Added <code>class="feed"</code> to Feed
* Added <code>class="entry"</code> to each Entry
* Moved <code>id="###"</code> up to the Entry (and deleted the empty anchor block)
* Added <code>rel="bookmark"</code> to the Entry Permalinks
* Made the Entry Permalink non-relative
* Added <code><span class="title"></code>...<code></div></code> around the Entry Title
* Added <code><span class="content"></code>...<code></div></code> around the Entry Title (!)
* Added <code><span class="content"></code>...<code></div></code> around the Entry Content
* Added <code><abbr class="published" title="YYYY-MM-DDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code><address></code> to the poster's name

Also note:
* there are multiple content blocks, because Natalie Solent embeds the title in the content
* cleaned up lots of crap HTML presentation stuff, with the assumption it would be fixed in the stylesheet
* this is one of the uglier transformations you're likely to see
* we've respected the poster's poster apparent wish for anonimity by not adding an hCard

=== Transformation 3 ===

A media page (from [http://www.cbc.ca/story/world/national/2005/11/22/birdlfu051122.html CBC Newsworld]).

Original:

<pre><nowiki>
<div class="news">
<div class="story">
<h1>China confirms new bird flu outbreaks</h1>
<span class="byline">Last Updated Tue, 22 Nov 2005 23:26:18 EST</span>
<div class="text"><a href="/news/credit.html">CBC News</a></div>

<div class="text">
<p>
China has confirmed three new outbreaks of bird flu, ...
<p>
<ul>
<li><font SIZE="1">INDEPTH: </font><font SIZE="2">
<a href="http://www.cbc.ca/news/background/avianflu/">Avian Flu</a></font>
</ul>
</p>
<table align="right" cellpadding="0" cellspacing="4" hspace="4" width="220">
<tr>
<td align="center">
<img src="http://www.cbc.ca/gfx/pix/birdflu_china_cp_7707271.jpg" width="220" height="223" hspace="3" border="0">
</td>
</tr>
<tr>
<td align="center">
<div class="caption">
<font size="1" face="verdana,arial"><i></i></font>
</div>
</td>
</tr>
</table>
<p>State media says the new outbreaks are in...</p>
<p>The news comes a day after China announced the ...</p>
<p>In China's eastern Anhui province, authorities have ...</p>
<p>The province says the measure will prevent domestic ...</p>
<p>Vietnamese health officials have confirmed that a ...</p>
<p>Doctors from the health department in the northern ...</p>
<p>Bird flu has killed 42 people in Vietnam since December ...</p>
<p>The World Health Organization fears the H5N1 strain of ...</p>
</div>

<p><font face="Verdana,Arial" size="1">with files from the Australian Broadcasting Corporation</font></p>
</div>
...
</div>
</nowiki></pre>

Transformed to hAtom compliant (shown in UPPER CASE for visibility only):

<pre><nowiki>
<div class="news">
<div class="FEED ENTRY story">
<h1>China confirms new bird flu outbreaks</h1>
<span class="byline">Last Updated
<ABBR CLASS="POSTED" TITLE="2005-11-23T04:26:18Z">Tue, 22 Nov 2005 23:26:18 EST</ABBR>
</span>
<ADDRESS CLASS="VCARD"><div class="text"><a CLASS="URL" href="/news/credit.html">CBC News</a></div></ADDRESS>

<div class="text">
<p CLASS="CONTENT">
China has confirmed three new outbreaks of bird flu, ...
</p>
<p>
<ul>
<li><font SIZE="1">INDEPTH: </font><font SIZE="2">
<a href="http://www.cbc.ca/news/background/avianflu/">Avian Flu</a></font>
</ul>
</p>
<table align="right" cellpadding="0" cellspacing="4" hspace="4" width="220">
<tr>
<td align="center">
<img src="http://www.cbc.ca/gfx/pix/birdflu_china_cp_7707271.jpg" width="220" height="223" hspace="3" border="0">
</td>
</tr>
<tr>
<td align="center">
<div class="caption">
<font size="1" face="verdana,arial"><i></i></font>
</div>
</td>
</tr>
</table>
<p CLASS="CONTENT">State media says the new outbreaks are in...</p>
<p CLASS="CONTENT">The news comes a day after China announced the ...</p>
<p CLASS="CONTENT">In China's eastern Anhui province, authorities have ...</p>
<p CLASS="CONTENT">The province says the measure will prevent domestic ...</p>
<p CLASS="CONTENT">Vietnamese health officials have confirmed that a ...</p>
<p CLASS="CONTENT">Doctors from the health department in the northern ...</p>
<p CLASS="CONTENT">Bird flu has killed 42 people in Vietnam since December ...</p>
<p CLASS="CONTENT">The World Health Organization fears the H5N1 strain of ...</p>
</div>

<p><font face="Verdana,Arial" size="1">with files from the <ADDRESS CLASS="CONTRIBUTOR">Australian Broadcasting Corporation</ADDRESS></font></p>
</div>
...
</div>
</nowiki></pre>

Changes:
* Added <code><div class="feed entry"></code> around the single entry on the page
: ''We have to make sure the nesting rules reflect nesting at the same level''
* Added <code><span class="content"></code>...<code></div></code> around every single paragraph -- this looks pathological but it may be the way this would need be produced from a template. The latter part of the document could be enclosed in a single "content" div but note that we did this so the "INDEPTH" part would not be marked as content,
* Added <code><abbr class="published" title="YYYYMMDDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code><address></code> to the CBC Newsroom
* Added <code><address class="contributor"></code> to a contributor's name

Also note:
* We may the document more XHTML compliant
* There is no <code>rel="bookmark"</code> so it is assumed to be the URI of the page
* The Entry Title was correctly marked with a <code><h1></code> element

=== Transformation 4 ===

A bulletin board ([http://forums.punbb.org/viewtopic.php?id=9135 PunBB])

Original:

<pre><nowiki>
<body>
<div id="punwrap">
<div id="punviewtopic" class="pun">

<div id="brdheader" class="block">
... header stuff ...
</div>

<div id="announce" class="block">
... announcement stuff ...
</div>

<div class="linkst">
... controls for the blog
</div>

<div id="p54390" class="blockpost rowodd firstpost">
<h2>
<span><span class="conr">#1 </span>
<a href="viewtopic.php?pid=54390#p54390">2005-10-16 10:36:24</a></span>
</h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><a href="profile.php?id=2">Rickard</a></strong></dt>

<dd class="usertitle"><strong>PunBB Developer</strong></dd>
<dd class="postavatar"><img src="img/avatars/2.png" width="60" height="60" alt="" /></dd>
<dd>From: 127.0.0.1</dd>
<dd>Registered: 2001-11-02</dd>
<dd>Posts: 7806</dd>
<dd class="usercontacts"><a href="http://www.punbb.org/">Website</a></dd>

</dl>
</div>
<div class="postright">
<h3>PunBB 1.2.9</h3>
<div class="postmsg">
<p>Just a quick note this time....</p>

</div>
<div class="postsignature"><hr />"Programming is like sex: ...</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>
<div class="postfootright"><div> </div></div>
</div>
</div>

</div>

<div id="p54392" class="blockpost roweven">
<h2><span><span class="conr">#2 </span><a href="viewtopic.php?pid=54392#p54392">2005-10-16 10:54:41</a></span></h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><a href="profile.php?id=5298">IdleFire</a></strong></dt>

<dd class="usertitle"><strong>Member</strong></dd>
<dd class="postavatar"></dd>
<dd>Registered: 2005-10-14</dd>
<dd>Posts: 27</dd>
</dl>
</div>
<div class="postright">

<h3> Re: PunBB 1.2.9</h3>
<div class="postmsg">
<p>...</p>
</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>

<div class="postfootright"><div> </div></div>
</div>
</div>
</div>

... more entries ...

<div id="brdfooter" class="block">
... footer stuff ...
</div>

</div>
</div>
</body>
</nowiki></pre>

Transformed to hAtom compliant (changes shown in UPPER CASE for visibility only):

<pre><nowiki>
<body>
<div id="punwrap">
<div id="punviewtopic" class="pun">

<div id="brdheader" class="block">
... header stuff ...
</div>

<div id="announce" class="block">
... announcement stuff ...
</div>

<div class="linkst">
... controls for the blog
</div>

<DIV CLASS="FEED">
<div id="p54390" class="ENTRY blockpost rowodd firstpost">
<h2>
<span><span class="conr">#1 </span>
<a REL="BOOKMARK" href="HTTP://FORUMS.PUNBB.ORG/viewtopic.php?pid=54390#p54390">
<ABBR CLASS="POSTED" TITLE="20051016T103624-0500">2005-10-16 10:36:24</ABBR>
</a></span>
</h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><ADDRESS><a href="profile.php?id=2">Rickard</a></ADDRESS></strong></dt>

<dd class="usertitle"><strong>PunBB Developer</strong></dd>
<dd class="postavatar"><img src="img/avatars/2.png" width="60" height="60" alt="" /></dd>
<dd>From: 127.0.0.1</dd>
<dd>Registered: 2001-11-02</dd>
<dd>Posts: 7806</dd>
<dd class="usercontacts"><a href="http://www.punbb.org/">Website</a></dd>

</dl>
</div>
<div class="postright">
<h3>PunBB 1.2.9</h3>
<div class="CONTENT postmsg">
<p>Just a quick note this time....</p>

</div>
<div class="postsignature"><hr />"Programming is like sex: ...</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>
<div class="postfootright"><div> </div></div>
</div>
</div>

</div>

<div id="p54392" class="ENTRY blockpost roweven">
<h2>
<span><span class="conr">#2 </span>
<a REL="BOOKMARK" href="HTTP://FORUMS.PUNBB.ORG/viewtopic.php?pid=54392#p54392">
<ABBR CLASS="POSTED" TITLE="20051016T1105441-0500">2005-10-16 10:54:41</ABBR>
</a></span>
</h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><ADDRESS CLASS="VCARD"><a CLASS="URL" href="profile.php?id=5298">IdleFire</a></ADDRESS></strong></dt>

<dd class="usertitle"><strong>Member</strong></dd>
<dd class="postavatar"></dd>
<dd>Registered: 2005-10-14</dd>
<dd>Posts: 27</dd>
</dl>
</div>
<div class="postright">

<h3> Re: PunBB 1.2.9</h3>
<div class="CONTENT postmsg">
<p>...</p>
</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>

<div class="postfootright"><div> </div></div>
</div>
</div>
</div>

... more entries ...
</DIV>

<div id="brdfooter" class="block">
... footer stuff ...
</div>

</div>
</div>
</body>
</nowiki></pre>

Changes:
* Added <code><div class="feed"></code> around the entries (as opposed to an existing <code><div</code> that enclosed more than entries.
* Added <code>class="entry"</code> to each Entry
* Added <code>rel="bookmark"</code> to the Entry Permalinks
* Made the Entry Permalink non-relative
* Added <code><span class="title"></code>...<code></div></code> around the Entry Title
* Added <code><span class="content"></code>...<code></div></code> around the Entry Content
* Added <code><abbr class="posted" title="YYYYMMDDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code><address></code> to the poster's name

Also note:
* We did not need to add <code>id="###"</code> to the Entry

=== More Examples ===

See [[hatom-examples]].

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

* [http://blog.davidjanes.com Ranting and Roaring] (David Janes)
* [http://www.myelin.co.nz/post/ Second p0st] (Phil Pearson)
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Sound Advice] (Benjamin Carlyle)

== Implementations ==

This section is '''informative'''.

* 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
* An [http://lukearno.com/projects/hAtom/ hAtom-2-Atom] XSLT is available

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

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

== Hints and Tips ==

=== CSS tips ===
HTML typically styles <code>address</code> as a block level element in an italic font. This will make it inline and plain within hAtom elements:

<pre><nowiki>
.entry address {
display: inline;
font-weight: normal;
font-style: normal;
}
</nowiki></pre>

HTML typically puts a dotted line under <code><abbr></code> elements. This will put postage paid to that for Entry Updated and Entry Posted:

<pre><nowiki>
.entry abbr.updated, .entry abbr.posted {
font-style: normal;
border: none;
}
</nowiki></pre>

=== MovableType Template ===

A datetime encoded in an ABBR element can be produced with the following template code:

<pre><nowiki>
<abbr
class="posted"
title="<$MTEntryDate format="%Y%m%dT%H%M%S"$><$MTBlogTimezone
no_colon="1"$>"><$MTEntryDate format="%X"$></abbr>
</nowiki></pre>

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

== Recent Changes ==

''Most recent at top please. This section will eventually be removed but should be helpful for people tracking changes during specing.''

* Entry Permalink now SHOULD (as opposed to MUST) be a complete URI
* Entry Title now preferentially uses class="title"
* Entry Author most explicitly be marked class="author"
* using an <code><address</code> around Entry Author and Entry Contributor is no longer required

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

hatom

2005-12-26T12:51:01Z

FuzzyBSc: Revert MUST to SHOULD re absolute URIs

= hAtom =

hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is a strongly based on a subset of the [http://www.atomenabled.org/ Atom] syndication format; every concept in hAtom has a corresponding definition in Atom.

This microformat is a draft; please address your concerns, issues, comments, etc. in [[hatom-issues]].

__TOC__

== Draft Specification ==

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

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

=== Contributors ===
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

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

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

== Introduction ==

== 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. This can (and probably should) be expanded.
* 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 "briding the gap"
:: ''for example, if an entry is missing an author (required by Atom), it is assumed to be that of the XHTML page''

=== Schema ===
Schema elements are based on the Atom nomenclature and follow the microformat pattern of prefixing a unique identifier (in this case, <code>atom</code>) on the outermost container elements -- the Feed or Entry. The parts of this microformat are based on analysis of many weblog, bulletin board and media posts and can be read [[blog-post-brainstorming#Discovered_Elements]]. Note the renaming of 'EntryGroup' to 'Feed' to be more consistent with Atom ternminology.

==== Nomenclature ====

{| width="100%" border="1" cellspacing="0"
|-
! width="150" | Concept
! Atom Identifier
! hAtom Microformat Usage
|-
| Feed
| <code>atom:feed</code>
| add <code>class="feed"</code>
|-
| Entry
| <code>atom:entry</code>
| Add <code>class="entry"</code>; if practical, also define <code>id="unique-identifier"</code> to the Entry.
|-
| Entry Title
| <code>atom:title</code>
| Add <code>class="title"</code>, alternately by <code><h#></code>.
|-
| Entry Content
| <code>atom:content</code>
| Add <code>class="content"</code> to all appropriate blocks. Multiple Entry Content blocks are logically considered one concatenated <code>atom:content</code> equivalent.
|-
| Entry Summary
| <code>atom:summary</code>
| Add <code>class="summary"</code> to all appropriate blocks. Multiple Entry Summary blocks are logically considered one concatenated <code>atom:summary</code> equivalent.
|-
| Entry Permalink
| <code>atom:link</code>
| Add <code>rel="bookmark"</code>.
|-
| Entry Published
| <code>atom:published</code>
| Use <code><abbr class="published" title="YYYYMMYYThh:mm:ss±ZZ:ZZ"></code>...<code></abbr></code>, following the [[datetime-design-pattern]].
|-
| Entry Updated
| <code>atom:updated</code>
| Use <code><abbr class="updated" title="YYYYMMYYThh:mm:ss±ZZ:ZZ"></code>...<code></abbr></code>, following the [[datetime-design-pattern]].
|-
| Entry Author
| <code>atom:author</code>
| Use <code><address></code>...<code></address></code>. Adding <code>class="author"</code> is optional. Adding a [[hcard|hCard]] is highly recommended.
|-
| Entry Contributor
| <code>atom:contibutor</code>
| Use <code><address class="contributor"></code>...<code></address></code>. Adding a [[hcard|hCard]] is highly recommended.
|}

==== Nesting Rules ====

{| width="100%" border="1" cellspacing="0"
|-
! Concept
! Nests In
! hAtom Opaque
! Cardinality
! Logical Cardinality
|-
| Feed
| HTML document
| No
| 1-N
| 1-N
|-
| Entry
| Feed
| No
| 0-N
| 0-N
|-
| Entry Title
| Entry<br />Entry Permalink
| No
| 0-N
| 0-1
|-
| Entry Content
| Entry
| Yes
| 0-N
| 0-1
|-
| Entry Summary
| Entry
| Yes
| 0-N
| 0-1
|-
| Entry Permalink
| Entry<br />Entry Title<br />Entry Published
| No
| 0-N
| 1
|-
| Entry Published
| Entry<br />Entry Permalink
| No
| 0-N
| 0-1
|-
| Entry Updated
| Entry<br />Entry Permalink
| No
| 0-N
| 1
|-
| Entry Author
| Entry
| Yes
| 0-N
| 1-N
|-
| Entry Contibutor
| Entry
| Yes
| 0-N
| 0-N
|}

===== hAtom Opaque =====

"hAtom Opaque" specifies whether a hAtom parser should "look inside" the element for further hAtom content. If there are multiple rules applied to the same element take the OR of the two (i.e. "Yes" always wins)

: ''hAtom Opaque is designed to make parsing rules less ambiguous. In particular, it allows "quoted" hAtom elements (from another blog being blockquoted, for example) ti be ignored. It also allows 'embedded' hAtom to be potentially delivered within hAtom itself, and to prevent accidental 'leaking' of other microformat information up into the hAtom container.''

===== Cardinality =====

How many times can an element of the given type appear in it's nesting/parent element.

===== Logical Cardinality =====

From a modeling/logical perspective, the number of times can an element appear.

: ''This is all rule dependent, see below. For example, an Entry Permalink may appear 6 times, but each one must be the same value; an Entry Content element may appear 3 times, but they are all concatenated together to make a single logical element.''

==== Rules and Definitions ====
See the [[#Nesting_Rules|Nesting Rules]] section above for placement of these elements.

===== Feed =====
* an XHTML Feed element is identified by <code>class="feed"</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]
: ''In particular, as a container for Entrys.''
* the Feed element is required, even if there is a single Entry
: ''This is for disambiguation''
* hAtom documents MAY have multiple, non-nested Feed elements
: ''This may happen on news pages, or weblogs with "mini-blogs" on the sidebar.''

===== Entry =====
* an Entry element is identified by <code>class="entry"</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]
* a weblog entry MUST be enclosed in a single Entry element
: ''That's what it's for, after all.''
* an Entry MUST have an enclosing Feed element
* ''This enclosing element can be the same as the Entry -- i.e. class="feed entry" is OK for feeds with a single entry.''

===== Entry Title =====
* an Entry Title element is identified by <code>class="title"</code>
* an Entry Title element alternately be identified by <code><h#></code>
* 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]

====== Disambiguation ======

* the first hAtom valid element with a <code>class="title"</code> is the Entry Title
: ''hAtom valid meaning somewhere where we expect it (like not inside Entry Content, for example).''
* otherwise, the first hAtom valid <code><h#></code> element to appear in an hAtom document is the Entry Title
* otherwise, the Entry Title is the empty string
: ''Atom does not allow for an entry not to have a title.''

===== Entry Content =====
* an Entry Content element is identified by <code>class="content"</code>
* 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
: ''We recognize this varies from the Atom spec: see the next rule.''
* 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.''
* the "logical Entry Content" MUST be complete; that is, contain the entire content of the Entry
: ''Otherwise it should be marked as Entry Summary.''

===== Entry Summary =====
* an Entry Summary element is identified by <code>class="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
: ''We recognize this varies from the Atom spec: see the next rule.''
* 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 <code>rel="bookmark"</code>
: ''We recognize that we have broken from Atom terminology at this point. See [[hatom-issues]] for discussion.''
: ''This may be a microformat in itself: [[rel-bookmark]].''
* 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]
* Entry Permalinks SHOULD be absolute URIs
* Entry Permalinks MUST be the same as the <code>atom:link</code> (or <code>rss:link</code>) used in syndication feeds
: ''The intention of the previous two rules to gently force people to use strings that can be byte compared for equivalence. In general, the canonical URI should be the link used in an Atom entry.''
: ''Is there a problem with FeedBurner?''
* if an Entry has multiple elements marked as the Entry Permalink, they MUST have exactly the same URI
* an Entry SHOULD have an Entry Permalink
: ''There are circumstances (such as media pages) where this won't happen. See the next rule.''
* there can be at most 1 Entry in an XHTML document without an Entry Permalink; the Entry Permalink of this Entry is the URI of the page
: ''This rule is needed for media pages (i.e. a news article on cnn.com). There is some ugliness of with this because the URI could be non-canonical.''

====== Disambiguation ======

* The first valid element in an Entry marked as an Entry Permalink is the Entry Permalink

===== Entry Published =====

* an Entry Published element is identified by <code>class="published"</code>
* a Entry Published element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9 atom published]
* the machine readable datetime should be encoded with an <code><abbr></code> element using the [[datetime-design-pattern]]; the machine readable datetime should be complete, that is, specified to the second with the timezone included
: ''This is to be consistent with the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.3.3 Atom Datetime Construct].
* optionally, this can be specified by an HTML element with the ISO datetime in the text.
: ''This is a little uglier for the reader, but it's possible.''

====== Disambiguation ======

* The first valid element in an Entry marked as an Entry Published is the Entry Published element

===== Entry Updated =====

* an Entry Updated element is identified by <code>class="updated"</code>
* a Entry Updated element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15 atom updated]
* the machine readable datetime should be encoded with an <code><abbr></code> element using the [[datetime-design-pattern]]; the machine readable datetime should be complete, that is, specified to the second with the timezone included
: ''This is to be consistent with the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.3.3 Atom Datetime Construct].
* if there is no Entry Updated element, the value is assumed to be that of Entry Published
: ''Entry Published is more often available in weblog templates, so we're going with that.''
* if there is no Entry Updated and Entry Published elements, transformation to Atom is problematic
: ''This is because a published element is required. Suggestions would be appreciated here.''
* optionally, this can be specified by an HTML element with the ISO datetime in the text.
: ''This is a little uglier for the reader, but it's possible.''

====== Disambiguation ======

* The first valid element in an Entry marked as an Entry Updated is the Entry Updated element

===== Entry Author =====

* an Entry Author element is represented by <code>class="author"</code>
* an Entry Author element SHOULD use an XHTML <code><address></code> element
* 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 SHOULD contain an [[hcard|hCard]]
: ''If it does not, just consider the text to effectively be the FN''
* an Entry MAY have 0 or more Entry Author elements
* if an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page
: ''Atom requires at least one Author''

===== Entry Contibutor =====

* an Entry Contibutor element is represented by <code>class="contributor"</code>
* an Entry Contibutor element SHOULD use an XHTML <code><address></code> element
* an Entry Contibutor element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.3 atom contributor]
* an Entry Contibutor element SHOULD contain an [[hcard|hCard]]
: ''If it does not, just consider the text to be the FN''
* an Entry MAY have 0 or more Entry Contibutor elements

=== 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>feed</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>entry</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>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>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>

=== Parsing Details ===

== Examples ==

This section is informative.

=== Transformation 1 ===

A well behaved weblog.

Original:

<pre><nowiki>
<body>
<div id="wrap">
<div id="content">
...
<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a>
</h3>
<p>We had a bit of trouble with ...</p>
<p>We’ve restored the wiki and ...</p>
<p>If anyone is working to combat said spammers ...</p>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://technorati.com/tag/mediawiki" rel="tag">mediawiki</a></li>
<li><a href="http://technorati.com/tag/microformats" rel="tag">microformats</a></li>
<li><a href="http://technorati.com/tag/spam" rel="tag">spam</a></li>
</ul>

<ul class="post-info">
<li>
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">October 10th, 2005</a>
</li>
<li>
<address class="vcard"><a class="url fn" href="http://theryanking.com">Ryan King</a></address>
</li>
<li>
<a href="http://www.microformats.org/blog/...">4 Comments</a>
</li>
</ul>
</div>

<div class="entry">
....
</div>
...
</div>
</div>
</body>
</nowiki></pre>

Transformed to hAtom compliant (shown in UPPER CASE for visibility only):

<pre><nowiki>
<body>
<div id="wrap">
<div CLASS="FEED" id="content">
...
<div class="entry" ID="post-60">
<h3>
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a>
</h3>
<DIV CLASS="CONTENT">
<p>We had a bit of trouble with ...</p>
<p>We’ve restored the wiki and ...</p>
<p>If anyone is working to combat said spammers ...</p>
</DIV>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://technorati.com/tag/mediawiki" rel="tag">mediawiki</a></li>
<li><a href="http://technorati.com/tag/microformats" rel="tag">microformats</a></li>
<li><a href="http://technorati.com/tag/spam" rel="tag">spam</a></li>
</ul>

<ul class="post-info">
<li>
<a href="http://www.microformats.org/blog/..." rel="bookmark"
title="..."><ABBR CLASS="PUBLISHED" TITLE="2005-10-10T14:07:00-07:00">October 10th, 2005</ABBR></a>
</li>
<li>
<address class="vcard"><a class="url fn" href="http://theryanking.com">Ryan King</a></address>
</li>
<li>
<a href="http://www.microformats.org/blog/...">4 Comments</a>
</li>
</ul>
</div>

<div class="entry" ID="post-59">
....
</div>
...
</div>
</div>
</body>
</nowiki></pre>

Changes:
* Added <code>class="feed"</code> to Feed
* Moved <code>id="###"</code> from <code><h3></code> to Entry
* Added <code><div class="content"></code>...<code></div></code> around the Entry Content
* Added <code><abbr class="PUBLISHED" title="YYYY-MM-DDThh:mm:ss+ZZ:ZZ"></code>...<code></abbr></code> around the Entry Datetime

Also note:
* We did not need to add a <code>class="entry"</code> to each Entry
* We did not need to add a <code><address></code> element
* We did not need to add a <code><h#></code> element
* We did not need to add a <code>rel="bookmark"</code> to Entry Permalinks

=== Transformation 2 ===

A not-so well behaved weblog (an older blogspot weblog)

Original:

<pre><nowiki>
<body bgcolor="...">

<div class="posts">
<a name="112993192128302715"> </a><br>
<div style="clear:both;"></div><strong>Nelson's final prayer</strong>
written on the night before Trafalgar:<blockquote>May the Great God, ... heart.
<div style="clear:both; padding-bottom: 0.25em;"></div>
<br>
<span class="byline">
posted by Natalie at
<a href="2005_10_16_nataliesolent_archive.html#112993192128302715">9:49 PM</a>
</span>
</div>

<div class="posts">
<a name="112993022840118939"> </a>
<br>
<div style="clear:both;"></div><strong>I really, truly </strong>didn't go ... view.
<div style="clear:both; padding-bottom: 0.25em;"></div>
<br>
<span class="byline">
posted by Natalie at
<a href="2005_10_16_nataliesolent_archive.html#112993022840118939">9:28 PM</a>
</span>
</div>
...

</body>
</nowiki></pre>

Transformed to hAtom compliant (shown in UPPER CASE for visibility only):

<pre><nowiki>
<body bgcolor="...">

<DIV CLASS="FEED">
<div class="ENTRY posts" ID="112993192128302715">
<strong CLASS="TITLE CONTENT">
Nelson's final prayer
</strong>
<SPAN CLASS="CONTENT">
written on the night before Trafalgar:<blockquote>May the Great God, ... heart.
</SPAN>
<DIV>
<span class="byline">posted by <address>Natalie</address> at
<a REL="BOOKMARK" href="HTTP://NATALIESOLENT.BLOGSPOT.COM/2005_10_16_nataliesolent_archive.html#112993192128302715">
<ABBR CLASS="PUBLISHED" TITLE="2005-10-24T09:49:00-00:00">9:49 PM</ABBR></a>
</span>
</DIV>
</div>

<div class="ENTRY posts" ID="112993022840118939">
<strong CLASS="TITLE CONTENT">I really, truly </strong>
<SPAN CLASS="CONTENT">
didn't go ... view.
</SPAN>
<DIV>
<span class="byline">
posted by <address>Natalie</address> at
<a REL="BOOKMARK" href="HTTP://NATALIESOLENT.BLOGSPOT.COM/2005_10_16_nataliesolent_archive.html#112993022840118939">
<ABBR CLASS="PUBLISHED" TITLE="2005-10-24T09:49:00-00:00">9:28 PM</ABBR></a>
</span>
</DIV>
</div>
...
</DIV>

</body>
</nowiki></pre>

Changes:
* Added <code>class="feed"</code> to Feed
* Added <code>class="entry"</code> to each Entry
* Moved <code>id="###"</code> up to the Entry (and deleted the empty anchor block)
* Added <code>rel="bookmark"</code> to the Entry Permalinks
* Made the Entry Permalink non-relative
* Added <code><span class="title"></code>...<code></div></code> around the Entry Title
* Added <code><span class="content"></code>...<code></div></code> around the Entry Title (!)
* Added <code><span class="content"></code>...<code></div></code> around the Entry Content
* Added <code><abbr class="published" title="YYYY-MM-DDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code><address></code> to the poster's name

Also note:
* there are multiple content blocks, because Natalie Solent embeds the title in the content
* cleaned up lots of crap HTML presentation stuff, with the assumption it would be fixed in the stylesheet
* this is one of the uglier transformations you're likely to see
* we've respected the poster's poster apparent wish for anonimity by not adding an hCard

=== Transformation 3 ===

A media page (from [http://www.cbc.ca/story/world/national/2005/11/22/birdlfu051122.html CBC Newsworld]).

Original:

<pre><nowiki>
<div class="news">
<div class="story">
<h1>China confirms new bird flu outbreaks</h1>
<span class="byline">Last Updated Tue, 22 Nov 2005 23:26:18 EST</span>
<div class="text"><a href="/news/credit.html">CBC News</a></div>

<div class="text">
<p>
China has confirmed three new outbreaks of bird flu, ...
<p>
<ul>
<li><font SIZE="1">INDEPTH: </font><font SIZE="2">
<a href="http://www.cbc.ca/news/background/avianflu/">Avian Flu</a></font>
</ul>
</p>
<table align="right" cellpadding="0" cellspacing="4" hspace="4" width="220">
<tr>
<td align="center">
<img src="http://www.cbc.ca/gfx/pix/birdflu_china_cp_7707271.jpg" width="220" height="223" hspace="3" border="0">
</td>
</tr>
<tr>
<td align="center">
<div class="caption">
<font size="1" face="verdana,arial"><i></i></font>
</div>
</td>
</tr>
</table>
<p>State media says the new outbreaks are in...</p>
<p>The news comes a day after China announced the ...</p>
<p>In China's eastern Anhui province, authorities have ...</p>
<p>The province says the measure will prevent domestic ...</p>
<p>Vietnamese health officials have confirmed that a ...</p>
<p>Doctors from the health department in the northern ...</p>
<p>Bird flu has killed 42 people in Vietnam since December ...</p>
<p>The World Health Organization fears the H5N1 strain of ...</p>
</div>

<p><font face="Verdana,Arial" size="1">with files from the Australian Broadcasting Corporation</font></p>
</div>
...
</div>
</nowiki></pre>

Transformed to hAtom compliant (shown in UPPER CASE for visibility only):

<pre><nowiki>
<div class="news">
<div class="FEED ENTRY story">
<h1>China confirms new bird flu outbreaks</h1>
<span class="byline">Last Updated
<ABBR CLASS="POSTED" TITLE="2005-11-23T04:26:18Z">Tue, 22 Nov 2005 23:26:18 EST</ABBR>
</span>
<ADDRESS CLASS="VCARD"><div class="text"><a CLASS="URL" href="/news/credit.html">CBC News</a></div></ADDRESS>

<div class="text">
<p CLASS="CONTENT">
China has confirmed three new outbreaks of bird flu, ...
</p>
<p>
<ul>
<li><font SIZE="1">INDEPTH: </font><font SIZE="2">
<a href="http://www.cbc.ca/news/background/avianflu/">Avian Flu</a></font>
</ul>
</p>
<table align="right" cellpadding="0" cellspacing="4" hspace="4" width="220">
<tr>
<td align="center">
<img src="http://www.cbc.ca/gfx/pix/birdflu_china_cp_7707271.jpg" width="220" height="223" hspace="3" border="0">
</td>
</tr>
<tr>
<td align="center">
<div class="caption">
<font size="1" face="verdana,arial"><i></i></font>
</div>
</td>
</tr>
</table>
<p CLASS="CONTENT">State media says the new outbreaks are in...</p>
<p CLASS="CONTENT">The news comes a day after China announced the ...</p>
<p CLASS="CONTENT">In China's eastern Anhui province, authorities have ...</p>
<p CLASS="CONTENT">The province says the measure will prevent domestic ...</p>
<p CLASS="CONTENT">Vietnamese health officials have confirmed that a ...</p>
<p CLASS="CONTENT">Doctors from the health department in the northern ...</p>
<p CLASS="CONTENT">Bird flu has killed 42 people in Vietnam since December ...</p>
<p CLASS="CONTENT">The World Health Organization fears the H5N1 strain of ...</p>
</div>

<p><font face="Verdana,Arial" size="1">with files from the <ADDRESS CLASS="CONTRIBUTOR">Australian Broadcasting Corporation</ADDRESS></font></p>
</div>
...
</div>
</nowiki></pre>

Changes:
* Added <code><div class="feed entry"></code> around the single entry on the page
: ''We have to make sure the nesting rules reflect nesting at the same level''
* Added <code><span class="content"></code>...<code></div></code> around every single paragraph -- this looks pathological but it may be the way this would need be produced from a template. The latter part of the document could be enclosed in a single "content" div but note that we did this so the "INDEPTH" part would not be marked as content,
* Added <code><abbr class="published" title="YYYYMMDDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code><address></code> to the CBC Newsroom
* Added <code><address class="contributor"></code> to a contributor's name

Also note:
* We may the document more XHTML compliant
* There is no <code>rel="bookmark"</code> so it is assumed to be the URI of the page
* The Entry Title was correctly marked with a <code><h1></code> element

=== Transformation 4 ===

A bulletin board ([http://forums.punbb.org/viewtopic.php?id=9135 PunBB])

Original:

<pre><nowiki>
<body>
<div id="punwrap">
<div id="punviewtopic" class="pun">

<div id="brdheader" class="block">
... header stuff ...
</div>

<div id="announce" class="block">
... announcement stuff ...
</div>

<div class="linkst">
... controls for the blog
</div>

<div id="p54390" class="blockpost rowodd firstpost">
<h2>
<span><span class="conr">#1 </span>
<a href="viewtopic.php?pid=54390#p54390">2005-10-16 10:36:24</a></span>
</h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><a href="profile.php?id=2">Rickard</a></strong></dt>

<dd class="usertitle"><strong>PunBB Developer</strong></dd>
<dd class="postavatar"><img src="img/avatars/2.png" width="60" height="60" alt="" /></dd>
<dd>From: 127.0.0.1</dd>
<dd>Registered: 2001-11-02</dd>
<dd>Posts: 7806</dd>
<dd class="usercontacts"><a href="http://www.punbb.org/">Website</a></dd>

</dl>
</div>
<div class="postright">
<h3>PunBB 1.2.9</h3>
<div class="postmsg">
<p>Just a quick note this time....</p>

</div>
<div class="postsignature"><hr />"Programming is like sex: ...</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>
<div class="postfootright"><div> </div></div>
</div>
</div>

</div>

<div id="p54392" class="blockpost roweven">
<h2><span><span class="conr">#2 </span><a href="viewtopic.php?pid=54392#p54392">2005-10-16 10:54:41</a></span></h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><a href="profile.php?id=5298">IdleFire</a></strong></dt>

<dd class="usertitle"><strong>Member</strong></dd>
<dd class="postavatar"></dd>
<dd>Registered: 2005-10-14</dd>
<dd>Posts: 27</dd>
</dl>
</div>
<div class="postright">

<h3> Re: PunBB 1.2.9</h3>
<div class="postmsg">
<p>...</p>
</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>

<div class="postfootright"><div> </div></div>
</div>
</div>
</div>

... more entries ...

<div id="brdfooter" class="block">
... footer stuff ...
</div>

</div>
</div>
</body>
</nowiki></pre>

Transformed to hAtom compliant (changes shown in UPPER CASE for visibility only):

<pre><nowiki>
<body>
<div id="punwrap">
<div id="punviewtopic" class="pun">

<div id="brdheader" class="block">
... header stuff ...
</div>

<div id="announce" class="block">
... announcement stuff ...
</div>

<div class="linkst">
... controls for the blog
</div>

<DIV CLASS="FEED">
<div id="p54390" class="ENTRY blockpost rowodd firstpost">
<h2>
<span><span class="conr">#1 </span>
<a REL="BOOKMARK" href="HTTP://FORUMS.PUNBB.ORG/viewtopic.php?pid=54390#p54390">
<ABBR CLASS="POSTED" TITLE="20051016T103624-0500">2005-10-16 10:36:24</ABBR>
</a></span>
</h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><ADDRESS><a href="profile.php?id=2">Rickard</a></ADDRESS></strong></dt>

<dd class="usertitle"><strong>PunBB Developer</strong></dd>
<dd class="postavatar"><img src="img/avatars/2.png" width="60" height="60" alt="" /></dd>
<dd>From: 127.0.0.1</dd>
<dd>Registered: 2001-11-02</dd>
<dd>Posts: 7806</dd>
<dd class="usercontacts"><a href="http://www.punbb.org/">Website</a></dd>

</dl>
</div>
<div class="postright">
<h3>PunBB 1.2.9</h3>
<div class="CONTENT postmsg">
<p>Just a quick note this time....</p>

</div>
<div class="postsignature"><hr />"Programming is like sex: ...</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>
<div class="postfootright"><div> </div></div>
</div>
</div>

</div>

<div id="p54392" class="ENTRY blockpost roweven">
<h2>
<span><span class="conr">#2 </span>
<a REL="BOOKMARK" href="HTTP://FORUMS.PUNBB.ORG/viewtopic.php?pid=54392#p54392">
<ABBR CLASS="POSTED" TITLE="20051016T1105441-0500">2005-10-16 10:54:41</ABBR>
</a></span>
</h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><ADDRESS CLASS="VCARD"><a CLASS="URL" href="profile.php?id=5298">IdleFire</a></ADDRESS></strong></dt>

<dd class="usertitle"><strong>Member</strong></dd>
<dd class="postavatar"></dd>
<dd>Registered: 2005-10-14</dd>
<dd>Posts: 27</dd>
</dl>
</div>
<div class="postright">

<h3> Re: PunBB 1.2.9</h3>
<div class="CONTENT postmsg">
<p>...</p>
</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>

<div class="postfootright"><div> </div></div>
</div>
</div>
</div>

... more entries ...
</DIV>

<div id="brdfooter" class="block">
... footer stuff ...
</div>

</div>
</div>
</body>
</nowiki></pre>

Changes:
* Added <code><div class="feed"></code> around the entries (as opposed to an existing <code><div</code> that enclosed more than entries.
* Added <code>class="entry"</code> to each Entry
* Added <code>rel="bookmark"</code> to the Entry Permalinks
* Made the Entry Permalink non-relative
* Added <code><span class="title"></code>...<code></div></code> around the Entry Title
* Added <code><span class="content"></code>...<code></div></code> around the Entry Content
* Added <code><abbr class="posted" title="YYYYMMDDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code><address></code> to the poster's name

Also note:
* We did not need to add <code>id="###"</code> to the Entry

=== More Examples ===

See [[hatom-examples]].

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

* [http://blog.davidjanes.com Ranting and Roaring] (David Janes)
* [http://www.myelin.co.nz/post/ Second p0st] (Phil Pearson)
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Sound Advice] (Benjamin Carlyle)

== Implementations ==

This section is '''informative'''.

* 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
* An [http://lukearno.com/projects/hAtom/ hAtom-2-Atom] XSLT is available

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

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

== Hints and Tips ==

=== CSS tips ===
HTML typically styles <code>address</code> as a block level element in an italic font. This will make it inline and plain within hAtom elements:

<pre><nowiki>
.entry address {
display: inline;
font-weight: normal;
font-style: normal;
}
</nowiki></pre>

HTML typically puts a dotted line under <code><abbr></code> elements. This will put postage paid to that for Entry Updated and Entry Posted:

<pre><nowiki>
.entry abbr.updated, .entry abbr.posted {
font-style: normal;
border: none;
}
</nowiki></pre>

=== MovableType Template ===

A datetime encoded in an ABBR element can be produced with the following template code:

<pre><nowiki>
<abbr
class="posted"
title="<$MTEntryDate format="%Y%m%dT%H%M%S"$><$MTBlogTimezone
no_colon="1"$>"><$MTEntryDate format="%X"$></abbr>
</nowiki></pre>

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

== Recent Changes ==

''Most recent at top please. This section will eventually be removed but should be helpful for people tracking changes during specing.''

* Entry Permalink now SHOULD (as opposed to MUST) be a complete URI
* Entry Title now preferentially uses class="title"
* Entry Author most explicitly be marked class="author"
* using an <code><address</code> around Entry Author and Entry Contributor is no longer required

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

hatom

2005-12-26T12:49:07Z

FuzzyBSc: Add href to my name under Contributors

= hAtom =

hAtom is a microformat for content that can be syndicated, primarily but not exclusively weblog postings. hAtom is a strongly based on a subset of the [http://www.atomenabled.org/ Atom] syndication format; every concept in hAtom has a corresponding definition in Atom.

This microformat is a draft; please address your concerns, issues, comments, etc. in [[hatom-issues]].

__TOC__

== Draft Specification ==

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

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

=== Contributors ===
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Benjamin Carlyle]

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

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

== Introduction ==

== 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. This can (and probably should) be expanded.
* 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 "briding the gap"
:: ''for example, if an entry is missing an author (required by Atom), it is assumed to be that of the XHTML page''

=== Schema ===
Schema elements are based on the Atom nomenclature and follow the microformat pattern of prefixing a unique identifier (in this case, <code>atom</code>) on the outermost container elements -- the Feed or Entry. The parts of this microformat are based on analysis of many weblog, bulletin board and media posts and can be read [[blog-post-brainstorming#Discovered_Elements]]. Note the renaming of 'EntryGroup' to 'Feed' to be more consistent with Atom ternminology.

==== Nomenclature ====

{| width="100%" border="1" cellspacing="0"
|-
! width="150" | Concept
! Atom Identifier
! hAtom Microformat Usage
|-
| Feed
| <code>atom:feed</code>
| add <code>class="feed"</code>
|-
| Entry
| <code>atom:entry</code>
| Add <code>class="entry"</code>; if practical, also define <code>id="unique-identifier"</code> to the Entry.
|-
| Entry Title
| <code>atom:title</code>
| Add <code>class="title"</code>, alternately by <code><h#></code>.
|-
| Entry Content
| <code>atom:content</code>
| Add <code>class="content"</code> to all appropriate blocks. Multiple Entry Content blocks are logically considered one concatenated <code>atom:content</code> equivalent.
|-
| Entry Summary
| <code>atom:summary</code>
| Add <code>class="summary"</code> to all appropriate blocks. Multiple Entry Summary blocks are logically considered one concatenated <code>atom:summary</code> equivalent.
|-
| Entry Permalink
| <code>atom:link</code>
| Add <code>rel="bookmark"</code>.
|-
| Entry Published
| <code>atom:published</code>
| Use <code><abbr class="published" title="YYYYMMYYThh:mm:ss±ZZ:ZZ"></code>...<code></abbr></code>, following the [[datetime-design-pattern]].
|-
| Entry Updated
| <code>atom:updated</code>
| Use <code><abbr class="updated" title="YYYYMMYYThh:mm:ss±ZZ:ZZ"></code>...<code></abbr></code>, following the [[datetime-design-pattern]].
|-
| Entry Author
| <code>atom:author</code>
| Use <code><address></code>...<code></address></code>. Adding <code>class="author"</code> is optional. Adding a [[hcard|hCard]] is highly recommended.
|-
| Entry Contributor
| <code>atom:contibutor</code>
| Use <code><address class="contributor"></code>...<code></address></code>. Adding a [[hcard|hCard]] is highly recommended.
|}

==== Nesting Rules ====

{| width="100%" border="1" cellspacing="0"
|-
! Concept
! Nests In
! hAtom Opaque
! Cardinality
! Logical Cardinality
|-
| Feed
| HTML document
| No
| 1-N
| 1-N
|-
| Entry
| Feed
| No
| 0-N
| 0-N
|-
| Entry Title
| Entry<br />Entry Permalink
| No
| 0-N
| 0-1
|-
| Entry Content
| Entry
| Yes
| 0-N
| 0-1
|-
| Entry Summary
| Entry
| Yes
| 0-N
| 0-1
|-
| Entry Permalink
| Entry<br />Entry Title<br />Entry Published
| No
| 0-N
| 1
|-
| Entry Published
| Entry<br />Entry Permalink
| No
| 0-N
| 0-1
|-
| Entry Updated
| Entry<br />Entry Permalink
| No
| 0-N
| 1
|-
| Entry Author
| Entry
| Yes
| 0-N
| 1-N
|-
| Entry Contibutor
| Entry
| Yes
| 0-N
| 0-N
|}

===== hAtom Opaque =====

"hAtom Opaque" specifies whether a hAtom parser should "look inside" the element for further hAtom content. If there are multiple rules applied to the same element take the OR of the two (i.e. "Yes" always wins)

: ''hAtom Opaque is designed to make parsing rules less ambiguous. In particular, it allows "quoted" hAtom elements (from another blog being blockquoted, for example) ti be ignored. It also allows 'embedded' hAtom to be potentially delivered within hAtom itself, and to prevent accidental 'leaking' of other microformat information up into the hAtom container.''

===== Cardinality =====

How many times can an element of the given type appear in it's nesting/parent element.

===== Logical Cardinality =====

From a modeling/logical perspective, the number of times can an element appear.

: ''This is all rule dependent, see below. For example, an Entry Permalink may appear 6 times, but each one must be the same value; an Entry Content element may appear 3 times, but they are all concatenated together to make a single logical element.''

==== Rules and Definitions ====
See the [[#Nesting_Rules|Nesting Rules]] section above for placement of these elements.

===== Feed =====
* an XHTML Feed element is identified by <code>class="feed"</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]
: ''In particular, as a container for Entrys.''
* the Feed element is required, even if there is a single Entry
: ''This is for disambiguation''
* hAtom documents MAY have multiple, non-nested Feed elements
: ''This may happen on news pages, or weblogs with "mini-blogs" on the sidebar.''

===== Entry =====
* an Entry element is identified by <code>class="entry"</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]
* a weblog entry MUST be enclosed in a single Entry element
: ''That's what it's for, after all.''
* an Entry MUST have an enclosing Feed element
* ''This enclosing element can be the same as the Entry -- i.e. class="feed entry" is OK for feeds with a single entry.''

===== Entry Title =====
* an Entry Title element is identified by <code>class="title"</code>
* an Entry Title element alternately be identified by <code><h#></code>
* 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]

====== Disambiguation ======

* the first hAtom valid element with a <code>class="title"</code> is the Entry Title
: ''hAtom valid meaning somewhere where we expect it (like not inside Entry Content, for example).''
* otherwise, the first hAtom valid <code><h#></code> element to appear in an hAtom document is the Entry Title
* otherwise, the Entry Title is the empty string
: ''Atom does not allow for an entry not to have a title.''

===== Entry Content =====
* an Entry Content element is identified by <code>class="content"</code>
* 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
: ''We recognize this varies from the Atom spec: see the next rule.''
* 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.''
* the "logical Entry Content" MUST be complete; that is, contain the entire content of the Entry
: ''Otherwise it should be marked as Entry Summary.''

===== Entry Summary =====
* an Entry Summary element is identified by <code>class="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
: ''We recognize this varies from the Atom spec: see the next rule.''
* 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 <code>rel="bookmark"</code>
: ''We recognize that we have broken from Atom terminology at this point. See [[hatom-issues]] for discussion.''
: ''This may be a microformat in itself: [[rel-bookmark]].''
* 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]
* Entry Permalinks MUST be absolute URIs
* Entry Permalinks MUST be the same as the <code>atom:link</code> (or <code>rss:link</code>) used in syndication feeds
: ''The intention of the previous two rules to gently force people to use strings that can be byte compared for equivalence. In general, the canonical URI should be the link used in an Atom entry.''
: ''Is there a problem with FeedBurner?''
* if an Entry has multiple elements marked as the Entry Permalink, they MUST have exactly the same URI
* an Entry SHOULD have an Entry Permalink
: ''There are circumstances (such as media pages) where this won't happen. See the next rule.''
* there can be at most 1 Entry in an XHTML document without an Entry Permalink; the Entry Permalink of this Entry is the URI of the page
: ''This rule is needed for media pages (i.e. a news article on cnn.com). There is some ugliness of with this because the URI could be non-canonical.''

====== Disambiguation ======

* The first valid element in an Entry marked as an Entry Permalink is the Entry Permalink

===== Entry Published =====

* an Entry Published element is identified by <code>class="published"</code>
* a Entry Published element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.9 atom published]
* the machine readable datetime should be encoded with an <code><abbr></code> element using the [[datetime-design-pattern]]; the machine readable datetime should be complete, that is, specified to the second with the timezone included
: ''This is to be consistent with the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.3.3 Atom Datetime Construct].
* optionally, this can be specified by an HTML element with the ISO datetime in the text.
: ''This is a little uglier for the reader, but it's possible.''

====== Disambiguation ======

* The first valid element in an Entry marked as an Entry Published is the Entry Published element

===== Entry Updated =====

* an Entry Updated element is identified by <code>class="updated"</code>
* a Entry Updated element represents the concept of [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.15 atom updated]
* the machine readable datetime should be encoded with an <code><abbr></code> element using the [[datetime-design-pattern]]; the machine readable datetime should be complete, that is, specified to the second with the timezone included
: ''This is to be consistent with the [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.3.3 Atom Datetime Construct].
* if there is no Entry Updated element, the value is assumed to be that of Entry Published
: ''Entry Published is more often available in weblog templates, so we're going with that.''
* if there is no Entry Updated and Entry Published elements, transformation to Atom is problematic
: ''This is because a published element is required. Suggestions would be appreciated here.''
* optionally, this can be specified by an HTML element with the ISO datetime in the text.
: ''This is a little uglier for the reader, but it's possible.''

====== Disambiguation ======

* The first valid element in an Entry marked as an Entry Updated is the Entry Updated element

===== Entry Author =====

* an Entry Author element is represented by <code>class="author"</code>
* an Entry Author element SHOULD use an XHTML <code><address></code> element
* 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 SHOULD contain an [[hcard|hCard]]
: ''If it does not, just consider the text to effectively be the FN''
* an Entry MAY have 0 or more Entry Author elements
* if an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page
: ''Atom requires at least one Author''

===== Entry Contibutor =====

* an Entry Contibutor element is represented by <code>class="contributor"</code>
* an Entry Contibutor element SHOULD use an XHTML <code><address></code> element
* an Entry Contibutor element represents the concept of an [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.3 atom contributor]
* an Entry Contibutor element SHOULD contain an [[hcard|hCard]]
: ''If it does not, just consider the text to be the FN''
* an Entry MAY have 0 or more Entry Contibutor elements

=== 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>feed</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>entry</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>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>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>

=== Parsing Details ===

== Examples ==

This section is informative.

=== Transformation 1 ===

A well behaved weblog.

Original:

<pre><nowiki>
<body>
<div id="wrap">
<div id="content">
...
<div class="entry">
<h3 id="post-60">
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a>
</h3>
<p>We had a bit of trouble with ...</p>
<p>We’ve restored the wiki and ...</p>
<p>If anyone is working to combat said spammers ...</p>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://technorati.com/tag/mediawiki" rel="tag">mediawiki</a></li>
<li><a href="http://technorati.com/tag/microformats" rel="tag">microformats</a></li>
<li><a href="http://technorati.com/tag/spam" rel="tag">spam</a></li>
</ul>

<ul class="post-info">
<li>
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">October 10th, 2005</a>
</li>
<li>
<address class="vcard"><a class="url fn" href="http://theryanking.com">Ryan King</a></address>
</li>
<li>
<a href="http://www.microformats.org/blog/...">4 Comments</a>
</li>
</ul>
</div>

<div class="entry">
....
</div>
...
</div>
</div>
</body>
</nowiki></pre>

Transformed to hAtom compliant (shown in UPPER CASE for visibility only):

<pre><nowiki>
<body>
<div id="wrap">
<div CLASS="FEED" id="content">
...
<div class="entry" ID="post-60">
<h3>
<a href="http://www.microformats.org/blog/..." rel="bookmark" title="...">Wiki Attack</a>
</h3>
<DIV CLASS="CONTENT">
<p>We had a bit of trouble with ...</p>
<p>We’ve restored the wiki and ...</p>
<p>If anyone is working to combat said spammers ...</p>
</DIV>

<h4 class="tags">Technorati Tags:</h4>
<ul class="tags">
<li><a href="http://technorati.com/tag/mediawiki" rel="tag">mediawiki</a></li>
<li><a href="http://technorati.com/tag/microformats" rel="tag">microformats</a></li>
<li><a href="http://technorati.com/tag/spam" rel="tag">spam</a></li>
</ul>

<ul class="post-info">
<li>
<a href="http://www.microformats.org/blog/..." rel="bookmark"
title="..."><ABBR CLASS="PUBLISHED" TITLE="2005-10-10T14:07:00-07:00">October 10th, 2005</ABBR></a>
</li>
<li>
<address class="vcard"><a class="url fn" href="http://theryanking.com">Ryan King</a></address>
</li>
<li>
<a href="http://www.microformats.org/blog/...">4 Comments</a>
</li>
</ul>
</div>

<div class="entry" ID="post-59">
....
</div>
...
</div>
</div>
</body>
</nowiki></pre>

Changes:
* Added <code>class="feed"</code> to Feed
* Moved <code>id="###"</code> from <code><h3></code> to Entry
* Added <code><div class="content"></code>...<code></div></code> around the Entry Content
* Added <code><abbr class="PUBLISHED" title="YYYY-MM-DDThh:mm:ss+ZZ:ZZ"></code>...<code></abbr></code> around the Entry Datetime

Also note:
* We did not need to add a <code>class="entry"</code> to each Entry
* We did not need to add a <code><address></code> element
* We did not need to add a <code><h#></code> element
* We did not need to add a <code>rel="bookmark"</code> to Entry Permalinks

=== Transformation 2 ===

A not-so well behaved weblog (an older blogspot weblog)

Original:

<pre><nowiki>
<body bgcolor="...">

<div class="posts">
<a name="112993192128302715"> </a><br>
<div style="clear:both;"></div><strong>Nelson's final prayer</strong>
written on the night before Trafalgar:<blockquote>May the Great God, ... heart.
<div style="clear:both; padding-bottom: 0.25em;"></div>
<br>
<span class="byline">
posted by Natalie at
<a href="2005_10_16_nataliesolent_archive.html#112993192128302715">9:49 PM</a>
</span>
</div>

<div class="posts">
<a name="112993022840118939"> </a>
<br>
<div style="clear:both;"></div><strong>I really, truly </strong>didn't go ... view.
<div style="clear:both; padding-bottom: 0.25em;"></div>
<br>
<span class="byline">
posted by Natalie at
<a href="2005_10_16_nataliesolent_archive.html#112993022840118939">9:28 PM</a>
</span>
</div>
...

</body>
</nowiki></pre>

Transformed to hAtom compliant (shown in UPPER CASE for visibility only):

<pre><nowiki>
<body bgcolor="...">

<DIV CLASS="FEED">
<div class="ENTRY posts" ID="112993192128302715">
<strong CLASS="TITLE CONTENT">
Nelson's final prayer
</strong>
<SPAN CLASS="CONTENT">
written on the night before Trafalgar:<blockquote>May the Great God, ... heart.
</SPAN>
<DIV>
<span class="byline">posted by <address>Natalie</address> at
<a REL="BOOKMARK" href="HTTP://NATALIESOLENT.BLOGSPOT.COM/2005_10_16_nataliesolent_archive.html#112993192128302715">
<ABBR CLASS="PUBLISHED" TITLE="2005-10-24T09:49:00-00:00">9:49 PM</ABBR></a>
</span>
</DIV>
</div>

<div class="ENTRY posts" ID="112993022840118939">
<strong CLASS="TITLE CONTENT">I really, truly </strong>
<SPAN CLASS="CONTENT">
didn't go ... view.
</SPAN>
<DIV>
<span class="byline">
posted by <address>Natalie</address> at
<a REL="BOOKMARK" href="HTTP://NATALIESOLENT.BLOGSPOT.COM/2005_10_16_nataliesolent_archive.html#112993022840118939">
<ABBR CLASS="PUBLISHED" TITLE="2005-10-24T09:49:00-00:00">9:28 PM</ABBR></a>
</span>
</DIV>
</div>
...
</DIV>

</body>
</nowiki></pre>

Changes:
* Added <code>class="feed"</code> to Feed
* Added <code>class="entry"</code> to each Entry
* Moved <code>id="###"</code> up to the Entry (and deleted the empty anchor block)
* Added <code>rel="bookmark"</code> to the Entry Permalinks
* Made the Entry Permalink non-relative
* Added <code><span class="title"></code>...<code></div></code> around the Entry Title
* Added <code><span class="content"></code>...<code></div></code> around the Entry Title (!)
* Added <code><span class="content"></code>...<code></div></code> around the Entry Content
* Added <code><abbr class="published" title="YYYY-MM-DDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code><address></code> to the poster's name

Also note:
* there are multiple content blocks, because Natalie Solent embeds the title in the content
* cleaned up lots of crap HTML presentation stuff, with the assumption it would be fixed in the stylesheet
* this is one of the uglier transformations you're likely to see
* we've respected the poster's poster apparent wish for anonimity by not adding an hCard

=== Transformation 3 ===

A media page (from [http://www.cbc.ca/story/world/national/2005/11/22/birdlfu051122.html CBC Newsworld]).

Original:

<pre><nowiki>
<div class="news">
<div class="story">
<h1>China confirms new bird flu outbreaks</h1>
<span class="byline">Last Updated Tue, 22 Nov 2005 23:26:18 EST</span>
<div class="text"><a href="/news/credit.html">CBC News</a></div>

<div class="text">
<p>
China has confirmed three new outbreaks of bird flu, ...
<p>
<ul>
<li><font SIZE="1">INDEPTH: </font><font SIZE="2">
<a href="http://www.cbc.ca/news/background/avianflu/">Avian Flu</a></font>
</ul>
</p>
<table align="right" cellpadding="0" cellspacing="4" hspace="4" width="220">
<tr>
<td align="center">
<img src="http://www.cbc.ca/gfx/pix/birdflu_china_cp_7707271.jpg" width="220" height="223" hspace="3" border="0">
</td>
</tr>
<tr>
<td align="center">
<div class="caption">
<font size="1" face="verdana,arial"><i></i></font>
</div>
</td>
</tr>
</table>
<p>State media says the new outbreaks are in...</p>
<p>The news comes a day after China announced the ...</p>
<p>In China's eastern Anhui province, authorities have ...</p>
<p>The province says the measure will prevent domestic ...</p>
<p>Vietnamese health officials have confirmed that a ...</p>
<p>Doctors from the health department in the northern ...</p>
<p>Bird flu has killed 42 people in Vietnam since December ...</p>
<p>The World Health Organization fears the H5N1 strain of ...</p>
</div>

<p><font face="Verdana,Arial" size="1">with files from the Australian Broadcasting Corporation</font></p>
</div>
...
</div>
</nowiki></pre>

Transformed to hAtom compliant (shown in UPPER CASE for visibility only):

<pre><nowiki>
<div class="news">
<div class="FEED ENTRY story">
<h1>China confirms new bird flu outbreaks</h1>
<span class="byline">Last Updated
<ABBR CLASS="POSTED" TITLE="2005-11-23T04:26:18Z">Tue, 22 Nov 2005 23:26:18 EST</ABBR>
</span>
<ADDRESS CLASS="VCARD"><div class="text"><a CLASS="URL" href="/news/credit.html">CBC News</a></div></ADDRESS>

<div class="text">
<p CLASS="CONTENT">
China has confirmed three new outbreaks of bird flu, ...
</p>
<p>
<ul>
<li><font SIZE="1">INDEPTH: </font><font SIZE="2">
<a href="http://www.cbc.ca/news/background/avianflu/">Avian Flu</a></font>
</ul>
</p>
<table align="right" cellpadding="0" cellspacing="4" hspace="4" width="220">
<tr>
<td align="center">
<img src="http://www.cbc.ca/gfx/pix/birdflu_china_cp_7707271.jpg" width="220" height="223" hspace="3" border="0">
</td>
</tr>
<tr>
<td align="center">
<div class="caption">
<font size="1" face="verdana,arial"><i></i></font>
</div>
</td>
</tr>
</table>
<p CLASS="CONTENT">State media says the new outbreaks are in...</p>
<p CLASS="CONTENT">The news comes a day after China announced the ...</p>
<p CLASS="CONTENT">In China's eastern Anhui province, authorities have ...</p>
<p CLASS="CONTENT">The province says the measure will prevent domestic ...</p>
<p CLASS="CONTENT">Vietnamese health officials have confirmed that a ...</p>
<p CLASS="CONTENT">Doctors from the health department in the northern ...</p>
<p CLASS="CONTENT">Bird flu has killed 42 people in Vietnam since December ...</p>
<p CLASS="CONTENT">The World Health Organization fears the H5N1 strain of ...</p>
</div>

<p><font face="Verdana,Arial" size="1">with files from the <ADDRESS CLASS="CONTRIBUTOR">Australian Broadcasting Corporation</ADDRESS></font></p>
</div>
...
</div>
</nowiki></pre>

Changes:
* Added <code><div class="feed entry"></code> around the single entry on the page
: ''We have to make sure the nesting rules reflect nesting at the same level''
* Added <code><span class="content"></code>...<code></div></code> around every single paragraph -- this looks pathological but it may be the way this would need be produced from a template. The latter part of the document could be enclosed in a single "content" div but note that we did this so the "INDEPTH" part would not be marked as content,
* Added <code><abbr class="published" title="YYYYMMDDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code><address></code> to the CBC Newsroom
* Added <code><address class="contributor"></code> to a contributor's name

Also note:
* We may the document more XHTML compliant
* There is no <code>rel="bookmark"</code> so it is assumed to be the URI of the page
* The Entry Title was correctly marked with a <code><h1></code> element

=== Transformation 4 ===

A bulletin board ([http://forums.punbb.org/viewtopic.php?id=9135 PunBB])

Original:

<pre><nowiki>
<body>
<div id="punwrap">
<div id="punviewtopic" class="pun">

<div id="brdheader" class="block">
... header stuff ...
</div>

<div id="announce" class="block">
... announcement stuff ...
</div>

<div class="linkst">
... controls for the blog
</div>

<div id="p54390" class="blockpost rowodd firstpost">
<h2>
<span><span class="conr">#1 </span>
<a href="viewtopic.php?pid=54390#p54390">2005-10-16 10:36:24</a></span>
</h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><a href="profile.php?id=2">Rickard</a></strong></dt>

<dd class="usertitle"><strong>PunBB Developer</strong></dd>
<dd class="postavatar"><img src="img/avatars/2.png" width="60" height="60" alt="" /></dd>
<dd>From: 127.0.0.1</dd>
<dd>Registered: 2001-11-02</dd>
<dd>Posts: 7806</dd>
<dd class="usercontacts"><a href="http://www.punbb.org/">Website</a></dd>

</dl>
</div>
<div class="postright">
<h3>PunBB 1.2.9</h3>
<div class="postmsg">
<p>Just a quick note this time....</p>

</div>
<div class="postsignature"><hr />"Programming is like sex: ...</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>
<div class="postfootright"><div> </div></div>
</div>
</div>

</div>

<div id="p54392" class="blockpost roweven">
<h2><span><span class="conr">#2 </span><a href="viewtopic.php?pid=54392#p54392">2005-10-16 10:54:41</a></span></h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><a href="profile.php?id=5298">IdleFire</a></strong></dt>

<dd class="usertitle"><strong>Member</strong></dd>
<dd class="postavatar"></dd>
<dd>Registered: 2005-10-14</dd>
<dd>Posts: 27</dd>
</dl>
</div>
<div class="postright">

<h3> Re: PunBB 1.2.9</h3>
<div class="postmsg">
<p>...</p>
</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>

<div class="postfootright"><div> </div></div>
</div>
</div>
</div>

... more entries ...

<div id="brdfooter" class="block">
... footer stuff ...
</div>

</div>
</div>
</body>
</nowiki></pre>

Transformed to hAtom compliant (changes shown in UPPER CASE for visibility only):

<pre><nowiki>
<body>
<div id="punwrap">
<div id="punviewtopic" class="pun">

<div id="brdheader" class="block">
... header stuff ...
</div>

<div id="announce" class="block">
... announcement stuff ...
</div>

<div class="linkst">
... controls for the blog
</div>

<DIV CLASS="FEED">
<div id="p54390" class="ENTRY blockpost rowodd firstpost">
<h2>
<span><span class="conr">#1 </span>
<a REL="BOOKMARK" href="HTTP://FORUMS.PUNBB.ORG/viewtopic.php?pid=54390#p54390">
<ABBR CLASS="POSTED" TITLE="20051016T103624-0500">2005-10-16 10:36:24</ABBR>
</a></span>
</h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><ADDRESS><a href="profile.php?id=2">Rickard</a></ADDRESS></strong></dt>

<dd class="usertitle"><strong>PunBB Developer</strong></dd>
<dd class="postavatar"><img src="img/avatars/2.png" width="60" height="60" alt="" /></dd>
<dd>From: 127.0.0.1</dd>
<dd>Registered: 2001-11-02</dd>
<dd>Posts: 7806</dd>
<dd class="usercontacts"><a href="http://www.punbb.org/">Website</a></dd>

</dl>
</div>
<div class="postright">
<h3>PunBB 1.2.9</h3>
<div class="CONTENT postmsg">
<p>Just a quick note this time....</p>

</div>
<div class="postsignature"><hr />"Programming is like sex: ...</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>
<div class="postfootright"><div> </div></div>
</div>
</div>

</div>

<div id="p54392" class="ENTRY blockpost roweven">
<h2>
<span><span class="conr">#2 </span>
<a REL="BOOKMARK" href="HTTP://FORUMS.PUNBB.ORG/viewtopic.php?pid=54392#p54392">
<ABBR CLASS="POSTED" TITLE="20051016T1105441-0500">2005-10-16 10:54:41</ABBR>
</a></span>
</h2>
<div class="box">
<div class="inbox">
<div class="postleft">
<dl>
<dt><strong><ADDRESS CLASS="VCARD"><a CLASS="URL" href="profile.php?id=5298">IdleFire</a></ADDRESS></strong></dt>

<dd class="usertitle"><strong>Member</strong></dd>
<dd class="postavatar"></dd>
<dd>Registered: 2005-10-14</dd>
<dd>Posts: 27</dd>
</dl>
</div>
<div class="postright">

<h3> Re: PunBB 1.2.9</h3>
<div class="CONTENT postmsg">
<p>...</p>
</div>
</div>
<div class="clearer"></div>
<div class="postfootleft"><p>Offline</p></div>

<div class="postfootright"><div> </div></div>
</div>
</div>
</div>

... more entries ...
</DIV>

<div id="brdfooter" class="block">
... footer stuff ...
</div>

</div>
</div>
</body>
</nowiki></pre>

Changes:
* Added <code><div class="feed"></code> around the entries (as opposed to an existing <code><div</code> that enclosed more than entries.
* Added <code>class="entry"</code> to each Entry
* Added <code>rel="bookmark"</code> to the Entry Permalinks
* Made the Entry Permalink non-relative
* Added <code><span class="title"></code>...<code></div></code> around the Entry Title
* Added <code><span class="content"></code>...<code></div></code> around the Entry Content
* Added <code><abbr class="posted" title="YYYYMMDDThh:mm:ss+ZZZZ"></code>...<code></abbr></code> around the Entry Datetime
* Added <code><address></code> to the poster's name

Also note:
* We did not need to add <code>id="###"</code> to the Entry

=== More Examples ===

See [[hatom-examples]].

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

* [http://blog.davidjanes.com Ranting and Roaring] (David Janes)
* [http://www.myelin.co.nz/post/ Second p0st] (Phil Pearson)
* [http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ Sound Advice] (Benjamin Carlyle)

== Implementations ==

This section is '''informative'''.

* 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
* An [http://lukearno.com/projects/hAtom/ hAtom-2-Atom] XSLT is available

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

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

== Hints and Tips ==

=== CSS tips ===
HTML typically styles <code>address</code> as a block level element in an italic font. This will make it inline and plain within hAtom elements:

<pre><nowiki>
.entry address {
display: inline;
font-weight: normal;
font-style: normal;
}
</nowiki></pre>

HTML typically puts a dotted line under <code><abbr></code> elements. This will put postage paid to that for Entry Updated and Entry Posted:

<pre><nowiki>
.entry abbr.updated, .entry abbr.posted {
font-style: normal;
border: none;
}
</nowiki></pre>

=== MovableType Template ===

A datetime encoded in an ABBR element can be produced with the following template code:

<pre><nowiki>
<abbr
class="posted"
title="<$MTEntryDate format="%Y%m%dT%H%M%S"$><$MTBlogTimezone
no_colon="1"$>"><$MTEntryDate format="%X"$></abbr>
</nowiki></pre>

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

== Recent Changes ==

''Most recent at top please. This section will eventually be removed but should be helpful for people tracking changes during specing.''

* Entry Permalink now SHOULD (as opposed to MUST) be a complete URI
* Entry Title now preferentially uses class="title"
* Entry Author most explicitly be marked class="author"
* using an <code><address</code> around Entry Author and Entry Contributor is no longer required

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

hatom-issues

2005-12-23T16:44:08Z

FuzzyBSc: Add my name, as per tantek's suggestion

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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...

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

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

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

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

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

== 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?

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

hatom-issues

2005-12-23T16:36:24Z

FuzzyBSc: Add Identification section

= Discussion Participants =

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

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

== Contributors ==
* [http://www.dannyayers.com Danny Ayers]
* [http://www.opendarwin.org/~drernie Ernest Prabhakar]

= 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 ==
# _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied

= Questions and Comments =
== Nomenclature ==
=== Why atomentry? ===
;class="atomentry"
: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]]) choose 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...

=== Why atomfeed? ===
;class="atomfeed"
: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 (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 acts as the Feed is 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)

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

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

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

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

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

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

== 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?

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