Microformats Wiki - User contributions [en]

hatom-issues

2007-06-28T14:19:24Z

Ben Ward: Added link to Mark Pilgrims piece against permalink IDs and for Tag URIs to the atom:id section.

__TOC__

= hAtom 0.2 =

== atom:category scheme ==

* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''rel-tag tagspaces should map to atom:category schemes''
*#* hAtom already defines how to map term and label. It seems that the tagspace can easily map to scheme

==Geo==
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

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

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

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

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

== Datetime format (atom:<i>updated</i> and atom:<i>published</i>) ==
* 2006-05-23 raised by [[User:RobertBachmann|Robert Bachmann]]
** Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.
*** ACCEPTED FAQ - hAtom references datetime-design-pattern, which discusses which date format to use

== Feed <i>id</i> (atom:<i>id</i>) ==
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# atom:<i>id</i> is required for atom:feed. Thus it should be available in hAtom to.

It is suggested the Feed permalink should be used as the feed ID, however a piece by Mark Pilgrim (http://diveintomark.org/archives/2004/05/28/howto-atom-id) makes arguments against using permalinks and in favour of Tag URIs.

== Feed <i>permalink</i> (atom:<i>permalink</i>) ==
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>
** I'm proposing the following rules:
**# a Feed Permalink element is identified by [[rel-bookmark]] at the feed level (inside a Feed element but not inside an Entry element)
**# a Feed <del>SHOULD</del><ins>MAY</ins> have a Feed Permalink
**# a Feed Permalink element represents the concept of an Atom link in a feed.
**# if the Feed Permalink is missing, use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI
** 2006-04-03 [[User:ChrisCasciano|ChrisCasciano]] - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.
** 2006-04-03 [[User:RobertBachmann|Robert Bachmann]]: I've replaced "SHOULD" with "MAY".
** 2006-04-24 [[User:RobertBachmann|Robert Bachmann]]: Maybe we could simplify my proposal to:
*** "''Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI''"
*** IMO this would be good enough for at least 80% of the cases.
** 2006-04-12 [[User:DavidJanes]]: can we find an example of this in the wild and if so we should add it to the -examples page.
** [[User:Singpolyma|singpolyma]] 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't [[rel-home]] make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.

== Feed <i>updated</i> (atom:<i>updated</i>) ==
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>updated</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# The Feed Updated element is identified by the class name <code>updated</code> at the feed level (inside a Feed element but not inside an Entry element)
**# If no element with the class name <code>updated</code> is present, use the youngest <code>updated</code> from the feed's entries.
** 2006-04-12 [[User:DavidJanes]] I like this. And the definition of "feed level"
** 2007-06-20 [[User:MikeKaply]] The "youngest" thing is a really bad idea. If a page has 100 hAtom entries, a parser would have to go through all 100 looking for a low date. That's crazy.

== Feed <i>title</i> (atom:<i>title</i>) ==
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>title</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# a Feed Title element is identified by the class name <code><del>entry</del><ins>feed</ins>-title</code>
**# a Feed SHOULD have an Feed Title
**# a Feed Title element represents the concept of an Atom feed title
**# if the Feed Title is missing, use
**#* <del>the first <code><h#></code> element in the Feed, or</del>
**#* the <code><title></code> of the page, or
**#* assume it is the empty string
** 2006-04-01 [[User:ChrisCasciano|ChrisCasciano]] - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using <code><title></code> before h# would be prefered if not the most common desire of the page author.
** 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><h#></code> to encode the date for a group of postings
** 2006-04-12 [[User:DavidJanes]]: why <code>entry-title</code> for the feed title. Why not <code>fn</code> or <code>feed-title</code>?
** 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.
** 2007-02-26 [[User:MikeKaply|Mike Kaply]]: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.

== Feed <i>author</i> and Entry author (atom:<i>author</i>) ==
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules for Feed author:
**# a Feed Author element is represented by class name <code>author</code> at the feed level (inside a Feed element but not inside an Entry element)
**# a Feed Author element represents the concept of a Atom author
**# a Feed Author element MUST be encoded in a [[hcard|hCard]]
**# a Feed Author element SHOULD be encoded in a <code><address></code> element
**# a Feed MAY have more than one Feed Author elements
**# if the Feed Author is missing
**#* find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
**#* otherwise <del>the Feed is invalid hAtom</del> <ins>there is no Feed Author</ins>
** I'm proposing the following rules for entry author:
**# an Entry Author element is represented by class name <code>author</code>
**# an Entry Author element represents the concept of an Atom author
**# an Entry Author element MUST be encoded in an [[hcard|hCard]]
**# an Entry Author element SHOULD be encoded in an <code><address></code> element
**#<del> If a Feed has no Feed author each Entry MUST have at least one Entry Author element</del>
**# <ins>If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
**#* find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code><address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
**#* otherwise the Entry is invalid hAtom</ins>
**# an Entry MAY have more than one Entry Author elements
** [[User:Singpolyma|singpolyma]] 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author. Also, one or more entries may be missing an author IF feed-level has an author.
** 2006-04-17 [[User:RobertBachmann|Robert Bachmann]]: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

== Entry <i>id</i> (atom:<i>id</i>) ==
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>id</i> is required for atom:entry. Thus it should be available in hAtom to. The Entry permalink should be used as the entry id.
** --[[User:Federico|Federico]] 19:52, 25 Apr 2006 (PDT): I would add "Only if the id attribute is not defined for the element that contains the entry". The id attribute can be a tag uri. If you use always use the Entry permalink as the entry id and the Atom feed uses tag uris, you would end with two different ids for the same entry.
** 2006-12-31 response by [[User:ComputerKid|Emanla Eraton]] No, it shouldn't be a permalink. It should be a "tag:" id for entries.
** 2007-06-06 [[RyanKing]] - the syntax of tag URIs and html id attributes are incompatible. HTML disallows forward-slash (/) in ids [http://www.w3.org/TR/html401/types.html#type-name], while tag URIs require them [http://www.faqs.org/rfcs/rfc4151.html].

== Author ==

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

The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]

* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a <div class="author"> element.
** [[Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"
** [[User:Fil|Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.

* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"
** [[Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec
***[[User:Phae|Frances]] - Just thought I'd mention a scenario I have where the author of an entry does make a pretty useless vCard - the author in each case is an entire team ("creative team", "technical department") etc., rather than a specific, identifiable, person. Some use may be regained when URL to specific team/information is included, in this circumstance.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki><span class="author"><span class="vcard"><span class="fn">My Name</span></span></span></nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki><span class="author vcard"><span class="fn">My Name</span></span></nowiki></code>

== Other Questions and Issues ==

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

=== Entry Updated Required? -- Blogger Issue ===

moved to [[hatom-brainstorming]]

=== 'MAY have multiple Feed elements' -- details and viability of multiple feeds ===

moved to [[hatom-brainstorming]]

= pre 0.1 issues =

'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''

== Feed (atom:feed)==

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

=== Initial proposal ===

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

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

=== Alternatives ===

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

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

==== Discussion ====

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

== Entry (atom:entry) ==

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

=== Initial Proposal ===

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

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

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

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

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

== Entry Title (atom:title) ==

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

=== proposals ===

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

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

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

== Entry Content (atom:content) ==

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

* <code>content</code> (Atom consistency)
** -1 [[Tantek]]
** +1 [[DavidJanes]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** -1 [[ChrisCasciano]]
** -1 KevinMarks - already too many in the wild
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion
** -1 Tantek - agreed with Ryan
** -1 KevinMarks
* <code>entry-content</code>
** +1 Niall Kennedy (proposed)
** +0.5 [[Tantek]]
** +1 KevinMarks
** +1 [[ChrisCasciano]]
* <code>atom-content</code>
** +0.5 [[Tantek]]
* <code>hcontent</code>
** -1 [[Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.

=== Discussion ===
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means. In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item. Whereas in hAtom is the thing itself. The feed is the data is the item. Thus it makes sense use a different class name than "description". Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard. Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.
* [[ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.
* [[Tantek]]: Chris Casciano is right. Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending. I have changed my vote to -1 for "content".
* [[Tantek]]: I have added a few proposed alternatives based on discussions with various folks. I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing. I have split my vote among the new alternatives for now.
* [[ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.
* [[KevinMarks]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.
* [[ChrisCasciano]] - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')

== Entry Summary (atom:summary) ==

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

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

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

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

== Entry Permalink (atom:link) ==

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

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

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

== Entry Published (atom:published) ==

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

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

=== Discussion ===
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user. IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system. It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p>
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p>
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.
* [[Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.

== Entry Updated (atom:updated) ==

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

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

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

== Entry Author (atom:author) ==

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

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

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

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

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

== Entry Geo (geo:Point) ==
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.

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

== Questions and Comments ==

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

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

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

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

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

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

=== hCards ===

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

RESOLVED: MUST use hCard for author.

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

=== Comparisons ===

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

--[[Ernie Prabhakar]]

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

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

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

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

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

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

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

-- [[BenjaminCarlyle]]

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

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

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

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

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

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

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

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

'''STATUS - OPEN'''.

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

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

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

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

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

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

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

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

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

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

=== Designating the page author ===

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

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

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

(2006-02-13 example by [[User:ChrisCasciano|Chris Casciano]])
There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.

==== Proposal ====
* If no author is found at the entry level try to use the author(s) at the feed level (i.e: <code>class="author"</code> at the feed level)
* If no author is found at the feed level try to use all <address>’s outside of the feed as authors.

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

= Template =

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

Talk:posh

2007-05-05T00:28:59Z

Ben Ward: /* Misuse of microformats logo for ‘POSH’ bling */

== Misuse of microformats logo for ‘POSH’ bling ==

On 3rd May Ben Ward [http://www.mail-archive.com/microformats-discuss@microformats.org/msg07543.html objected] to the use of the microformats logo in graphics promoting ‘POSH’, on grounds that it creates confusing and undesirable ambiguity between the terms ‘microformat’ and ‘POSH’. We're at a point where people are wrongly interpreting ‘microformat’ as a general term for semantic class names. The endorsement of these graphics on our own Wiki is a massive hindrance to our efforts to discourage such misuse.

Please indicate a vote below on the removal of the microformats logo POSH buttons.

+1 — Ben Ward

Talk:posh

2007-05-05T00:18:40Z

Ben Ward: The POSH page is a standalone article referenced from around the web and not part of µf development. It is inappropriate to add discussion/voting, so created a TALK page for the µf/posh badge vote.

== Misuse of microformats logo for ‘POSH’ bling ==

On 3rd May Ben Ward [http://www.mail-archive.com/microformats-discuss@microformats.org/msg07543.html objected] to the use of the microformats logo in graphics promoting ‘POSH’, on grounds that it creates confusing and undesirable ambiguity between the terms ‘microformat’ and ‘POSH’. We're at a point where people are wrongly interpreting ‘microformat’ as a general term for semantic class names and the endorsement of these graphics on our own Wiki is a massive hindrance to that effort.

Please indicate a vote below on the removal of the microformats logo POSH buttons.

+1 — Ben Ward

events/2007-02-17-barcamplondon2

2007-02-12T18:01:11Z

Ben Ward: /* Microformateers in attendance */

<h1>Microformats at BarCampLondon</h1>

One of several microformats [[events]].

__TOC__

== Summary ==

[http://barcamp.org/BarCampLondon2 BarCampLondon] is the 2nd UK BarCamp event.

It will be held at the BT Centre in London on Saturday 17th February (9am) - Sunday 18th February (5pm), 2007

''"What is BarCampLondon2? Think of it as a way to get the tech/geek community together in London. What will happen during the event? Only one thing is certain: It's up to you to decide. The most important thing you should take away from the event? Relationships with other geeks!"''

== Microformateers in attendance ==

*[[User:Phae|Frances Berriman]]
*[[User:Brian|Brian Suda]]
*[[User:Ben Ward|Ben Ward]]

== Proposed sessions ==

*Microformats discussion panel - Contestants required! Bug [[User:Phae|Frances]] or [[User:Brian|Brian]] to find out a bit more.

== Attending ==

* ..

== Session Comments and Q&A ==

* ...

== Photos ==

chat-brainstorming

2006-10-29T17:52:39Z

Ben Ward: /* hChatLog Strawman Proposal */ Fixed username link.

== Requirements ==

=== Scope ===

Should a microformat matching these requirements be capable of representing only transcripts of existing IM protocols or should it also be able to serve as an exchange format itself. This '''might''' be useful for simple AJAX IM platforms, although I doubt if [http://www.xmpp.org/ XMPP] is not per definition a better choise for such purposes. --[[User:BigSmoke|BigSmoke]] 13:09, 21 Jun 2006 (PDT)

- Anything that can be parsed can be used in AJAX, so we don't need to consider this in developing a microformat. --[[User:ScottReynen|Scott Reynen]]

How much, and what kind of data is going to be in the file? The work done by the [http://purl.org/NET/ULF/SPEC Unified Logging Format WG] has a pretty good overview of the various types of things that an IM client would want to log. Don't make too much of a bikeshed about it -- I'm mostly linking it beacuse it's a good overview of the sorts of general element types (message, event, status) we probably want to use. --[[User:Colin Barrett|Colin Barrett]] 05:33, 22 Aug 2006 (PDT)
=== Chat rooms ===

Is it useful for this microformat to support the representation of "chat rooms", such as IRC channels? --[[User:BigSmoke|BigSmoke]]

- Location is a problem that can be clearly separated from chats. We should stick to solving the smallest problem possible, so we can more easily combine microformats later to solve larger problems. --[[User:ScottReynen|Scott Reynen]]

- On chat-formats and chat-examples, IRC logs are used. I would say we should include IRC logs in our spec -- it just makes sense to design for mult-user chat, because one-to-one messaging is just a special case of that. --[[User:Colin Barrett|Colin Barrett]] 05:33, 22 Aug 2006 (PDT)
== Example playground ==

<pre>
<div class="hchat-log">
<p class="hchat-msg">
<abbr class="time" title="YYYY-MM-DDTHH:MM:SS">HH:MM:SS</abbr>

</p>
</div>
</pre>

== hChatLog Strawman Proposal==

Initially compiled by [[User:Ben Ward|BenWard]].

Following [http://microformats.org/discuss/mail/microformats-discuss/2006-October/006719.html a post] to uf-discuss, Colin Barrett requested I write up my hChatLog example in more detail, so I present it here as a straw man proposal to see if chat can gain any traction.

It's based around the initial brainstorming, but was initially led by my own preferences for mark-up. The class names introduced are reused or derived from other existing microformats, and new class names are based on the Unified Logging Format, as the element names in ULF are already human-friendly.

===hChatLog Structure===

* hChatLog
** message
*** dt (or time)
*** sender (which MUST be an hCard and SHOULD be a CITE element)
*** 'quoted message content' (which MUST be a Q or BLOCKQUOTE element)
** status
*** dt (or time)
*** sender (which MUST be an hCard and SHOULD be a CITE element)
*** type (from a predefined list of values)
*** message (optional, the custom message the user assigns to a status, e.g. an 'away message')

====Notes about the above structure====

* message, sender, status and type are all taken from ULF. Note that 'type' also corresponds with tel > type and adr > type in hCard.
* 'dt' is proposed as a derivative of 'dtstart' and 'dtend' as used in hCalendar, however 'time' (again from ULF) may be preferable
* The message text does not have a class name, and is instead identified as from quoted text within a message, marked up with Q (for common single line messages) or BLOCKQUOTE (for multiline or otherwise complex messages).

====List of status 'type' values====

This should be a single-word list of the common status types from current IM implementations, namely:

* Online
* Offline
* Away
* Busy
* BRB (Be Right Back)
* Lunch (Out To Lunch)
* Phone (On The Phone)

===Example===

Note that this example uses an OL as the container, with LI elements for each message/status. This mark-up scheme for dialogue is subject to opinions of how strictly an Ordered List should be specified. For this reason OL/LI mark-up as is not specified as 'SHOULD' or 'MUST' in the structure above. The WHATWG list was recently included a discussion about tightening of the definition of OL for HTML5 (no definitive resolution was made though).

<pre>
<ol class="hChatLog">
<li class="message">
<abbr class="dt" title="2006-10-26T01:22:00+0100">1:22am</abbr>:
<cite class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=HanniUsername">Hanni</a></cite>
<q>Hello Ben</q>
</li>
<li class="message">
<abbr class="dt" title="2006-10-26T01:25:00+0100">1:25am</abbr>:
<cite class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=BenWardcouk">Ben</a></cite>
<blockquote>
<p>Hello Hanni</p>
<p>How're you today?</p>
</blockquote>
</li>
<li class="status"> 
<abbr class="dt" title="2006-08-08T01:27:00+0100">1:27am</abbr>:
<span class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=HanniUsername">Hanni</a> went <span class="type">away</span></span>
</li>
<li class="status">
<abbr class="dt" title="2006-08-08T01:28:00+0100">1:28am</abbr>:
<span class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=HanniUsername">Hanni</a>
<abbr class="type" title="online">came back</abbr></span>
</li>
</ol></pre>

In this example, two messages are exchanged followed by two status changes. Each message contains an hCard, identifying the user's nickname (which should map to the user's 'display name' or 'screen name') and uses the form proposed in [[hcard-examples]] for New Types of Contact Info to identify the AIM usernames.

Messages are quoted. Single line messages in Q elements and multiline messages in BLOCKQUOTE. There's no reason to limit each message to contain only one Q or BLOCKQUOTE, as depending on the precision of the timestamps being used, it may be appropriate to allow messages from the same individual to be placed together.

Status messages contain the DT, SENDER and then a TYPE. Since we're presenting humans-first information here, note that the first status change ('Hanni went away') uses the exact status type, the second ('Hanni came back') uses the abbr-pattern to embed the 'online' status type name.

It may be necessary to integrate the IM service URL patterns into the 'hChatLog' microformat itself, depending on whether they are treated as a formal part of hCard yet, but a means to identify service usernames with less reliance on implications is needed (for example, MSN accounts are identified by @hotmail, @msn or @passport domains, which is not inclusive of MSN Messenger users with their own domains, while other IM services may not have a URI scheme at all).

===Example of 'chat-username' class, extending hCard===

Whilst fitting this into the process needs to be clarified, it would be clearest to introduce a 'chat-username' class within hCards in hChatLog, to identify usernames.

<pre><li class="message">
<abbr class="dt" title="2006-10-26T01:25:00+0100">1:25am</abbr>:
<cite class="sender vcard"><a class="url" href="aim:goim?screenname=BenWardcouk"><abbr class="chat-username" title="BenWardcouk"><span class="fn nickname">Ben</span></abbr></a></cite>
<q>Hello</q>
</li></pre>

This fits into existing patterns OK, but loses one very important piece of information, the service provider. This could be spec'd as a prefix (<abbr class="chat-username" title="aim:BenWardcouk">…</abbr>) or could be a separate property altogether (chat-service).

===Example with include-pattern===

Introducing two new properties to each message hCard would create much clutter in the mark-up, and the repeition of hCards is already sub-optimal. The include-pattern in hCard can be used to keep the format cleaner, as demonstrated below.

Note: In this example, I'm still using the aim: URL form of representing usernames.

<pre><html> 
<body>
<h1>Chat between Ben and Hanni – Friday October 26th</h1>

<h2>Participants</h2>
<ul>
<li id="benwardcouk">
<h3><a class="fn url nickname" href="aim:goaim?benwardcouk">Ben</a></h3>
<p><a class="url" href="http://ben-ward.co.uk">Homepage</a></p>
<p class="description">Ben is a 22 year old web application developer in Birmingham, England</p>
</li>
<li id="hanni">
<h3><a class="fn url nickname" href="aim:goaim?hanniusername">Hanni</a></h3>
<p><a class="url" href="http://hanniross.com">Homepage</a></p>
</li>
</ul>

<ol class="hChatLog">
<li class="message">
<abbr class="dtstart" title="2006-08-08T01:22:00+0100">1:22am</abbr>:
<cite class="sender vcard"><a class="include" href="#hanni">Hanni</a></cite>
<q>Hello Ben</q>
</li>
<li class="message">
<abbr class="dtstart" title="2006-08-08T01:25:00+0100">1:25am</abbr>:
<cite class="sender vcard"><a class="include" href="#benward">Ben</a></cite>
<blockquote><p>Hello Hanni</p>
<p>How're you today?</p></blockquote>
</li>
<li class="status">
<abbr class="dtstart" title="2006-08-08T01:27:00+0100">1:27am</abbr>:
<span class="sender vcard"><a class="include" href="#hanni">Hanni</a> went <span class="type">away</span></span>
</li>
<li class="status">
<abbr class="dtstart" title="2006-08-08T01:28:00+0100">1:28am</abbr>:
<span class="sender vcard"><a class="include" href="#hanni">Hanni</a>
<abbr class="type" title="online">came back</abbr></span>
</li>
</ol>
</pre>

In this last example, the repeated hCards are declared once at the top of the document, with additional detail, and then can be parsed into the log itself using the include-pattern. The A/@class=include pattern is used, rather than OBJECT, as it allows the user display name to be repeated in each message as text, but will be replaced when parsed.

Note: The VCARD class name is on the CITE elements in each message/status, rather than on the LIs where the hCards are declared in full. This is because the include-pattern currently only to works <em>inside</em> an hCard. It would be tidier to have the VCARD class on the LIs in the participants list, but unless the include-pattern can be extended to apply natively inside hChatLog, the hCards must be arranged like this.

== Ideas ==

=== Using paragraphs to represent chat messages ===

I think that individual messages in a chat log should be formatted as XHTML paragraphs (<code><p></code>), because this is how conversations are commonly formatted. From the [[chat-examples|examples]] I gather that this is also what the [[chat-examples#ILRT_Logger_Bot_Format|ILRT Logger Bot]] currently does. --[[User:BigSmoke|BigSmoke]] 13:09, 21 Jun 2006 (PDT)

- We can't assume all paragraphs are chat messages, so we'll need a class name to identify a chat message. Once a class name is identifying something as a message, what is the advantage of applying the additional stipulation of a specific HTML tag? It doesn't appear to aid parsing, and it only constrains publishers. --[[User:ScottReynen|Scott Reynen]]

- I'm not convinced that ‘messages are paragraphs’ is an overly fair assumption: Lots of chat is extremely fragmented into sentences (or even partial sentences). I'd be nervous about generalising the P element any further than it all ready.

I have a lot of love for [http://microformats.org/wiki/chat-examples#MSN_Messenger_Marked_Up_By_Anne_van_Kesteren Anne van Kesteren's chat mark-up] (using Q elements for single line text, and BLOCKQUOTE > P for multiline messages, where the presence of newlines seems a more concrete basis on which to describe paragraph).

As far as block level element construction goes, AvK's mark-up again highlights the capability of raw HTML: OL is certainly correct, as is CITE and Q/BLOCKQUOTE. Paragraphs might not always be correct.

--[[User:Ben Ward|BenWard]] 12:29, 24 Sep 2006 (PDT)

- No sooner do I say ‘OL is certainly correct’ but something comes up to question it. Those interested in developing hChat might also like to keep an eye on the WHATWG list where there's been [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg02526.html some questioning of using OL for dialogue]. Additionally, there's a fresh [http://meyerweb.com/eric/thoughts/2006/10/23/broken-rights/ discussion on dialogue mark-up at Eric Meyer's blog].

--[[User:Ben Ward|BenWard]] 03:41, 24 Oct 2006 (PDT)

chat-brainstorming

2006-10-29T17:50:21Z

Ben Ward: /* hChatLog Strawman Proposal */

== Requirements ==

=== Scope ===

Should a microformat matching these requirements be capable of representing only transcripts of existing IM protocols or should it also be able to serve as an exchange format itself. This '''might''' be useful for simple AJAX IM platforms, although I doubt if [http://www.xmpp.org/ XMPP] is not per definition a better choise for such purposes. --[[User:BigSmoke|BigSmoke]] 13:09, 21 Jun 2006 (PDT)

- Anything that can be parsed can be used in AJAX, so we don't need to consider this in developing a microformat. --[[User:ScottReynen|Scott Reynen]]

How much, and what kind of data is going to be in the file? The work done by the [http://purl.org/NET/ULF/SPEC Unified Logging Format WG] has a pretty good overview of the various types of things that an IM client would want to log. Don't make too much of a bikeshed about it -- I'm mostly linking it beacuse it's a good overview of the sorts of general element types (message, event, status) we probably want to use. --[[User:Colin Barrett|Colin Barrett]] 05:33, 22 Aug 2006 (PDT)
=== Chat rooms ===

Is it useful for this microformat to support the representation of "chat rooms", such as IRC channels? --[[User:BigSmoke|BigSmoke]]

- Location is a problem that can be clearly separated from chats. We should stick to solving the smallest problem possible, so we can more easily combine microformats later to solve larger problems. --[[User:ScottReynen|Scott Reynen]]

- On chat-formats and chat-examples, IRC logs are used. I would say we should include IRC logs in our spec -- it just makes sense to design for mult-user chat, because one-to-one messaging is just a special case of that. --[[User:Colin Barrett|Colin Barrett]] 05:33, 22 Aug 2006 (PDT)
== Example playground ==

<pre>
<div class="hchat-log">
<p class="hchat-msg">
<abbr class="time" title="YYYY-MM-DDTHH:MM:SS">HH:MM:SS</abbr>

</p>
</div>
</pre>

== hChatLog Strawman Proposal==

Initially compiled by [[User:Ben_Ward]].

Following [http://microformats.org/discuss/mail/microformats-discuss/2006-October/006719.html a post] to uf-discuss, Colin Barrett requested I write up my hChatLog example in more detail, so I present it here as a straw man proposal to see if chat can gain any traction.

It's based around the initial brainstorming, but was initially led by my own preferences for mark-up. The class names introduced are reused or derived from other existing microformats, and new class names are based on the Unified Logging Format, as the element names in ULF are already human-friendly.

===hChatLog Structure===

* hChatLog
** message
*** dt (or time)
*** sender (which MUST be an hCard and SHOULD be a CITE element)
*** 'quoted message content' (which MUST be a Q or BLOCKQUOTE element)
** status
*** dt (or time)
*** sender (which MUST be an hCard and SHOULD be a CITE element)
*** type (from a predefined list of values)
*** message (optional, the custom message the user assigns to a status, e.g. an 'away message')

====Notes about the above structure====

* message, sender, status and type are all taken from ULF. Note that 'type' also corresponds with tel > type and adr > type in hCard.
* 'dt' is proposed as a derivative of 'dtstart' and 'dtend' as used in hCalendar, however 'time' (again from ULF) may be preferable
* The message text does not have a class name, and is instead identified as from quoted text within a message, marked up with Q (for common single line messages) or BLOCKQUOTE (for multiline or otherwise complex messages).

====List of status 'type' values====

This should be a single-word list of the common status types from current IM implementations, namely:

* Online
* Offline
* Away
* Busy
* BRB (Be Right Back)
* Lunch (Out To Lunch)
* Phone (On The Phone)

===Example===

Note that this example uses an OL as the container, with LI elements for each message/status. This mark-up scheme for dialogue is subject to opinions of how strictly an Ordered List should be specified. For this reason OL/LI mark-up as is not specified as 'SHOULD' or 'MUST' in the structure above. The WHATWG list was recently included a discussion about tightening of the definition of OL for HTML5 (no definitive resolution was made though).

<pre>
<ol class="hChatLog">
<li class="message">
<abbr class="dt" title="2006-10-26T01:22:00+0100">1:22am</abbr>:
<cite class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=HanniUsername">Hanni</a></cite>
<q>Hello Ben</q>
</li>
<li class="message">
<abbr class="dt" title="2006-10-26T01:25:00+0100">1:25am</abbr>:
<cite class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=BenWardcouk">Ben</a></cite>
<blockquote>
<p>Hello Hanni</p>
<p>How're you today?</p>
</blockquote>
</li>
<li class="status"> 
<abbr class="dt" title="2006-08-08T01:27:00+0100">1:27am</abbr>:
<span class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=HanniUsername">Hanni</a> went <span class="type">away</span></span>
</li>
<li class="status">
<abbr class="dt" title="2006-08-08T01:28:00+0100">1:28am</abbr>:
<span class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=HanniUsername">Hanni</a>
<abbr class="type" title="online">came back</abbr></span>
</li>
</ol></pre>

In this example, two messages are exchanged followed by two status changes. Each message contains an hCard, identifying the user's nickname (which should map to the user's 'display name' or 'screen name') and uses the form proposed in [[hcard-examples]] for New Types of Contact Info to identify the AIM usernames.

Messages are quoted. Single line messages in Q elements and multiline messages in BLOCKQUOTE. There's no reason to limit each message to contain only one Q or BLOCKQUOTE, as depending on the precision of the timestamps being used, it may be appropriate to allow messages from the same individual to be placed together.

Status messages contain the DT, SENDER and then a TYPE. Since we're presenting humans-first information here, note that the first status change ('Hanni went away') uses the exact status type, the second ('Hanni came back') uses the abbr-pattern to embed the 'online' status type name.

It may be necessary to integrate the IM service URL patterns into the 'hChatLog' microformat itself, depending on whether they are treated as a formal part of hCard yet, but a means to identify service usernames with less reliance on implications is needed (for example, MSN accounts are identified by @hotmail, @msn or @passport domains, which is not inclusive of MSN Messenger users with their own domains, while other IM services may not have a URI scheme at all).

===Example of 'chat-username' class, extending hCard===

Whilst fitting this into the process needs to be clarified, it would be clearest to introduce a 'chat-username' class within hCards in hChatLog, to identify usernames.

<pre><li class="message">
<abbr class="dt" title="2006-10-26T01:25:00+0100">1:25am</abbr>:
<cite class="sender vcard"><a class="url" href="aim:goim?screenname=BenWardcouk"><abbr class="chat-username" title="BenWardcouk"><span class="fn nickname">Ben</span></abbr></a></cite>
<q>Hello</q>
</li></pre>

This fits into existing patterns OK, but loses one very important piece of information, the service provider. This could be spec'd as a prefix (<abbr class="chat-username" title="aim:BenWardcouk">…</abbr>) or could be a separate property altogether (chat-service).

===Example with include-pattern===

Introducing two new properties to each message hCard would create much clutter in the mark-up, and the repeition of hCards is already sub-optimal. The include-pattern in hCard can be used to keep the format cleaner, as demonstrated below.

Note: In this example, I'm still using the aim: URL form of representing usernames.

<pre><html> 
<body>
<h1>Chat between Ben and Hanni – Friday October 26th</h1>

<h2>Participants</h2>
<ul>
<li id="benwardcouk">
<h3><a class="fn url nickname" href="aim:goaim?benwardcouk">Ben</a></h3>
<p><a class="url" href="http://ben-ward.co.uk">Homepage</a></p>
<p class="description">Ben is a 22 year old web application developer in Birmingham, England</p>
</li>
<li id="hanni">
<h3><a class="fn url nickname" href="aim:goaim?hanniusername">Hanni</a></h3>
<p><a class="url" href="http://hanniross.com">Homepage</a></p>
</li>
</ul>

<ol class="hChatLog">
<li class="message">
<abbr class="dtstart" title="2006-08-08T01:22:00+0100">1:22am</abbr>:
<cite class="sender vcard"><a class="include" href="#hanni">Hanni</a></cite>
<q>Hello Ben</q>
</li>
<li class="message">
<abbr class="dtstart" title="2006-08-08T01:25:00+0100">1:25am</abbr>:
<cite class="sender vcard"><a class="include" href="#benward">Ben</a></cite>
<blockquote><p>Hello Hanni</p>
<p>How're you today?</p></blockquote>
</li>
<li class="status">
<abbr class="dtstart" title="2006-08-08T01:27:00+0100">1:27am</abbr>:
<span class="sender vcard"><a class="include" href="#hanni">Hanni</a> went <span class="type">away</span></span>
</li>
<li class="status">
<abbr class="dtstart" title="2006-08-08T01:28:00+0100">1:28am</abbr>:
<span class="sender vcard"><a class="include" href="#hanni">Hanni</a>
<abbr class="type" title="online">came back</abbr></span>
</li>
</ol>
</pre>

In this last example, the repeated hCards are declared once at the top of the document, with additional detail, and then can be parsed into the log itself using the include-pattern. The A/@class=include pattern is used, rather than OBJECT, as it allows the user display name to be repeated in each message as text, but will be replaced when parsed.

Note: The VCARD class name is on the CITE elements in each message/status, rather than on the LIs where the hCards are declared in full. This is because the include-pattern currently only to works <em>inside</em> an hCard. It would be tidier to have the VCARD class on the LIs in the participants list, but unless the include-pattern can be extended to apply natively inside hChatLog, the hCards must be arranged like this.

== Ideas ==

=== Using paragraphs to represent chat messages ===

I think that individual messages in a chat log should be formatted as XHTML paragraphs (<code><p></code>), because this is how conversations are commonly formatted. From the [[chat-examples|examples]] I gather that this is also what the [[chat-examples#ILRT_Logger_Bot_Format|ILRT Logger Bot]] currently does. --[[User:BigSmoke|BigSmoke]] 13:09, 21 Jun 2006 (PDT)

- We can't assume all paragraphs are chat messages, so we'll need a class name to identify a chat message. Once a class name is identifying something as a message, what is the advantage of applying the additional stipulation of a specific HTML tag? It doesn't appear to aid parsing, and it only constrains publishers. --[[User:ScottReynen|Scott Reynen]]

- I'm not convinced that ‘messages are paragraphs’ is an overly fair assumption: Lots of chat is extremely fragmented into sentences (or even partial sentences). I'd be nervous about generalising the P element any further than it all ready.

I have a lot of love for [http://microformats.org/wiki/chat-examples#MSN_Messenger_Marked_Up_By_Anne_van_Kesteren Anne van Kesteren's chat mark-up] (using Q elements for single line text, and BLOCKQUOTE > P for multiline messages, where the presence of newlines seems a more concrete basis on which to describe paragraph).

As far as block level element construction goes, AvK's mark-up again highlights the capability of raw HTML: OL is certainly correct, as is CITE and Q/BLOCKQUOTE. Paragraphs might not always be correct.

--[[User:Ben Ward|BenWard]] 12:29, 24 Sep 2006 (PDT)

- No sooner do I say ‘OL is certainly correct’ but something comes up to question it. Those interested in developing hChat might also like to keep an eye on the WHATWG list where there's been [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg02526.html some questioning of using OL for dialogue]. Additionally, there's a fresh [http://meyerweb.com/eric/thoughts/2006/10/23/broken-rights/ discussion on dialogue mark-up at Eric Meyer's blog].

--[[User:Ben Ward|BenWard]] 03:41, 24 Oct 2006 (PDT)

chat-brainstorming

2006-10-27T08:58:49Z

Ben Ward: /* hChatLog Strawman Proposal */ – Typo corrections.

== Requirements ==

=== Scope ===

Should a microformat matching these requirements be capable of representing only transcripts of existing IM protocols or should it also be able to serve as an exchange format itself. This '''might''' be useful for simple AJAX IM platforms, although I doubt if [http://www.xmpp.org/ XMPP] is not per definition a better choise for such purposes. --[[User:BigSmoke|BigSmoke]] 13:09, 21 Jun 2006 (PDT)

- Anything that can be parsed can be used in AJAX, so we don't need to consider this in developing a microformat. --[[User:ScottReynen|Scott Reynen]]

How much, and what kind of data is going to be in the file? The work done by the [http://purl.org/NET/ULF/SPEC Unified Logging Format WG] has a pretty good overview of the various types of things that an IM client would want to log. Don't make too much of a bikeshed about it -- I'm mostly linking it beacuse it's a good overview of the sorts of general element types (message, event, status) we probably want to use. --[[User:Colin Barrett|Colin Barrett]] 05:33, 22 Aug 2006 (PDT)
=== Chat rooms ===

Is it useful for this microformat to support the representation of "chat rooms", such as IRC channels? --[[User:BigSmoke|BigSmoke]]

- Location is a problem that can be clearly separated from chats. We should stick to solving the smallest problem possible, so we can more easily combine microformats later to solve larger problems. --[[User:ScottReynen|Scott Reynen]]

- On chat-formats and chat-examples, IRC logs are used. I would say we should include IRC logs in our spec -- it just makes sense to design for mult-user chat, because one-to-one messaging is just a special case of that. --[[User:Colin Barrett|Colin Barrett]] 05:33, 22 Aug 2006 (PDT)
== Example playground ==

<pre>
<div class="hchat-log">
<p class="hchat-msg">
<abbr class="time" title="YYYY-MM-DDTHH:MM:SS">HH:MM:SS</abbr>

</p>
</div>
</pre>

== hChatLog Strawman Proposal==

Initially compiled by [[Ben_Ward]].

Following [http://microformats.org/discuss/mail/microformats-discuss/2006-October/006719.html a post] to uf-discuss, Colin Barrett requested I write up my hChatLog example in more detail, so I present it here as a straw man proposal to see if chat can gain any traction.

It's based around the initial brainstorming, but was initially led by my own preferences for mark-up. The class names introduced are reused or derived from other existing microformats, and new class names are based on the Unified Logging Format, as the element names in ULF are already human-friendly.

===hChatLog Structure===

* hChatLog
** message
*** dt (or time)
*** sender (which MUST be an hCard and SHOULD be a CITE element)
*** 'quoted message content' (which MUST be a Q or BLOCKQUOTE element)
** status
*** dt (or time)
*** sender (which MUST be an hCard and SHOULD be a CITE element)
*** type (from a predefined list of values)
*** message (optional, the custom message the user assigns to a status, e.g. an 'away message')

====Notes about the above structure====

* message, sender, status and type are all taken from ULF. Note that 'type' also corresponds with tel > type and adr > type in hCard.
* 'dt' is proposed as a derivative of 'dtstart' and 'dtend' as used in hCalendar, however 'time' (again from ULF) may be preferable
* The message text does not have a class name, and is instead identified as from quoted text within a message, marked up with Q (for common single line messages) or BLOCKQUOTE (for multiline or otherwise complex messages).

====List of status 'type' values====

This should be a single-word list of the common status types from current IM implementations, namely:

* Online
* Offline
* Away
* Busy
* BRB (Be Right Back)
* Lunch (Out To Lunch)
* Phone (On The Phone)

===Example===

Note that this example uses an OL as the container, with LI elements for each message/status. This mark-up scheme for dialogue is subject to opinions of how strictly an Ordered List should be specified. For this reason OL/LI mark-up as is not specified as 'SHOULD' or 'MUST' in the structure above. The WHATWG list was recently included a discussion about tightening of the definition of OL for HTML5 (no definitive resolution was made though).

<pre>
<ol class="hChatLog">
<li class="message">
<abbr class="dt" title="2006-10-26T01:22:00+0100">1:22am</abbr>:
<cite class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=HanniUsername">Hanni</a></cite>
<q>Hello Ben</q>
</li>
<li class="message">
<abbr class="dt" title="2006-10-26T01:25:00+0100">1:25am</abbr>:
<cite class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=BenWardcouk">Ben</a></cite>
<blockquote>
<p>Hello Hanni</p>
<p>How're you today?</p>
</blockquote>
</li>
<li class="status"> 
<abbr class="dt" title="2006-08-08T01:27:00+0100">1:27am</abbr>:
<span class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=HanniUsername">Hanni</a> went <span class="type">away</span></span>
</li>
<li class="status">
<abbr class="dt" title="2006-08-08T01:28:00+0100">1:28am</abbr>:
<span class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=HanniUsername">Hanni</a>
<abbr class="type" title="online">came back</abbr></span>
</li>
</ol></pre>

In this example, two messages are exchanged followed by two status changes. Each message contains an hCard, identifying the user's nickname (which should map to the user's 'display name' or 'screen name') and uses the form proposed in [[hcard-examples]] for New Types of Contact Info to identify the AIM usernames.

Messages are quoted. Single line messages in Q elements and multiline messages in BLOCKQUOTE. There's no reason to limit each message to contain only one Q or BLOCKQUOTE, as depending on the precision of the timestamps being used, it may be appropriate to allow messages from the same individual to be placed together.

Status messages contain the DT, SENDER and then a TYPE. Since we're presenting humans-first information here, note that the first status change ('Hanni went away') uses the exact status type, the second ('Hanni came back') uses the abbr-pattern to embed the 'online' status type name.

It may be necessary to integrate the IM service URL patterns into the 'hChatLog' microformat itself, depending on whether they are treated as a formal part of hCard yet, but a means to identify service usernames with less reliance on implications is needed (for example, MSN accounts are identified by @hotmail, @msn or @passport domains, which is not inclusive of MSN Messenger users with their own domains, while other IM services may not have a URI scheme at all).

===Example of 'chat-username' class, extending hCard===

Whilst fitting this into the process needs to be clarified, it would be clearest to introduce a 'chat-username' class within hCards in hChatLog, to identify usernames.

<pre><li class="message">
<abbr class="dt" title="2006-10-26T01:25:00+0100">1:25am</abbr>:
<cite class="sender vcard"><a class="url" href="aim:goim?screenname=BenWardcouk"><abbr class="chat-username" title="BenWardcouk"><span class="fn nickname">Ben</span></abbr></a></cite>
<q>Hello</q>
</li></pre>

This fits into existing patterns OK, but loses one very important piece of information, the service provider. This could be spec'd as a prefix (<abbr class="chat-username" title="aim:BenWardcouk">…</abbr>) or could be a separate property altogether (chat-service).

===Example with include-pattern===

Introducing two new properties to each message hCard would create much clutter in the mark-up, and the repeition of hCards is already sub-optimal. The include-pattern in hCard can be used to keep the format cleaner, as demonstrated below.

Note: In this example, I'm still using the aim: URL form of representing usernames.

<pre><html> 
<body>
<h1>Chat between Ben and Hanni – Friday October 26th</h1>

<h2>Participants</h2>
<ul>
<li id="benwardcouk">
<h3><a class="fn url nickname" href="aim:goaim?benwardcouk">Ben</a></h3>
<p><a class="url" href="http://ben-ward.co.uk">Homepage</a></p>
<p class="description">Ben is a 22 year old web application developer in Birmingham, England</p>
</li>
<li id="hanni">
<h3><a class="fn url nickname" href="aim:goaim?hanniusername">Hanni</a></h3>
<p><a class="url" href="http://hanniross.com">Homepage</a></p>
</li>
</ul>

<ol class="hChatLog">
<li class="message">
<abbr class="dtstart" title="2006-08-08T01:22:00+0100">1:22am</abbr>:
<cite class="sender vcard"><a class="include" href="#hanni">Hanni</a></cite>
<q>Hello Ben</q>
</li>
<li class="message">
<abbr class="dtstart" title="2006-08-08T01:25:00+0100">1:25am</abbr>:
<cite class="sender vcard"><a class="include" href="#benward">Ben</a></cite>
<blockquote><p>Hello Hanni</p>
<p>How're you today?</p></blockquote>
</li>
<li class="status">
<abbr class="dtstart" title="2006-08-08T01:27:00+0100">1:27am</abbr>:
<span class="sender vcard"><a class="include" href="#hanni">Hanni</a> went <span class="type">away</span></span>
</li>
<li class="status">
<abbr class="dtstart" title="2006-08-08T01:28:00+0100">1:28am</abbr>:
<span class="sender vcard"><a class="include" href="#hanni">Hanni</a>
<abbr class="type" title="online">came back</abbr></span>
</li>
</ol>
</pre>

In this last example, the repeated hCards are declared once at the top of the document, with additional detail, and then can be parsed into the log itself using the include-pattern. The A/@class=include pattern is used, rather than OBJECT, as it allows the user display name to be repeated in each message as text, but will be replaced when parsed.

Note: The VCARD class name is on the CITE elements in each message/status, rather than on the LIs where the hCards are declared in full. This is because the include-pattern currently only to works <em>inside</em> an hCard. It would be tidier to have the VCARD class on the LIs in the participants list, but unless the include-pattern can be extended to apply natively inside hChatLog, the hCards must be arranged like this.

== Ideas ==

=== Using paragraphs to represent chat messages ===

I think that individual messages in a chat log should be formatted as XHTML paragraphs (<code><p></code>), because this is how conversations are commonly formatted. From the [[chat-examples|examples]] I gather that this is also what the [[chat-examples#ILRT_Logger_Bot_Format|ILRT Logger Bot]] currently does. --[[User:BigSmoke|BigSmoke]] 13:09, 21 Jun 2006 (PDT)

- We can't assume all paragraphs are chat messages, so we'll need a class name to identify a chat message. Once a class name is identifying something as a message, what is the advantage of applying the additional stipulation of a specific HTML tag? It doesn't appear to aid parsing, and it only constrains publishers. --[[User:ScottReynen|Scott Reynen]]

- I'm not convinced that ‘messages are paragraphs’ is an overly fair assumption: Lots of chat is extremely fragmented into sentences (or even partial sentences). I'd be nervous about generalising the P element any further than it all ready.

I have a lot of love for [http://microformats.org/wiki/chat-examples#MSN_Messenger_Marked_Up_By_Anne_van_Kesteren Anne van Kesteren's chat mark-up] (using Q elements for single line text, and BLOCKQUOTE > P for multiline messages, where the presence of newlines seems a more concrete basis on which to describe paragraph).

As far as block level element construction goes, AvK's mark-up again highlights the capability of raw HTML: OL is certainly correct, as is CITE and Q/BLOCKQUOTE. Paragraphs might not always be correct.

--[[User:Ben Ward|BenWard]] 12:29, 24 Sep 2006 (PDT)

- No sooner do I say ‘OL is certainly correct’ but something comes up to question it. Those interested in developing hChat might also like to keep an eye on the WHATWG list where there's been [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg02526.html some questioning of using OL for dialogue]. Additionally, there's a fresh [http://meyerweb.com/eric/thoughts/2006/10/23/broken-rights/ discussion on dialogue mark-up at Eric Meyer's blog].

--[[User:Ben Ward|BenWard]] 03:41, 24 Oct 2006 (PDT)

chat-brainstorming

2006-10-27T00:27:41Z

Ben Ward: /* Example playground */ Added strawman

== Requirements ==

=== Scope ===

Should a microformat matching these requirements be capable of representing only transcripts of existing IM protocols or should it also be able to serve as an exchange format itself. This '''might''' be useful for simple AJAX IM platforms, although I doubt if [http://www.xmpp.org/ XMPP] is not per definition a better choise for such purposes. --[[User:BigSmoke|BigSmoke]] 13:09, 21 Jun 2006 (PDT)

- Anything that can be parsed can be used in AJAX, so we don't need to consider this in developing a microformat. --[[User:ScottReynen|Scott Reynen]]

How much, and what kind of data is going to be in the file? The work done by the [http://purl.org/NET/ULF/SPEC Unified Logging Format WG] has a pretty good overview of the various types of things that an IM client would want to log. Don't make too much of a bikeshed about it -- I'm mostly linking it beacuse it's a good overview of the sorts of general element types (message, event, status) we probably want to use. --[[User:Colin Barrett|Colin Barrett]] 05:33, 22 Aug 2006 (PDT)
=== Chat rooms ===

Is it useful for this microformat to support the representation of "chat rooms", such as IRC channels? --[[User:BigSmoke|BigSmoke]]

- Location is a problem that can be clearly separated from chats. We should stick to solving the smallest problem possible, so we can more easily combine microformats later to solve larger problems. --[[User:ScottReynen|Scott Reynen]]

- On chat-formats and chat-examples, IRC logs are used. I would say we should include IRC logs in our spec -- it just makes sense to design for mult-user chat, because one-to-one messaging is just a special case of that. --[[User:Colin Barrett|Colin Barrett]] 05:33, 22 Aug 2006 (PDT)
== Example playground ==

<pre>
<div class="hchat-log">
<p class="hchat-msg">
<abbr class="time" title="YYYY-MM-DDTHH:MM:SS">HH:MM:SS</abbr>

</p>
</div>
</pre>

== hChatLog Strawman Proposal==

Initially compiled by [[Ben_Ward]]. (Please note: There are likely to be a large number of slightly random typos in this first version of the document, this is entirely the fault of my keyboard which intermittently spews extra characters into sentences when I press Option or Command. Also, it's 1am. I will attempt to revise it when I have access to more reliable hardware!)

Following [http://microformats.org/discuss/mail/microformats-discuss/2006-October/006719.html a vaguely related post] to uf-discuss, Colin Barrett requested I write up my hChatLog example in more detail, so I present it here as a straw man proposal to see if chat can gain any traction. It's based off reading around the initial brainstorming, but is initially led by my own preferences for mark-up. Class names, however, have where possible been reused or derived from other existing Microformats, and new class names are generally based on the Unified Logging Format, simply because the element names in ULF are very much human-friendly.

===hChatLog Structure===

* hChatLog
** message
*** dt (or time)
*** sender (which MUST be an hCard and SHOULD be a CITE element)
*** 'quoted message content' (which MUST be a Q or BLOCKQUOTE element)
** status
*** dt (or time)
*** sender (which MUST be an hCard and SHOULD be a CITE element)
*** type (from a predefined list of values)

====Notes about the above structure====

* message, sender, status and type are all from ULF.
* 'dt' is proposed based on 'dtstart' and 'dtend' as used in hCalendar, however 'time' (again from ULF) may be preferable
* The message text does not have a class name, and is instead identified as being quoted text within a message, marked up with Q or BLOCKQUOTE.
* An alternative, pre-ULF draft name for 'status' was 'event', however this is bad as it conflicts too closely with hCalendar.

====List of status type values====

This should be a single-word list of the common status types from current IM implementations, namely:

* Online
* Offline
* Away
* Busy
* BRB (Be Right Back)
* Lunch (Out To Lunch)

This is better represented with a mark-up example. Note that this example uses an OL as the container, with LI elements for each message/status. This mark-up scheme for dialogue is oft debated and subject to opinions of how strictly an Ordered List shoul3dl be specified, hense not listing OL/LI mark-up as SHOULD or MUST in the structure above. It should be worth watching the WHATWG list as tightening of the definition has recently be proposed for HTML5.

===Example===

<pre>
<ol class="hChatLog">
<li class="message">
<abbr class="dt" title="2006-10-26T01:22:00+0100">1:22am</abbr>:
<cite class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=HanniUsername">Hanni</a></cite>
<q>Hello Ben</q>
</li>
<li class="message">
<abbr class="dt" title="2006-10-26T01:25:00+0100">1:25am</abbr>:
<cite class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=BenWardcouk">Ben</a></cite>
<blockquote>
<p>Hello Hanni</p>
<p>How're you today?</p>
</blockquote>
</li>
<li class="status"> 
<abbr class="dt" title="2006-08-08T01:27:00+0100">1:27am</abbr>:
<span class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=HanniUsername">Hanni</a> went <span class="type">away</span></span>
</li>
<li class="status">
<abbr class="dt" title="2006-08-08T01:28:00+0100">1:28am</abbr>:
<span class="sender vcard"><a class="fn nickname url" href="aim:goim?screenname=HanniUsername">Hanni</a>
<abbr class="type" title="online">came back</abbr></span>
</li>
</ol></pre>

In this example, two messages are exchanged followed by two status changes. Each message contains an hCard, identifying the user's nickname (which should be the user's 'display name' or 'screeen name') and uses the form proposed in [[hcard-examples]] for New Types of Contact Info to identify the AIM usernames.

Messages are quoted. Single line messages in Q elements and multiline messages in BLOCKQUOTE. There's no reason to limit each message to contain only one Q or BLOCKQUOTE, as depending on the precision of the timestamps being used, it may be appropriate to have allow messages from the same individual to be placed together.

Status messages contain the timestamp, sender and then a TYPE. Since we're presenting humans-first information here, note that while the first status change ('Hanni went away') uses the exact status type, the second ('Hanni came back') uses the abbr-pattern to embed the 'online' status type.

It may be necessary to first integrate the IM service URLs into any hChatLog microformat, and also provide a means to identify service usernames with less reliance on implications (for example, MSN accounts are identified by hotmail, msn or passport domains, which is not inclusive of MSN Messenger users with their own domains).

===Example of 'chat-username' class, extending hCard===

Whilst fitting this into the process needs to be clarified, it would be clearest perhaps to introduce a 'chat-username' class within hCards in hChatLog, to make usernames more explicit.

<pre><li class="message">
<abbr class="dt" title="2006-10-26T01:25:00+0100">1:25am</abbr>:
<cite class="sender vcard"><a class="url" href="aim:goim?screenname=BenWardcouk"><abbr class="chat-username" title="BenWardcouk"><span class="fn nickname">Ben</span></abbr></a></cite>
<q>Hello</q>
</li></pre>

This fits into existing patterns OK, but loses one very important piece of information, the service provider. This could be spec'd as a prefix (<abbr class="chat-username" title="aim:BenWardcouk">…</abbr>) or could be a separate property altogether.

===Example with include-pattern===

Introducing two new properties to each message sender would create some clutter in the mark-up, as (arguably) the repeition of hCards already is. We can use the include-pattern in hCard to clean this up, as demonstrated in the following HTML document.

In this example, I'm back to using the aim: URL form of representing usernames.

<pre><html> 
<body>
<h1>Chat between Ben and Hanni – Friday cOctober 26th</h1>

<h2>Participants</h2>
<ul>

<li id="benwardcouk">
<h3><a class="fn url nickname" href="aim:goaim?benwardcouk">Ben</a></h3>
<p><a class="url" href="http://ben-ward.co.uk">Homepage</a></p>
<p class="description">Ben is a 22 year old web application developer in Birmingham, England</p>
</li>
<li id="hanni">
<h3><a class="fn url nickname" href="aim:goaim?hanniusername">Hanni</a></h3>
<p><a class="url" href="http://hanniross.com">Homepage</a></p>
</li>
</ul>


<ol class="hChatLog">

<li class="message">
<abbr class="dtstart" title="2006-08-08T01:22:00+0100">1:22am</abbr>:
<cite class="sender vcard"><a class="include" href="#hanni">Hanni</a></cite>
<q>Hello Ben</q>
</li>
<li class="message">
<abbr class="dtstart" title="2006-08-08T01:25:00+0100">1:25am</abbr>:
<cite class="sender vcard"><a class="include" href="#benward">Ben</a></cite>
<blockquote><p>Hello Hanni</p>
<p>How're you today?</p></blockquote>
</li>
<li class="status">
<abbr class="dtstart" title="2006-08-08T01:27:00+0100">1:27am</abbr>:
<span class="sender vcard"><a class="include" href="#hanni">Hanni</a> went <span class="type">away</span></span>
</li>
<li class="status">
<abbr class="dtstart" title="2006-08-08T01:28:00+0100">1:28am</abbr>:
<span class="sender vcard"><a class="include" href="#hanni">Hanni</a>
<abbr class="type" title="online">came back</abbr></span>
</li>
</ol>
</pre>

So in this last example, the repeated hCards are declared once at the top of the document, with extended details, and then can be parsed into the log itself using the include pattern.

Note: technically in the above the vcard class name is on the CITE elements rather than the LIs where the hCards are declared in full. This is because the include-pattern is currently specified only to work <em>inside</em> an hCard. It would be tidyer to have the vcard class on the LIs for the participants list, but unless the include-pattern can be extended to apply natively inside hChatLog, the hCards must be arranged like this.

== Ideas ==

=== Using paragraphs to represent chat messages ===

I think that individual messages in a chat log should be formatted as XHTML paragraphs (<code><p></code>), because this is how conversations are commonly formatted. From the [[chat-examples|examples]] I gather that this is also what the [[chat-examples#ILRT_Logger_Bot_Format|ILRT Logger Bot]] currently does. --[[User:BigSmoke|BigSmoke]] 13:09, 21 Jun 2006 (PDT)

- We can't assume all paragraphs are chat messages, so we'll need a class name to identify a chat message. Once a class name is identifying something as a message, what is the advantage of applying the additional stipulation of a specific HTML tag? It doesn't appear to aid parsing, and it only constrains publishers. --[[User:ScottReynen|Scott Reynen]]

- I'm not convinced that ‘messages are paragraphs’ is an overly fair assumption: Lots of chat is extremely fragmented into sentences (or even partial sentences). I'd be nervous about generalising the P element any further than it all ready.

I have a lot of love for [http://microformats.org/wiki/chat-examples#MSN_Messenger_Marked_Up_By_Anne_van_Kesteren Anne van Kesteren's chat mark-up] (using Q elements for single line text, and BLOCKQUOTE > P for multiline messages, where the presence of newlines seems a more concrete basis on which to describe paragraph).

As far as block level element construction goes, AvK's mark-up again highlights the capability of raw HTML: OL is certainly correct, as is CITE and Q/BLOCKQUOTE. Paragraphs might not always be correct.

--[[User:Ben Ward|BenWard]] 12:29, 24 Sep 2006 (PDT)

- No sooner do I say ‘OL is certainly correct’ but something comes up to question it. Those interested in developing hChat might also like to keep an eye on the WHATWG list where there's been [http://www.mail-archive.com/whatwg@lists.whatwg.org/msg02526.html some questioning of using OL for dialogue]. Additionally, there's a fresh [http://meyerweb.com/eric/thoughts/2006/10/23/broken-rights/ discussion on dialogue mark-up at Eric Meyer's blog].

--[[User:Ben Ward|BenWard]] 03:41, 24 Oct 2006 (PDT)

mailing-lists-proposals

2006-10-25T08:59:28Z

Ben Ward: /* microformats-tf */

=Mailing Lists Proposals=

There is a proposal for creating a new [[mailing-lists|mailing list]] for discussing the research and creation of new microformats so that those discussions do not overwhelm microformats-discuss.

Some candidates for names with the thinking behind them. Feel free to add your name and opinion (+/- 1 or 0).

==microformats-new==
Focusing on discussing "new" microformats
* +1 Tantek
* +1 ScottReynen
* -1 Lachlan Hunt
* +1 Joe Andrieu
* -1 Andy Mabbett
* +1 Bob Jonkman
* +1 Ben Ward
* +1 Ben O'Neill
==microformats-research==
Focusing on the essential, and often overlooked by first-time proposers "research" phase(s) in the process
* +0 Tantek
* +1 ScottReynen
* +1 cgriego
* +1 Phae
* +1 JustinThorp
* -1 Andy Mabbett
* -1 Joe Andrieu
* -1 Bob Jonkman (research is part of process, best documented on the Wiki)
* -1 Ben Ward (strikes me as dilution too far of µf-discuss and µf-new)
* 0 Lachlan Hunt
==microformats-process==
That's really what we're talking about with research of new microformats, isn't it?
* +1 ScottReynen
* +1 Lachlan Hunt
* +1 [[User:Singpolyma|singpolyma]]
* -1 Andy Mabbett
* -1 Joe Andrieu
* -1 cgriego (reminds me of parsing--processing--more so than even microformats-dev)
* -1 Bob Jonkman (Is this the process of creating a new microformat, or the some other process? Document it on the Wiki, I say)
* +0 Tantek
==microformats-propose==
* -1 Tantek
* -1 ScottReynen
* 0 Andy Mabbett
* -1 Bob Jonkman
* -1 Ben Ward

Comment (possibly by Tantek?): It misses the point of the process, and implies that there is a desire for microformats proposals - there isn't.

==microformats-suggest==
Similar to propose but milder ;)
* +1 ChrisMessina
* -1 Tantek
* -1 ScottReynen
* -1 Phae (I feel this is just -propose in disguise)
* -1 BenWest
* -1 Andy Mabbett
* -1 Bob Jonkman
* -1 Ben Ward (If µf-new or similar is created for active spec'ing and format development, uf-discuss would comfortably accomodate this as part of the course of discussion)
==microformats-work==
For working on microformats, new and old.

* +1 BenWest: I thought we are interested in a list that provides a venue for iterating through the process, and revising and refining microformats in general. discuss is for newbies, and dev is for implementing them.
* -1 Tantek: work could mean anything though, not just work on creating new microformats.

==microformats-wg==
WG is an abbreviation of Working Group
* +1 Lachlan Hunt
* -1 Tantek: "working group" means something quite specific in W3C terminology. Very little of that applies to the set of people that work on creating new microformats.
* -1 BenWard: As Tantek says, ‘working group’ means something that Microformats doesn't have and doesn't want. What's more, to an observer ‘Working Group’ implies exclusivity which isn't what µf development is about.

==microformats-tf==
TF is an abbreviation of Task Force
* 0 Lachlan Hunt
* -1 Tantek: Though less overloaded with specific meaning than "working group", "task force" still means something quite specific in W3C terminology as well as other standards organizations. Very little of that applies to the set of people that work on creating new microformats.
* -1 BenWard

==Change nothing==
e.g fix uf-dev, do nothing else (for now)
* +1 RyanKing
* +1 Tim White
* +1 Andy Mabbett
* 0 Bob Jonkman
* 0 Ben Ward
* -1 BenWest
* -1 Tantek (we have opened uf-dev and I still strongly believe we need a new list for the discussion of new microformats, separate from microformats-discuss in order to avoid overwhelming new folks with details and minutiae of new and in development formats.)

= General Comments=

==Andy Mabbett==
Why not create a new mailing list for each proposal, once it's reached a certain stage? Then , if the uF is created, or the proposal abandoned, the specific list would be closed, and the archive retained as a link from the "brainstorming" page, as a permanent, and discrete record of discussion on that topic.

Alternatively, the list could be retained for discussion of the implementation and development of that specific uF.

For example, several academic and professional taxonomists have told me in e-mail that they would be interested in the [[species]] proposal, (and one astronomer, likewise, for [[mars]]/ [[luna]]), but do not have the time to follow a general mailing list; indeed, a couple asked me specifically if I would set up a separate mailing list for the subject.

[[User:AndyMabbett|Andy Mabbett]] 04:44, 24 Oct 2006 (PDT)

The biggest challenge with creating new microformats (especially for new comers) is with following the process. The same discussions are often had over and over for different formats, thus it makes sense for people developing different formats to at least see the discussions around the creation of other formats and hopefully learn from them and avoid repeating the same questions or mistakes.

In addition, part of the [[microformats]] methodology/philosophy/principles is simplicity and minimalism - the fewer the better. This applies not only to microformats, microformats properties, and microformats values, but to microformats mailing lists as well. Thus since the beginning we have only created lists when absolutely necessary (i.e. when the traffic/topics crowded out one of the other lists), and then only one at a time. [[User:Tantek|Tantek]] 00:10, 25 Oct 2006 (PDT)

mailing-lists-proposals

2006-10-25T08:57:31Z

Ben Ward: /* microformats-wg */ Added vote against.

=Mailing Lists Proposals=

There is a proposal for creating a new [[mailing-lists|mailing list]] for discussing the research and creation of new microformats so that those discussions do not overwhelm microformats-discuss.

Some candidates for names with the thinking behind them. Feel free to add your name and opinion (+/- 1 or 0).

==microformats-new==
Focusing on discussing "new" microformats
* +1 Tantek
* +1 ScottReynen
* -1 Lachlan Hunt
* +1 Joe Andrieu
* -1 Andy Mabbett
* +1 Bob Jonkman
* +1 Ben Ward
* +1 Ben O'Neill
==microformats-research==
Focusing on the essential, and often overlooked by first-time proposers "research" phase(s) in the process
* +0 Tantek
* +1 ScottReynen
* +1 cgriego
* +1 Phae
* +1 JustinThorp
* -1 Andy Mabbett
* -1 Joe Andrieu
* -1 Bob Jonkman (research is part of process, best documented on the Wiki)
* -1 Ben Ward (strikes me as dilution too far of µf-discuss and µf-new)
* 0 Lachlan Hunt
==microformats-process==
That's really what we're talking about with research of new microformats, isn't it?
* +1 ScottReynen
* +1 Lachlan Hunt
* +1 [[User:Singpolyma|singpolyma]]
* -1 Andy Mabbett
* -1 Joe Andrieu
* -1 cgriego (reminds me of parsing--processing--more so than even microformats-dev)
* -1 Bob Jonkman (Is this the process of creating a new microformat, or the some other process? Document it on the Wiki, I say)
* +0 Tantek
==microformats-propose==
* -1 Tantek
* -1 ScottReynen
* 0 Andy Mabbett
* -1 Bob Jonkman
* -1 Ben Ward

Comment (possibly by Tantek?): It misses the point of the process, and implies that there is a desire for microformats proposals - there isn't.

==microformats-suggest==
Similar to propose but milder ;)
* +1 ChrisMessina
* -1 Tantek
* -1 ScottReynen
* -1 Phae (I feel this is just -propose in disguise)
* -1 BenWest
* -1 Andy Mabbett
* -1 Bob Jonkman
* -1 Ben Ward (If µf-new or similar is created for active spec'ing and format development, uf-discuss would comfortably accomodate this as part of the course of discussion)
==microformats-work==
For working on microformats, new and old.

* +1 BenWest: I thought we are interested in a list that provides a venue for iterating through the process, and revising and refining microformats in general. discuss is for newbies, and dev is for implementing them.
* -1 Tantek: work could mean anything though, not just work on creating new microformats.

==microformats-wg==
WG is an abbreviation of Working Group
* +1 Lachlan Hunt
* -1 Tantek: "working group" means something quite specific in W3C terminology. Very little of that applies to the set of people that work on creating new microformats.
* -1 BenWard: As Tantek says, ‘working group’ means something that Microformats doesn't have and doesn't want. What's more, to an observer ‘Working Group’ implies exclusivity which isn't what µf development is about.

==microformats-tf==
TF is an abbreviation of Task Force
* 0 Lachlan Hunt
* -1 Tantek: Though less overloaded with specific meaning than "working group", "task force" still means something quite specific in W3C terminology as well as other standards organizations. Very little of that applies to the set of people that work on creating new microformats.

==Change nothing==
e.g fix uf-dev, do nothing else (for now)
* +1 RyanKing
* +1 Tim White
* +1 Andy Mabbett
* 0 Bob Jonkman
* 0 Ben Ward
* -1 BenWest
* -1 Tantek (we have opened uf-dev and I still strongly believe we need a new list for the discussion of new microformats, separate from microformats-discuss in order to avoid overwhelming new folks with details and minutiae of new and in development formats.)

= General Comments=

==Andy Mabbett==
Why not create a new mailing list for each proposal, once it's reached a certain stage? Then , if the uF is created, or the proposal abandoned, the specific list would be closed, and the archive retained as a link from the "brainstorming" page, as a permanent, and discrete record of discussion on that topic.

Alternatively, the list could be retained for discussion of the implementation and development of that specific uF.

For example, several academic and professional taxonomists have told me in e-mail that they would be interested in the [[species]] proposal, (and one astronomer, likewise, for [[mars]]/ [[luna]]), but do not have the time to follow a general mailing list; indeed, a couple asked me specifically if I would set up a separate mailing list for the subject.

[[User:AndyMabbett|Andy Mabbett]] 04:44, 24 Oct 2006 (PDT)

The biggest challenge with creating new microformats (especially for new comers) is with following the process. The same discussions are often had over and over for different formats, thus it makes sense for people developing different formats to at least see the discussions around the creation of other formats and hopefully learn from them and avoid repeating the same questions or mistakes.

In addition, part of the [[microformats]] methodology/philosophy/principles is simplicity and minimalism - the fewer the better. This applies not only to microformats, microformats properties, and microformats values, but to microformats mailing lists as well. Thus since the beginning we have only created lists when absolutely necessary (i.e. when the traffic/topics crowded out one of the other lists), and then only one at a time. [[User:Tantek|Tantek]] 00:10, 25 Oct 2006 (PDT)

mailing-lists-proposals

2006-10-25T08:55:28Z

Ben Ward: Reformatted the now huge list with headings, so as to enable section level editing in MediaWiki (rather than having to edit the entire page to add a vote to a new proposal).

=Mailing Lists Proposals=

There is a proposal for creating a new [[mailing-lists|mailing list]] for discussing the research and creation of new microformats so that those discussions do not overwhelm microformats-discuss.

Some candidates for names with the thinking behind them. Feel free to add your name and opinion (+/- 1 or 0).

==microformats-new==
Focusing on discussing "new" microformats
* +1 Tantek
* +1 ScottReynen
* -1 Lachlan Hunt
* +1 Joe Andrieu
* -1 Andy Mabbett
* +1 Bob Jonkman
* +1 Ben Ward
* +1 Ben O'Neill
==microformats-research==
Focusing on the essential, and often overlooked by first-time proposers "research" phase(s) in the process
* +0 Tantek
* +1 ScottReynen
* +1 cgriego
* +1 Phae
* +1 JustinThorp
* -1 Andy Mabbett
* -1 Joe Andrieu
* -1 Bob Jonkman (research is part of process, best documented on the Wiki)
* -1 Ben Ward (strikes me as dilution too far of µf-discuss and µf-new)
* 0 Lachlan Hunt
==microformats-process==
That's really what we're talking about with research of new microformats, isn't it?
* +1 ScottReynen
* +1 Lachlan Hunt
* +1 [[User:Singpolyma|singpolyma]]
* -1 Andy Mabbett
* -1 Joe Andrieu
* -1 cgriego (reminds me of parsing--processing--more so than even microformats-dev)
* -1 Bob Jonkman (Is this the process of creating a new microformat, or the some other process? Document it on the Wiki, I say)
* +0 Tantek
==microformats-propose==
* -1 Tantek
* -1 ScottReynen
* 0 Andy Mabbett
* -1 Bob Jonkman
* -1 Ben Ward

Comment (possibly by Tantek?): It misses the point of the process, and implies that there is a desire for microformats proposals - there isn't.

==microformats-suggest==
Similar to propose but milder ;)
* +1 ChrisMessina
* -1 Tantek
* -1 ScottReynen
* -1 Phae (I feel this is just -propose in disguise)
* -1 BenWest
* -1 Andy Mabbett
* -1 Bob Jonkman
* -1 Ben Ward (If µf-new or similar is created for active spec'ing and format development, uf-discuss would comfortably accomodate this as part of the course of discussion)
==microformats-work==
For working on microformats, new and old.

* +1 BenWest: I thought we are interested in a list that provides a venue for iterating through the process, and revising and refining microformats in general. discuss is for newbies, and dev is for implementing them.
* -1 Tantek: work could mean anything though, not just work on creating new microformats.

==microformats-wg==
WG is an abbreviation of Working Group
* +1 Lachlan Hunt
* -1 Tantek: "working group" means something quite specific in W3C terminology. Very little of that applies to the set of people that work on creating new microformats.

==microformats-tf==
TF is an abbreviation of Task Force
* 0 Lachlan Hunt
* -1 Tantek: Though less overloaded with specific meaning than "working group", "task force" still means something quite specific in W3C terminology as well as other standards organizations. Very little of that applies to the set of people that work on creating new microformats.

==Change nothing==
e.g fix uf-dev, do nothing else (for now)
* +1 RyanKing
* +1 Tim White
* +1 Andy Mabbett
* 0 Bob Jonkman
* 0 Ben Ward
* -1 BenWest
* -1 Tantek (we have opened uf-dev and I still strongly believe we need a new list for the discussion of new microformats, separate from microformats-discuss in order to avoid overwhelming new folks with details and minutiae of new and in development formats.)

= General Comments=

==Andy Mabbett==
Why not create a new mailing list for each proposal, once it's reached a certain stage? Then , if the uF is created, or the proposal abandoned, the specific list would be closed, and the archive retained as a link from the "brainstorming" page, as a permanent, and discrete record of discussion on that topic.

Alternatively, the list could be retained for discussion of the implementation and development of that specific uF.

For example, several academic and professional taxonomists have told me in e-mail that they would be interested in the [[species]] proposal, (and one astronomer, likewise, for [[mars]]/ [[luna]]), but do not have the time to follow a general mailing list; indeed, a couple asked me specifically if I would set up a separate mailing list for the subject.

[[User:AndyMabbett|Andy Mabbett]] 04:44, 24 Oct 2006 (PDT)

The biggest challenge with creating new microformats (especially for new comers) is with following the process. The same discussions are often had over and over for different formats, thus it makes sense for people developing different formats to at least see the discussions around the creation of other formats and hopefully learn from them and avoid repeating the same questions or mistakes.

In addition, part of the [[microformats]] methodology/philosophy/principles is simplicity and minimalism - the fewer the better. This applies not only to microformats, microformats properties, and microformats values, but to microformats mailing lists as well. Thus since the beginning we have only created lists when absolutely necessary (i.e. when the traffic/topics crowded out one of the other lists), and then only one at a time. [[User:Tantek|Tantek]] 00:10, 25 Oct 2006 (PDT)

chat-brainstorming

2006-10-24T10:41:11Z

Ben Ward: /* Using paragraphs to represent chat messages – Sorry, left off username in comment */

chat-brainstorming

2006-10-24T10:40:33Z

Ben Ward: /* Using paragraphs to represent chat messages */

chat-brainstorming

2006-10-24T10:40:19Z

Ben Ward: /* Using paragraphs to represent chat messages – Added references to WhatWG OL-for-dialogue discussion and Eric Meyer's blog on dialogue mark-up */

mailing-lists

2006-10-21T23:01:07Z

Ben Ward: /* new list proposal: Added votes for Ben Ward */

<h1> Mailing Lists </h1>

Read the [http://microformats.org/discuss/ microformats discuss page] first.

Then read the [http://microformats.org/mailinglists-policies/ mailing list policies].

Ok, now here are some additional notes of scope and topics for each list.

__TOC__

== microformats-discuss ==
A mailing list for general discussion of microformats, with a strong leaning towards:

* starting out with microformats
* real-world content authoring

=== good topics for discussion ===
Here is a list (certainly not definitive) of good topics which are appropriate for the microformats-discuss mailing list:

* general thoughts on the design and use of semantic XHTML markup
* how to use and write microformats in content
* how to use microformat design patterns in content

=== good topics that belong somewhere else ===
* see [http://microformats.org/wiki/mailing-lists#good_topics_for_discussion_2 microformats-dev good topics for discussion]

=== bad topics for discussion ===

AKA topics better discussed elsewhere (somewhere other than microformats.org).

Here is a list (also not definitive) of topics which are undesired and inappopriate for the microformats-discuss mailing list. In fact, they're not even worth the time to bother discussing, so please do not bring them up on the microformats-discuss mailing list. We'll add more topics as people come up with more off-topic or out-of-scope or rathole topics.

# '''How to make a "general purpose" (micro)format.''' Go read [http://microformats.org/wiki/microformats#microformats_are_not what microformats are not], actually, go read the entire [[microformats|principles]] page. Sometimes this may masquerade as a "format of formats". Either way, it is one of those boil the ocean ratholes which are far outside the focus of microformats. If you really want to work on such subjects, teach yourself DTD (SGML, XML), XML Schema, Relax NG, RDF Schema, and find the communities working on those technologies.
# '''Using namespaces and namespace prefixes.''' In short, namespaces are neither necessary (the Internet ran just fine without them for decades, go read some RFCs), nor desirable (prefixes make formats far uglier and more difficult to hand-code). See also [[namespaces-considered-harmful]].
# '''Using non-English names for properties'''. This was briefly discussed on the microformats-discuss list most recently as "Language Maps" but has been raised before that. Some folks have raised the issue that microformats use English names for properties, and they would like alternate (non-English) names in other (natural) languages, and perhaps try to establish a mapping between them. As microformats property names are based on existing standards (see [[process]], and [[naming-principles]]), this is another problem that is far outside the scope of microformats. As Ryan King put it, this is a pre-existing (unsolved) "problem" with English-based HTML, the English-based CSS, the English-based HTTP and so on. Note that this is NOT about the internationalization (i18n) of the content and data itself - which is of course an excellent goal, advocated and promoted by microformats and the standards they are based on (e.g. W3C, IETF). This is purely about the names of the properties (and enumerated values) in the formats.

== microformats-dev ==
For discussion of microformats development, with a leaning towards:

* anything that involves writing code
* abstractions / models (in contrast to actual content)

=== good topics for discussion ===
These tend to be topics that belong in microformats-dev instead of microformats-discuss. This list is also not definitive, but illustrates the general areas:

* microformat parsing
* microformat "(auto)-discovery"
* comparisons of microformats with other data abstractions or data representations (e.g. XML, RDF)
* compatibility/interoperability of microformats with other data abstractions or data representations

Formerly, the membership to this list was moderated and limited to people who had demonstrated public implementations of microformats. We've since relaxed this requirement, yet maintain the same expectations that people involved in the discussion are focused on concrete and pragmatic topics related to writing code using microformats.

== microformats-rest ==
For discussion of use of microformats with [http://en.wikipedia.org/wiki/Representational_State_Transfer REST], in protocols, services, APIs etc.

== how to search the mailing list archives ==
If your post to the list starts off "I'm new to the list and microformats so I don't know if you've discussed this already" READ THROUGH THE [http://microformats.org/discuss/mail/microformats-discuss/ ARCHIVES]!

The archives are getting larger, so here are a few simple ways you can search them. Most popular search engines imploy some sort of site based results filtering. Google does this in your initial search. Type "site:http://microformats.org/discuss/ <search terms here>" to limit the search results to only our discussion list. This will help you from asking a question that has already been posted, debated, and possibly resolved. It saves everyone time and energy!

== new list proposal ==

There is a proposal for creating a new mailing list for discussing the research and creation of new microformats so that those discussions do not overwhelm microformats-discuss.

Some candidates for names with the thinking behind them. Feel free to add your name and opinion (+/- 1 or 0).

* microformats-new (focusing on discussing "new" microformats)
** +1 tantek
** +1 ScottReynen
** +1 Lachlan Hunt
** +1 Joe Andrieu
** -1 Andy Mabbett
** +1 Bob Jonkman
** +1 Ben Ward
* microformats-research (focusing on the essential, and often overlooked by first-time proposers "research" phase(s) in the process)
** +1 tantek
** +1 ScottReynen
** +1 cgriego
** +1 Phae
** +1 JustinThorp
** -1 Andy Mabbett
** -1 Joe Andrieu
** -1 Bob Jonkman (research is part of process, best documented on the Wiki)
** -1 Ben Ward (strikes me as dilution too far of µf-discuss and µf-new)
* microformats-process (That's really what we're talking about with research of new microformats, isn't it?)
** +1 ScottReynen
** +1 Lachlan Hunt
** -1 Andy Mabbett
** -1 Joe Andrieu
** -1 cgriego (reminds me of parsing--processing--more so than even microformats-dev)
** -1 Bob Jonkman (Is this the process of creating a new microformat, or the some other process? Document it on the Wiki, I say)
* microformats-propose (it misses the point of the process, and implies that there is a desire for microformats proposals - there isn't)
** -1 tantek
** -1 ScottReynen
** 0 Andy Mabbett
** -1 Bob Jonkman
** -1 Ben Ward
* microformats-suggest (similar to propose but milder ;)
** +1 ChrisMessina
** 0 tantek
** -1 ScottReynen
** -1 Phae (I feel this is just -propose in disguise)
** - BenWest
** -1 Andy Mabbett
** -1 Bob Jonkman
** -1 Ben Ward (If µf-new or similar is created for active spec'ing and format development, uf-discuss would comfortably accomodate this as part of the course of discussion)
* nothing (fix uf-dev, do nothing else (for now))
** +1 RyanKing
** +1 BenWest
** +1 Tim White
** +1 Andy Mabbett
** 0 Bob Jonkman
** 0 Ben Ward

chat-brainstorming

2006-09-24T19:29:20Z

Ben Ward: /* Using paragraphs to represent chat messages */

hresume

2006-07-14T18:15:01Z

Ben Ward: /* Examples in the wild */

<h1> hResume </h1>

hResume is a microformat for publishing resumes and CVs.

This paragraph is where we write some thing that makes everyone in the world want to use hResume. Because, you know, hResume's the future and people like the future. And so on... [[hresume-use|Wanna get started on hResume right now?]]

<h2> Microformats Draft Specification </h2>

; Editor/Author: [http://theryanking.com Ryan King]
; Acknowledgments: See [http://microformats.org/wiki/hresume#Acknowledgements acknowledgments].

Microformats [http://microformats.org/wiki/hresume#Copyright copyright] and [http://microformats.org/wiki/hresume#Patents patents] statements apply.

__TOC__

== Status ==
Draft, version 0.1.

== Introduction ==
=== Semantic XHTML Design Principles ===
{{SemanticXHTMLDesignPrinciples}}

== Format ==
=== In General ===
The hResume format is based on a set of fields common to numerous resumes published today on the web. Where possible field names have been chosen and reused from preexisting microformats.

=== Schema ===
The hResume schema consists of the following:

* hResume
** summary. optional. text.
** contact info. required. '''Must''' use [[hcard|hCard]]. '''Should''' use <code class="element"><address></code> + [[hcard|hCard]].
** experience. optional. One or more [[hcalendar]] events with the class name '<code class="class-name">experience</code>', with an embedded [[hcard|hCard]] indicating the job title, name of company, address of company etc.
** education. optional One or more [[hcalendar]] events with the class name '<code class="class-name">education</code>', with an embedded [[hcard|hCard]] indicating the name of school, address of school etc.
** skills. optional. phrases or keywords using the [[rel-tag]] microformat with the class name '<code class="class-name">skill</code>'.
** affiliations. optional. the class name <code class="class-name">affiliation</code> along with an [[hcard]] of the organization
** publications. optional. One or more citations. Use cite tag.

=== Field details ===
The fields of the hResume schema represent the following:

* '''<code class="class-name">hresume</code>''':: root class name
* '''<code class="class-name">summary</code>''':: The class name <code class="class-name">summary</code> is used to mark up an overview of qualifications and objectives.
* '''contact''':: Current contact info in an [[hCard]]. '''Should''' use <code class="element"><address></code> with [[hCard]] when possible.
* '''<code class="class-name">education</code>''':: the class name '<code class="class-name">education</code>' is applied to an [[hcalendar]] event.
* '''<code class="class-name">experience</code>''':: the class name '<code class="class-name">experience</code>' is applied to an [[hcalendar]] event. Job titles/positions should use an [[hCard]].
* '''<code class="class-name">skill</code>''':: An hResume may be tagged using the [[rel-tag]] microformat and the '<code class="class-name">skill</code>' class name.
* '''<code class="class-name">affiliation</code>''':: The class name <code="class-name">affiliation</code> is used along with an [[hcard]] of the organization
* '''publications''':: just use <code class="element"><cite></code>. When there is a [[citation]] microformat, then that can be used in combination with the cite element to further markup the components of the citation.

=== Notes ===
This section is informative.

*...

== Examples ==
=== Summary ===
An example summary:

<pre><nowiki>
<p class="summary">
I have 10 years experience with all Web 2.0 technologies– I've been working with Ajax since 1996,
designing with pastels while others will still using tiled background images and frames...
</p>
</nowiki></pre>

=== Contact ===
<pre><nowiki>
<address class="vcard">
<span class="fn">Pedro Sanchez</span>
<span class="adr">
<span class="street-address">123 Fake St.</span>
<span class="locality">Preston</span>, <span class="region">Idaho</span> <span class="postal-code">83263</span>
</span>
<span>Email: <a class="email" href="mailto:joe@example.com">pedro@vote-for-pedro.com</a></span>
<span>Homepage: <a class="url" href="http://vote-for-pedro.com/">vote-for-pedro.com</a></span>
<span>Phone: <span class="tel">+01.208.555.4567</span></span>
</address>
</nowiki></pre>

=== Education ===
<pre><nowiki>
<ol class="vcalendar">
<li class="education vevent">
<a class="url summary" href="http://example.edu/">Preston High School</a>
(<abbr class="dtstart" title="2001-01-24">2001</abbr> - <abbr class="dtend" title="2005-05-25">2005</abbr>)
</li>
...
</nowiki></pre>

=== Experience ===
==== Basic ====
A basic experience event:

<pre><nowiki>
<ol class="vcalendar">
<li class="experience vevent">
<span class="summary">President</span>,
<span class="location">Preston High School</span>,
<abbr class="dtstart" title="2004-09-01">May 2004</abbr> - <abbr title="2005-05-25">present</abbr>
</li>
...
</nowiki></pre>

==== Job Titles ====
To express one or more job titles/positions in the same experience event you should use [[hCard]]s. [[hcard]] requires the <code class="class-name">fn</code> ("formatted name") field, but it isn't reasonable to repeat your name for every job title you mark up in [[hResume|hresume]]. So, you may use an <code class="element"><object></code> and the class name '<code class="class-name">include</code>' with a reference to the <code class="class-name">fn</code> somewhere else on the page.

For example, this [[hCard]] refers to another [[hCard]]

<pre>
<span class="vcard">
<object data="#j" class="include"></object>
<span class="org">Preston High School</span>
<span class="title">Class President</span>
</span>
</pre>

Where "<code class="attr-value">j</code>" is the id attribute value of the "<code class="mf-prop">fn n</code>" element of the contact [[hCard]] at the top of the page, e.g. (shown here as a verbose [[hCard]] for purposes of illustration that the reference may be to a subtree, not just a text node):

<pre><nowiki>
<address class="vcard">
<span class="fn n" id="j">
<span class="given-name">Pedro</span>
<span class="family-name">Sanchez</span>
</span>
</address>
</nowiki></pre>

This method of hCard property indirection via an object element [[include-pattern|has been generalized]] to apply to any/all string/text properties in hCard.
Note: the object data attribute MUST be a local ID reference. External references (which would require a consuming application to load an external resource) are currently not supported by this method.

=== Skills ===
Some sample skills tags:
<pre><nowiki>
I have skills in <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Bow_%28weapon%29">bow hunting</a>
and <a class="skill" rel="tag" href="http://en.wikipedia.org/wiki/Nunchucks">nunchucks</a>.
</nowiki></pre>

=== Affiliations ===
<pre><nowiki>
<span class="affiliation vcard"><span class="fn org">National Honor Society</span></span>
</nowiki></pre>

=== Publications ===
<pre><nowiki>
<cite>Breeding Ligers for Fun and Magic</cite>, Idaho Press, 2004.
</nowiki></pre>

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

The following sites have published hResumes, and thus are a great place to start for anyone looking for examples "in the wild" to try parsing, indexing, organizing etc. If you have an hResume on your own page, feel free to add it to the top of this list. Once the list grows too big, we'll make a separate wiki page.

* [[User:Ralph Brandi|Ralph Brandi]] has [http://www.brandi.org/ralph/resume/ marked up his resume] with hResume, additionally using the object.include method to associate one description with three hCalendar experiences.
* [[User:Pat Ramsey|Pat Ramsey]] has his [http://www.southwestern.edu/~ramseyp/ramsey_resume2006.html resume] marked up as an hResume.
* [[User:Wim Le Page|Wim Le Page]] has also marked up [http://adrem.ua.ac.be/~wlepage/curriculum-vitae/ his curriculum vitae] as an hResume.
* [[user:Jonathan Arkell|Jonathan Arkell]] has posted an [http://portfolio.jonnay.net/cv/ hResume] on his portfolio website.
* [http://steve.ganz.name/hresume/ Steve Ganz - hResume 0.1]
* [[User:Dave Cardwell|Dave Cardwell]] has marked up [http://davecardwell.co.uk/cv/ his curriculum vitae] as an hResume.
* [[user:Izo|Mathieu Drouet]] has posted an [http://izo.aucuneid.com/hresume.html hResume]. ''Incorrect root class name hResume? -- [[DavidJanes]]''
* [[User:EdwardOConnor|Edward O'Connor]]'s [http://edward.oconnor.cx/resume/ resume] is in hResume, and has some experimental JavaScript in it to extract a skill summary from the resume.
* [[User:Lindsey Simon|Lindsey Simon]] has his [http://www.commoner.com/~lsimon/lindsey_simon_resume.html resume] marked up as an hResume - with lots of thanks to Pat Ramsey.
* [[User:Ben Ward|Ben Ward]] has published [http://ben-ward.co.uk/cv his CV] with hResume.

== Profile ==
@TODO

== Implementations ==
@TODO

== References ==
=== Normative References ===
* [http://www.w3.org/TR/REC-html40/ HTML 4]
* [http://www.w3.org/TR/xhtml1/ XHTML]
* [http://gmpg.org/xmdp/ XMDP]
* [[rel-tag| Rel-Tag]]
* @TODO

=== Informative References ===
@TODO

== Copyright ==
{{MicroFormatCopyrightStatement2006}}

== Patents ==
{{MicroFormatPatentStatement}}

== Acknowledgements ==

=== Concept ===
* [http://theryanking.com/ Ryan King], [http://technorati.com Technorati]
* [http://tantek.com/ Tantek Çelik], [http://technorati.com Technorati]
* James Levine [http://simplyhired.com Simply Hired]
* [http://epeus.blogspot.com/ Kevin Marks], [http://technorati.com Technorati]

== See also ==
* [[resume-examples]]
* [[resume-formats]]
* [[resume-brainstorming]]

== Discussions ==

* Feedback is encouraged on the [[hresume-feedback]] page.
* See also [http://www.technorati.com/cosmos/referer.html blogs discussing this page].

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

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

User:BenWard

2006-03-09T00:45:23Z

Ben Ward: Created User Page

== Ben Ward ==
* http://ben-ward.co.uk/
* ben at ben-ward dot co dot uk

irc

2006-03-09T00:43:28Z

Ben Ward: /* People on irc */

__NOTOC__
= Microformats IRC =

We have an IRC channel, [irc://irc.freenode.net#microformats #microformats on the freenode network].

There's typically someone there at any point during the day, though there isn't always active discussion. Sometimes, though this is the best place to discuss issues that need lots of back and forth discussion.

== People on irc ==
A list of IRC regulars and their normal timezones.

* [[User:Amette|amette]] (+1000)
* [[User:BenjaminCarlyle|BenjaminCarlyle]] (+1000)
* [[User:B.K._DeLong|bkdelong]] (-0500)
* [[User:Cgriego|cgriego]] (-0600)
* [[User:ChrisCasciano|pnhChris]] (-0500)
* [[User:DimitriGlazkov|dglazkov]] (-0600)
* [[User:ChrisMessina|factoryjoe]] (-0800)
* [[User:EdwardOConnor|hober]] (-0800)
* [[User:Enric|enric]] (-0800)
* [[User:Fil|Fil]] (+0200)
* [[User:IanHickson|Hixie]] (-0800)
* [[User:Izo|IZO]]
* [[User:JoeGregorio|jcgregorio]]
* [http://epeus.blogspot.com/ KevinMarks] (-0800)
* [[User:neuro|neuro`]]
* [[User:RyanKing|kingryan]] (-0800)
* [[User:RobertBachmann|RobertBachmann]] (+0100)
* [[User:Tantek|Tantek]] (-0800)
* [[User:ChristopherStJohn|cks]] (-0600)
* [[User:Mark Mansour|Mark Mansour]] (+1100)
* [[User:Dave Cardwell|davecardwell]] (+0000)
* [[User:Boneill|boneill]] (+0000)
* [[User:Steve Ganz|Steve Ganz]] (-0800)
* [[User:Hlb|hlb]] (+0800)
* [[User:Ben Ward|BenWard]] (+0000)

=== bots ===

* [[mfbot]]
* [[mflogbot]]
* [http://joi.ito.com/joiwiki/JiBot jibot]

== Logs ==

Available here: http://rbach.priv.at/Microformats-IRC/

== IRC meetups ==

The idea of having IRC meetups (that is, a set time for meeting on IRC) has been suggested by [[User:RyanKing|Ryan King]], as it appears to work well for the WordPress community and may help us from time-to-time. As of yet, there are no plans to have meetups, though.