Re: [uf-discuss] hAtom draft - class=title
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
Re: [uf-discuss] hAtom draft - class=title
Ryan, On Thu, 2005-12-29 at 23:47 -0600, Ryan King wrote: ...I believe that context and specific rules on opacity are sufficient for making thing unambiguous. Admittedly, with microformats we tend to walk a fine line here, but its not without reason- we're trying to optimize for publishers- which mainly includes geeks who hand-write html in textareas and web developers/ designers. Is it your position that hAtom's title class can have a different meaning to hCard's title, and that hAtom's summary class can have a different meaning to hReview's summary class? Is it your position that opacity will allow for classes to have different definitions depending on scope? Tantek, is this your position also? Does anyone need more time or more direct discussion to consider the question? If this is carried through, hAtom should be able to stay as it is and may be ready for promotion and use as it currently exists. It may be important to define which class names have a globally-understood meaning and which have context-sensitive meaning. If this trajectory is carried through, I would suggest that top-level microformat names such as vcard, feed, rel=tag, and the like should all have immutable definitions that cannot be used in other microformats. A parser looking for vcards on a page should be able to find them even though they are embedded in in hAtom author contexts. Child elements of these top-level microformats could change in definition according to context, including summary and title. Parsers could not go searching for them except within the appropriate contexts. All parsers should recognise whatever the mfo class eventually gets transformed into and not assume familiar class names within those scopes are understandable, except for top-level microformats. Would all of the experienced microformatters be happy with this resolution? -- Benjamin Carlyle [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft - class=title
On 12/31/05 1:58 AM, Benjamin Carlyle [EMAIL PROTECTED] wrote: Ryan, On Thu, 2005-12-29 at 23:47 -0600, Ryan King wrote: ...I believe that context and specific rules on opacity are sufficient for making thing unambiguous. Admittedly, with microformats we tend to walk a fine line here, but its not without reason- we're trying to optimize for publishers- which mainly includes geeks who hand-write html in textareas and web developers/ designers. Is it your position that hAtom's title class can have a different meaning to hCard's title, and that hAtom's summary class can have a different meaning to hReview's summary class? Is it your position that opacity will allow for classes to have different definitions depending on scope? Tantek, is this your position also? No. Like I said[1], this is one of the two most common mistakes that namespaces both enable and encourage. [1] http://microformats.org/discuss/mail/microformats-discuss/2005-December/002 498.html 1. The same term is used to mean two different things 2. Two terms are used to mean the same things The current established microformats have avoided this problem by essentially reusing from earlier microformats when possible, *before* reusing from other standards. One problem with most standards committees that design a new format is that they are typically focused only on that one format, and often pick a new vocabular instead of acknowledging previous vocabularies and attempting compatibility. That's not the microformat way. We don't invent new terms when unnecessary. Similarly, we prefer terms from older more established standards than newer standards. And by the way, one of the ways to optimize for publishers is to make the overall vocabulary of microformats easy to understand and use. Sticking with one term = one meaning (and vice versa) makes this much easier. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft - class=title
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 In RSS 'link' is used for both 'entry permalink' and 'external linked element from a brief entry'. The current established microformats have avoided this problem by essentially reusing from earlier microformats when possible, *before* reusing from other standards. E.g. hReview has reused a lot from hCard and hCalendar. See http://microformats.org/wiki/existing-classes for an overview. In the case of 'title', Paul is right. hCard (by way of vCard) has defined 'title' to mean something in particular. In the case of hReview, we used 'summary' from hCalendar to serve this purpose. Would it be possible to do so for hAtom as well? I would say that letting hCard use a bare 'title' to mean 'honorific form of address' was possibly a mistake in retrospect, but it is established. That said, 'title' is context-defined in Atom - it can mean 'feed title' or 'entry title'. Replacing this with 'summary' would be a mistake, as that needlessly blurs the summary/content distinction which is important for authors, readers and parsers alike. I think keeping 'summary' and 'content' are good. hReview's and hCalendar's 'summary' is IMO not really a title in the atom/rss sense, but a one-line abbreviated form. So I would suggest 'entry-title'. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft - class=title
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 In RSS 'link' is used for both 'entry permalink' and 'external linked element from a brief entry'. The current established microformats have avoided this problem by essentially reusing from earlier microformats when possible, *before* reusing from other standards. E.g. hReview has reused a lot from hCard and hCalendar. See http://microformats.org/wiki/existing-classes for an overview. In the case of 'title', Paul is right. hCard (by way of vCard) has defined 'title' to mean something in particular. In the case of hReview, we used 'summary' from hCalendar to serve this purpose. Would it be possible to do so for hAtom as well? I would say that letting hCard use a bare 'title' to mean 'honorific form of address' was possibly a mistake in retrospect, but it is established. That said, 'title' is context-defined in Atom - it can mean 'feed title' or 'entry title'. Replacing this with 'summary' would be a mistake, as that needlessly blurs the summary/content distinction which is important for authors, readers and parsers alike. I think keeping 'summary' and 'content' are good. hReview's and hCalendar's 'summary' is IMO not really a title in the atom/rss sense, but a one-line abbreviated form. So I would suggest 'entry-title'. Hi Kevin, (1) There'll still be a dual use for the name summary, so we really have to establish whether this is going to be kosher or not. I'm cool if it's not ... if it's an enumerated design goal of the microformats community. From my POV, this is the only major sticking point to making a change (or not) is this point. (2) 'entry-title' is cool with me, but my feeling was that this is explicitly resolved by context; that is, title appearing within a entry is an EntryTitle, whereas title appearing within a feed but not within an entry is a FeedTitle. This is fairly easy to resolve in an XPath sense and using DOM manipulation as I do in Python, and is the same rule Atom uses. (3) Note that opacity is the only real way to stop meaning conflicts in a meaning sense. For example, what if someone included a hCalendar object within a hReview ... I saw this concert and this is what I thought of it, here's the schedule for the other nights the band is playing in town? We'll still have multiple summary elements floating about. (4) Happy New Years everyone! I'm off to party. And jeez, Benjamin, shouldn't you be in bed by now? Unless you're not where your extension says you are! Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft - utility of feeds
On Wed, 2005-12-28 at 17:10 -0500, David Janes -- BlogMatrix wrote: I notice that Tantek has placed a generic opaque container as a potential idea onto the blog. If multiple feeds per page is OK with all and a generic opaque container is available, then we get it for free. I'll try to share some of my thinking on the opacity question: Opacity is required when: 1. There is a uf element that I think I understand, but may have a definition that differs from mine. 2. There is a uf element that I think I understand, but it may not apply to my context. It may apply to a context that I do not recognise and have skipped over. Opacity (identified nesting generally, in fact) could be about solving the problem of applying context to complete a triple, or about providing a walled garden over which common definitions do not apply, or about both. Microformats already make use of nesting that can only be understood if you are a parser of that microformat, and annotates each nested level with at least one type (vcard, vcalendar, etc). I have a quick mapping of the potential solution space: == Different Definitions, aka naming the type == 1.1 Do not permit different definitions of the same term 1.1.1 Hold old microformat definitions valid until they pass out of common use + Definitions are stable, new versions of old ufs are not created - The set of terms may become more esoteric than necessary when the most widely-understood usage of a term is barred in favour of an older and less widely-understood one 1.1.2 Review the validity of old definitions from time to time and widen or replace them with more appropriate definitions +/- inverse of keeping definitions valid Possible mitigating strategies: * Start with esoteric names such as vcard-title rather than title, or reviewer rather than author (of a review). Move to more mainstream names only when it is proven across several microformats to be widely-understood. Parsers accept both esoteric and mainstream names until esoteric ones pass out of common use. 1.2 Permit different definitions. Opacity is required to avoid tripping over elements that appear to signify something they do not. - Opacity is no longer a matter of completing the triple using context. It is also a boundary of understanding. What can you rely on? title? author? vcard? It may be important to specify which definitions are fixed, and which movable. - Without a boundary of understanding in place users would be able to define arbirary contexts to allow author, contributor, and the like to be applied to individual documents. This might not directly affect parsing. Consider the atom entry concept. It may not have to exist if it were always clear what an atom author applied to. Likewise, one might mark up a hreview of hcard in the hAtom style. All that would be needed would be to add mfo to a div and insert further metadata relating to that div. - Harder to use css? == Different Contexts, aka completing the triple == 2.1 Define global ruleset for context 2.1.1 Applies to parent context (mfo) but not children of that context +/-? 2.1.2 Applies to parent context and child mfos + Good for author, contributor 2.1.3 Applies only to child mfos of the element +/-? 2.2 Define a per-element ruleset for context + Allow author to be defined differently to ??? 2.3 Allow individual element instances to identify context + Allow the whole triple to be defined in one place, foo is author of bar - More complicated... triples don't seem to match human prose well. Back to the subject of hAtom, I think the terminology issue has to come to a head if forward momentum is to be maintained. It would be nice to get a resolution to that as early as possible in the mfo process. Will there be divergence in definitions? If not, who will budge? What should the strategy be going forwards? I think this will rely on the people involved getting as face-to-face as possible for a few hours at some point :) -- Benjamin Carlyle [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft - class=title
On Thu, 2005-12-29 at 08:06 -0500, David Janes -- BlogMatrix wrote: I'm fairly happy with the way things are named in hAtom right now: anyone familiar with weblogs and/or Atom will immediately recognize all the elements. The one (so far) variance is rel=bookmark, which is defined in HTML so that's cool. I'm waiting for someone to express a stronger opinion or principle on how elements should be named, preferably with a reference to a Wiki page listing it. At this point, there's serious proposals to rename 75%+ of the elements in hAtom, which means hAtom won't look very Atomish at all! However, if there's a consensus, that's the way it goes. I would back this with the observation that the atom standardisation process suggests that the terms in use are widely accepted and understood. Stepping away from them may be stepping into esoterica. I understand that on one hand you want to maintain compatability with existing implementations by protecting the current namespace. On the other hand, you'll never have a smaller installed base than you do today. Opacity might allow for a resolution, but using identified scoping in that way has its own problems. Unless an experienced microformatter is able to take a stand based on solid experience, I don't think this will be solved via email. -- Benjamin Carlyle [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft - class=title
On Dec 29, 2005, at 7:06 AM, David Janes -- BlogMatrix wrote: I'm waiting for someone to express a stronger opinion or principle on how elements should be named, preferably with a reference to a Wiki page listing it. At this point, there's serious proposals to rename 75%+ of the elements in hAtom, which means hAtom won't look very Atomish at all! However, if there's a consensus, that's the way it goes. I assume you're referring to the suggestion that elements get prefixed with atom- and/or entry- I have a couple of responses to this idea (which I think I've already gone over on this list, but anyway...): First, its just ugly. I just want to say 'entry,' not 'atomentry.' Second, I believe that context and specific rules on opacity are sufficient for making thing unambiguous. Admittedly, with microformats we tend to walk a fine line here, but its not without reason- we're trying to optimize for publishers- which mainly includes geeks who hand-write html in textareas and web developers/ designers. I'm sure I have other responses, but can't think of them right now (they're probably in the archive somewhere). -rk -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft - class=title
Paul Bryson wrote... I'm just looking for extra confirmation of this little problem before touching the wiki. It appears that hAtom uses the class attribute title for it's title, such as what would go in a heading hn However, the hCard also uses title, but in a completely different context. Here is an example of what I am trying to do. http://files.commo.de/md-lite/mdforum/topic-combined-2.html Atamido ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft - class=title
Paul Bryson wrote: David Janes -- BlogMatrix wrote... Nice. I just discovered a bug in my parser that screwed up the title nesting. Here's [1] the new and improved version. Does your parser fill the Author from the hCard's FN/NICKNAME field? I am curious if it would, given that the hCard should be opaque, but it is also the Author. The author is opaque in that hAtom is not looking for further hAtom elements within that element. However, hAtom does know that this element is a hCard and parses it as a hCard. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft - class=title
Paul Bryson wrote: You'll want to move class=logo from the li down to the img where it belongs though. Done. Is it required to be in an IMG only, or can the IMG act as another element's value (as I had it previously). You should be able to now convert the Date Posted into a nice published element. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft - class=title
David Janes -- BlogMatrix wrote ... The author is opaque in that hAtom is not looking for further hAtom elements within that element. However, hAtom does know that this element is a hCard and parses it as a hCard. Ah, that explains a lot. Thanks. Atamido ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft - class=title
David Janes -- BlogMatrix wrote... You should be able to now convert the Date Posted into a nice published element. It isn't already? Honestly, in production I'm not sure that I will have access to the date in an ISO format. I will include it though for the example. I'm not a fan of how things are laid out around the published element, but I guess it probably doesn't matter to much. It is a shame that we cannot use dtpublished to keep with what has already been pulled from hCard and hCalendar. Atamido ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
On Dec 20, 2005, at 7:44 AM, Benjamin Carlyle wrote: David, On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote: Have at it: http://microformats.org/wiki/hatom I'm currently doing some work based on Luke Arno's hAtom2Atom.xsl to get my feed reader of choice (liferea) to parse hAtom sites. I currently have the xsl scraping the html page for each entry in order to fill out author details when they are not present in the entry itself. I first search the entry proximity, then start back at xpath / if none are found. This is in line with the Entry Author heading in the microformat[1] which states: if an Entry has 0 Entry Athor elements, the logical Entry Author is assumed to be the author of the XHTML page Looking at the required feed[2] and entry[3] elements from atomenabled.org it seems that only id, title, and updated are required in each. Is this a mismatch with the standard, or is my understanding of the hAtom spec mismatched? I think the point of this is that in html we have a way of determining an author, without the help of hAtom (ie, address + hcard). Reading the information from that atomenabled.org I'm inclined to write the parser as only placing author and contributor elements in an entry when they appear in the hAtom html within an entry. If author and contributor fields were only to be found at the feed level I would only repeat them there in the atom output. Is my inclination reasonable? That would make any atom feed reader responsible for making the association between a feed with a particular author an each entry having a particular author rather than the transform... I'm not sure I follow what you're saying here. Are you saying that when you transform to Atom, you're inclined to replicate the author information on every entry? -rk -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
- Original Message - From: Benjamin Carlyle [EMAIL PROTECTED] To: Microformats Discuss microformats-discuss@microformats.org Sent: Tuesday, December 20, 2005 10:44 AM Subject: Re: [uf-discuss] hAtom draft David, On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote: Have at it: http://microformats.org/wiki/hatom I'm currently doing some work based on Luke Arno's hAtom2Atom.xsl to get my feed reader of choice (liferea) to parse hAtom sites. I currently have the xsl scraping the html page for each entry in order to fill out author details when they are not present in the entry itself. I first search the entry proximity, then start back at xpath / if none are found. This is in line with the Entry Author heading in the microformat[1] which states: if an Entry has 0 Entry Athor elements, the logical Entry Author is assumed to be the author of the XHTML page Looking at the required feed[2] and entry[3] elements from atomenabled.org it seems that only id, title, and updated are required in each. Right. Is this a mismatch with the standard, or is my understanding of the hAtom spec mismatched? The Atom spec layers further requirements in the text, specifically from the Recommended Elements [4] Names one author of the entry. An entry may have multiple authors. An entry must contain at least one author element unless there is an author element in the enclosing feed, or there is an author element in the enclosed source element. Reading the information from that atomenabled.org I'm inclined to write the parser as only placing author and contributor elements in an entry when they appear in the hAtom html within an entry. If author and contributor fields were only to be found at the feed level I would only repeat them there in the atom output. Is my inclination reasonable? That would make any atom feed reader responsible for making the association between a feed with a particular author an each entry having a particular author rather than the transform... I'm going to consider this a little further over Christmas. Right now, the hAtom spec does not define author (or contributor) at the feed level. This is an ommission, but I was concerned with making the minimal set of rules I could make. Here's what I was/am thinking: - the page also represents feed data; this is the reality of most blogs and there's a nice parsimony in not duplicating the information - have you seen a blog where the Author is specified outside the entries (and not in the entries)? I.e. are we inventing edge cases that don't really exist? That's not to say that what you're suggesting isn't a bad idea: that author/contributor are brought in IF they appear within the feed. Regards, etc... David -- Benjamin Carlyle [EMAIL PROTECTED] [1] http://microformats.org/wiki/hatom#Entry_Author [2] http://atomenabled.org/developers/syndication/#requiredFeedElements [3] http://atomenabled.org/developers/syndication/#requiredEntryElements [4] http://atomenabled.org/developers/syndication/#recommendedEntryElements ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
Ryan King wrote: On Dec 4, 2005, at 9:15 AM, David Janes -- BlogMatrix wrote: Ryan King wrote: 4. Why do we prefer h# over class=title for entry titles? See my earlier note. I'd really appreciate if you or Tantek got back to me here: my understanding is that we'd always prefer appropriate XHTML constructs. Yes, I'd say we should prefer the appropriate html construct. In this particular case, though, I'm afraid using h# is a bit brittle- this is coming from helping triage support requests coming into Technorati about us not indexing their blog properly. For this particular element I would prefer: 1. an explicit classname (most people are using a classname already, no?) 2. fallback to h# I think the explicit declaration should be preferred, but this is just a suggestion. I know that other xhtml-syndication efforts have used h# for entry titles, but I'm not sure of their success. Anyone with experience here, please speak up. I'm going to go with your suggestion. I've actually been doing lots of playing with parsing Microformats using Python, DOMs, and so forth and I'm getting a better sense of what practically works. 5. Entry Permalinks MUST be absolute URIs. Why? We have well established rules for relative urls. I could lower this to SHOULD; feedback would be appreciated. I think requiring absolute URIs is a bit too high a hurdle, not not quite neccessary. I'm going to change this to SHOULD. There, done. However, what I'm trying to accomplish is to let rel-bookmark provide byte comparable strings for providing the best location for this resource. Like I said, the rules for transforming relative URIs to absolute ones are pretty well established, so any consumer should be able to take care of this for themselves. I think this is just a case where we need to optimize for the publisher over the consumer. I was reading a blog post yesterday about how much misery atom:base and relative URIs are causing. Can't find it, ah well. The problem with relative URIs is that readers at http://instapundit.com; and at http://www.instapundit.com; will come up with two different sets of Entry Permalinks that are actually representing the same resources. This even gets uglier with LiveJournal. I do recognize this may be an attempt at some mild social engineering on my part. FWIW, there has been some (offline and on-) discussion about a rel-canonical microformat. Maybe hAtom should defer this problem (*it is* bigger than just atom/blogs). Fair enough. Maybe it'll be a role model. 6. quote: there can be at most 1 Entry in an XHTML document without an Entry Permalink; the Entry Permalink of this Entry is the URI of the page This rule is needed for media pages (i.e. a news article on cnn.com). There is some ugliness of with this because the URI could be non-canonical. I'm not sure I follow this and don't see anything on the brainstorming page about it. It's in the blog-post-examples [1]. I'd like to make in practical for organizations such as CNN to markup pages such as [2] in hAtom without requiring them rewriting the way they do pages. So the use-case is a document with one entry? Is this really worth making a general rule about? ... It's all great -- bring it on. I'm back in fighting shape :-) Great. A few more changes have gone in. I've documented a list [1] for people tracking the proposal. I've also started collecting practical advice on templates, CSS and so forth [2]. Contributions from WP people and so forth would be appreciated. -ryan Regards, etc... David http://www.blogmatrix.com [1] http://microformats.org/wiki/hatom#Recent_Changes [2] http://microformats.org/wiki/hatom#Hints_and_Tips ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
David, Just in case people didn't say this enough: this hAtom thing is tremendous. I am working on implementing it at a client's site and I am enjoying the quality of the spec and the level of thought that went into it. Now, try to fit that head into a doorway :) :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
Thanks Dimitri, I aim to please. I hope to have an interesting webservice to show off before the end of the week relating to uFs also. Regards, etc... David Dimitri Glazkov wrote: David, Just in case people didn't say this enough: this hAtom thing is tremendous. I am working on implementing it at a client's site and I am enjoying the quality of the spec and the level of thought that went into it. Now, try to fit that head into a doorway :) :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
On Dec 6, 2005, at 3:59 AM, David Janes -- BlogMatrix wrote: However, what I'm trying to accomplish is to let rel-bookmark provide byte comparable strings for providing the best location for this resource. Like I said, the rules for transforming relative URIs to absolute ones are pretty well established, so any consumer should be able to take care of this for themselves. I think this is just a case where we need to optimize for the publisher over the consumer. I was reading a blog post yesterday about how much misery atom:base and relative URIs are causing. Can't find it, ah well. Tantek can tell you about about atom:base problems. :D Anyway, for better or worse, we have relative URIs in [X]HTML. The problem of resolving them is bigger than hatom. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
Ryan King wrote: On Nov 23, 2005, at 1:02 AM, David Janes -- BlogMatrix wrote: Have at it: http://microformats.org/wiki/hatom Some comments (sorry, its taken me awhile to get to this): 1. I notice that feed title and feed permalink have been deferred to future versions (see http://microformats.org/wiki/hatom#Nomenclature). Any reasons why? I must be missing something, 'cause these seem easy to me. Honestly, I didn't find any consistent pattern and I didn't want to spend time figuring it out, so I deferred. If anyone wants to plug through the examples and try themselves... 2. Not to pick nits, but datetime's probably don't *have to* use the datetime-design-pattern. People who want to are free to publish the ISO Fair enough; I've updated hAtom with a note. Note that to be consistent with the Atom Datetime Construct, the time must be specified to the second. 3. I see that we're allowing multiple feeds per page. I wonder what the pros and cons of this are? It's a common pattern and offhand I don't foresee too many difficulties because most operations will be at the Entry level and disambiguatable (if that's a word) via. the Entry Permalink. 4. Why do we prefer h# over class=title for entry titles? See my earlier note. I'd really appreciate if you or Tantek got back to me here: my understanding is that we'd always prefer appropriate XHTML constructs. 5. Entry Permalinks MUST be absolute URIs. Why? We have well established rules for relative urls. I could lower this to SHOULD; feedback would be appreciated. However, what I'm trying to accomplish is to let rel-bookmark provide byte comparable strings for providing the best location for this resource. The problem with relative URIs is that readers at http://instapundit.com; and at http://www.instapundit.com; will come up with two different sets of Entry Permalinks that are actually representing the same resources. This even gets uglier with LiveJournal. I do recognize this may be an attempt at some mild social engineering on my part. 6. quote: there can be at most 1 Entry in an XHTML document without an Entry Permalink; the Entry Permalink of this Entry is the URI of the page This rule is needed for media pages (i.e. a news article on cnn.com). There is some ugliness of with this because the URI could be non-canonical. I'm not sure I follow this and don't see anything on the brainstorming page about it. It's in the blog-post-examples [1]. I'd like to make in practical for organizations such as CNN to markup pages such as [2] in hAtom without requiring them rewriting the way they do pages. 7. the machine readable datetime should be encoded with an abbr . Again, maybe this *should* should be a *may* ? See 2. 8. Open item for the list: if there is no Entry Updated and Entry Published elements, transformation to Atom is problematic This is because a published element is required. Suggestions would be appreciated here. Alright, so I'm going to stop before digging into the xmdp and parsing details. Forgive me, david if any of this is ignorance. It's all great -- bring it on. I'm back in fighting shape :-) Regards, etc... David [1] http://microformats.org/wiki/blog-post-examples#No_Entry_Permalink [2] http://www.cnn.com/2005/US/12/03/katrina.townhall/index.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
On Dec 4, 2005, at 9:15 AM, David Janes -- BlogMatrix wrote: Ryan King wrote: 4. Why do we prefer h# over class=title for entry titles? See my earlier note. I'd really appreciate if you or Tantek got back to me here: my understanding is that we'd always prefer appropriate XHTML constructs. Yes, I'd say we should prefer the appropriate html construct. In this particular case, though, I'm afraid using h# is a bit brittle- this is coming from helping triage support requests coming into Technorati about us not indexing their blog properly. For this particular element I would prefer: 1. an explicit classname (most people are using a classname already, no?) 2. fallback to h# I think the explicit declaration should be preferred, but this is just a suggestion. I know that other xhtml-syndication efforts have used h# for entry titles, but I'm not sure of their success. Anyone with experience here, please speak up. 5. Entry Permalinks MUST be absolute URIs. Why? We have well established rules for relative urls. I could lower this to SHOULD; feedback would be appreciated. I think requiring absolute URIs is a bit too high a hurdle, not not quite neccessary. However, what I'm trying to accomplish is to let rel-bookmark provide byte comparable strings for providing the best location for this resource. Like I said, the rules for transforming relative URIs to absolute ones are pretty well established, so any consumer should be able to take care of this for themselves. I think this is just a case where we need to optimize for the publisher over the consumer. The problem with relative URIs is that readers at http:// instapundit.com and at http://www.instapundit.com; will come up with two different sets of Entry Permalinks that are actually representing the same resources. This even gets uglier with LiveJournal. I do recognize this may be an attempt at some mild social engineering on my part. FWIW, there has been some (offline and on-) discussion about a rel- canonical microformat. Maybe hAtom should defer this problem (*it is* bigger than just atom/blogs). 6. quote: there can be at most 1 Entry in an XHTML document without an Entry Permalink; the Entry Permalink of this Entry is the URI of the page This rule is needed for media pages (i.e. a news article on cnn.com). There is some ugliness of with this because the URI could be non-canonical. I'm not sure I follow this and don't see anything on the brainstorming page about it. It's in the blog-post-examples [1]. I'd like to make in practical for organizations such as CNN to markup pages such as [2] in hAtom without requiring them rewriting the way they do pages. So the use-case is a document with one entry? Is this really worth making a general rule about? ... It's all great -- bring it on. I'm back in fighting shape :-) Great. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
Hello, On 12/2/05, Benjamin Carlyle [EMAIL PROTECTED] wrote: Hello, On Wed, 2005-11-23 at 04:02 -0500, David Janes -- BlogMatrix wrote: Have at it: http://microformats.org/wiki/hatom I've had a play at applying this to my weblog[1]. One question I would like to ask is about the author field. I currently have my name tagged with dc-author and foaf-name on the main page. I think the dc-author is non-standard in the body and used in this way. The foaf-name is experimental based on a generalised microformat for rdf, which of course is not microformat because it is too general. I see that hAtom currently recommds the use of a hcard. I could add this in as well, but what does a hcard mean when floating around on a web page? I'm also uneasy about including a span class=vcard/span section in the document. Not all of the relevant information is in one place. Urrgh. I'm not quite getting this out right, but what is the most straightforward way to say This page and everything in it was authored by Benjmain Carlyle? :) In HTML the address element can be used to specify the author of a document. So, you could combine an address element with a hCard and do something like: address class=vcard span class=fnBenjmain Carlyle/span /address Or, if you want to get more sophisticated (and more detailed and complex), you could do something like the following: address class=vcard span class=fnspan class=given-nameBenjmain/span span class=family-nameCarlyle/span/span /address Note, that's pretty plain... you can add extra stuff -- text, tags, etc -- in there to make it look better. (If you don't know what I mean, I can explain. I'm just too tired to type one out right now :-) ) I don't want to add a URL. Why should I? You don't have to. You're already at my home page. I don't want to add an email address, or not a precisely valid one. I don't want to attract spam. Technorati has the only photo I display, and that is provided by javascript I don't control. I can't directly reference it. I just want to quickly make a few assertions and have them picked up by a hAtom parser. -- Benjamin Carlyle [EMAIL PROTECTED] [1] http://members.optusnet.com.au/benjamincarlyle/benjamin/blog/ -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
On Fri, 2005-12-02 at 22:04 -0800, Charles Iliya Krempeaux wrote: In HTML the address element can be used to specify the author of a document. So, you could combine an address element with a hCard and do something like: address class=vcard span class=fnBenjmain Carlyle/span /address Couldn't address mean something else, though? Perhaps identifying the person this page is about rather than its author? Wouldn't using dublin core be more specific? -- Benjamin Carlyle [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
Hello, On 12/2/05, Benjamin Carlyle [EMAIL PROTECTED] wrote: On Fri, 2005-12-02 at 22:04 -0800, Charles Iliya Krempeaux wrote: In HTML the address element can be used to specify the author of a document. So, you could combine an address element with a hCard and do something like: address class=vcard span class=fnBenjmain Carlyle/span /address Couldn't address mean something else, though? Perhaps identifying the person this page is about rather than its author? Wouldn't using dublin core be more specific? Here's something I found here: http://www.w3.org/MarkUp/html3/address.html The ADDRESS element specifies such information as address, signature and authorship for the current document... The problem is that the address element by itself is only human readable (and not machine readable). (Which is why things like dublin core are sometimes useful... they made it so things were machine readable too.) However, the address element combined with and hCard brings in the machine readable part,... so that an address element combined with an hCard is both human readable and machine readable. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Never forget where you came from ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
On 12/1/05, Ryan King [EMAIL PROTECTED] wrote: On Nov 23, 2005, at 1:02 AM, David Janes -- BlogMatrix wrote: [ snip ] 4. Why do we prefer h# over class=title for entry titles? A preference one way or the other does make the XSLT make sense. [ snip ] 8. Open item for the list: if there is no Entry Updated and Entry Published elements, transformation to Atom is problematic This is because a published element is required. Suggestions would be appreciated here. Actually it is updated that is required. Published is not. o atom:feed elements MUST contain exactly one atom:updated element. o atom:entry elements MUST contain exactly one atom:updated element. o atom:entry elements MUST NOT contain more than one atom:published element. - Luke ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
Tantek Çelik wrote: On 12/1/05 12:41 PM, Ryan King [EMAIL PROTECTED] wrote: On Dec 1, 2005, at 6:24 AM, Luke Arno wrote: On 12/1/05, Ryan King [EMAIL PROTECTED] wrote: On Nov 23, 2005, at 1:02 AM, David Janes -- BlogMatrix wrote: [ snip ] 4. Why do we prefer h# over class=title for entry titles? A preference one way or the other does make the XSLT make sense. Let me rephrase: 4. Why not just use class=title? Or re-use classnames that mean the same thing from the other established microformats (hCard, hCalendar) like we did in hReview. We should reuse the building blocks from existing microformats as much as possible. Excuse my lack of replies -- I've been/am in rather rotten health (hopefully temporary). The h# rule is based on use appropriate XHTML elements first principle. h# are titles (and are used as such in many blogs). Regards, etc... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
On Nov 23, 2005, at 1:02 AM, David Janes -- BlogMatrix wrote: Have at it: http://microformats.org/wiki/hatom Some comments (sorry, its taken me awhile to get to this): 1. I notice that feed title and feed permalink have been deferred to future versions (see http://microformats.org/wiki/ hatom#Nomenclature). Any reasons why? I must be missing something, 'cause these seem easy to me. 2. Not to pick nits, but datetime's probably don't *have to* use the datetime-design-pattern. People who want to are free to publish the ISO 3. I see that we're allowing multiple feeds per page. I wonder what the pros and cons of this are? 4. Why do we prefer h# over class=title for entry titles? 5. Entry Permalinks MUST be absolute URIs. Why? We have well established rules for relative urls. 6. quote: there can be at most 1 Entry in an XHTML document without an Entry Permalink; the Entry Permalink of this Entry is the URI of the page This rule is needed for media pages (i.e. a news article on cnn.com). There is some ugliness of with this because the URI could be non-canonical. I'm not sure I follow this and don't see anything on the brainstorming page about it. 7. the machine readable datetime should be encoded with an abbr . Again, maybe this *should* should be a *may* ? 8. Open item for the list: if there is no Entry Updated and Entry Published elements, transformation to Atom is problematic This is because a published element is required. Suggestions would be appreciated here. Alright, so I'm going to stop before digging into the xmdp and parsing details. Forgive me, david if any of this is ignorance. -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom draft
On 11/24/05, David Janes -- BlogMatrix [EMAIL PROTECTED] wrote: I'm not much of an XSLT guy, to tell you truth. When I was in CompSci and studying Prolog, our prof mentioned that the great thing about Prolog was you didn't have to tell it everything like other languages. My friend remarked not only do you have to tell it everything, you have to tell it everything in a really fucked up way. XSLT kind of reminds me of that :-) Heh, nicely put. I must admit I find writing the stuff a headache-generator, but like the way once it's done it's done. I tend to flip between languages quite a lot, and being able to carry over the same XSLT works out quite a timesaver compared to writing (or finding and integrating) parsers afresh. I'm going to fix up the spec bugs mentioned so far, clarify my position on summary, allow feeds to be nested (because then comments can be modeled very easy). Good man. Code wise, I'm going to rework something I have lying around called the template rewriter which will take MT, Blogger or (maybe) Wordpress templates and add the hAtom markup automatically. I'll be looking for victims for that. If you do WordPress, count me in as a victim. And this weekend there's a thing called TorCamp which I'm considering throwing together some powerpoints on Microformats. powerpoints!? What about OpenOffice? S5? (and is class=topleft really semantic??) Cheers, Danny. -- http://dannyayers.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hAtom draft
Have at it: http://microformats.org/wiki/hatom Regards, etc... David http://www.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
