[uf-discuss] hAtom and microformats extraction screencast
Here's a demo screencast [1] -- there's a few issues with the screencapture tool and my script -- of a tool I've been working on to analyze microformats on a page and allow you to perform actions on each microformat. In particular, I'm looking a hAtom and showing the content (both as formatted and unformatted HTML), printing out a weblog entry (or if it was used, a comment, or a newspaper entry) and reblogging -- that is, quoting an entry for reuse in my own blog. I'm off on vacation for a couple of days but when I'm back I'll probably polish up this demo and make it available on the net (i.e. at blogmatrix.com). It will get even more interesting with hCards and hCalendars, where you can look at events or whatever on the net and load them directly into your own blog/information repository. If you were looking for used cars, or someone to hire, then the same process would follow. Regards, etc... David [1] http://www.davidjanes.com/hAtom%20Capture.wmv ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] does hatom for comments make sense?
Right -- and a uF for expressing that relationship; this gets a little trickier. As uFs are about codifying existing practices, my (superficial) look at comment nesting shows that many sites (like slashdot) using nesting to express relationships, not explicit URI linking. On the other hand, threaded mail list managers do use links to express the hierarchy. The nice part is that this (hypothetical uF) composites with hAtom to achieve our result; the trickier part is documenting nesting examples to support the uF. Regards, etc... David On 9/12/06, Karl Dubost [EMAIL PROTECTED] wrote: Just think that a comment is a weblog post about a weblog post uri1 --- comment-x/uri2 about uri1 --- comment-xa/uri5 about uri2 --- comment-xb/uri6 about uri2 --- comment-y/uri3 about uri1 --- comment-z/uri4 about uri1 It is just a question of having the right *atomic* model. and to make individual statements about things. Then the application layer is above. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] LinkedIn will support microformats
If I can then get GMail to dynamically read the hCards from LinkedIn, I'll be in Web 2.0 e-mail Nirvana. Regards, etc... David On 9/11/06, Chris Messina [EMAIL PROTECTED] wrote: Check it out... as part of their redesign, LinkedIn will be supporting hcard and hresume: http://factoryjoe.com/blog/2006/09/09/linkedin-refreshes/#comment-16885 Tara and I have been talking with LinkedIn, but this is the first confirmation we have that they'll actually be implementing microformats. Sweet. Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ 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] does hatom for comments make sense?
Comments are nested within entries and hfeed elements can be nested too. Typically, one doesn't see multiple entries with comments on the same page. In usage that I've seen, one would probably use this nesting structure: * hfeed (for the blog, optional) ** hentry (for the one entry on the page) *** hfeed (for the comment, required) hentry (comment #1) hentry (comment #2) As Stephen notes, there should be a class element indicated that the comment-hfeed is associated with the first hentry (the blog entry), but we deliberately chose to keep that out of scoping for hAtom 0.1, because, ahh, the quote it was just making shit up. Another option would be that hfeeds in hentrys would be assumed to be comments and the entry-title is inheritable. Regards, etc... David On 9/12/06, Stephen Paul Weber [EMAIL PROTECTED] wrote: Comments are (almost) always right after a post... so yes, the comment feeds would have to be nested, unless the existed only on item pages. Having all the data avaliable at once has proved very useful in my previous applications of related technology (XOXO-based encoding as seen on http://blogxoxo.blogspot.com/) -- Singpolyma On 9/12/06, Stephanie Booth (bunny) [EMAIL PROTECTED] wrote: would the feeds be nested? I think that in the example I saw, there were two feeds. One with only the blog post, and a separate one with the comments. Is it permitted by hAtom to nest feeds? I thought it wasn't. Steph On 9/12/06, Stephen Paul Weber [EMAIL PROTECTED] wrote: I think that if using hAtom for comments is going to become 'standard' that we definately need to use class=comments (or something similar) to identify the nested comments feeds inside the main hfeed. Also, comments don't really have a 'title'... you could use the original post title (rarely done, and could confuse the user), or an auto-generated thing based on content (ie 'comment by jake on post'... usually how comment feed titles work, but then you have data duplication..) -- Singpolyma -- http://climbtothestars.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- - Stephen Paul Weber, Amateur Writer http://www.awriterz.org MSN/GTalk/Jabber: [EMAIL PROTECTED] ICQ/AIM: 103332966 NSA: [EMAIL PROTECTED] BLOG: http://singpolyma-tech.blogspot.com/ ___ 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] does hatom for comments make sense?
Why wouldn't it make sense? Comments are structured much the same way blog posts are. My personal rule of thumb is things that you'd make an Atom feed for -- and comments certainly fall under this category -- should be worth considering for hAtom if there's a clear HTML representation. What isn't defined is the relationship between a hfeed defining a set of comments and the hentry for the entry the comments are on. Regards, etc... David On 9/11/06, Stephen Paul Weber [EMAIL PROTECTED] wrote: I don't think it makes much sense... I use a 'standard' XOXO markup on comments... On 9/11/06, Stephanie Booth (bunny) [EMAIL PROTECTED] wrote: A while back somebody showed me a blog marked up with hatom. That person used hatom on the comments too (on the single post page) -- that meant two hfeeds: one containing only the post, and another one with the comments. Does this way of using hatom on comments make sense to you? I noticed that neither K2 nor Sandbox wordpress themes do this. Steph -- http://climbtothestars.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- - Stephen Paul Weber, Amateur Writer http://www.awriterz.org MSN/GTalk/Jabber: [EMAIL PROTECTED] ICQ/AIM: 103332966 NSA: [EMAIL PROTECTED] BLOG: http://singpolyma-tech.blogspot.com/ ___ 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] does hatom for comments make sense?
On 9/11/06, Ben Ward [EMAIL PROTECTED] wrote: On 11 Sep 2006, at 23:17, Stephanie Booth (bunny) wrote: Does this way of using hatom on comments make sense to you? It does to me, yes. Although not using two separate hAtom feeds. I'd just have one with the original post as the first entry in the feed and comments following on sequentially. It's _a feed of the discussion_, in my eyes. Don't forget that hAtom isn't a feed per-se. It's semantic mark up of elements of in HTML document to say they have a certain meaning. Using this as a feed is a choice you may make (I don't think it's a wise one) but that's an application of the data. I'm not sure I understand the reason for wanting multiple feeds or nested feeds to represent comments. I can't see the need for a distinction between a comment and the original post at all. Well, again that's a choice you can make but I'd say most people clearly have a logical distinction between a post they've made and a comment some random stranger has applied to that post. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Profile-examples
How about public-profiles? Regards, etc... David On 9/4/06, Chris Messina [EMAIL PROTECTED] wrote: While I take your point that profiles vs xmdp profiles I confusing, the notion of a profile can also apply to groups or teams... So user-profiles would be too specific. Perhaps we should do more research and see if this effort requires two separate formats for groups and individuals. Chris On 9/4/06, Brian Suda [EMAIL PROTECTED] wrote: To avoid confusion with XMDP profiles, we should choose a more specific name, such as user-profile-examples, or user-bio-examples, etc. -brian On 9/3/06, Chris Messina [EMAIL PROTECTED] wrote: A long time ago we discussed the need for a user-profile microformat. Clearly this would be a superset of hcard as well as an amalgamation of other microformats, but I thought I'd throw up a page so that we could start collecting data and practices: http://microformats.org/wiki/profile-examples This follows an email thread from January that hasn't, to my knowledge, been picked up on: http://microformats.org/discuss/mail/microformats-discuss/2006-January/002685.html Please let me know if anyone's interested. This work will directly effect a social networking platform that a client of mine is currently working on. They've already implemented hcard and xfn and now want to mark up the rest of a user's profile page and need guidance. Thanks, Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [X] bloggable[ ] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ 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] Profile-examples
Random thought: there may be some knowledge in this area that's extractable from LDAP [1][2]. Regards, etc... David http://blogmatrix.blogmatrix.com [1] http://www.howtoforge.com/linux_ldap_authentication [2] http://www.linuxjournal.com/article/6266 On 9/3/06, Chris Messina [EMAIL PROTECTED] wrote: A long time ago we discussed the need for a user-profile microformat. Clearly this would be a superset of hcard as well as an amalgamation of other microformats, but I thought I'd throw up a page so that we could start collecting data and practices: http://microformats.org/wiki/profile-examples This follows an email thread from January that hasn't, to my knowledge, been picked up on: http://microformats.org/discuss/mail/microformats-discuss/2006-January/002685.html Please let me know if anyone's interested. This work will directly effect a social networking platform that a client of mine is currently working on. They've already implemented hcard and xfn and now want to mark up the rest of a user's profile page and need guidance. Thanks, Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [X] bloggable[ ] ask first [ ] private ___ 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] OpenSearch
This looks very possible. In particular, (1) according the article, Yahoo only returns its results in HTML, so we know HTML is good (2) one could add an extra field to the OpenSearch XML (a description file about how your results are returned) indicating that the file is hAtom (3) parties not understanding hAtom can just display HTML (4) parties wating to understand hAtom can do it themselves or use a webservice When I was at MashupCamp in January (Feb?) there was a guy from A9/OpenSearch very interested in mashup type applications and developer feedback so there's a door open for us. I'll also note that his WordPress integration problem will probably go away if we did this, as an independent XML-feed result will not have to be returned; Regards, etc... David http://blogmatrix.blogmatrix.com On 8/30/06, Scott Reynen [EMAIL PROTECTED] wrote: On Aug 29, 2006, at 10:23 PM, Ted Drake wrote: It's slightly off topic, but I thought I'd share my latest post about how we added the OpenSearch protocol to the Yahoo! Tech site. This open protocol lets you define how your web site's search engine works and then activates the personal search box in IE7 and Firefox 2. It also helps the aggregating search engines, such as A9. http://www.last-child.com/add-opensearch-to-your-web-site/ Sorry if it is too off-topic. I'm not sure this is off-topic at all. I think OpenSearch solves a problem by extending RSS that microformats could solve by extending HTML, possibly hAtom specifically. The problem is identifying search results for reuse in aggregation, reformatting, etc. The use cases are obvious as there are plenty of applications that already reuse this type of data and could benefit from a standard format for already published search results (A9, OS X Sherlock, etc.), there's certainly no shortage of search results on the web to use as real- world examples from the general web searches to very narrow-focus searches, and between hAtom and OpenSearch, I suspect most of the work is already done. hSearch? ` Peace, Scott ___ 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] hCal in table - I think I might have cracked it?
Like this [1]. 20 events, all look sensible. Regards, et... David [1] http://tinyurl.com/fs9sr On 8/28/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes One (or more, by the time you read this) of the events on this page is marked up as an hCal. They all are, now. How does it look? http://www.westmidlandbirdclub.com/diary/indexEXPAND.htm Anyone? -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ 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] hCal in table - I think I might have cracked it?
Try fn org instead of fn [1]. Regards, etc... David [1] http://microformats.org/wiki/hCard#Implied_.22n.22_Optimization On 8/28/06, Gazza [EMAIL PROTECTED] wrote: David Janes mumbled the following on 28/08/2006 11:38: Like this [1]. 20 events, all look sensible. Including the hcard name(s) within vevent 20?! [1] http://tinyurl.com/fs9sr On 8/28/06, Andy Mabbett [EMAIL PROTECTED] wrote: How does it look? http://www.westmidlandbirdclub.com/diary/indexEXPAND.htm Anyone? -- Regards, Gazza ___ 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] Automatic conversion of XML to microformat and vice versa; recommendation for handling XML attributes?
And in particular, have a look at XOXO Rest Datatypes [1]. There's probably more work that could be done here to model typed values (i.e. 12000 meters) amongst other things; maybe you're the right person ;-) Regards, etc... David [1] http://microformats.org/wiki/rest/datatypes On 8/27/06, Brian Suda [EMAIL PROTECTED] wrote: On 8/27/06, Costello, Roger L. [EMAIL PROTECTED] wrote: Microformat newbie here, so please bear with me if my questions are misguided. --- welcome Roger. Question #1 Do you agree with using dl for XML leaf nodes? If not, do you recommend something else? while this might work in your case, trouble appears when you have attibutes on those Element... how would you encode those? The XOXO microformat (http://microformats.org/wiki/xoxo) allows for this sort of encoding. You could tweak it slighty so you get class attribute values which you could then style. XOXO uses OL lists, with DL lists for attributes and should solve your problems, i would suggest reading-up on that and if there are still problems let us know. There are also several implementations of how to internalize a XOXO list into a PHP, Python,Ruby,etc. array. Sort of an HTML JSON. -brian -- brian suda http://suda.co.uk ___ 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] Google Base API
- Google Base data API is more or less the Atom Publishing Protocol. - This means you can read/write/search - The GBase data model is just adding key/value pairs to each entry - Google Base is a store of records/entries with these key/values - key can come from a predefined list or you can make up your own - limited access to your Google Base silo can be assigned to a 3rd party It's actually fairly straight forward, though obviously there's a limit to what you can model without hierarchy. There is another data model Google provides called the GData model which isn't compatible but allows for deeper structures. More analysis here [1] Regards, etc... David [1] http://blogmatrix.semantic.blogmatrix.com/google%20base/ On 8/24/06, Chris Messina [EMAIL PROTECTED] wrote: WTF. http://code.google.com/apis/base/ It's like from outer space. But unreal. Chris -- Chris Messina Agent Provocateur, Citizen Agency Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [X] bloggable[ ] ask first [ ] private ___ 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] Google Base API
Google Base is explicitly trying to do something that Microformats are not: boil the ocean, or in this particular case, a sea in the ocean. Google Base silos are basically spreadsheets; each record is a row in the spreadsheet. How do you model that in Microformats? In fact, the best/easiest way of modeling that is supported by Google Base: you can upload CSV files. The Google Base data API just provides a simple way of expressing that spreadsheet in XML. Marc Canter's bizarre rant this morning about standards aside, I know of no standard alternative way to do this. RDF/XML is too expressive, Microformats doesn't try to be expressive outside of defined problems. BTW: I demoed in April a quick and dirty hCalendar to Google Calendar translator (the API to Google Calendar is GData). I didn't pursue this any further except to demo as a trick because Google didn't provide a mechanism for 3rd parties to post on your behalf, which meant your password would have to be given up. With AuthSub [2] this is no longer an issue so perhaps it's worth reinvestigating. Regards, etc... David [1] http://blog.davidjanes.com/:search:democamp [2] http://code.google.com/apis/gdata/authsub.html On 8/24/06, Scott Reynen [EMAIL PROTECTED] wrote: On Aug 24, 2006, at 12:27 PM, Chris Messina wrote: However, microformats seem a whole lot easier and a lower barrier to entry in many respects (though they'd have to get involved in the community process which may be too slow for them). At the very least, supporting both microformats and their own made up magical API would be a nice overture. If you think a microformats API to Google Base would be useful, why not build one on top of the existing API? Live applications make for more compelling arguments. Peace, Scott ___ 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] Widgetbox thinks outside the box...
Dojo [1], a popular AJAX library, uses something even more XHTML unfriendly for its widget inclusion: div id=... dojoType=DojoWidgetName widgetId=ID [Attribute=Value] /div Regards, etc... David [1] http://dojotoolkit.org/ On 8/4/06, Chris Messina [EMAIL PROTECTED] wrote: ...and develops YAWS (yet another widget syntax). One that looks like this: wbx:keywords xmlns:wbx=urn:wbx value=tech / Here's how a user might create a smart blog post: http://beta.widgetbox.com/docs/smartblogs/ Essentially, from what I can tell, they use JS to go in and replace the wbx / instances with iframes that pull content from the WidgetBox site (according to this: http://forums.widgetbox.com/viewtopic.php?id=13). While they support rel-tag, they seem to have dispensed with the microformats concept after that. Any thoughts on this? I contacted them to get their side -- seems a pity that they wouldn't try working on the hWidget spec if they're aware of it, given what they say on their homepage: This is a work in progress. We certainly need more documentation, more widgets, and more assistance putting widgets on blogs. Please let us know what we need most. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] solidifying multiple hatom feed behavior
Chris Casciano wrote: You're missing my case of working with a document that normally assumes a full page feed if a page is coded for that minimal case then all could be working just fine unless one of the authors of the site happens to post a feed in the body of an item and then you've gone and totally rewired the document as a result. I don't see where opacity comes in here when the page wide feed disappears under these circumstances... ... If I'm understanding your reading of the spec someone could be subscribing to the blog posts via page.html and have things work as expected until post-003 is made and it hijacks the blog feed Under what circumstances would the author of the post put a hfeed into it? If you're thinking about quoting another blog, we've already got that covered by the blockquote rules in entry [1]. Regards, etc... David [1] http://microformats.org/wiki/hatom#Entry ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] UID in iCalendar
Tantek Çelik wrote: Agreed with Brian's interpretation. In addition, I think if we make a stronger suggestion (perhaps a SHOULD) that individual hCards and hCalendar events have a unique-to-the-document 'id' attribute on their root elements, then automatic construction of globally unique UIDs becomes fairly straightforward, and we can write an implied UID rule for hCard and hCalendar at a minimum. Thoughts? I'd like to add SHOULD use 'id' and implied UID to hCard and hCalendar soon if no one objects. And yes, we should update the creators so that they auto-specify uniqueish 'id' attributes on the root elements as well for ease of authoring. This is an excellent idea. Any thoughts on whether this implies a design pattern that can be used across other microformats (perhaps extracting a UID microformat like you did with geo [1] and adr [2])? Regards, etc... David [1] http://microformats.org/wiki/adr [2] http://microformats.org/wiki/geo ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] UID in iCalendar
Dimitri Glazkov wrote: On 7/3/06, brian suda [EMAIL PROTECTED] wrote: For example, http://events.example.com/#123 would become [EMAIL PROTECTED] Why not just keep it as is, http://events.example.com/#123? You can't have id attributes that start with a number [1], so you would have to create invalid XHTML to imply the URI. Regards, etc... David [1] http://www.w3.org/TR/REC-html40/types.html#type-id ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] UID in iCalendar
Dimitri Glazkov wrote: Sorry about that! :) But.. isn't that beside the point? Orthogonal! ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] media file example of hAtom
No [1]. LINK and A only. Regards, etc... David [1] http://www.w3.org/TR/REC-html40/index/attributes.html Enric wrote: Can rel= be used on span ? -- Enric ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] LinkedIn and Microformats
I was going to report the happy news that LinkedIn [1] is using hCards, as my little Greasemonkey script was showing an icon on the page. Alas, it's not to be -- here's what they're doing: p class=vcarda href=/addressBookExport?exportMemberVCard=memberID=6172221 name=_exportVCardDownload vCard/a/p D'oh -- they're using vcard to mark that there's, umm, a vcard at the other end of the link. If anyone knows anyone at LinkedIn, you may want to give them a nudge. Regards, etc... David [1] http://www.linkedin.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] LinkedIn and Microformats
Chris Casciano wrote: On Jun 13, 2006, at 5:18 PM, David Janes -- BlogMatrix wrote: I was going to report the happy news that LinkedIn [1] is using hCards, as my little Greasemonkey script was showing an icon on the page. Alas, it's not to be -- here's what they're doing: p class=vcarda href=/addressBookExport?exportMemberVCard=memberID=6172221 name=_exportVCardDownload vCard/a/p D'oh -- they're using vcard to mark that there's, umm, a vcard at the other end of the link. If anyone knows anyone at LinkedIn, you may want to give them a nudge. Regards, etc... David [1] http://www.linkedin.com/ And? And tell them about hCard and how cool and easy it would be if they used that instead? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] media file example of hAtom
I suspect you won't go wrong using rel-enclosure [1] inside the hentry. This is probably a candidate for official documentation. Regards, etc... David [1] http://microformats.org/wiki/rel-enclosure Enric wrote: This is probably obvious. But I'm just starting to look at hAtom for media/video files. Is there an example of hAtom enclosing an audio/video files like mp3, mov, wmv, etc.? Thanks, Enric ___ 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] LinkedIn and Microformats
Did you get a sense from your recent projects of: (1) what percentage of uF pages use profiles? (2) what percentage of uFs are broken? Regards, etc... David Tantek Çelik wrote: We *do* have an hCard profile with URI, thanks to DanC: http://www.w3.org/2006/03/hcard But even without that, it is not unreasonable to assume that class=vcard is an hCard. Just as it is not unreasonable (as in they all do it) for a browser to assume that html is an HTML document even if there is no DOCTYPE that points to a DTD URL which defines the element html as such. We'll get to the point in a few years where more folks are using profiles, but for now, microformats are like the early days of HTML where no one bothered to use DTDs. Be patient, we'll get there. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats meetup tomorrow in toronto?
I thought Tara was tiring you out bringing you to clubs all hours of the night [1]? Alas, I have an early evening engagement. Are you going to Mush [2]? Regards, etc... David [1] http://www.horsepigcow.com/2006/05/jazz-in-tdot.html [2] http://www.whatswiththat.ca/mush/ Chris Messina wrote: Anyone up for a brief microformats meetup tomorrow around 6pm in Toronto? Chris ___ 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] Microformats Cheatsheet
Ah, very exciting, very nice. The only suggestion I have off the top of my head is to make it more obvious where the uFs join together. Instead of (hCard) maybe + hCard, with hCard being bold or something? I like the fact to that you show the nesting of the elements of the right hand side. Regards, etc... David brian suda wrote: One of the common questions when people are implementing microformats is that they are not sure what properties are available and/or which are required. The specs are pretty good about explaining what properties are REQUIRED, OPTIONAL and their cardinality (0-1, 0-*, 1-*, once). I know the Wiki also has a chart with all the existing class names[1] to help everyone know what is available and a brief description of each property. I have tried to combine both the specs and the chart to a single 'cheat sheet' for all the common microformats. This is a single page document that describes both elemental microformats (XFN, RelTag, etc) and compound microformats. I have attempted to show all of the available properties, their hierarchy (what is a child/parent of what), if they are required or optional, and if they are available multiple times, etc. I also have a chart that shows which properties are available with which microformats - it is not as detailed as the Wiki (this is a study aid and does not replace knowing what each item means - and besides, i am cramming this onto a single sheet space is at a premium) Please have a look and let me know your feedback, i'm open to suggestions - it is still a very early iteration so if you find mistakes let me know and i'll correct them. (There have been requests to make this an HTML document, and i probably will, but for a first run i can get more minute control if i make things PDFs, as well, any changes will get folded back into the wiki page[1]) http://suda.co.uk/projects/microformats/cheatsheet/ This isn't meant to replace the information on the wiki, but to condense and supplement it. I hope this print out can help folks better visualize some of these more complex microformats. Thanks, -brian [1] - http://microformats.org/wiki/existing-classes ___ 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] Adobe's XMP Platform (for media metadata)
Bruce D'Arcus wrote: On 4/30/06, Chris Messina [EMAIL PROTECTED] wrote: [...] We've talked much about media-metadata and fotonotes... I wonder where XMP fits into this, as it's open source... At the very least we should do due diligence, eh? FWIW, XMP is just marketing speak for an RDF subset. And while there is an open source toolkit, it's C++-only. The format itself is not particularly open. I had to do a surprisingly large amount of reading to get to that point in their docs! I was hoping to find more of substance in terms of data modeling; maybe I haven't pushed down to the right level yet. I find Adobe's site pretty hard to navigate. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] nested hatom feeds?
Chris Casciano wrote: A somewhat silly, but practical question on hatom parsing rules and opaqueness... Can you nest hatom feeds... and if so will the inner feed be seen as a unique item or will it be hidden from parsers because its inside of the outer feed's content element? You can nest the feeds, but at this point you can't make any assumptions about what the nesting means (i.e. what the relationship between the feeds is). Real world scenario that brought this up: I have a site that doesn't use hatom anywhere yet. On one page I wanted to add a small hatom feed with some application version/release information. The feed would sit in what I would consider the content area of the html document. *If* I came though in a few months and changed the templates that the site uses so that each page had hatom elements wrapping the content so the entire page could be subscribed to (similar to the setup I now have on chunkysoup.net) what would then happen to the hatom feed that happened to now be embedded inside another feed? I would expect that a parser could pick out the 2 feeds independently -- in the case of the outer feed it just sees the inner feed as some random html like any other content -- but I'm just not sure and the hatom-parsing docs have for the most part yet to be written. I think this is exactly how it should work, and I'll make sure the Almost Universal MF Parser does this. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plazes Microformats
Maybe this would be a good time to bring up rel-vcard (and rel-microformat in general). In particular, to do one of a rel=vcard href=/profile/fiahless/span class=fn nicknamefiahless/span/a or a class=vcard rel=vcard href=/profile/fiahless/span class=fn nicknamefiahless/span/a To indicate that not only is this a vcard, but a better or reference vcard is available at the other end of the link. Regards, etc... David Chris Messina wrote: I believe that this is possible, given that a proposed optimization to collapse vcard and fn into one class value (class=vcard fn) was rejected for this very reason. Additionally, you might consider that the more important hcard in this case is the location instead of the discover and dispense with the nested hcard for clarity. You don't have to do this of course, but is another solution to consider. On 4/19/06, Pieter Walsweer [EMAIL PROTECTED] wrote: div class=vcard a class=fn org href=http://beta.plazes.com/plaze/cd21e1717f61ba9cf9df9006038da172/; Clara's Coffeeshop/a div class=note This place is a free public WiFi in a restaurant and was discovered by a class=vcard href=/profile/fiahless/span class=fn nicknamefiahless/span/a. /div ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plazes Microformats
Chris Messina wrote: Ooo... that's pretty cool. How does that compare with the object-include concept? ;) Good question: - object-include is data inclusion from elsewhere on a page - rel-uF is indicating that there's a better or more canonical version of this uF object on the other side of the link. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plazes Microformats
Scott Reynen wrote: On Apr 19, 2006, at 2:23 PM, Ryan King wrote: That's right. The reason you can't collapse a 'vcard' class name and its 'fn' class name is that it makes putting a 'vcard' class name inside another one becomes ambiguous. I've seen this explanation a few times, and I've never personally found the separation of vcard and fn to be a problem, but I don't understand the explanation. Couldn't the spec prevent such ambiguity simply by stating that vcard and fn in the same node should be treated by parsers as an fn node within the vcard node. More generally, why doesn't nearest-in-parent [1] start with the current node rather than the parent node? [1] http://microformats.org/wiki/algorithm-nearest-in-parent This is great place to continue this debate. The issue (as I understand it) is that this optimization doesn't allow nested vcards: span class=vcard fn[SPAM-DATA]/span The reason, as I see it, is that because you've asserted fn, [SPAN-DATA] can pretty well only be a FN because otherwise you're asserting something that isn't true logically. Thus, in terms of this particular optimization, there is no particular need for worrying about nested vcards since it can't happen from a logical point of view. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plazes Microformats
Ryan King wrote: This is great place to continue this debate. The issue (as I understand it) is that this optimization doesn't allow nested vcards: span class=vcard fn[SPAM-DATA]/span This would still be a problem if it were nested inside another hcard. (remember, @class is an order-insignificant list.) Well, what's the rule for associating a fn with a vcard? We're just asking that it be changed from (as you're saying): -- fn belongs to the vcard that contains it to (as we're asking): -- fn belongs to the vcard that contains it or is at the same level. This won't break any existing vcards, since no-one is doing the fn-optimization yet. Regards, etc... PS. I meant SPAN-DATA, not SPAM-DATA! ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plazes Microformats
Ryan King wrote: But the relationship isn't 'vcard'. 'vcard' describes the format (or part of the format) of the referenced resource, not the relationship between the two. OK, fair enough: vcard is just a word, and in particular [top-level-uf-id] is just a word. But because we're devising these names to be unique under almost all circumstances, I don't think it's confusing. Would your objection disappear it to be 'is-canonical-vcard'? We've already made the leap that current document means the uFed object in question on the source side, cf. rel-tag. Right, we've stretched @rel to apply to parts of documents, rather than whole documents. However, this isn't the problem I have with using 'vcard' as a rel value. The problem is that the typical @rel interpetation doesn't make sense. To illustrate: In document A I have: a rel=tag href=Bblah/a this can be inpreted as B is a tag for A. In this case: a rel=vcard href=Bblah/a B is a vcard for A doesn't make sense. B *is* a vcard, even if A doesn't exist. OK, there's something that didn't translate here: rel=vcard (and rel=uF) in general can only be used within/at a class=vcard. I.e. either you have A= span class=vcard a rel=vcard href=Bblah/a /span ... that is, your statement: B is a vcard for A OR a class=vcard rel=vcard href=Bspan class=fnblah/a/a ... that is, B is vcard for blah Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hcard validation
Your memory serves you very poorly. Start here: http://microformats.org/wiki/class-design-pattern Regards, etc... Mark Wallace wrote: I'm sorry for asking a really silly question, but doesn't it make sense that any class should have a a space as either a dash or underscore? If memory serves, the url fn would break the standard css formating... -=Mark W. Wallace=- ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Upcoming adds hCards
I have a weird feeling I may have had something to do with this (see the comments): http://blog.davidjanes.com/mtarchives/2006_04.html#003591 Regards, etc... David Chris Messina wrote: At least the folks under the Yahoo umbrella get it: http://upcoming.org/news/archives/2006/04/12/invite_f/ Sweet! Chris ___ 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] Live Clipboard and uF escaping (was Fwd: 0.91 Spec comment: escaped markup is harmful)
Weird, I had just responded saying: 1. microformats are well-defined, XML, and easy to use and thus nothing is gained from pure XML serialization 2. content payload definition is well defined in Atom [1/2], so they should consider using that. I think it takes time for people to get their heads around uFs, so they tend to look for the complicated solution when the easier one looks just fine. Regards, etc... David [1] http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.content [2] http://tinyurl.com/9vr68#element.content Danny Ayers wrote: Dear uFers, The post below is from the MS Live Clipboard list, http://discuss.microsoft.com/archives/live-clip.html in relation to: http://spaces.msn.com/editorial/rayozzie/demo/liveclip/specification/v091.html I'm not sure I understand why Matt suggests XML data might have to be delivered as both XML and escaped as well, but he gets into browser/DOM territory, a place presumably well-known around this list - thoughts appreciated. -- Forwarded message -- From: Matt Augustine [EMAIL PROTECTED] Date: Apr 6, 2006 5:23 AM Subject: Re: 0.91 Spec comment: escaped markup is harmful To: [EMAIL PROTECTED] Thanks for all the information. Escaping only non-XML data formats and leaving XML data formats as part of the Live Clipboard document seems like a reasonable compromise, but I have a few reservations: Since the items in the LiveClipboardContent object might contain either XML or escaped, non-XML data, we would most likely have to add a second property, named something like xmlData, to hold an XML node in addition to the existing data property. Applications would have to know which property to use based on the contenttype of the format. In the microformat case, treating the data as a string rather than as parsed XML makes it easy to display the data by setting it as the value of the innerHTML property of an element on the page. In order to avoid forcing applications that use this technique to first serialize the xmlData, we would probably want to always provide this serialized data in the existing item data property. If there is a way to directly add the parsed XHTML of the microformat into an HTML element we could avoid this, but as far as I know this isn't possible. IE6 provides an easy way to get the serialized string value of all the xml content of a particular node via the xml property. I'm not aware of a similar property when using the DOMParser in Mozilla or other browsers. Is there an easy way to get access to this serialized data in order to satisfy the previous requirement? As for David's comments about the ugly XML parsing / serialization code, we tried to contain all of that error-prone stuff within our script to make interfacing with Live Clipboard data as simple as possible for the developer and to make sure the emitted XML put on the clipboard is compliant with the spec. We're certainly open to alternative light weight implementations of the control though, as long as they are compatible with the clipboard XML format as specified and present the same user experience for copy/paste. Thanks, Matt Augustine Software Design Engineer CTO Concept Development Team Microsoft Corporation ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] very simple microformat for URIs
Alf Eaton wrote: At the moment, microformatted URIs are generally marked up in the href attribute of an a tag with a class of 'url' (hreview, hcard) or 'email' (hcard). This works for URIs that normally have browser protocol handlers (http:, mailto:), but not so well for other URIs (urn:, info:, etc) - which are particularly important in the context of a citation microformat. Ummm ... this is because one is identifying _this particular link_ as having a well defined meaning. I.e. this is the hcard's URL, as defined by vCard. It's not saying that this is a URL or this is a e-mail address, except within that narrow definition. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom handheld CSS..?
This is an interesting idea. Here are the key elements to Russell Beattie's proposal (I think) as it relates to hAtom: I have to say I’m getting more and more convinced that this is the direction that the mobile web is going to go. No recoding markup, no “separate and always unequal” access to content, etc. Just include a different style sheet on your server and you can re-arrange your web-standard markup as you see fit. So what's being said is _make your websites so they can be restyled using CSS to make a mobile friendly presentation_. And... But it’s still the same underlying markup. And this works for the whole portal like this, so for example if you sign up for a blog, you also get a mobile readable/usable blog as well. That’s pretty awesome. So they're producing weblogs also. The two points uses for for hAtom are (1) hAtom provides a regular and consistent way to mark up your weblog content, not just for semantic reasons but also for presentation ones. Since they're proposing that web pages should be produced in a way that allows CSS restyling -- a non-trivial task -- having a standard way to mark up well known content means it will be easier for web designers to produce these stylesheets. So since web designers often work on blog presentation, having hAtom as the way to mark up weblog content to do all this is the way to go. A win/win for everyone. Note that we're not proposing a panacea here, just a partial solution to one frequently faced problem. (2) They're producing blogs, so they should use hAtom anyway! Regards, etc... David http://www.blogmatrix.com Chris Messina wrote: Perhaps Danny can shed some light on his proposal? On 3/27/06, Chris Casciano [EMAIL PROTECTED] wrote: On Mar 27, 2006, at 3:39 PM, Chris Messina wrote: On 3/27/06, Chris Casciano [EMAIL PROTECTED] wrote: I guess I'm not clear where microformats (including hAtom or not) would serve to solve the handheld 'problem'. I'm not clear either, except that, like CSS Zen Garden, having one set of CSS classes to design for means that I could concoct one stylesheet that could be used as the handheld stylesheet for thousands of blogs instead of just one blog that chooses its own CSS classes. In that way, we could actually iterate on design knowing that there's some consistency in CSS classes. Chris But what about everything else on the page -- from navigation to branding to any non-atom-like content? Or pages with multiple hatom feeds? Or the wide variety of stuff that could be entry content -- from images, photos or screenshots to lengthy articles -- that would presumably go un-specified in an hatom-garden type setting. I guess I don't see how the others participating think the pages would be consumed, and the win I see from hAtom (the ability to subscribe to elements on any page of a site without shipping mulutple versions of a document) isn't at all related to the handheld space. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom look-see
I've just made a small reorg on hatom-issues [1]. It should be fairly clear where to start adding your suggestions and proposals for what goes into hAtom 0.2. If it's fairly clear what the exact atom analogy is (e.g. Feed Title), there's a place for that. And if it's more handwavy, there's a section for that too. Regards, etc... David [1] http://microformats.org/wiki/hatom-issues Ryan King wrote: On Mar 23, 2006, at 9:54 AM, Dr. Ernie Prabhakar wrote: Is there TBD section of the wiki to start the discussion about 0.2? As far as I can tell, no, but David Janes may know better. David? -rk ___ 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] What to do when a microformat doesn't quite fit?
Angus McIntyre wrote: These lists of articles - which are essentially 'feeds' - seem like an obvious match for hAtom, so I've tried to make the library produce hAtom. However, there are some problems. First, hAtom demands an author - either at the entry level, or at the feed level - and in these two use cases, there's no obvious author. In the case of the Inca Trail collection, the articles linked to sometimes have authors and sometimes don't. I could put myself as the 'author' of the collection as a whole, but I'm not sure that makes strict sense. I would suggest going with your latter option, even though it's a little ugly. At that point, we're really constrained by the Atom spec and in some technical sense you (or some contact at your organization) is the author of the feed even though you're not the person creating the content of the individual entries. Second, hAtom demands 'entry-content' and makes 'entry-summary' optional. In the first example, there's neither content nor summary (because that's how the client wants it). In the second, the text is really more in the nature of a summary than content, but content is the required item. Atom demands entry:content, hAtom assumes it's the empty string [1] if you don't add it. Finally, the articles all have a 'source' (i.e. the publication where they appeared), but I'm unclear on how to represent that in hAtom. It's always OK to add new things semantic elements, though obviously others won't know what they are -- until they're added to the hAtom spec: - looking through the Atom spec (especially here [2]) for something you can use (via?) and bring it back to the group for discussion - raise an issue in hatom-issues [3] for what's missing and what you [update] I've just looked at what you've done. It's OK as-is [4,5]. What's the best course of action in cases like these? My use-case doesn't exactly fit hAtom because it doesn't meet the mandatory 'author' and 'content' requirements. But at the same time, it looks as if hAtom fits better than anything else. Should I a. Force my listings into the hAtom mold, by calling the summaries 'content' (and putting in an empty content block in the first case), and adding an author somehow, or b. Avoid using hAtom at all, on the grounds that if I can't meet the requirements, I shouldn't deceive innocent robots by promising them hAtom and not delivering? a. is not an issue -- call your summaries entry-summary and entry-content will default to the empty string Beyond that, I think you're OK except for the author ugliness. I just ran it through the AUMFP and it looks like it's going in the right direction. Regards, etc... David [1] http://microformats.org/wiki/hatom#Entry_Content [2] http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rel_attribute [3] http://microformats.org/wiki/hatom-issues#hAtom_0.2 [4] http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.2.7 [5] http://microformats.org/wiki/hatom#Entry_Permalink ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Experimental implementation of hAtom on diveintomark.org
Mark Pilgrim wrote:
http://beta.diveintomark.org/archives/2004/10/18/exit
Based on Wordpress 2.0.2. No changes were required in the Wordpress
code; it already marks up categories with rel=tag, and everything
else could be done in my theme files.
One question: does the vCard need to be inside the hentry? Because
mine isn't, and it would be inconvenient (though not impossible) to
move it. I see something on the wiki about a nearest in parent
algorithm, but I missed the discussion about it and I'm not
comprehending the sample code at the moment.
It's looking good to me -- I'm just putting the finishing touches on a
version of the AUMFP for hAtom 0.1. Here's what I'm seeing right now
(hopefully this isn't too obtuse):
{'@index': 'hentry-1',
'author': [{'@index': 'vcard-1',
u'fn': u'Mark Pilgrim',
'n.family-name': u'Pilgrim',
'n.given-name': u'Mark',
u'url': u'mailto:[EMAIL PROTECTED]'}],
u'bookmark': u'http://beta.diveintomark.org/archives/2004/10/18/exit',
u'entry-content': u'pIt\u2019s time for me to find a new hobby.
Preferably one that\ndoesn\u2019t involve angle brackets. Or computers.
Or\nelectricity./p',
u'entry-title': u'Every exit',
'tag': [{'@index': 'tag-1',
u'name': u'general',
u'uri':
u'http://beta.diveintomark.org/archives/rooms/general/'}]}
The algorithm kinda sucks and is misnamed as Dimitri notes. Here's what
I'm doing now.
Basic loop -- look through parents:
- look at the parent of the 'entry' for a proper hCard
- if any hCards found, use all of them
- if not found, repeat on the parent of the parent
Definition of a proper hCard:
- it must be an address
- it must have class 'author'
- it must not be in an entry
This is a little more comprehensible. The next change I would suggest
(for 0.2) is that the (hcard author) should be findable inside of an
address element.
Regards, etc...
David
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Almost Universal Microformats Parser 0.6.0
This has been updated for hAtom 0.1: http://www.blogmatrix.com/tls/src/aumfp-0.6.0.tar.gz Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom 0.1 question: Author
Andreas Haugstrup wrote: I want to change my blog output to be hAtom compatible. It looks pretty straightforward, but I have a question about author information. I don't sign my name with every blog entry. I'm just me on my blog and I don't see the point. Looking at hAtom it seems that Entry Author is optional, but then it also says: if the Entry Author is missing - find the Nearest In Parent address element(s) with class name author and that is/are a valid hCard - otherwise the entry is invalid hAtom The Nearest In Parent link points to a page I don't really understand (being a non-programmer) URL: http://microformats.org/wiki/algorithm-nearest-in-parent My blog is at URL: http://www.solitude.dk/ . Would I be correct in assuming that if I change the link on my name at the top to an hCard then the author requirement of hAtom is satisfied? This is probably what you're looking for: address class=vcard author style=display: inline span class=fnMy Name/span /address As speced: - you need an address element - you need class name author - you need a hCard Instead of doing the display:inline trick (to stop block behavior), you should be able to define a CSS rule address.vcard to do the styling also. The Nearest in Parent link is mainly for the benefit of parsers. Note for hAtom 0.2: it should be that the address element _contains_ an author hCard. Also does this mean that if I one day choose to omit my name from my blog front page I cannot have a valid hAtom front page? Is this intended? I'm not sure I want to leave that top box on every page, but I would also like my blog to be valid hAtom... This is correct. The reason is we decided that hAtom pages must translate to valid Atom feeds and Atom requires feeds require an author. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Rejoice: Microsoft has invented Microformats!
Ray Ozzie demoed something called Live Clipboard [1] at ETech. The application shouldn't be of any surprise to the folks here, though there's no doubt there is a clever, useful and original part to what MS has done. Here's [2] what Ozzie claims: We've defined small XML schemas, microformats that represent the data elements that we might be able to exchange between sites. Where is the clipboard of the web. What is the thing that lets people get information from one site, one web app to another as easily as it's possible to do today with GUI-based apps. The microformats we defined are in fact hCard and hCalendar. I'm not trying to be over sensitive here, I'm sure it's something of an oversite -- perhaps he meant to say reused. Maybe. Here's my blog post http://blog.davidjanes.com/mtarchives/2006_03.html#003555 Regards, etc... [1] http://tinyurl.com/mabsy [2] http://radar.oreilly.com/archives/2006/03/etech_ray_ozzie.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom - ready for 0.1?
Dr.Ernie Prabhakar wrote: Stick a fork in it, looks done to me. :-) Great work, everyone. I'm sure there's much more that could (and will) be done, but this is an excellent foundation. Best, Thanks. You all have 20 hours to object :-) to the official 0.1izing of hAtom. If there's no objections, I'm going to do it first thing to tomorrow morning EST. I am going to add Robert's suggestion that the id attribute of a hentry element without a permalink gets added to the page's URI to create the implied permalink for the hentry. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom suggestions
Robert Bachmann wrote: Opacity --- [A]ny microformat content inside a blockquote or cite element within the Entry is should not be considered part of the Entry. I think this should also apply to q, since q is very similar to blockquote. This is what I meant to have in there. Done. Note that this whole thing came from a very very last minute discussion I had with Tantek while leaving Google after Mashup Camp, to clarify the whole opacity thing (and to avoid using that word). I believe this use of BLOCKQUOTE/Q will be transportable to other microformats. Entry Permalink --- [I]f the Entry Permalink is missing, use the URI of the page IMO this should be changed to * If the Entry Permalink is missing, the URI of the page is used. * If the Entry element has an ID attribute it will be append to the page URI. So the permanent link for div class=hentry id=bar ... /div !-- found on http://example.com/foo.html -- would be http://example.com/foo.html#bar. I'm for this. Does anyone have any objections? Feed title -- Feed Permalink -- I'm not saying no, I'm not saying yes: we're just not going to do this in 0.1 to get this out the door. rel-tag and categories -- How should rel-tag's be mapped to Atom categories? Someone suggested that a href=http://example.com/tags/foo;bar/a should be mapped to atom:category term=foo label=bar / An other way would be atom:category term=http://example.com/tags/foo; label=bar scheme=http://microformats.org/wiki/rel-tag#Profile; / I added this earlier this morning under Feed Category and Entry Category, following the first pattern you give there. Let's leave the SCHEME part alone for now, unless anyone has any major objections. Parsing rules - I think we should create a page similar to hcard-parsing for hAtom. I noticed there's already a page named hatom-hints which has seems to have the same purpose. Maybe it should be renamed to hatom-parsing? Sure. Go ahead if you want. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom permalink
Benjamin Carlyle wrote: My feeling on this issue is that there is generally no requirement to allow multiple a elements to be marked rel=bookmark. Certainly multiple a elements with the same or different href values should be permitted, but marking more than one as the bookmark seems extraneous to me at this time. I think we would need specific examples to justify the permission for multiple bookmarks, especially if they are permitted to contain different href values for the same lang and type attributes. Those different href values must pertain to different contexts within the html document, and we currently have no reasonable means to determine which belongs to the hentry and which to the unknown context. I would prefer that hAtom 0.1 contain text similar to: An entry must contain at most one element marked as the Entry Permalink for each media type and language This requirement can be relaxed as a justification and a corresponding technique for disambiguation arises. This wording also allows bookmarks in different formats and languages, which I think would be normal to permit for any such link. My issues: - have we seen an entry with multiple different permalinks, depending on the language, anywhere in the wild? - does this translate to Atom? I.e. are we just making stuff up because we might think it will be useful in the future? Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] thought: weekly microformats meetups
Tantek Çelik wrote: My first thought is early Monday evenings like 5-6pm pacific time. We could also try one on 2/13 and see how it goes. 2/20 is during MashupCamp, but I think enough microformatters will be there to hold an impromptu meetup. How about having one after Mashup Camp, on the 21st? Just saying because Monday night goes till 12 PM; on Tuesday it ends at 4:00 PM ... and my flight back to Toronto doesn't leave until 10:15. Regards, etc... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hatom parsing question
The AUMFP doesn't match up with the hAtom spec at this second because we've done quite a bit of changing in terminology over the last 5 weeks and I haven't updated the code base. This is what's causing the problem you're seeing there. I'll put on my list of to-dos to get this to where the spec is and I suspect your problem will go away. Regards, etc... David Chris Casciano wrote: Over the weekend I was looking at the feasibility of moving the default textpattern template[1] over to hatom and I seem to have hit a snag (or lack of understanding on my part. At its simplest form, here's what the output of the basic posting code looks like marked up with hatom: http://placenamehere.com/temp/hatomtest.html It contains the following header inside the post entry... h3a href=http://127.0.0.1/index.php?id=7; rel=bookmark class=headlineTest Post/a #183; abbr class=published title=2006-02-05T17:03:32-0800a few seconds ago/abbr by span class=authorChris/span/h3 When i run that though the the Almost Universal Parser[2] it seems to pick up both the published date as well as the author values, but the title it is outputting for the post is the full text of the h3 element: Test Post · a few seconds ago by Chris Is this parser error, some clash between the spec and markup used by this template? Is there a remedy that doesn't involve completely changing the semantics of the original template? [1] the default txp code/template can be seen here: http://textpattern.net/wiki/index.php?title=Default_Forms#default [2] http://www.trinityanne.com/tools/extract/?uri=http%3A%2F%2Fplacenamehere.com%2Ftemp%2Fhatomtest.htmlmicroformat=hatomsubmit=Submit --[ Chris Casciano ] [ [EMAIL PROTECTED] ] [ http://placenamehere.com ] ___ 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
[uf-discuss] FYI: ROR Structed Feeds/MeaningFuel
This looks like some other sort of structured data initiative. Does anyone know anything else about them? http://www.rorweb.com/ http://www.meaningfuel.org/wiki/index.php?title=Main_Page Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] locality sans adr;abbr for state/country etc?
brian suda wrote: David Janes -- BlogMatrix wrote: If you were to do this (I'm not saying it's a good or bad idea) wouldn't you do it the other way, with the machine readable data inside the title? abbr class=region title=CACalifornia/a, abbr class=country title=USU.S.A./abbr except by definition of the ABBR element, the text node is the short form. So it would have to be abbr class=region title=CaliforniaCA/abbr you could do span class=region title=CACalifornia/span and that is both valid HTML and the microformat parser should use California in this instance. Isn't this the opposite of datetime-design-pattern though? I'm thinking here ... maybe we're operating under different assumptions ... of CA is a computer readable form, not as an abbreviation. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] locality sans adr;abbr for state/country etc?
Ryan King wrote: On Jan 16, 2006, at 1:34 PM, David Janes -- BlogMatrix wrote: Ryan King wrote: Why not: p Unbelievable. Yesterday's high temperature in span class=adr localitySalem/span it was 57 degrees out. /p Because locality is a subproperty of adr. They can't be on the same element. Let me ask this -- would we lose something by allowing this type of compacting? It seems to me there's no information loss. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Universal Feed Parser 4.2 will support microformats
Mark Pilgrim wrote: I just checked support for basic microformat parsing into feedparser.py CVS. Currently supported: - rel=tag (maps to 'tags', like atom:category, rss:category, dc:subject, etc.) - rel=enclosure (maps to 'enclosures', like rss:enclosure and atom:[EMAIL PROTECTED]) - XFN To David: sorry, I decided against using your Almost Universal Microformat Parser because it requires well-formed XHTML, which is unacceptable for my needs. *sniff* :-) I hear what you're saying though. It does use TIDY to clean up malformed HTML but since I assume you're going though each entry and pulling out the contents, that would be somewhat expensive. I may, however, try to adapt your code to handle more complicated microformats like hCard, which would be quite messy to support with my current SAX-based approach. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] entry permalink in hatom
Ryan King wrote: In http://microformats.org/wiki/hatom#Entry_Permalink, we have: This may be a microformat in itself: rel-bookmark. Which does not seem neccessary, as 'bookmark' is defined as a link type in HTML 4 [http://www.w3.org/TR/REC-html40/types.html#h-6.12]. Why don't we just reference the HTML spec here? I've been kind of pushing this for the last few months in the background (that is rel-bookmark). I was just thinking we'd make it explicit with a page that basically just references the HTML spec. Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] entry permalink in hatom
Tantek Çelik wrote: An explanation is different from a specification. I would welcome a tutorial on rel-bookmark on microformats.org -- let's just be very clear that it is NOT a new microformat, nor would it be a specification. Perhaps we could call it: http://microformats.org/wiki/rel-bookmark-tutorial Other suggestions for indicating that something is a explicitly an informative tutorial rather than a specification (I'm not saying we have to always append -tutorial, but naming conventions tend to be useful, especially when one could easily confuse a /wiki/rel-bookmark page as being a specification since the URL looks like other /wiki/rel-* pages). Conceptually, is there a microformat rel-bookmark or not (irregardless of who is providing the spec)? Because if there is, that's the name where people are going to look. This of course code just say this is defined by HTML 4.01 and here's how we use it [[rel-bookmark-tutorial]] Regards, etc... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom and blog-post-* need some more work
Dr.Ernie Prabhakar wrote: Hi David, On Dec 31, 2005, at 9:58 AM, David Janes -- BlogMatrix wrote: I don't even have the slightest idea how to respond to this. I've been working on hAtom since August (hardly a rush), constantly soliciting feedback, documenting progress and descions, recently providing code, and so forth. Now suddenly a new there's some new microformat principles -- not appearing on the Wiki in any obvious place or (particularly) the process page. I certainly affirm your efforts to play by the rules and solicit input. I think what Tantek may be reacting to was the perceived pressure to formalize hAtom as an official microformat. I think you've done a fantastic job of documenting 'hAtom' per se, but there are valid concerns about taking it to the next level. Sure, and I've been consistently soliciting input on the nomenclature for a blog post microformat and changes have been made ... bookmark, for example ... based on this input. Furthermore, I have no issues with debating and or changing the nomenclature involved. For example, two or three days ago I explained the options that were available to us for the various elements, the precedence of HTML is using the word title or heading to mean title and why the word summary is particularly ill-suited in the the blog world for describing a title. (Direct responses: 0) If there's a process, it can be followed by anyone, even if everyone here went away and was replaced by some other group of people. If hAtom breaks the process in any sort of non-trite way, I'll be the first to say that we should change it. But if we're just debating terminology, well let us debate that as opposed to a broad statement that I've been trumped by precedent, process and principles of the community. I have no issue renaming elements in hAtom, as long as there's a microformats process that I'm actually following -- something that I've seriously attempt to do since the second week I've been on this list. I'm assuming the process is driven by documentation and discussion, and not by personality. I think Tantek's principles are useful, and I agree they should be on the wiki. Are they? I'm not sure: Well, have a look. By this is something that should be debated by the community -- if the principle is one name/one meaning and first use, first dibs, lets discuss the pros and cons of that. Strangely, I note that on the few discussions on namespaces (for example, [1]) the answer isn't we don't need namespaces since we'll never reuse CSS classes to mean something different than a previous use. Just because other standards keep inventing new terms for the same thing, doesn't mean we should. We should actively AVOID inventing new terms for the same thing, even if those new terms come from other standards. Thanks for all your efforts. No sweat. Well, actually, quite a bit of sweat -- which is why it's nicer to hear we should be doing this differently two months in rather than 4. Regards, etc... David [1] http://microformats.org/wiki/faqs-for-rdf#What_about_namespaces_for_the_attributes.2C_should_I_use_.22xxx:term.22.3F ___ 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
[uf-discuss] Almost Universal Microformat Parser: source code
The AUMFP provides Python (2.3) classes for extracting microformat content from HTML documents, and includes classes for hCard, hCalendar, xFolk, and rel-tag. It should be easily extendable to new uF types. The source code is here [1] as a tarball and includes a CGI interface. A running demo is here [2] with samples and a minor amount of documentation available here [3] and here [4]. I'd like to know if you're using it in a project (preferably credited) and I'd like bug fixes and new parses fed back to me. Regards, etc... David http://www.blogmatrix.com [1] http://www.blogmatrix.com/tools/src/ [2] http://www.blogmatrix.com/tools/extract/ [3] http://blog.davidjanes.com/mtarchives/2005_12.html#003472 [4] http://blog.davidjanes.com/mtarchives/2005_12.html#003468 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] XOXO Comments
Try MochiKit [1].
var xoxo_elements = getElementsByTagAndClassName(*, xoxo)
for (var xi = 0; xi xoxo_elements.length; xi++) {
var children = getElementsByTagAndClassName(*)
for (var ci = 0; ci children.length; ci++) {
element = children[ci]
if ((element.tagName == UL) || (element.tagName == OL)) {
// ... do stuff ...
}
}
}
Regards, etc...
David
[1] http://www.mochikit.com/doc/html/MochiKit/DOM.html
Paul Bryson wrote:
David Janes -- BlogMatrix wrote...
What are you trying to do in Javascript? Certainly, you couldn't expect
all XOXO's in the wild to look like this.
Not at all. I want the JavaScript on MY page to be simple, I think I can
make it work easiest if every child of an XOXO on MY page has a
class=xoxo. So I was wondering if this is allowed or not.
I was not suggesting that any other page on the internet do the same as what
I am trying to do.
Atamido
___
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 - 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
- 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] Call for Victims (II)
Cool: http://tinyurl.com/btb8z I'm still trying to figure out if the structured blogging stuff is generating proper hreview or if there's a problem with my parser. A minor concern: I'm off to semi-vacation for a 10 day. Here's some samples if folks want to look at it: http://outputthis.blogspot.com/ http://pokemon.broadbandmechanics.com/~phil/mt/ Regards, etc... David Ryan King wrote: On Dec 12, 2005, at 7:22 AM, David Janes -- BlogMatrix wrote: The hAtom Template Rewriter now supports WordPress (as well as MovableType and Blogger). If you have a WordPress blog and would like to support the hAtom microformat, please send me a note and I'll set you up FWIW, I did mine by hand. Took about 5 minutes: http://theryanking.com/blog/ -ryan -- Ryan King [EMAIL PROTECTED] ___ 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
[uf-discuss] Call for Victims (II)
The hAtom Template Rewriter now supports WordPress (as well as MovableType and Blogger). If you have a WordPress blog and would like to support the hAtom microformat, please send me a note and I'll set you up Regards, etc... David http://www.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Call for Victims: Template Rewriter
Hi Steve, (1) If you're running Mozilla, Greasemonkey and all that, install: http://www.blogmatrix.com/tools/greasemonkey/microformat-action.user.js to identify MF content (2) The template rewriter: http://www.blogmatrix.com/tools/rewrite/ (3) I can't stress enough making a backup of your existing template(s) (4) The URIs above redirect to trinityanne.com -- this is a temporary thing. Please let me know how it works! Regards, etc. Steve Jenson wrote: I'd be willing to help. I have a Blogger blog. Steve On 12/10/05, David Janes -- BlogMatrix [EMAIL PROTECTED] wrote: I'm looking for Blogger, MovableType or TypePad bloggers to test my hAtom Template Rewriter tool. This is a web page that you input your existing script and out pops a rewritten script with all the appropriate hAtom css class/rel information added. Also, if you're using a different blogging platform and you'd like me to try to write a Rewriter for that, please send me a note (and a copy of your templates as attachment, if possible) Regards, etc... David http://www.blogmatrix.com ___ 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Call for Victims: Template Rewriter
I'm looking for Blogger, MovableType or TypePad bloggers to test my hAtom Template Rewriter tool. This is a web page that you input your existing script and out pops a rewritten script with all the appropriate hAtom css class/rel information added. Also, if you're using a different blogging platform and you'd like me to try to write a Rewriter for that, please send me a note (and a copy of your templates as attachment, if possible) Regards, etc... David http://www.blogmatrix.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Almost UMP:xFolk Supported
I've added xFolk [1] to the list of microformats the Almost Universal Microformat Parser handles. Examples: http://tinyurl.com/cdcfp (http://de.lirio.us/rubric) http://tinyurl.com/cddta (http://unalog.com/) Regards, etc... David [1] http://microformats.org/wiki/xfolk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Nomenclature Question
- RelHome? - rel-home? - Rel-Home? Variants of these across the rel-* are all available. My understanding is that this should be: - RelHome -- this official name - rel-home -- the wiki page name Yes, no? Regards, etc... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Almost UMP:xFolk Supported
C. Hudley wrote: On 12/8/05, David Janes -- BlogMatrix [EMAIL PROTECTED] wrote: I've added xFolk [1] to the list of microformats the Almost Universal Microformat Parser handles. Examples: http://tinyurl.com/cddta (http://unalog.com/) This is very cool, thanks! What is the intended meaning of the repeating @uri = http://unalog.com; here? Is it intended to be the identifier for the entry? I'm asking because there is a URI of sorts embedded in the COinS for each entry (see [EMAIL PROTECTED](Z3988)]). @uri and in fact @anything are little pieces of information the parser has picked up among the way, not necessarily part of the uF. In this particular case, it's the uri of the page being parsed. There's another I added this morning, called '@index' which allows the uF element to be corresponded to the parsed version. For example, '@id=vevent-3'means that the 3rd element with vevent in the class attribute is the one that was parsed. Over on gcs-pcs-list we've been talking about a simplification of the COinS spec when simply indicating what-the-identifier-is, which is (obviously) rather lost inside the OpenURL ContextObject inside the span. Lately we've considered instead just using class='uri' and a URI in a title or as the textnode content. I'm experimenting with something like this in the canary database as well. How about rel=bookmark (i.e. rel-bookmark) Not only is it used in hAtom, it's also part of the HTML spec [1] All of which brings me back to the question of clarifying where the identifiers are... Regards, etc... David [1] http://www.w3.org/TR/REC-html40/types.html#type-links ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Somewhat Universal Microformat Parser
Here's what I've been working on for the last couple of days. It's a
service -- actually, a front end onto a Python library/framework -- that
can rip apart microformats into a (hopefully) simpler format that will
be easier for programs to manipulate.
pages:
- the interface [1]
- an example of hAtom parsing [2]
you can paste XHTML fragments in -- try something from the hReview page [3].
microformats supported:
- hatom - pretty good
- hreview - a lot of work is needed
- hcard - pretty good
- rel-tag - actually, a slightly expanded rel-reviewed-tag from hreview
I hope to have vCalendar and xEntry in their this afternoon/tomorrow.
Here's what a parser looks like [4]
Regards, etc...
David
http://www.blogmatrix.com
[1] http://www.davidjanes.com/microformats/extract/
[2]
http://www.davidjanes.com/microformats/extract/?uri=http%3A%2F%2Fblog.davidjanes.com%2Fmicroformat=hatomsubmit=Submit
[3] http://microformats.org/wiki/hreview
[4]
class MicroformatHReview(microformat.Microformat):
def __init__(self):
microformat.Microformat.__init__(self, hreview)
self.CollectClassText('version')
self.CollectClassText('summary', text_type = microformat.TT_XML_INNER)
self.CollectClassText('description', text_type =
microformat.TT_XML_INNER)
self.CollectClassText('type')
self.CollectClassText('dtreviewed', text_type = microformat.TT_ABBR_DT)
self.CollectClassText('info', text_type = microformat.TT_XML_OUTER)
self.CollectClassText('reviewer', text_type = microformat.TT_XML_OUTER)
self.CollectRelAttribute('permalink', 'href')
self.CollectClassText('rating', text_type = microformat.TT_ABBR)
self.CollectClassText('best', text_type = microformat.TT_ABBR)
self.CollectClassText('worst', text_type = microformat.TT_ABBR)
self.CollectClassModifier('item')
self.CollectRelReparse('tag', reltag.MicroformatRelTag())
self.CollectClassReparse('reviewer', hcard.MicroformatHCard())
self.DeclareRepeatingName('reviewer')
self.DeclareRepeatingName('tag')
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview Question/Statement
Tantek Çelik wrote: From a schema standpoint, yes, agreed completely. As to the names of the specific fields, as noted above, we can reuse the property/value construct from hCard, and avoid having to have both rated and rating. Thanks very much for the feedback David. This will be a definite improvement in hReview 0.3. I'm getting into the spirit of what the spec meanings now, so it's all becoming a little clearer. I've modified my parser a bit to reflect your's and Ryan's comments, plus a better understanding how reviewer/item works. Here's some parsed hReviews, randomly chosen: http://tinyurl.com/ctg6m http://tinyurl.com/c7kyd http://tinyurl.com/dmxnr http://tinyurl.com/99nwc Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Almost UMP: hCalendar Supported
Buffalo Bills in EvDB http://tinyurl.com/ck7jr Some Chilean event http://tinyurl.com/csedz Ice Hockey stuff -- alas missing the times. Perhaps there's something wrong with my parser? http://iceoasis.shrub.ca/ http://tinyurl.com/ahrs3 Brian Suda's lesser known holidays: http://tinyurl.com/9cz2c As per usual, start here if you want to try it yourself: http://www.davidjanes.com/microformats/extract/ Regards, etc... David ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Problems with hCalendar formatting
Tantek Çelik wrote: On 12/7/05 12:59 PM, David Janes -- BlogMatrix [EMAIL PROTECTED] wrote: I'm looking at this [1]. It looks like the dtstart and dtend are outside of the associated vevents and thus shouldn't be parsed. Agree or disagree? Regards, etc... David [1] http://we05.com/program.cfm Note the judicious use of headers attributes to link the vevent table data cells to their dtstart and dtend table header cells. Technique described here: http://microformats.org/wiki/hcalendar-brainstorming#Tabular_Data Ah, brilliant. Here's the Web05 data parsed: http://tinyurl.com/cdy5m I still need to work on the categories stuff. Regards, etc... ___ 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] rel=homepage?
Danny Ayers wrote: On 12/6/05, Andreas Haugstrup [EMAIL PROTECTED] wrote: Sorry, that was a typo. rel=start gets shown as a home button in the browser. Thanks - got it. [[ Start Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection. ]] Hmm, I'm not sure, might there not be a conflict in the blog archive scenario - archived post #1 being rel=start..? Yes, exactly. After reading through the last couple of posts, I would think that rel=home has to be something different. Regards, etc... ___ 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
[uf-discuss] Fwd: Uploading the Semantic Web into Google Base?
I'm forwarding this e-mail from the semantic web mailing list as there seems to be some interesting ideas that can be drawn upon. Here's [1] an example FOAF profile on Google Base. Looks very doable for hCards, no? Regards, etc... David http://www.blogmatrix.com [1] http://base.google.com/base/items?oid=18377492770755894565 Original Message Subject:Uploading the Semantic Web into Google Base? Resent-Date:Mon, 05 Dec 2005 09:44:43 + Resent-From:[EMAIL PROTECTED] Date: Mon, 5 Dec 2005 10:38:48 +0100 From: Chris Bizer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi all, we have developed a crawler that collects FOAF profiles from the Web and uploads them into Google Base. The profiles that our crawler has uploaded so far are found at: http://base.google.com/base/search?authorid=1107889 It's nice to see how geo coordinates in the profiles get rendered as Google maps: http://base.google.com/base/items?oid=396209429990798149 And it's strange to own Tim Berners-Lees profile on Google Base ;-) http://base.google.com/base/items?oid=12665418913991123756 If you want us to upload your profile also, please add it to the FOAF Bulletin Board http://rdfweb.org/topic/FOAFBulletinBoard and it will be included in our next crawler run. If you want to be removed from Google Base, please send us a mail and we will remove you. It's strange that there hasn't been too much discussion in the Semantic Web community about Google base yet. Should we be happy, that Google provides us with a fast repository and a nice search interface? Or should we be critical because a single company is trying to gain a dominant market position by building a single central Web data repository? Should we be happy that Google is promoting the idea of publishing structured information on the Web? Or should we be critical to their (over-)simplification of the RDF data model? All comments are welcome. Cheers, Chris Bizer and Richard Cyganiak -- Chris Bizer Freie Universität Berlin Phone: +49 30 838 54057 Mail: [EMAIL PROTECTED] Web: www.bizer.de ___ 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
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] communications log marked up semantically using uF's.
dl class=telcall dtCaller/dt dd+44 (0)7860 138 086/dd dtType/dt ddIncoming/dd dtStart/dt ddabbr title=20051124T22:36:00Z24 Nov, 22:36/abbr/dd (etc) /dl Regards, etc... David Simon Kittle wrote: Hi, After the brief discussion and thoughts I gained from the experts I've marked up an entry for my desired communications log. Although it's not directly a discussion of a proposed or upcoming uF in itself I was hoping for just general thoughts on the design - I've used elemental uF's and uF design patterns where I can see there use. An example would be: div class=telcall !-- tel elemental uF -- div class=telspan class=value+44 (0)7860 138 086/span span class=typemobile/span/div !-- type of telcall -- span class=typeIncoming/spanbr / !-- using date-time-design pattern -- abbr class=dtstart title=2005-11-24T22:36:0024 Nov, 22:36/abbr - abbr class=dtend title=2005-11-24T22:46:0022:46/abbrbr / !-- optional contact, specified as a vcard -- div class=contact div class=vcardspan class=fnDavid/span - span class=orgNTL/span/div /div div class=notesSpoke about blah blah, arranged blah to be done on blah blah./div /div Any thoughts on how this could be improved would be greatly apprecieated. Regards, Simon -- Simon Kittle Isa 40:30-31 http://www.moseyondown.com ___ 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] Avatar Microformat ?
Instead of narrowing the problem to letting users specify their own avatar, why not let them specify their own vcard (or the URI to that vcard), solving not only the the avatar image problem but allowing alternate ids depending on the context? At this point, I'll mention a uF I started sketching out several days ago for alternates [1]. One could then have a page saying that these 3 vcards are alternates of one another doing something like (under one proposal): ul class=alternates myid li class=vcard myid... vcard 1 .../li li class=vcard myid... vcard 2 .../li li class=vcard myid... vcard 3 .../li /ul (myid is an arbitrary string). You would use ol if there was a preference involved. If you then added 'id=vcard1' (etc) to each of the lis, the vcards are individually URI addressable. Regards, etc... David [1] http://microformats.org/wiki/alternates-brainstorming PS. Since I misunderstood the question initially, I might as well give the vcard transformation I did on Planet Gnome: div class=person-info a href=http://tirania.org/blog/index.html; title=Miguel de Icaza img class=face src=http://planet.gnome.org/heads/miguel.png; alt= br / Miguel de Icaza br / (miguel) /a /div ... becomes ... div class=vcard person-info a class=url href=http://tirania.org/blog/index.html; title=Miguel de Icaza img class=photo class=face src=http://planet.gnome.org/heads/miguel.png; alt= br / span class=fnMiguel de Icaza/span br / (span class=nicknamemiguel/span) /a /div Charles Iliya Krempeaux wrote: Hello, On 11/24/05, Tantek Çelik [EMAIL PROTECTED] wrote: On 11/23/05 11:05 PM, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote: Hello, Is there a Micformat for specifying a user's Avatars? Could you be more specific about what you mean by an Avatar? Here's basically what I want. I want to be able to specify a list of avatars. (I.e., I want to be able to specify more than one avatar for myself. And possibly associate metadata with each avatar.) Here's a use case for it. Consider Planet GNOME http://planet.gnome.org/. This site aggregates the blogs of many of the GNOME developers. Next to each post there is an avatar for each person. (Specifically, this site uses a special kind of avatar called a Hackergotchi.) Now, this site is running Planet Planet http://planetplanet.org/. And I know that it is NOT getting these avatar images from each of the authors websites. It has them stored locally. And there is an internal configuration file that associates avatar images with blog. I think it would be better if it would let blog authors specify their own avatar. A microformat for avatars would help software (like Planet Planet) get each person's avatar. (If the Planet Planet software could get a list of each blog author's avatars, and then find the Hackergotchi avatar, and then use that... it would be good.) Perhaps providing a URL to an example or two would help. http://planet.gnome.org/ http://planet.debian.net/ http://planet.ubuntulinux.org/ Anyone working on one? (A Microformat where a user could specify a list of avatars that one uses would be preferable.) If you're speaking of Gravatars for example, then hCard already solves this problem, as it provides the key pieces: url, email, fn, logo. The problem with hCard is that it displays you avatar (on the page). It would be nice if you could declare your avatars without having to display them. I.e., maybe something along the lines of: a rel=avatar href=/image/avatar1.png.../a a rel=avatar href=/image/avatar2.png.../a a rel=avatar href=/image/avatar3.png.../a (Instead of using img tags.) (I didn't find anything in the wiki about one.) Try the search box in the left column of the wiki. When I search the wiki for Avatar, I found it on one page: http://microformats.org/wiki/blog-post-formats Sorry, I should have worded that better. I didn't find anything along the lines of what I wanted. Which only discussed an example of an existing blog post format that uses an Avatar which *could* use hCard. But you're right. We should at least provide a place to answer questions like how would I represent X, where X can potentially be represented using an existing microformat. I've added Gravatars and a few other applications to a new section on the hCard spec. http://microformats.org/wiki/hcard#Additional_Applications I think it is desirable to be able to specify more than just gravatar avatars. (For example, using hackergotchi avatars would also be desirable). For example, maybe something like: a class=href-hackergotchi rel=avatar href=/image/avatar1.png.../a a class=href-gravatar rel=avatar href=/image/avatar2.png.../a a rel=avatar href=/image/avatar3.png.../a (I guess you could equally use the link tag for this too.) See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/
[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
