Kevin, On Sat, 2005-12-31 at 15:48 -0800, Kevin Marks wrote: > On Dec 27, 2005, at 3:43 PM, Tantek Çelik wrote: > > This means working deliberately to avoid the two cardinal sins that > > namespaces typical both enable and encourage: > > 1. The same term is used to mean two different things > > 2. Two terms are used to mean the same things > Indeed. In fact this is one of the advantages of Atom over RSS - > resolving ambiguous usage. > In RSS 'description' is used for both summary and full-content feeds. > Atom defines distinct 'summary' and 'content' elements for this
I have suggested a possible naming on the hAtom-issues page that I would like to see debated with a view to replacement or acceptance. I think this fits in reasonably well with early uses of the terms involved, and the equivalence is as follows: atom:title = hAtom summary atom:summary = hAtom description atom:content = hAtom content The disabmiguation between atom:summary and atom:content is still afforded because there is a clear 1:1 relationship to atom's terminology. Summary is already used by iCalendar-derived specifications such as hCalendar and hReview to mean what I believe atom:title means. Description can trace its roots both VJOURNAL and RSS, where I think they were originally intended to mean a short description of content somewhere else or of an event that has occured. I think it was overrun by the popularity of full-text syndication which created the ambiguous meaning we know today from rss. I think that content is still a valid and appropriate new term introduced by atom which could be used in similar ways by future microformats. My association with the histories of syndication formats is not close enough for me to really see whether this proposal is a good one or not. I think it meets the basic technical merits, but I would like to get some gut reactions from those with more experience in the subject domain. > In RSS 'link' is used for both 'entry permalink' and 'external linked > element from a brief entry'. I believe this is a resolved issue in hAtom. See <http://microformats.org/wiki/hatom-issues#Why_rel.3D.22link.22_.3F>. Do you feel this requires further resolution? Tantek has pointed out that choosing names for hAtom elements that differ from those of corresponding atom elements is not necessarily a bad thing. The technological imperative is to ensure there is a correspondance between hAtom and atom elements. Perhaps it is indicative of his exitement about hAtom that he made the following comments in irc the other night[1]: [19:24:25] <Tantek> one thing to keep in mind re: atom vs. hAtom authors, once we have solidified hAtom, it is quite likely that hAtom may become the largest source of Atom on the web * [19:24:55] <Tantek> for the same reasons that hCard is becoming the largest source of vCards on the web * [19:25:00] <Tantek> and so forth * [19:25:15] <Tantek> it's easier to author/publish than a separate file with a separate mime-type etc. * [19:25:41] <Tantek> thus it is more important for microformats to get things right, than it was for various independent/individual XML formats ... * [19:32:51] <Tantek> naming things is one of the hardest things to do well, especially in the context of existing work * [19:33:10] <Tantek> and even then, especially in the context of several existing works * [19:34:05] <Tantek> BTW, my understanding of the Atom process for naming was to pick the names that made the most sense on their own in Atom. There was no attempt (AFAIK) to reuse names of elements or properties from existing standards. * [19:35:02] <Tantek> Thus it should not surprise us that hAtom will likely have different names than Atom, since hAtom, as a microformat, is focussed on reusing pre-existing names, whereas Atom did not. Noone is dissing the hAtom standard. It was developed by smart people who knew what had to be done to fix the semantics of syndication on the Internet. The suggestion here is that syntax, naming and a few other issues may need to be tweaked in order to apply atom to the microformat world. Atom's semantics and scope should still be the grounding for any microformat syndication model. At the present this is a question about names, not meanings. Noone wants to re-do the work of atom standardisation. > That said, 'title' is context-defined in Atom - it can mean 'feed > title' or 'entry title'. I have raised the issue of whether the completion of hAtom depends on the completion of mfo or not[2], but at this stage I think the answer is "no". hAtom parsers and publishers should take heed of it if mfo reaches maturity, but hAtom currently defines its own opacity behaviour. I have raised another issue[3] that might still influence this question, though. If the possibility of overlapping definitions for terms can be excluded from the scope of mfo then its sole responsiblity becomes completing the triple. You have a predicate in the form of a html class. You have your object as the content of the classified node. The question is, "what subject does this assertion apply to?" > So I would suggest 'entry-title'. I (and I presume others) would welcome specific suggestions being added to the hAtom issues page. -- Benjamin Carlyle <[EMAIL PROTECTED]> [1] http://rbach.priv.at/Microformats-IRC/2005-12-31 [2] http://microformats.org/wiki/hatom-issues#mfo [3] http://microformats.org/wiki/hatom-issues#Opaqueness_of_summary_and_content _______________________________________________ microformats-discuss mailing list [email protected] http://microformats.org/mailman/listinfo/microformats-discuss
