On 10/28/05, Thomas Broyer <[EMAIL PROTECTED]> wrote: > > Luke Arno wrote: > > > > On 10/27/05, James M Snell <[EMAIL PROTECTED]> wrote: > >> > >> Your proposal says, > >> > >> The title of an APP collection will be the title of the > >> XHTML anchor or link with rel='entry' or 'generic' pointing > >> to the collection's primary feed. > >> If these are not present then it will be the text of the > >> anchor (if it is an anchor). > >> If these are not present then the contents of the > >> element within the collection (but not within a nested > >> collection) with a class name of collectionTitle > >> will be considered the name of the collection. > >> If none of these exist, it is highest ranking heading element > >> within the collection container. > >> If none of these exist, it is simply an unnamed collection. > >> > >> Does that mean that if the contents the anchor (or collectionTitle, etc) > >> contains additional markup (e.g br tags) that markup is part of the > >> title of the collection? > >> > > > > "Contents" means what you would get from an xsl:value-of: > > concatenation of text node descendants. > > How about an xhtml:img? As an XHTML writer, I'd expect the title attribute > to be used, or if not present, the alt attribute. > Or maybe, as Eric pointed it out, use the title attribute as a short > description and the alt as the title of the collection? >
That is an interesting thought. I think I have to make the profile itself a little less flexible so that parsers/writers have less to consider, though. > I'm sorry but I can't buy your argument about XHTML "parseability". > What makes you think it is so hard? Like I said, the profile probably *does* offer too many options at this point. This is not a limitation of microformats however, but my crappy profile. Further iterations will be much better. > And I'm still not convinced an introspection document has to be > displayable in a browser… > TypePad/Blogger/etc. will probably tell you "point your AtomPP client to > http://…"; > Of course it does not *have* to be. I just want to see us weigh out the specific pros and cons and decide when we are informed. It looks great from where I am sitting now, but I am open to specific costs that I may have overlooked. That said, I believe Mark Pilgram, Brian Suda, Bud Gibson, and Tantek Celik that parsing is no big. I will be a very surprised if that is a real issue. We should definitely have a sample parser before putting it in the spec, though. That is just the responsible thing to do. - Luke
