Difference between revisions of "hatom-faq"

From Microformats Wiki
Jump to navigation Jump to search
(improved a few of the FAQs, add FAQ about not (re)using 'title' and 'summary' for hAtom)
m (Replace <entry-title> with {{DISPLAYTITLE:}})
Line 1: Line 1:
<entry-title>hAtom FAQ</entry-title>
Frequently asked questions about [[hAtom]].   
Frequently asked questions about [[hAtom]].   

Latest revision as of 16:23, 18 July 2020

Frequently asked questions about hAtom 0.1.

If you have a new question to ask, Please consider first asking your question on the microformats #microformats on freenode channel, or the microformats-discuss list.

Editing this Page

Please do not use "?" or other punctuation in the headers - it helps to keep the URLs to their fragment identifiers shorter and easier to read, copy/paste etc.

Is hAtom intended to replace RSS or Atom

Is hAtom intended to replace RSS or Atom?

No, hAtom is not intended to replace RSS or Atom. While most weblogs and other websites do provide their latest articles in a separate XML side file (in RSS and/or Atom format), older articles are typically not provided in such XML feed files.

hAtom allows all blog posts and articles to be published with episodic structure, especiallly those in archives.

Is there a way to hide to the entry author information

My client does not want to display their name after every post, but would like this to be valid. Can I hide the author info in an abbr tag or something?

In the case of single author: If a page is authored by only one author ever, then implied "address" as author can be used whereby in the absense of a valid hCard example within the hAtom being found, the parser will use the hCard information in the <address> element and hCard of the page (See final clause of hAtom address author field http://microformats.org/wiki/hatom#Entry_Author). This negates the need to specify an author in each entry.

Answer required for multiple authors?

Blogs with multiple authors display each author's name near their blog posts.

Why does hAtom use class names with prefixes

Why does hAtom use class names with prefixes?

The mailing list archives have the reasoning in depth (would be nice to extract those and explain them here), but in summary: since we were reusing the semantics of the IETF Atom standard, we very much wanted to reuse the vocabulary as well to minimize confusion and mean precisely the same semantics as defined in the Atom RFC 4287, and thus a few of the hAtom properties use class names that appear to have shared prefixes (entry-title, entry-content, entry-summary) in order to literally reuse those terms from the Atom RFC (title, content, summary) with the Atom-specific semantics defined therein, rather than the generic semantics, e.g. "summary" has a much more general purpose semantic that is utilized broadly by multiple microformats.

Could hAtom instead use title content and summary

Instead of entry-title, entry-content and entry-summary, could hAtom use title, content and summary?

In short no.

In general newer microformats do re-use properties from previous microformats (per the Naming Principles, specifically, minimal vocabulary).

However, in order to reflect the precise Atom semantics as defined in RFC 4287, we chose specific class names for capturing and communicating Atom Entry title, Atom Entry content and Atom Entry summary.

'title' already means job title as defined by hCard 1.0, and per the Naming Principles of not using the same term for two different meanings, we are not reusing title (which is just as well, as historically the term 'title' has been quite ambiguous, and presentation-centric, in numerous metadata efforts and formats).

Similarly, 'summary' is already defined by hCalendar 1.0, much more broadly than Atom's definition of summary.

Since these three Atom Entry elements (title, summary, content) are often used together, it makes sense to prefix them all to communicate their explicit tying and connection to the Atom Entry semantics.