[uf-discuss] Re: Wow -- Hicks takes on Microformats in Safari
I use Camino as my primary browser. It's grand. ;) On 6/20/06, Michael MD [EMAIL PROTECTED] wrote: Its certainly an interesting task... as a plugin or shipped right in the browser... though i'd love to see it in camino first... having support in sfari does me about as much good as tails does ;) this is the first I've heard of Camino so I did a search for it - another Mac browser... It says that its based on Mozilla - so maybe tails could be made to run on it somehow? Not having access to a Mac capable of running OSX I can't try anything like that here. I wish I was able to test calendar stuff in Apple's iCal here... has anyone had any success with any kind of mac emulator for this kind of testing? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Agent Provocateur, Citizen Agency Open Source Ambassador-at-Large Work / citizenagency.com Blog / 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
Re: [uf-discuss] more hatom rambling - detection
Chris, How about this: * look for hentry * if found, traverse ancestors to see if there's an hfeed ** if found, add hfeed to list of feeds ** otherwise, add page to list of feeds, stop looking for hfeeds * repeat :DG On 6/20/06, Chris Casciano [EMAIL PROTECTED] wrote: Let me continue my hatom spec/issue rambling by piggy backing on the recent hcard detection / class hijacking thread... Given [1]: the Feed element is optional and, if missing, is assumed to be the page What are the rules for detecting that an hatom feed exists in a page? Like the other thread, I'm thinking less about the context of actually parsing the document with an hatom capable parser, but more in the detection context where you may have some other application (browser or plugin) detecting that the feed exists and preparing to hand off the document to another (feed reading) application. [1] http://microformats.org/wiki/hatom#Feed -- [ 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
Re: [uf-discuss] Using hCalendar to Create History Timelines
Thanks for the links, Brian, and sorry for my delayed response. Mark Pilgrim states in that microformats-dev thread that it's problematic when it comes to marking BCE dates.[1] Tantek agreed, but responded that Alternatively, RFC2550 contains a proposal for representing BCE dates[2] [3], which looks promising, but I not clear from the microformats-dev thread that the method is workable for hCalendar. Are the methods discussed in RFC2550 valid for hCalendar and ISO dates? I can markup a some vevents with BCE dates for the list, using the RFC2550 guidelines, if that would help the conversation. I guess that I'm not clear on the status of RFC2550 with regard to hCalendar and the microformats community. On a different (but related) note, and using more recent events (20th century), here are three examples of some timeline markup I'm working on. All lack specific dates for the event, and instead span an entire month, but each uses different methods to represent the date in the code. The first example uses both a class=dtstart and class=dtend to represent the period of June 1953. I think I've made this to specs with the wiki example for hCalendar, specifically with regard to the end date being July 1, 1953 to include all of June 1953: div class=vevent span class=dateabbr class=dtstart title=19530601June/abbr abbr class=dtend title=195307011953/abbr/span span class=summaryAfrican-Americans in Baton-Rouge, Louisiana boycott segregated city buses./span /div The second example uses only a class=dtstart with a title value of 19540501 to represent the period of May 1954. The abbreviation tag wrap around the entire date, May 1954. Jeremy Keith's markup of the 15th-century Renaissance is somewhat similar to this[4]: div class=vevent abbr class=dtstart title=19540501May 1954/abbr span class=summaryBrown v. Board of Education of Topeka, Kansas./ span /div I'm not a fan of the previous method, simply because it uses a specific DAY (May 1, 1954) in the title attribute to represent the entire month. A third method, similar to the second, would omit a specific day and use only the year and month numbers in the title attribute, thus referencing the entire month: div class=vevent id=niagara-movement abbr class=dtstart title=190905May 1909/abbr span class=summaryNiagara Movement convenes (later becomes the abbr title=National Association for the Advancement of Colored PeopleNAACP/abbr)./span /div The second example isn't great because I can add specific dates for the Brown v. Board trial, but the first is more problematic because there aren't specific begin and end dates for the event in question. I'm cautious about the third example because I haven't found any hCalendar examples that use only the year and month (are there any?). But, from my novice perspective, this solution seems to make the most sense, and is most inline with the ISO Date formats.[5] Barring these caveats, which is the better method? Or are there better methods? Thanks, Jeremy [1] http://microformats.org/discuss/mail/microformats-dev/2005- December/46.html [2] http://microformats.org/discuss/mail/microformats-dev/2005- December/47.html [3] http://www.ietf.org/rfc/rfc2550.txt (section 3.5) [4] http://adactio.com/articles/1132/ [5] http://www.w3.org/TR/NOTE-datetime ; http://www.ietf.org/rfc/ rfc3339.txt ; http://en.wikipedia.org/wiki/ISO_8601; http:// www.iso.org/iso/en/prods-services/popstds/datesandtime.html On Jun 16, 2006, at 10:24 AM, brian suda wrote: We discussed briefly the issues with ISO Dates on the Dev List http://microformats.org/discuss/mail/microformats-dev/2005-December/ 45.html Recently, at reboot 8, which was all about the 14th century renaissance, there has been use of vevents to describe events that took place hundreds of years ago[1,2]. Because hCalendar uses ISO Dates we are limited. We can't switch easily between gregorian and julian, as well as describe BCE dates, or circa 1492. -brian [1] - http://adactio.com/articles/1132/ [2] - http://adactio.com/journal/1141/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] more hatom rambling - detection
Having a XMDP URL declare in the head of the document would say for certain that in this page, when you come across these values, you can safely assume they are part of the microformat without there is not guarantee that class=vcard means this is an hCard microformat. Now, just having an XMDP URL in the profile does not guarantee that microformats are present, some CMSes add the XFN profile automatically with or without actual XFN values. I would say that the profile can be used for Detection, in the RSS world you simply add a link element in the head with special rel values. The browser is not actually following that link and determining that it is an RSS file, i could serve-up an image... the browser would say that there is an RSS feed here, then when you suck it into the RSS Reader it could still fail. Going solely off of the XMDP Profile values would cause some false-positives. Short of actually then parsing and checking the output, THEN saying microformats were found, i'm not sure you can do full-proof detection. There was some discussion about auto-discovery awhile ago on the wiki[1], that might be a good place to document/update ideas and/or take this discussion to the Dev-List. -brian [1] - http://microformats.org/wiki/hcard-brainstorming#Auto-Discovery Chris Casciano wrote: Let me continue my hatom spec/issue rambling by piggy backing on the recent hcard detection / class hijacking thread... Given [1]: the Feed element is optional and, if missing, is assumed to be the page What are the rules for detecting that an hatom feed exists in a page? Like the other thread, I'm thinking less about the context of actually parsing the document with an hatom capable parser, but more in the detection context where you may have some other application (browser or plugin) detecting that the feed exists and preparing to hand off the document to another (feed reading) application. [1] http://microformats.org/wiki/hatom#Feed ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Using hCalendar to Create History Timelines
Jeremy Boggs wrote: Mark Pilgrim states in that microformats-dev thread that it's problematic when it comes to marking BCE dates.[1] Tantek agreed, but responded that Alternatively, RFC2550 contains a proposal for representing BCE dates[2] [3], which looks promising, but I not clear from the microformats-dev thread that the method is workable for hCalendar. Are the methods discussed in RFC2550 valid for hCalendar and ISO dates? --- Since hCalendar is modeled after iCalendar (RFC 2445) and iCalendar uses ISO dates, we are only modeling ISO dates. At the time there is no activity in using RFC2550 dates, because they can't map back to ISO dates (because ISO can't represent BCE). This is a limitation of the older iCalendar technology. The second example uses only a class=dtstart with a title value of 19540501 to represent the period of May 1954. The abbreviation tag wrap around the entire date, May 1954. Jeremy Keith's markup of the 15th-century Renaissance is somewhat similar to this[4]: div class=vevent abbr class=dtstart title=19540501May 1954/abbr span class=summaryBrown v. Board of Education of Topeka, Kansas./span /div Technically, this would only represent the 1st day as you mentioned. The W3C has a date-time note[1] document, which shows that a valid ISO Date can simply be -MM (without a day component). It is questionable what will happen to a date like this once imported into a calendaring application, but abbr class=dtstart title=195405May 1954/abbr would be a valid ISO date. Which is what you concluded in your third method. Or are there better methods? --- it is not wildly supported by parsers yet (and i'm not sure it is better), but there are a few more properties in the iCalendar RFC that could be used, namely DURATION. With duration you specify a string that defined a time period: Example: A duration of 15 days, 5 hours and 20 seconds would be: P15DT5H0M20S A duration of 7 weeks would be: P7W So for a month long event you could use a duration of 31 days, (or 365 days, or 365274 days, etc.): div class=vevent abbr class=dtstart title=19540501abbr title=P31D class=durationMay/abbr 1954/abbr span class=summaryBrown v. Board of Education of Topeka, Kansas./span /div I hope this helps. -brian [1] - http://www.w3.org/TR/NOTE-datetime ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Wow -- Hicks takes on Microformats in Safari
On Jun 20, 2006, at 10:37 PM, Michael MD wrote: Its certainly an interesting task... as a plugin or shipped right in the browser... though i'd love to see it in camino first... having support in sfari does me about as much good as tails does ;) this is the first I've heard of Camino so I did a search for it - another Mac browser... It says that its based on Mozilla - so maybe tails could be made to run on it somehow? No, its really only based on Gecko, it lacks the rest of the Mozilla runtime stuff (a feature, not a bug- its Cocoa-based and much faster than Firefox). -ryan -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Book Contents Format
There might be something gleaned from TEI: http://www.tei-c.org/ Maybe not. -Ross. On 6/21/06, Tantek Çelik [EMAIL PROTECTED] wrote: On 6/21/06 2:33 PM, Scott Reynen [EMAIL PROTECTED] wrote: On Jun 21, 2006, at 4:24 PM, Alex Ezell wrote: That is, this is not to describe something like the Table of Contents, but actually structure each chapter or section or what have you. It seems that Project Gutenberg and the Distributed Proofreaders may be the leading edge on this front, but I thought that the microformatters would be a good place to start as well. I checked the wiki and the info was sparse, so I thought the mailing list readers might have more info tucked away on blogs somewhere. I assume you've seen these pages: http://microformats.org/wiki/book-brainstorming http://microformats.org/wiki/book-examples http://microformats.org/wiki/book-formats I suspect the wiki is sparse because there aren't many real world examples from which to draw semantics. There are two examples on the examples page and one points to bibliography markup for a plain-text book (as I believe all Project Gutenberg books are). So that leaves us with only one example from which to draw semantics That's not quite accurate. You can't dismiss the Project Gutenberg books because although they don't use angle brackets, their use of standardized whitespace and punctuation to represent various book semantics is a markup format of sorts and thus still quite useful from a implied schema research perspective. prompting the question: is there really a need for such a microformat? It's an interesting question, especially since a particular proposed book microformat (boom!) has been used to actually markup and *publish* a real physical book. http://www.alistapart.com/articles/boom Back when Håkon started working on boom, I gave him a bit of leeway, for various reasons: http://microformats.org/discuss/mail/microformats-discuss/2006-January/0028 70.html Suffice it to say that much of the microformats principles and process I have derived and designed from what I learned from Håkon. His instincts tend to be quite good. That said, I am still asking Håkon to go through the process with research of pre-existing formats, and naming of class names to reuse and take advantage of existing formats. Thanks, Tantek ___ 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] More Microformats Browser UI
Heh, yeah, that was the design that I was going to use in Flock except that Tantek disuaded me from using it because you'll never be able to keep up with all the microformats! Maybe in the prefs you could turn on and off detection of different formats... starting with hCard and hCalendar on by default? That said, this is not a long-term interface solution. For example, when you look at a Word document, you don't see image detection icons or table detection icons. We need to move beyond exposing that which *should* be marked up semantically to creating deeper interface concepts. For example, in Camino, when I right click on an email address, it asks Add to Address Book? We need to be thinking more along the lines of contextual behaviors for specific data types. Like right clicking on an event: Add to Google Calendar; an hCard Send email, read blog, view photos... etc. That's not to poo-poo your idea at all. It's where I started. But detection isn't what's cool -- nor is importing to *someplace else*. It's how we can improve the user experience in the context in which they find themselves -- without transporting them someplace else so that they have to figure out how to get back to where they were! So, here's a challenge: what kind of solutions can we come up with that are single click only? Chris On 6/21/06, Ben Ward [EMAIL PROTECTED] wrote: Chris Messina wrote: Beautiful: http://www.hicksdesign.co.uk/journal/a-proposal-for-a-safari-microformats-plugin Well, I saw Jon's post it this morning let out an involuntary cry/laugh/choke kind of reaction. I demo'd a terrifyingly similar concept to Tantek on Saturday [EMAIL PROTECTED] (whilst stealing his nachos, naturally). It's my bad for not posting weeks ago of course, but… wow. Similarity is proof of a good idea I hope. With thanks to Jon for the unintended kick up the arse to finish my write-up, I've finally published my interpretation of what is really a very similar idea: http://ben-ward.co.uk/journal/microformats-ui/ It's under a Creative Commons Attr+SA license, but as it says in the post if you want to implement it and can't meet the SA part for commercial reasons I'll happily relicense. The intention is just to encourage public evolution of the ideas. Regards, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Agent Provocateur, Citizen Agency Open Source Ambassador-at-Large Work / citizenagency.com Blog / 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
Re: [uf-discuss] Book Contents Format
On 6/21/06, Scott Reynen [EMAIL PROTECTED] wrote: I assume you've seen these pages: http://microformats.org/wiki/book-brainstorming http://microformats.org/wiki/book-examples http://microformats.org/wiki/book-formats Yes, and as evidenced by my email, they left me wanting more. is there really a need for such a microformat? From a research perspective, there is certainly a need. Now that entire books are searchable and excerptable (is that a word?) electronically, it's important that systems and humans can be easily given some context for these excerpts besides the title of the book. Especially in the realm of a concordance, where the closeness/distance of words to one another within lines, paragraphs, chapters, and entire books can be an aspect of study, this context becomes paramount. Yes, it's fairly esoteric, but some would argue that XFN is just as useful/useless. Honestly, I didn't think this mailing list would question the need for a microformat. Question its structure and its uses, of course, but question its necessity? It seems fundamental that a standard for presenting book-format texts should be written. /alex ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Book Contents Format
OK, I owe the list an apology. That last email came off as really pedantic. I guess what I came here looking for was some encouragement and support. As Tantek mentioned, there aren't many real-world examples. Perhaps, my project could be one such example and I would like for this group to have as much input into the final format I use as makes sense. I hope that clears the air a bit. Sorry for any ruffled feathers. /alex ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
