Revision as of 21:11, 1 January 2006

Discussion Participants

Editors

David Janes

Authors

David Janes

Contributors

Purpose

Questions or comments about hAtom go here. Please add your name to the 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

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.

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

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

STATUS - RESOLVED. We are using rel="bookmark".

Tantek: agreed.

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
- 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.
'Subject', as used by SMTP email
'heading'
'entry-title'

summary reserved by hReview

The summary class is reserved by hCalendar, and also hReview, to mean "review 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. Kevin Marks 15:51, 31 Dec 2005 (PST)
- There is no ambiguity because we point to a precise definition. Using 'description' it not only not a problem, but it is well established by vCalendar, iCalendar (RFC 2445), hCalendar, hReview etc. - 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 could be described as partial-description
atom:summary could be described as excerpt
atom:summary is described as abstract in 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 <address> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please -- DavidJanes

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 <address>’s semantics are too loose to describe an Atom person construct but using <addr class="vcard"> 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 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 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 here, here, here and here.

Your thoughts please... -- 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 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 class="opaque" element. -- 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 <ins> and <del> 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:

<div class="content"><div class="summary">......

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 <a href="http://apple.com/ipod" rel="tag">iPod</a>. 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. 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. 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?

@@ Line 27: / Line 27: @@
 = Questions and Comments =
 == 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"
+;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
@@ Line 37: / Line 42: @@
 -- [[DannyAyers]]
-* I ([[User:DavidJanes|David Janes]]) choose the "atom" prefix:
+* 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.)
@@ Line 46: / Line 51: @@
 '''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"
+;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 (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
+* 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 acts as the Feed is many cases
+** 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" ? ===
@@ Line 70: / Line 87: @@
 * OK, I'm happy with this -- [[User:DavidJanes|David Janes]]
-'''STATUS - RESOLVED'''. We are using <code>class="bookmark"</code>.
+'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.
+* Tantek: agreed.
 === title reserved by hCard ===
-The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):
+The title class is reserved by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):
-* Summary, as used by hReview, hCalendar, VJOURNAL
+* 'summary', as used by hReview, hCalendar, VJOURNAL
-* Subject, as used by SMTP email
+** 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.
+* 'Subject', as used by SMTP email
+* 'heading'
+* 'entry-title'
 === summary reserved by hReview ===
-The summary class is reserved by hReview to mean "document title". Possible alternatives include (add to list):
+The summary class is reserved by [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "review 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)
+** There is no ambiguity because we point to a precise definition.  Using 'description' it not only not a problem, but it is well established by vCalendar, iCalendar (RFC 2445), hCalendar, hReview etc. - Tantek
 * Depending on your interpretation, atom:summary could still be summary. Here is another option: subject (atom:title) -> summary (atom:summary) -> content (atom:content).

hatom-issues: Difference between revisions

Revision as of 21:11, 1 January 2006

Contents

Discussion Participants

Editors

Authors

Contributors

Purpose

Goals for hAtom

Anti-Goals for hAtom

Questions and Comments

Nomenclature

Why atomentry?

Why atomfeed?

Why rel="link" ?

title reserved by hCard

summary reserved by hReview

Why content?

Date and time names have precedent

Relationship to hReview definitions needs clarification

hCards

Comparisons

Repeated Elements

Opaqueness

Opaqueness of other microformat elements

Opaqueness of summary and content

Identification

HTML Title

rel-tag

Excess disambiguation rules?

Dependancies

mfo

last-modified

Is atom:content necessary?

See Also

Navigation menu

hatom-issues: Difference between revisions

Revision as of 21:11, 1 January 2006

Discussion Participants

Editors

Authors

Contributors

Purpose

Goals for hAtom

Anti-Goals for hAtom

Questions and Comments

Nomenclature

Why atomentry?

Why atomfeed?

Why rel="link" ?

title reserved by hCard

summary reserved by hReview

Why content?

Date and time names have precedent

Relationship to hReview definitions needs clarification

hCards

Comparisons

Repeated Elements

Opaqueness

Opaqueness of other microformat elements

Opaqueness of summary and content

Identification

HTML Title

rel-tag

Excess disambiguation rules?

Dependancies

mfo

last-modified

Is atom:content necessary?

See Also

Navigation menu

Search