IRC Log for #microformats on 2006-01-01

Timestamps are in UTC.

  1. [00:06:20] * factoryjoe (n=cmessina@h-67-103-44-6.snfccasy.covad.net) has joined #microformats
  2. [00:06:21] <jibot> factoryjoe is Chris Messina, works for Flock, Bar Camp and Rhyzomatic and is working towards open source world domination
  3. [00:08:42] <megasquid> Tantek: that makes sense, thanks
  4. [00:09:10] <KevinMarks> hi chris
  5. [00:09:19] <KevinMarks> you seen the CEScamp thing?
  6. [00:09:26] <factoryjoe> um?
  7. [00:09:28] <factoryjoe> link?
  8. [00:10:16] <KevinMarks> http://ces.bubbleshare.com/index.php?wiki=CesCamp
  9. [00:11:57] <factoryjoe> mm
  10. [00:12:45] <factoryjoe> wow
  11. [00:12:50] <KevinMarks> they likely need a bit of help to get it coing
  12. [00:12:51] <factoryjoe> man, we sure started something
  13. [00:12:56] <factoryjoe> seems like it
  14. [00:12:58] <factoryjoe> who's in chrage?
  15. [00:13:02] <factoryjoe> charge even?
  16. [00:13:30] <KevinMarks> er, nto sure
  17. [00:13:35] <factoryjoe> k
  18. [00:13:39] <KevinMarks> Jeneane pointed me at it
  19. [00:14:02] <KevinMarks> I think Albert Lai set up the wiki
  20. [00:14:14] <factoryjoe> ah, i don't know them
  21. [00:14:40] <KevinMarks> ?def jeneane
  22. [00:14:41] <jibot> jeneane is THE Jeneane, and blogs to http://allied.blogspot.com/ and from Venus
  23. [00:17:11] <factoryjoe> from venus?
  24. [00:31:56] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
  25. [00:32:42] * Tantek (n=Tantek@pool-71-104-248-219.lsanca.dsl-w.verizon.net) Quit ("via the nearest exit")
  26. [00:34:47] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  27. [00:42:54] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
  28. [00:44:05] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  29. [00:54:31] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
  30. [00:56:33] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  31. [00:57:17] * factoryjoe (n=cmessina@h-67-103-44-6.snfccasy.covad.net) Quit ()
  32. [01:06:39] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
  33. [01:08:39] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  34. [01:19:40] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
  35. [01:21:07] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  36. [01:34:06] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
  37. [01:35:09] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  38. [01:36:39] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Remote closed the connection)
  39. [01:52:08] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  40. [01:52:09] <jibot> Atamido is Paul Bryson, http://orangeman.commo.de/
  41. [02:38:22] * edsu (n=esummers@66.187.134.52) has joined #microformats
  42. [03:10:17] * jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) has joined #microformats
  43. [03:12:59] <Hixie> hey does anyone have any links to people who have written blogs about what class attribute values people use? or who can remember who wrote that blog entry about who uses xhtml?
  44. [03:13:10] <Hixie> (other than the one by john allsopp than tantek mentioned earlier)
  45. [03:48:26] <KevinMarks> I know a blog search engine you coudl try, Hixie
  46. [03:49:00] <Hixie> hah
  47. [03:49:04] <Hixie> yeah well tried that
  48. [03:49:08] <KevinMarks> hm
  49. [03:49:11] <Hixie> i did find a couple of sites
  50. [03:49:15] <Hixie> http://www.goer.org/Journal/2003/Apr/index.html
  51. [03:49:18] <Hixie> http://www.markokarppinen.com/20020222.html
  52. [03:49:20] <Hixie> http://phnk.com/design/survey/
  53. [03:49:31] <Hixie> and http://westciv.typepad.com/dog_or_higher/2005/11/real_world_sema.html
  54. [03:49:34] <Hixie> but i was hoping for more
  55. [03:51:09] <KevinMarks> have a loook a zen garden and the link trail fromthat fro the hard-core CSSies
  56. [03:52:08] <Hixie> yeah, didn't find anything in the blogosphere other than those four
  57. [03:52:14] <Hixie> lots of people _talking_ about those
  58. [03:52:16] <Hixie> or linking to them
  59. [03:52:31] <Hixie> or generally waffling on about xhtml being good or bad or semantics being hard or whatever
  60. [03:52:38] <Hixie> but very little genuine research
  61. [03:53:02] <KevinMarks> we need to get Pilgrim blogging again
  62. [03:53:26] <Hixie> oh hey i met mark the other day actually
  63. [03:53:43] <Hixie> he was at some mozilla shingdig, had lunch with him at google
  64. [03:53:55] <KevinMarks> I dind't know he was up this way
  65. [03:53:55] <Hixie> apparently he's all busy at ibm
  66. [03:54:20] <KevinMarks> I need to get on with microformats in feedparser wiht him
  67. [03:55:23] <jcgregorio> I'm pretty sure mark won't blog again
  68. [03:56:52] <KevinMarks> well, get him a syndicated newspaper column or something
  69. [03:58:45] * edsu (n=esummers@66.187.134.52) Quit ("leaving")
  70. [04:17:09] * Tantek (n=Tantek@pool-71-104-248-219.lsanca.dsl-w.verizon.net) has joined #microformats
  71. [04:47:14] <Tantek> good evening
  72. [04:58:09] <jcgregorio> hello and happy new year!
  73. [04:58:24] <jcgregorio> at least in two minutes for me
  74. [05:01:46] <Tantek> happy new year joe!
  75. [05:02:11] <Tantek> and to everybody else in Eastern Standard Time!
  76. [05:10:16] <jcgregorio> thanks!
  77. [05:45:36] * jcgregorio (n=chatzill@adsl-072-148-043-048.sip.rmo.bellsouth.net) Quit ("Chatzilla 0.9.68.5.1 [Firefox 1.0.7/20051010]")
  78. [06:24:30] <Frederic> Happy new year
  79. [06:52:08] <Tantek> Happy New Year Frederic!
  80. [07:09:06] <Frederic> Happy new year Tantek
  81. [07:09:38] * Tantek (n=Tantek@pool-71-104-248-219.lsanca.dsl-w.verizon.net) Quit (Remote closed the connection)
  82. [07:46:06] * Tantek (n=Tantek@pool-71-104-248-219.lsanca.dsl-w.verizon.net) has joined #microformats
  83. [08:00:47] <KevinMarks> happy new year chaps
  84. [08:29:24] <Tantek> happy new year everyone!
  85. [08:29:42] * bkdelong (n=bkdelong@h-67-102-164-116.cmbrmaor.covad.net) Quit (Read error: 110 (Connection timed out))
  86. [09:10:54] <Frederic> happy *.*
  87. [13:32:32] * megasquid (n=megasqui@cpe-66-27-237-225.bak.res.rr.com) Quit ()
  88. [14:26:18] * fuzzyBSc (n=fuzzy@c210-49-73-138.rochd2.qld.optusnet.com.au) has joined #microformats
  89. [14:26:19] <jibot> fuzzyBSc is Benjamin Carlyle, http://soundadvice.id.au/blog/
  90. [14:28:47] * ichigo (n=ichigo@M2660P022.adsl.highway.telekom.at) has joined #microformats
  91. [14:28:57] * ichigo (n=ichigo@M2660P022.adsl.highway.telekom.at) Quit (Client Quit)
  92. [14:33:36] <mfbot> [[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3652 * FuzzyBSc * (+45) Clarify current suggestion
  93. [15:13:51] <fuzzyBSc> I have obliquely summarised some of the discussions had on the channel to microformats-discuss, and have described my nomenclature suggestion for atom:title/atom:summary/atom:content = hAtom summary/description/content
  94. [15:14:09] <fuzzyBSc> Does the channel have any immediate feedback? :)
  95. [15:15:34] * AndreasHaugstrup (i=usenet@D40A9676.rev.stofanet.dk) has joined #microformats
  96. [15:19:26] * AndreasHaugstrup (i=usenet@D40A9676.rev.stofanet.dk) has left #microformats
  97. [15:21:58] <mfbot> [[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3653 * FuzzyBSc * (+503) Add hReview and date-time question
  98. [15:27:25] <mfbot> [[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3654 * FuzzyBSc * (+33) Add subject as alternative to atom:title
  99. [15:30:20] <fuzzyBSc> An alternative to content might be body, actually.
  100. [15:30:35] <fuzzyBSc> It wouldn't work too well in html though, I guess. Not with the established <body> element :)
  101. [15:49:11] <mfbot> [[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3655 * FuzzyBSc * (+172) Add subject-based alternative
  102. [15:50:04] <fuzzyBSc> I currently have two alternatives in play that may or may not be compatible with existing precedent:
  103. [15:50:08] <fuzzyBSc> summary (atom:title) -> description (atom:summary) -> content (atom:content)
  104. [15:50:19] <fuzzyBSc> subject (atom:title) -> summary (atom:summary) -> content (atom:content)
  105. [15:52:01] * RobertBachmann (n=RobertBa@M2500P001.adsl.highway.telekom.at) has joined #microformats
  106. [16:07:17] <RobertBachmann> greetings.
  107. [16:22:28] * Tantek (n=Tantek@pool-71-104-248-219.lsanca.dsl-w.verizon.net) Quit (Remote closed the connection)
  108. [16:27:51] <fuzzyBSc> Morning, Robert :)
  109. [16:28:18] * Tantek (n=Tantek@pool-71-104-248-219.lsanca.dsl-w.verizon.net) has joined #microformats
  110. [16:34:16] <fuzzyBSc> Hrrm.
  111. [16:34:55] <fuzzyBSc> rfc2445: "When the action is "EMAIL", the alarm MUST include a "DESCRIPTION" property, which contains the text to be used as the message body, a "SUMMARY" property, which contains the text to be used as the message subject, and one or more "ATTENDEE" properties, which contain the email address of attendees to receive the message."
  112. [16:36:52] <fuzzyBSc> That may indicate that description is meant to be equivalent to a full message body, and summary equivalent to message subject. VJournal description, atom:content, and atom:summary may overlap. VJournal summary, atom:title, and atom:summary may also overlap.
  113. [16:37:46] <fuzzyBSc> I have been struggling to find a clear definition of what summary has meant in earlier standards. Is it exclusively atom:title, it exclusively atom:summary, or could it be either?
  114. [16:39:16] <fuzzyBSc> The requirement that summary be used as an email subject line implies to me that it is meant to be a single line title rather than a single paragraph teaser.
  115. [16:42:02] <fuzzyBSc> rfc2445: This property [description] is used in the "VJOURNAL" calendar component to capture one more textual journal entries.
  116. [16:42:31] <fuzzyBSc> This makes it sound like atom:content. In which case, what do you call atom:summary?
  117. [16:42:58] <mfbot> [[hresume]] MN http://microformats.org/wiki/hresume * Tantek * (+222)
  118. [16:43:33] <fuzzyBSc> rfc2445: "Purpose: This property [description] provides a more complete description of the calendar component, than that provided by the "SUMMARY" property."
  119. [16:43:59] <fuzzyBSc> You could take this to mean it is still the description of some content like atom:summary is, rather than content in and of itself.
  120. [17:10:40] <mfbot> [[recipe-examples]] N http://microformats.org/wiki/recipe-examples * Tantek * (+1592) recipe-examples first draft
  121. [17:11:36] <Tantek> hi Fuzzy
  122. [17:11:47] <Tantek> you are correct that description = full content
  123. [17:12:36] <Tantek> BTW, using the name "content" anywhere in a schema is not really a good idea. It implies that the rest of the data is not content - which is clearly a matter of perspective.
  124. [17:13:08] <Tantek> Same problem with the "meta-data" distinction. In practice it is not very useful.
  125. [17:13:36] <Tantek> From a user's perspective, there is the information they care about and the information they don't care about.
  126. [17:14:05] <Tantek> The former includes what theoreticians distinguish as data vs. meta-data, but the end user doesn't care about such a distinction.
  127. [17:14:18] <Tantek> Headings are the perfect example.
  128. [17:14:32] <Tantek> Some would say they are part of the "content", some would say they are not.
  129. [17:15:31] <Tantek> The other evidence for "content" being a bad name to use in a schema is the existence in the wild of such evolved terms as "main-content", which implies that there was a "content" at one level, but someone else came along that wanted something more specific that *they* thought was *really* the content, so they made up their own term.
  130. [17:16:42] <Tantek> BTW, consider how people discuss RSS/Atom feeds
  131. [17:16:56] <Tantek> They don't say "summary feed" vs. "content feed"
  132. [17:17:35] <Tantek> They say "partial-text" vs. "full-text" feeds
  133. [17:23:27] * fuzzyBSc nods
  134. [17:25:09] <fuzzyBSc> I have already raised one issue about opacity of hAtom content regarding update time. Content in the atom sense really means "what the feed reader user sees in the main panel for a full-conent feed". That usually includes some information about updates, particularly the text of the update itself.
  135. [17:26:06] <fuzzyBSc> It seems the publisher should be able to define this box of what is inside and out, but the box may not be opaque and it may be useful sometimes to say <div class="entry content">...</div> and have everything appear in the box.
  136. [17:26:51] <fuzzyBSc> Atom is about separating the human- from the machine- readable, but hAtom should not be.
  137. [17:29:40] <fuzzyBSc> I think there is still value in allowing a feed with both summary and content selections for "read more" blogs. That I think was the determination of the atom committee when they created two elements rather than just allowing one with a "is-full" attribute. The question still remains as to what to call them, though. All prior existing terms seem heavily overloaded.
  138. [17:30:11] <fuzzyBSc> (or at least are not compatible with the three-tier level of detail atom provides)
  139. [17:32:26] <fuzzyBSc> The thing that is bugging me at the moment is that I am not sure a title is always a summary. The title of the CD in front of me is "Breathing Tornados", rather than "Ben Lee sings about life in the nineties".
  140. [17:33:33] <Tantek> fuzzy, you said: "Atom is about separating the human- from the machine- readable, but hAtom should not be."
  141. [17:33:37] <Tantek> That is precisely correct!
  142. [17:33:52] <Tantek> You have captured one of the key essences of microformats in that short statement.
  143. [17:34:00] <fuzzyBSc> The summary concept as extracted from iCalendar is a descriptive title. It is a short summary of the event that is being described or listed. Summary might say "U2 Concert", but it might still be legitimate to use "Elevation" as the title.
  144. [17:34:41] <Tantek> I just realized that atom's use of "summary" as name for partial content is actually semantically incorrect.
  145. [17:34:44] <fuzzyBSc> Tantek: Yes, I know :) Sometimes I state the obvious for effect ;)
  146. [17:34:55] <Tantek> Rarely is the "summary" an actual *summary*
  147. [17:35:06] <Tantek> It is more often just the first part of the description
  148. [17:35:10] <Tantek> It is an abbreviation
  149. [17:35:14] <Tantek> It is partial
  150. [17:35:18] <Tantek> It is NOT a summary
  151. [17:36:04] <Tantek> Perhaps we should consider a term that reflects actual usage
  152. [17:36:08] <Tantek> and actual discussion
  153. [17:36:17] <Tantek> hence why I raised the point about "partial-text"
  154. [17:36:31] <Tantek> Since we have "description" already to mean "full text"
  155. [17:36:47] <Tantek> Perhaps we could consider "partial-description"
  156. [17:37:46] <Tantek> (side-note: yes, the term "content" is both way too ambiguous and overloaded to be of any practical use in a data format schema)
  157. [17:38:12] <fuzzyBSc> Oh, I don't know. Let's take the rss feed from http://xml.coverpages.org/covernews.xml as an example. As a semi-serious news site it summarses each entry dilligently in the feed. It is very similar to the introductary paragraph of the story by not identical.
  158. [17:38:24] <Tantek> fuzzy, you are right that in practice, a title is not always a summary, but, in blog posts, it often is
  159. [17:38:35] <Tantek> perhaps even >50% of the time
  160. [17:39:04] <Tantek> (you gave an example of CD, let's side-table the media info discussion for now)
  161. [17:39:19] <fuzzyBSc> Tantek: I think that most of the time title could accurately be described as a "heading".
  162. [17:39:21] * Tantek goes to xml.coverpages....
  163. [17:39:56] <Tantek> fuzzy, yes
  164. [17:40:13] * Tantek wonders if http://xml.coverpages.org/covernews.xml is a 20% case rather than an 80% case.
  165. [17:40:39] <Tantek> the relationship between title and heading is a subset/subclass
  166. [17:40:46] <Tantek> i.e. most titles are headings
  167. [17:40:52] <Tantek> but most headings are not titles
  168. [17:41:00] <Tantek> titles could be said to be a specific type of heading
  169. [17:41:08] <fuzzyBSc> Tantek: For blogging I think it would be a 20% case. I'm not sure whether it would be or not for syndicated journalism. My blogroll is wide, but not that wide ;)
  170. [17:41:11] <Tantek> which is exactly what you see in practice on blogs!
  171. [17:41:12] <Tantek> e.g.
  172. [17:41:18] <Tantek> <h3 class="title">...</h3>
  173. [17:41:58] <Tantek> fuzzy, if it is the 20% case, then it *certainly* shouldn't be used to steer a naming discussion
  174. [17:41:59] <fuzzyBSc> So is title = summary or not? :)
  175. [17:43:04] <fuzzyBSc> Tantek: Well, I suppose we could always use summary (atom:title) -> shortdescription (atom:summary) -> description (atom:content)
  176. [17:43:23] <Tantek> I think we need a different term for what Atom calls "summary", since in practice, the 80/20 case is that people don't actually use it for a "summary"
  177. [17:43:34] <Tantek> right, something like that
  178. [17:43:47] <Tantek> except even then, why not use what people call these things?
  179. [17:44:09] <Tantek> What else do people call them besides "partial" ?
  180. [17:44:16] <Tantek> (in actual discussions)
  181. [17:44:18] <fuzzyBSc> In all honesty, I think that the use of summary itself is in the 20%... but it is growing as publishers want users to visit their site and click on their ads.
  182. [17:45:07] <fuzzyBSc> Tantek: Partial is the word I have heard used. Perhaps more reasearch would be useful.
  183. [17:45:29] <Tantek> precisely
  184. [17:45:31] <Tantek> here is a URL
  185. [17:45:32] <Tantek> http://scobleizer.wordpress.com/2005/11/28/the-fullpartial-debate-roars-on/
  186. [17:45:52] <Tantek> So let's ask this question: why didn't Atom use the term "partial" ?
  187. [17:46:10] <fuzzyBSc> In fact, partialdescription is semantically neat. It exists to tell you that it is not the whole description. A short description could be complete, but a partial one is always accompanied by a full description.
  188. [17:46:40] <fuzzyBSc> s/accompanied/matched/
  189. [17:48:06] <Tantek> right
  190. [17:48:09] <fuzzyBSc> Are you wedded to summary = atom:title at this stage, then?
  191. [17:48:32] <Tantek> of course, using microformat property naming rules, we would use a hyphen rather than omit the space when converting "partial description" to a property name
  192. [17:48:53] <fuzzyBSc> :)
  193. [17:48:53] <fuzzyBSc> Ok. I'm still new in this game.
  194. [17:49:03] <Tantek> No, I'm trying to solve the problem of what better name to use for Atom's ill-named concept of "summary"
  195. [17:49:35] <Tantek> Even if/when we solve that problem, it is still unclear whether we should use the property name "summary" to refer to "atom:title"
  196. [17:50:02] <Tantek> We may want to not use "summary" at all in hAtom, due to fact that it will confuse either or both microformat or Atom developers.
  197. [17:50:15] <fuzzyBSc> So there is still room for movement on each of the three axis, and any proposal should set forth all three.
  198. [17:50:23] <Tantek> Not necessarily.
  199. [17:50:29] <Tantek> It may be easier to solve one problem at a time.
  200. [17:50:42] <fuzzyBSc> Perhaps
  201. [17:50:59] <Tantek> In untangling this dependency mess, it appeared to me that solving the what to call "atom:summary" problem was one we could address independently of the others.
  202. [17:51:24] <Tantek> So let's make that a concrete proposal then.
  203. [17:51:34] <Tantek> "partial-description"
  204. [17:52:04] <fuzzyBSc> I'll write it up.
  205. [17:52:36] <Tantek> Another term I have heard:
  206. [17:52:39] <Tantek> "excerpt"
  207. [17:53:20] * Tantek just read down to comment #15 on Scoble's post: http://scobleizer.wordpress.com/2005/11/28/the-fullpartial-debate-roars-on/#comment-5201
  208. [17:53:47] <Tantek> I like it because it is short and to the point
  209. [17:54:31] <Tantek> Though it may be too specific, as "excerpt" implies a proper subset, whereas a "partial-description" sounds like it allows for different content than in the "description".
  210. [17:57:52] <fuzzyBSc> I'll put both in. There is presumably no harm in having a bit of brainstorming... or should this iteration be moved back to blog-post-brainstorming at some point?
  211. [17:58:27] <mfbot> [[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3656 * FuzzyBSc * (+249) Add partial-description and excerpt as options for atom:summary
  212. [18:00:27] <fuzzyBSc> In a typical "read more" situation the summary is likely to be a proper excerpt. Although it isn't supported by current opacity rules I imagine a nesting such as <div class="content"><div class="summary">...</div>...</div>
  213. [18:02:43] <mfbot> [[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3657 * FuzzyBSc * (+201) Add "read more" summary nested in content example for opaqueness
  214. [18:05:18] <Tantek> yes, i agree, in typical (one might even say >80%) situations, these will be proper excerpts with "read more" links.
  215. [18:05:35] <Tantek> this feels much better. we are designing based on actual behavior.
  216. [18:06:25] * RobertBachmann (n=RobertBa@M2500P001.adsl.highway.telekom.at) Quit (Read error: 104 (Connection reset by peer))
  217. [18:09:56] <fuzzyBSc> It does seem unlikely that a summary rather than an excerpt will be commonly used in hAtom. It could still be done, but to make it work visually you may have to hide the summary at the same time as you exposed the content.
  218. [18:10:17] <Tantek> right
  219. [18:10:45] <Tantek> in addition for the title vs. summary debate, I have a feeling we will have to not use "summary" in hAtom to mean anything, just to avoid confusion.
  220. [18:10:57] <fuzzyBSc> Interestingly, hAtom could handle summary-only feeds well also. A publisher could simply enter the full content but only mark up a portion as summary. No markup would be provided for content, except perhaps a permalink.
  221. [18:11:10] <Tantek> oh wow, that would totally work
  222. [18:11:29] <Tantek> you should *definitely* add that observation to the brainstorming page
  223. [18:11:40] <fuzzyBSc> :)
  224. [18:11:51] <Tantek> excerpt-only feeds :)
  225. [18:12:06] <Tantek> just by marking up the excerpt in the blog, and *not* the description
  226. [18:23:30] <mfbot> [[blog-post-brainstorming]] http://microformats.org/wiki?title=blog-post-brainstorming&diff=0&oldid=3658 * FuzzyBSc * (+381) Add partial-content blog use case
  227. [18:31:10] <fuzzyBSc> Some of the possible shifts in hAtom going forwards may start to depend on mfo directly. If atom:content elements are no longer considered opaque in the search for metadata such as atom:updated or atom:summary information mfo may have to be provided to avoid tripping over other microformats.
  228. [18:34:12] <fuzzyBSc> Hrmm.. on the other hand, if there are no conflicting definitions the problem dropps off significantly. The only reason I have seen it in practice is because of hCard title and hCalendar summary elements.
  229. [18:36:34] <_fil_> fuzzyBSc: I currently embed <a relTag> in my RSS "content" part, and process it accordingly, and it's magic
  230. [18:37:26] <Tantek> fuzzy, you don't need to worry about hCard and hCalendar and opaqueness, because by defintion when a parser encounters an hCard or hCalendar, it shouldn't look inside for any of its own properties
  231. [18:38:08] <fuzzyBSc> _fil_: I'm not sure I follow. Is this for partial feeds?
  232. [18:38:47] <fuzzyBSc> Tantek: So a hAtom parser should explicitly drop out when it sees those? That isn't currently codified in standard or xsl, but makes sense.
  233. [18:43:37] <Tantek> right
  234. [18:44:20] <Tantek> the reason I brought up mfo is because of exactly that -- it's not documented which other microformats, e.g. root class names, should act as opaque layers that other microformat parsers shouldn't parse "into"
  235. [18:44:52] <Tantek> thus for now, an hAtom parser has to look for an know that when it finds a class="vcard" or class="vcalendar" or class="vevent", that it should not look inside
  236. [18:44:52] <fuzzyBSc> ... and it isn't possible to future-proof parsers against new microformats.
  237. [18:44:57] <Tantek> precisely
  238. [18:45:06] <Tantek> and that's why i proposed the mfo-examples
  239. [18:45:33] <Tantek> if each such opaque microformatted chunk also included a class name to indicate the opacity, e.g. class="mfo vcard"
  240. [18:46:05] <_fil_> fuzzyBSc: I thought it was relevant to the discussion you're having now. My RSS parser does seek the relTags inside the "atom:content" part of the text, to extract tags-links
  241. [18:46:08] <Tantek> then an hAtom parser (and any other new microformat parser), could simply look for any element with class name of "mfo" and know not to parse inside it
  242. [18:46:24] <Tantek> yes, sometimes you *want* transparency
  243. [18:46:26] <Tantek> that's my point
  244. [18:46:34] <Tantek> you need to be able to control it
  245. [18:46:42] <Tantek> this is future proof
  246. [18:46:54] <Tantek> in that a parser can just look for "mfo" (or whatever name we come up with)
  247. [18:47:10] <fuzzyBSc> _fil_: Ahh, ok!
  248. [18:47:13] <Tantek> and that any new microformats which are supposed to be opaque, can also add the "mfo" class name to the root element of the data
  249. [18:47:30] <Tantek> and presto, you have forward/backward compatibility
  250. [18:47:48] <Tantek> and you avoid having to list a specific set of microformat root classes as "opaque"
  251. [18:48:38] <jibot> WildFox is Mr. KDOM. Co-author of kdom, ksvg and kcanvas.
  252. [18:48:49] * RobertBachmann (n=RobertBa@N137P031.adsl.highway.telekom.at) has joined #microformats
  253. [18:50:32] <fuzzyBSc> Tantek: It'd be interesting to think how this would interact with uf html classes becoming mainstream elements in a future html. If vcard was an element, would you still need to say <vcard class="mfo">...</vcard>, or would you prefer to say <mfo class="vcard">...</mfo>?
  254. [18:50:34] <_fil_> it's not clear if you should define opaque-ness OR transparency
  255. [18:51:18] <fuzzyBSc> _fil_: I think ideally what is defined is context. You have your vcard and its content... now what does it apply to?
  256. [18:51:44] <fuzzyBSc> Hrrm... or maybe that is you have your author and its vcard content.
  257. [18:52:02] <fuzzyBSc> Now what (which microformat) is it the author of?
  258. [18:52:36] <mfbot> [[media-info-examples]] N http://microformats.org/wiki/media-info-examples * Tantek * (+2263) first attempt at a simplified media info examples page
  259. [18:52:47] <_fil_> right now it would be the first mf that embeds this vcard
  260. [18:53:01] <Tantek> fuzzy, element names are overrated
  261. [18:53:05] <Tantek> you can only have one of them per element
  262. [18:53:07] <Tantek> so limiting. ;)
  263. [18:53:18] <Tantek> whereas (X)HTML classes you can have as many as you want per element
  264. [18:53:19] <fuzzyBSc> :)
  265. [18:53:29] <Tantek> I've often wondered if this is a fundamental flaw of XML.
  266. [18:53:37] <Tantek> the whole "only one element name" problem
  267. [18:53:55] <Tantek> which then forces people into very strange hierarchical contortions that often don't map very well to the actual underlying data models
  268. [18:54:20] <_fil_> Too many ppl think too ordered
  269. [18:54:25] <_fil_> actual data is fuzzy
  270. [18:54:30] <Tantek> and too hierarchical
  271. [18:54:38] <Tantek> sometimes the data is fuzzy
  272. [18:54:39] <fuzzyBSc> Well good xml practice usually teaches that the hierarchy of types that make up the element semantics are not part of the document. The parser should be reading "valid" XML.
  273. [18:54:47] <fuzzyBSc> It doesn't quite fit with good web practice :)
  274. [18:54:49] <Tantek> but by focusing on what people actually publish on *the Web*
  275. [18:54:59] <Tantek> we are able to find patterns of structure
  276. [18:55:26] <Tantek> this is why we emphasize real-world web publishing behavior so much
  277. [18:57:33] <mfbot> [[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3659 * FuzzyBSc * (+157) Add _fil_'s rel-tag-in-content usage
  278. [18:58:06] <fuzzyBSc> I don't know if I can build an opacity test case for hAtom.
  279. [18:58:42] <fuzzyBSc> I can put a vcard where one is not expected, but none of the class names line up, so it is already invisible.
  280. [18:59:15] <fuzzyBSc> Oh. Title would, and hcalendar's summary would.. but these will soon be excluded from hAtom.
  281. [18:59:28] <_fil_> fuzzyBSc: you can point to www.spip.net for the usage you just described
  282. [18:59:39] <fuzzyBSc> _fil_: ok.
  283. [19:00:02] <fuzzyBSc> _fil_: Any particular page?
  284. [19:00:27] <_fil_> not yet :)
  285. [19:00:43] <_fil_> but i just created a login so i can do it myself
  286. [19:00:57] <fuzzyBSc> _fil_: I'll leave it to you, then ;)
  287. [19:01:04] <mfbot> [[media-info-examples]] M http://microformats.org/wiki?title=media-info-examples&diff=0&oldid=3660 * Tantek * (+156)
  288. [19:09:47] <RobertBachmann> I think I've found a bug.
  289. [19:10:15] <mfbot> [[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3661 * FuzzyBSc * (+148) Add abstract as option for summary
  290. [19:12:04] <RobertBachmann> When we extract emails from a hcard like this: <a href="mailto:joe@example.com" class="email">joe's email</a> we should use the value of mailto:
  291. [19:12:34] <fuzzyBSc> To turn the whole atom:content issue on its head... you could consider the entire entry element atom:content. Perhaps it should all be made available for viewing in the feed reader box.
  292. [19:12:58] <Tantek> Robert, the attribute is still "href"
  293. [19:13:23] <Tantek> I believe hcard-parsing covers the email/mailto detail
  294. [19:13:28] <Tantek> Take a look
  295. [19:13:46] <RobertBachmann> will do. I'm a little bit slow today ;-)
  296. [19:14:15] <fuzzyBSc> The current implementation is always taking the visible text rather than the href.
  297. [19:14:33] <fuzzyBSc> If it is an anchor it should use the href instead, yes.
  298. [19:14:35] <Tantek> Robert, yes, it is right here: http://microformats.org/wiki/hcard-parsing#parsing_hCard_properties_and_values
  299. [19:14:44] * fuzzyBSc writes up a test case
  300. [19:14:52] <Tantek> Anyone writing hCard parsing code MUST read that page thoroughly.
  301. [19:15:12] <Tantek> fuzzy, you wrote: "To turn the whole atom:content issue on its head... you could consider the entire entry element atom:content. Perhaps it should all be made available for viewing in the feed reader box."
  302. [19:15:16] <Tantek> precisely!
  303. [19:15:26] <Tantek> "available for viewing" is the key piece here
  304. [19:15:36] <Tantek> the user doesn't care about some programmer's abstraction about metadata
  305. [19:15:45] <Tantek> the user just cares about *viewing* the *information*
  306. [19:16:05] <Tantek> whether it is the title, summary, description, entry data, when published etc.
  307. [19:17:22] <fuzzyBSc> Tantek: My feed reader displays the entry title in a list, separate to the content. That is also where it displays the date. Any metadata it knows how to extract gets thrown down the bottom, and content is placed in a scrollable panel.
  308. [19:17:54] <fuzzyBSc> Making the whole entry content would put all those things back into the panel. Good or bad, I don't know :)
  309. [19:20:28] * RobertBachman1 (n=RobertBa@M2455P005.adsl.highway.telekom.at) has joined #microformats
  310. [19:22:20] <RobertBachman1> fuzzryBSc: I'm already writting one.
  311. [19:22:58] * RobertBachmann (n=RobertBa@N137P031.adsl.highway.telekom.at) Quit (Nick collision from services.)
  312. [19:23:01] <fuzzyBSc> Robert: Ok.
  313. [19:23:31] * RobertBachman1 is now known as robertbachmann
  314. [19:32:32] <mfbot> [[to-do]] http://microformats.org/wiki?title=to-do&diff=0&oldid=3662 * Tantek * (+323) need to write naming-principles document
  315. [19:58:01] * robertbachmann (n=RobertBa@M2455P005.adsl.highway.telekom.at) Quit (Read error: 110 (Connection timed out))
  316. [19:58:11] * RobertBachman1 (n=RobertBa@M2470P023.adsl.highway.telekom.at) has joined #microformats
  317. [20:17:51] <Tantek> fuzzy, your feed reader could still extract the entry title, date etc. if that's the view you want. but by default it makes sense to display it all.
  318. [20:18:11] <Tantek> where they are displayed is merely a styling / presentational issue, not a structural / data format issue
  319. [20:18:12] <Tantek> that's the key
  320. [20:19:15] <KevinMarks> I dislike 'description' - that is legacy usage from the origins of RSS
  321. [20:19:22] <Tantek> it predates RSS
  322. [20:19:32] <KevinMarks> yes
  323. [20:20:13] <Tantek> already extremely well established with vCalendar, iCalendar, and RSS.
  324. [20:20:19] <Tantek> not going to change something that consistent now.
  325. [20:20:33] <KevinMarks> in those cases it makes sense
  326. [20:20:39] <KevinMarks> well, not rss so much
  327. [20:20:50] <KevinMarks> becasue in there it is describing something else
  328. [20:21:09] <KevinMarks> in classic rss it was describing the link being referred to for clickthrough
  329. [20:21:27] <KevinMarks> however, for blogs it is nto a description fo the blog post but the post itself
  330. [20:21:53] <KevinMarks> atom:content, that is
  331. [20:22:29] <KevinMarks> with atom you can have tite/summary/content for progressive revelation of more
  332. [20:23:08] <KevinMarks> but most feedreaders are built with the RSS ambiguity about whetehr there is more at the permalink or not
  333. [20:23:52] <KevinMarks> so we have a problem in mapping the 2-level model used in hCalendar and hReview to the 3-level model in Atom
  334. [20:25:49] <Tantek> Kevin, see IRC archives, there's already been a lot of discussion of that, including the very poor choice of "summary" as a name, since it is rarely used for that.
  335. [20:26:17] <KevinMarks> yes, I read scrollback
  336. [20:27:23] <KevinMarks> summary is also a poor name for the title
  337. [20:27:28] <KevinMarks> headline, maybe
  338. [20:28:49] <KevinMarks> MT and wordpress have long had separate entry boxes for summaries, or partials, but they are less-used
  339. [20:29:10] <KevinMarks> the other thing MT does is the 'show the beginning, and have a 'read more' link
  340. [20:29:39] <KevinMarks> which would imply you could have a 'partial' and a 'full' that overlap
  341. [20:31:24] <mfbot> [[hatom-issues]] http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3663 * FuzzyBSc * (+549) Why not use whole atom:entry as content?
  342. [20:32:32] * KevinMarks (n=Snak@pdpc/supporter/active/kevinmarks) Quit (Read error: 104 (Connection reset by peer))
  343. [20:32:32] <fuzzyBSc> Kevin: The suggestion is that this might be the common case for any explicit atom:summary... that it is really an extract rather than an abstract.
  344. [20:34:36] * KevinMarks (n=Snak@h-68-164-81-209.snvacaid.dynamic.covad.net) has joined #microformats
  345. [20:36:31] <fuzzyBSc> Kevin: The suggestion is that this might be the common case for any explicit atom:summary... that it is really an extract rather than an abstract.
  346. [20:36:42] <KevinMarks> great time for a powercut
  347. [20:36:46] <KevinMarks> what was the last you got from me?
  348. [20:36:51] <fuzzyBSc> Atom allows for either, perhaps with good reason.
  349. [20:37:03] <fuzzyBSc> Kevin: "which would imply you could have a 'partial' and a 'full' that overlap"
  350. [20:38:59] <KevinMarks> my thought is that if we have semantic overlap we should add clarification
  351. [20:39:15] <KevinMarks> distingush extract and abstract
  352. [20:41:28] <KevinMarks> I got no responses after tantek saying 'see archives'
  353. [20:41:36] <KevinMarks> so if I missed a slice, my apologies
  354. [20:42:14] <fuzzyBSc> So a hAtom entry conceptually looks like this: <atom:entry><atom:title>...</atom:title>[<atom:summary-abstract>...</atom:summary-abstract>]<atom:content>...[<atom:summary-extract>...</atom:summary-extract>]...</atom:content></atom:entry>, with metadata spread liberally throughout?
  355. [20:43:00] <_fil_> t's what I do in fact
  356. [20:43:57] <KevinMarks> well, that will break the mapping back to Atom unless you amke it clear that you can have only one of abstract/partial
  357. [20:44:19] <KevinMarks> or that abstract trumps partial in coonverting to atom
  358. [20:44:55] * fuzzyBSc nods
  359. [20:47:09] <KevinMarks> http://intertwingly.net/wiki/pie/PaceContentAndSummaryDistinct2 is what I recall
  360. [20:47:13] <KevinMarks> let me check the RFC
  361. [20:48:25] <KevinMarks> "The "atom:summary" element is a Text construct that conveys a short
  362. [20:48:25] <KevinMarks> summary, abstract, or excerpt of an entry.
  363. [20:48:25] <KevinMarks> "
  364. [20:49:09] <KevinMarks> not sure what the semntic distinction between 'sumamry' and 'abstract' is in that context
  365. [20:49:28] <fuzzyBSc> My current thinking would write that as <div class="entry"><h3 class="summary">...</h3>[<div class="abstract">...</div>]<div class="description">...[<div class="extract">...</div>]...</div></div>, but summary is confusing to atom developers as tantek has pointed out and description is confusing to rss developers as you pointed out.
  366. [20:50:18] <KevinMarks> rss2 says
  367. [20:50:32] <KevinMarks> description: ithe item synopsis
  368. [20:51:17] <fuzzyBSc> :)
  369. [20:51:30] <fuzzyBSc> That rss 2.0 doesn't go into a whole lot of detail, does it?
  370. [20:51:32] <Tantek> RSS2 is more about practice than what is specified though.
  371. [20:51:34] <KevinMarks> nope
  372. [20:51:38] <KevinMarks> indeed
  373. [20:51:47] <Tantek> thus description = full content in practice
  374. [20:51:58] <KevinMarks> so my point is that Atom clears up one semantic confusion
  375. [20:52:02] <Tantek> which is the same practice as found in vCalendar/iCalendar
  376. [20:52:11] <KevinMarks> distinguishing full/partial
  377. [20:52:23] <Tantek> Kevin, no one is arguing that we shouldn't make that distinction.
  378. [20:52:26] <KevinMarks> but not distingusging abstract and extract
  379. [20:52:37] <Tantek> well that on the otherhand is totally not 80% ;)
  380. [20:53:20] <KevinMarks> no, I'm reflecting back your point
  381. [20:53:28] <Tantek> in addition, the goal here is NOT to try to redo/improve Atom's semantics
  382. [20:53:52] <Tantek> however, the process Atom went thru for naming elements/properties was insufficient for microformats
  383. [20:54:06] <Tantek> (and scroll-back is insufficient, unless you scrollback about 2-3 days worth ;)
  384. [20:54:13] <KevinMarks> I did
  385. [20:54:20] <KevinMarks> and read the email threads
  386. [20:54:24] <Tantek> cool
  387. [20:54:30] <fuzzyBSc> Interestingly, that page uses excerpt as well.
  388. [20:55:01] <Tantek> currently, fuzzy and I are considering both "partial-description" and "excerpt" as alternatives to "atom:summary" as far as a name
  389. [20:55:02] <Tantek> fuzzy has documented this on the wiki
  390. [20:58:05] <KevinMarks> http://www.imc.org/atom-syntax/mail-archive/msg01153.html
  391. [20:58:18] <KevinMarks> which failed...
  392. [20:58:34] <KevinMarks> http://www.intertwingly.net/wiki/pie/ContentMustHaveRel
  393. [21:01:36] <KevinMarks> the mapping is interesting here in the blog
  394. [21:02:02] <KevinMarks> because if you have an extract, the natural markup is to use a span round it
  395. [21:02:12] <KevinMarks> as it is a subset fo the post
  396. [21:02:39] <KevinMarks> but if you do have an abstract, it appears at the top of the post, and is a distinct piece of text
  397. [21:02:50] <_fil_> remember the user will generally not want to edit a summary by hand
  398. [21:03:20] <KevinMarks> in Atom, duplicating the extract in another element is an outcome of the hierarchical thinking XML mindset
  399. [21:03:41] <_fil_> it's also good for reducing bandwidth, don't forget
  400. [21:03:53] <KevinMarks> and doing that in HTML would be odd, and require you to explicitly hide it
  401. [21:03:58] <_fil_> (but this can be done otherwise)
  402. [21:04:26] <fuzzyBSc> A wysiwyg editor could allow someone to simply select some text and click "excerpt".
  403. [21:05:07] <fuzzyBSc> _fil_: That is something hAtom won't be able to do on its own. If you want a partial-text feed to reduce bandwidth you'll have to publish as two separate html pages.
  404. [21:05:40] <KevinMarks> it's genreally nto about reducing bandwidth, it's about getting ad impressions from the full page
  405. [21:07:24] <_fil_> when you get 800.000 hits a day on your feed, you want to reduce bandwidth :)
  406. [21:07:27] <fuzzyBSc> An interesting follow-through on the excerpt bizzo is that you might start seeing them added to blocks around the main content in larger fonts, magazine-style. You would have to be careful that the two concepts of excerpts don't get confused.
  407. [21:07:37] <_fil_> otherwise, you're right, no worry
  408. [21:08:16] <fuzzyBSc> _fil_: With that much attention you are probably still worried about your ad-words ;)
  409. [21:08:17] <KevinMarks> right, but the explanations I've seen for partials have been to do with funding
  410. [21:09:04] <_fil_> that's not the way I use them myself. My issue is that I usually deal with very long (magazine) articles
  411. [21:09:06] <fuzzyBSc> A site that big has to make money somehow or will go off the air no matter how summarised the content is.
  412. [21:09:37] <_fil_> fuzzyBSc: it's not really attention I get, but blind hits
  413. [21:09:52] <KevinMarks> eg http://www.janegalt.net/blog/archives/005113.html
  414. [21:10:07] <_fil_> my rss feed has been included in the standard Mac OS X list of RSS feeds when you install the French version of Tiger/Safari
  415. [21:10:27] <_fil_> maybe 0.1% of these hits actualy result in "visits" (by humans)
  416. [21:10:39] <_fil_> I have yet to find the time to analyse the data
  417. [21:11:55] <fuzzyBSc> _fil_: Ouch.
  418. [21:12:01] <mfbot> [[hatom-issues]] M http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3664 * Tantek * (+1782) Added some feedback and clarifications.
  419. [21:13:48] <_fil_> it's kind of a free advertising, but not *that* free given the time I spent fortifying the server :)
  420. [21:14:42] <KevinMarks> hm
  421. [21:29:54] <RobertBachman1> fuzzyBSc: I've commited a new version with better handling for email addresses.
  422. [21:47:25] <fuzzyBSc> Robert: Cool. Should that check for img be looking at @title instead? I thought the result of recent microformats-discussion emails was that alt should be reserved for graphic-impaired humans.
  423. [21:48:13] <fuzzyBSc> Also, the value-of template doesn't yet support img in this way. Should it?
  424. [21:51:07] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
  425. [21:54:56] <RobertBachman1> According to http://microformats.org/wiki/hcard-parsing#parsing_hCard_properties_and_values the check is correct.
  426. [21:55:38] <RobertBachman1> AFAIK the recent discussion about @alt vs. @title lead to no change.
  427. [21:55:51] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  428. [21:55:53] <fuzzyBSc> Hrmm.. ok.
  429. [21:55:59] <Tantek> Robert, Fuzzy, that's correctt
  430. [21:56:23] <Tantek> because the alt is *supposed to be* the *user-visible* text description of what is in the image graphic
  431. [21:57:35] <Tantek> so far, the *only* use of the 'title' attribute in microformats is specifically with <abbr>, and there, *only* when the human and machine readable versions of the information cannot be reconciled
  432. [21:58:46] <fuzzyBSc> Tantek: Is there no general interpretation of img at this stage, or is it always interpreted to @alt for existing microformats?
  433. [21:59:40] <Tantek> There is.
  434. [22:01:01] <Tantek> 'alt' attribute by default for a property value
  435. [22:01:38] <RobertBachman1> Tantek: http://microformats.org/wiki/hcard-parsing#parsing_hCard_properties_and_values says "For all properties, when the element for a property is: <abbr>: use the value of the 'title' attribute."
  436. [22:01:44] <Tantek> for properties which take a value of type URL/URI, then use the 'src' attribute
  437. [22:01:53] <Tantek> Robert, correct
  438. [22:01:56] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
  439. [22:02:13] <fuzzyBSc> Ok, committed.
  440. [22:02:16] <Tantek> but we seek to minimize use of <abbr> in that way
  441. [22:02:31] <Tantek> fuzzy, the use of img alt vs. src is documented in hcard-parsing
  442. [22:02:39] <Tantek> like I said, definitely read that doc thoroughly :)
  443. [22:02:49] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  444. [22:03:32] <Tantek> Kevin Marks wrote: MT and wordpress have long had separate entry boxes for summaries, or partials, but they are less-used
  445. [22:03:36] <Tantek> indeed
  446. [22:03:51] <Tantek> those separate entry boxes are DEFINITELY not 80/20
  447. [22:04:02] <Tantek> hardly anyone I know uses them ever
  448. [22:04:15] <Tantek> heck, I'd prefer if they were hidden/concealed in the UI by default
  449. [22:05:10] <Tantek> IMHO that kind of feature / user interface addition is the kind of thing you start seeing more and more of in "bloated" applications/interfaces.
  450. [22:05:35] <Tantek> exactly the kind of thing we explicitly seek to avoid in microformats
  451. [22:13:00] <fuzzyBSc> Tantek: I'm not 100% clear. If we want an email address and are not on an <a href> element, do we fall back to URI handling and also cut off the mailto: or do we give up?
  452. [22:13:16] <fuzzyBSc> (or do we fall back to regular property handling?
  453. [22:13:21] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
  454. [22:14:15] <fuzzyBSc> Oh. Fall back to regular property handling I think.
  455. [22:15:34] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  456. [22:22:19] <Tantek> fuzzy, right
  457. [22:24:53] <fuzzyBSc> tantek: "if the element for a property has one or more children with a class name of "value"..." does that mean direct children as per xpath, or descendant as per xpath?
  458. [22:25:37] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
  459. [22:26:52] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  460. [22:30:04] <mfbot> [[hatom-issues]] M http://microformats.org/wiki?title=hatom-issues&diff=0&oldid=3665 * Tantek * (+2333) more feedback edits/corrections
  461. [22:31:20] <Tantek> fuzzy, in practice it has been only direct children
  462. [22:31:31] <Tantek> but we could consider making it descendant
  463. [22:31:49] <Tantek> i would ask you to find a real world example that appears to require descendant first ;)
  464. [22:31:56] <mburns> can i have a <a href="" rel="licenese nofollow"></a> to indicate that 1. it links to my license and 2. spiders should not give it weight for my linking?
  465. [22:32:23] <mburns> put another way, can I stack rel tags and have them both be honored
  466. [22:33:03] <fuzzyBSc> tantek: :) I'm happy to leave it as child.
  467. [22:33:12] <Tantek> mburns, please see definition of rel in HTML4
  468. [22:33:17] <Tantek> and linktypes for that matter
  469. [22:33:23] <Tantek> this is an RTFM FAQ. thanks.
  470. [22:33:31] <Tantek> fuzzy, ok
  471. [22:33:54] <Tantek> fuzzy, and yes, i deliberately made it children to make it more restrictive for now, until someone finds a real world use case and raises an issue with it
  472. [22:38:39] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
  473. [22:39:49] <KevinMarks> mburns: the answer is 'yes, you can'
  474. [22:39:50] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  475. [22:41:27] * KevinMarks (n=Snak@pdpc/supporter/active/kevinmarks) Quit ("bye")
  476. [22:52:53] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Excess Flood)
  477. [22:53:06] <fuzzyBSc> Tantek: In addition to the hCard-parsing instructions I am currently doing normalise-space on any input. Tools like tidy tend to introduce newlines at inopportune places, and they aren't always ignored by atom parsers.
  478. [22:53:34] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  479. [22:56:28] <mburns> thank you.
  480. [22:59:54] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) Quit (Read error: 104 (Connection reset by peer))
  481. [23:00:29] * Atamido (n=atamido@user-0ccsqt9.cable.mindspring.com) has joined #microformats
  482. [23:00:30] <jibot> WildFox is Mr. KDOM. Co-author of kdom, ksvg and kcanvas.
  483. [23:10:15] <RobertBachman1> http://microformat.org? Does anybody know this site?
  484. [23:10:20] * t1m (n=t1m@pool-151-199-47-177.bos.east.verizon.net) Quit (Read error: 110 (Connection timed out))
  485. [23:10:34] * RobertBachman1 is now known as RobertBachmann
  486. [23:19:57] <Tantek> Robert, oh wow, they used to be an another attempt to define their own microformats, but now they appear to be pointing to microformats.org for the formats, and have morphed into a tool.
  487. [23:21:40] <Tantek> Please visit Microformats.org to learn more about Microformatting.
  488. [23:21:40] <Tantek> Microformat.org runs a template engine service to make it easier to blog with microformats. (Coming Soon)
  489. [23:21:43] <Tantek> "
  490. [23:37:23] * factoryjoe (n=cmessina@adsl-71-139-210-182.dsl.snfc21.pacbell.net) has joined #microformats
  491. [23:37:23] <jibot> factoryjoe is Chris Messina, works for Flock, Bar Camp and Rhyzomatic and is working towards open source world domination
  492. [23:57:37] <RobertBachmann> Tantek: Hit this site accidently. However seems like there's not much going on there.

These logs were automatically created by mflogbot on chat.freenode.net using a modified version of the Java IRC LogBot.

See http://microformats.org/wiki/mflogbot for more information.