[uf-discuss] WP-XFN-hCard: Code Review?
Cross-posting because I didn't get a reply from -dev and I'd like to post this to my blog (but not before I get buddy-checked!)... I've never developed a WordPress plugin before, but I thought I'd give it a go... so if anyone wants to take a look at my code and let me know how I can improve it, I'd appreciate it! http://factorycity.net/projects/wp-xfn-hcard/ The output: http://factoryjoe.com/blog/roll/ Thanks, Chris -- 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] WP-XFN-hCard: Code Review?
On 5 Jul 2006, at 08:43, Chris Messina wrote: Cross-posting because I didn't get a reply from -dev and I'd like to post this to my blog (but not before I get buddy-checked!)... Nothing's come through on -dev since the 29th. For me at least. A case of cold-server rather than cold-shoulder ;) I've never developed a WordPress plugin before, but I thought I'd give it a go... so if anyone wants to take a look at my code and let me know how I can improve it, I'd appreciate it! http://factorycity.net/projects/wp-xfn-hcard/ The output: http://factoryjoe.com/blog/roll/ I'm not a WP user, so not much help on that front. The only thing I'd note, is that if your plugin is inserting the link to http:// technorati.com/contacts/referrer, you may want to see if WP gives you access to write out the full page URL instead. Referrers are really handy, but for all sorts of reasons often the referring URL might not get passed through. (faux 'home internet security' products, paranoid corporate firewalls and lame ISPs are all prime suspects). But meh, hardly worth losing sleep over. :) drew. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar / hCard implementation, check please
There are a few minor issues. 1) you have dtstart in two places, dtstart can only exist once, so the second portion would be ignored. To correct this, you can simply do away with the first dtstart inside the h2, and on the second one you can use the full date-time: abbr class=dtstart title=20060230T120012:00PM/abbr 2) The second issue is that 'status' has an enumerated list of values: statvalue = TENTATIVE ;Indicates event is tentative. / CONFIRMED ;Indicates event is definite. / CANCELLED ;Indicates event was cancelled. ;Status values for a VEVENT I would suggest that you either do way with class=status, or roll the open to the public... into the description. My only other suggestion (and it is not super important in this instance) would be to also mark-up the location with an hCard. This way people could extract the building data easily as well. You would have to place additional information in to the location, similar to this: dtLocation:/dt dd class=location vcard div class=fn orgCornell University/div div class=adr span class=extended-addressMyron Taylor Hall/span span class=street-address/span span class=locality/span span class=region/span span class=country-name/span /div /dd This can easily be extracted as a vCard and degrades perfectly to just plain text for the unstructured LOCATION in hCalendar. I hope this helps, -brian Lukasz Lysakowski wrote: Hello. I recently stumbled upon the microformats standards and found the idea terrific. I am currently developing a web project for a higher-ed department and I would like to implement the microformat standards into my current development. I have setup an events result-description page using the hcalendar / hcard formats. I want to make sure my implementation is correct so any feedback will be greatly appreciated. Thank you lukasz div id=event-description class=vevent h2abbr class=dtstart title=20060230Thursday, February 30/abbr/h2 span class=timeabbr class=dtstart title=T120012:00PM/abbr/span h4 class=summaryPublic Interest Career Symposium/h4 p class=descriptionLorem ipsum dolor sit amet. /p dl dtLocation:/dt dd class=locationMyron Taylor Hall/dd dtAdmission:/dt dd class=statusOpen to the Public, Faculty and Students/dd dtWebsite:/dt dd class=urlhttp://www.cornell.edu//dd dtContact Info::/dt dd class=vcardspan class=fnLeslie Intermann/spanbr / span class=tel255-0864/spanbr / a class=email href=[EMAIL PROTECTED]/a /dd /dl /div lukasz lysakowski web developer iws - cornell university ___ 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] UID in iCalendar
I've looked at this again and here's a couple of things I don't like in this algorithm: * Throwing away the data in the last step. I am very unhappy about ignoring good event information, even though it does not contain explicit UIDs. * No reliance on URL property of vevent. IMHO, vevent is used with a URL -- the link to the actual event page. Maybe that could be another implicit UID? What are your thoughts on this, folks? :DG On 7/3/06, Dimitri Glazkov [EMAIL PROTECTED] wrote: If I read the spec correctly, yes, UID is required for the VEVENT component, which means that UID is required for hCalendar. Okkayy... So, here's another stab at the implied algorithm: * if UID is specified, use it * otherwise, if id attribute is specified, construct full URL with fragment identifier and use it as UID * otherwise, if only one vevent present in document, use document URL as UID * otherwise, only accept the first vevent with document URL as UID and discard all others? :DG On 7/3/06, brian suda [EMAIL PROTECTED] wrote: I stand corrected. In section 4.6.1 Event Component, of the RFC it lists which properties are optional, and UID is in that list. That is what i cited in the last email. ; the following are optional, ; but MUST NOT occur more than once class / created / description / dtstart / geo / last-mod / location / organizer / priority / dtstamp / seq / status / summary / transp / uid / url / recurid / Although it doesn't list which items are required. It does seem a bit silly to have an event without a dtstart. So i guess there needs to be some interpretation about the intention of the spec. Since the portion of the spec where REQUIRED is found is closer to the actual definition of UID, i would assume the authors intended that UID be required. Anyone disagree? This could then change the steps of how to build an implied-UID. -brian Marko Mrdjenovic wrote: Brian, I said that one needs to be specified if it's required. The RFC says this in section 4.8.4.7 Unique Identifier: Conformance: The property MUST be specified in the VEVENT, VTODO, VJOURNAL or VFREEBUSY calendar components. I think the important thing is to make hCalendar as importable but to keep it as human friendly as possible. The spec should not require a UID but if it's required it should be recommended to the converter how to create one. Regards, Marko Mrdjenovic brian suda wrote: I like these steps and i'm pretty indifferent on HOW the implied-UID value is formed, i just wanted to point out that fragment identifiers are not globally unique, we'd need to add more to it, where/what gets added isn't important. Either behind an '@' like the recommendation, or the plain URL, it doesn't really matter to me. Marko Mrdjenovic suggested that we should always create a UID, the RFC says that UID is optional so i'm not sure we should force one to exists. ; the following are optional, ; but MUST NOT occur more than once class / created / description / dtstart / geo / last-mod / location / organizer / priority / dtstamp / seq / status / summary / transp / uid / url / recurid / -brian Dimitri Glazkov wrote: Sorry about that! :) But.. isn't that beside the point? The implied UID algorithm could be as follows: * if UID is specified, use it * otherwise, if id attribute is specified, construct full URL with fragment identifier and use it as UID * otherwise, if only one vevent present in document, use document URL and use it as UID * otherwise, don't specify UID. :DG On 7/3/06, David Janes -- BlogMatrix [EMAIL PROTECTED] wrote: 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 ___ 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
[uf-discuss] hreview for books, Blogger example
Hiya Folks, Could I ask someone from the hreview spec to have a look at this review in Blogger and validate compliance (if there's a validator out there I didn't find it)? I found that when coding for book reviews I took some liberties with the spec - in particular, I founded I wanted to add author, publisher and publication date fields, which are not explicitly defined in the hreview spec and which are inconsistently applied in the examples. My intent is to demonstrate microformatted book reviews in Blogger. Here's the URL to look at: http://downes-review.blogspot.com/ Thanks. -- Stephen -- Stephen Downes ~ Research Officer ~ National Research Council Canada http://www.downes.ca ~ [EMAIL PROTECTED] __\|/__ Free Learning ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] X2V converter bug?
I've updated our implementation. -ryan On Jul 3, 2006, at 6:50 PM, Brian Suda wrote: i have looked into the problem, and you are absolutely correct. I have made the updates to the XSLT and staged them here: http://suda.co.uk/projects/X2V/ I'll see what i can do about getting Technorati to update their service as well. Thanks for catching that error, i have also added a similar situation to the test cases so we can help others from making the same mistake. Thanks, -brian On 7/3/06, Marko Mrdjenovic [EMAIL PROTECTED] wrote: I've been doing some experimenting with types on the tel class today and ended up with this: http://www.adria-airways.com/_static/mailings/060703/index.html The problematic code in there is this: p class=telabbr class=type title=voiceT/abbr: span class=value+39 06 42045327/span/p After parsing this should look like: TEL;TYPE=voice:+39 06 42045327 What I get on http://feeds.technorati.com/contacts/http://www.adria-airways.com/ _static/mailings/060703/index.html (saved also to http://www.adria-airways.com/_static/mailings/060703/hCard.vcf) is this: TEL:+39 06 42045327 Is this a bug? I don't think I'm doing anything wrong here... Best regards, Marko Mrdjenovic friedcellcollective.net ___ 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 -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] UID in iCalendar
On Jul 3, 2006, at 7:37 PM, Dimitri Glazkov wrote: If I read the spec correctly, yes, UID is required for the VEVENT component, which means that UID is required for hCalendar. Okkayy... So, here's another stab at the implied algorithm: * if UID is specified, use it * otherwise, if id attribute is specified, construct full URL with fragment identifier and use it as UID I hate to make this more complex, but the construction of the full URL is not going to be entirely simple. I think for it to be robust it needs to know about http://microformats.org/wiki/rel-bookmark. One reason for this is that not only does UID need to be unique, but it should also not change. The reason for this is that it would allow consuming applications to be sure that the new item is an update to the previous item. A suggestion for finding the full URL: 1. If the item has a sibling like a[rel=~bookmark], use that @href as a the value. 2. Else - use document URL. The URL yielded by this algorithm can then be joined[1]. To the @id value of the element to create the UID. There's also room here for other compound microformats to provide more specific information, but since rel-bookmark is the common mechanism, this shouldn't be too tough. Sidenote: This is a reason we re-use stuff like rel-bookmark - it allows nice interoperability without consumers having to know about every microformat. They just have to know about the external stuff that matters to them. -ryan 1. In the sense of this: http://corelib.rubyonrails.org/classes/ URI.html#M001617 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] [OT] Is it just me?
I'm gonna say just you. At least, my messages go through pretty quickly. -ryan On Jul 5, 2006, at 7:56 AM, Colin D. Devroe wrote: Sorry to go OT. But, is it just me or does this list take HOURS to post messages. I replied to a few messages this morning at around 8am EST. It is now 11am and I have yet to see my responses. Anyone else experiencing this? Again, sorry to go OT. Colin D. Devroe # http://cdevroe.com/ # http://9rules.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Ryan King [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Is it just me?
Ok, I got your msgs. Call me weird, but if I reply to any messages from the list, they never make the list. I replied to Chris' WP hCard plugin about 10 seconds after it appeared, and it has never made it into my inbox, nor on the site archives. However, when I create a new mail and send it, it works perfectly and gets posted pretty much immediately. Very strange indeed. Colin D. Devroe ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Is it just me?
Test reply. On Jul 5, 2006, at 6:33 PM, Tantek Çelik wrote: Colin, you may want to confirm how your email client is handling reply-to email headers. It is possible that when you reply, your email client is not respecting the reply-to header and only replying to the sender of the message rather than list. I know, an obvious longshot, but figure it was a possibility. Tantek On 7/5/06 3:24 PM, Colin D. Devroe [EMAIL PROTECTED] wrote: Ok, I got your msgs. Call me weird, but if I reply to any messages from the list, they never make the list. I replied to Chris' WP hCard plugin about 10 seconds after it appeared, and it has never made it into my inbox, nor on the site archives. However, when I create a new mail and send it, it works perfectly and gets posted pretty much immediately. Very strange indeed. Colin D. Devroe ___ 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
Re: [uf-discuss] Re: Is it just me?
Got that one! On 7/5/06, Colin D. Devroe [EMAIL PROTECTED] wrote: Test reply. On Jul 5, 2006, at 6:33 PM, Tantek Çelik wrote: Colin, you may want to confirm how your email client is handling reply-to email headers. It is possible that when you reply, your email client is not respecting the reply-to header and only replying to the sender of the message rather than list. I know, an obvious longshot, but figure it was a possibility. Tantek On 7/5/06 3:24 PM, Colin D. Devroe [EMAIL PROTECTED] wrote: Ok, I got your msgs. Call me weird, but if I reply to any messages from the list, they never make the list. I replied to Chris' WP hCard plugin about 10 seconds after it appeared, and it has never made it into my inbox, nor on the site archives. However, when I create a new mail and send it, it works perfectly and gets posted pretty much immediately. Very strange indeed. Colin D. Devroe ___ 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 -- 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
[uf-discuss] proposal: a[rel=~include]
As many of us already know, browser support for the object element is somewhat annoying and problematic when using the include pattern[1]. When we[2] first brainstormed this idea, we knew that using the object element could get us in trouble. As a result of the problems with using the object element, Yahoo local has removed the include pattern from their implementation of hReview and documented their feedback [4]. Now, I'd like to make a proposal- we should relax the include pattern to also be used on anchors, like so (from [1]): span class=vcard span class=fn n id=j span class=given-nameJames/span span class=family- nameLevine/span /span /span span class=vcard object data=#j class=include type=text/html/object This would become: a href=#j class=include/a (sidenote: I don't think the @type should be required after this change) span class=orgSimplyHired/span span class=titleMicroformat Brainstormer/span /span I don't think using anchor tags for this is optimal or pretty, but it has the nice advantage of working well in the real world. As a historical sidenote, I believe I suggested [EMAIL PROTECTED] first, then Tantek countered with [EMAIL PROTECTED] (note that they occur in this order on [3]). Personally, I think we should prefer the object element, if only for semantic aesthetic reasons (and because browser shortcomings are likely to change and/or go away in the future), but allow for anchor tags to be used in their place. Is there anything I'm missing here? Are there any objections? -ryan 1. http://microformats.org/wiki/include-pattern 2. Tantek and I [3]. 3. http://flickr.com/photos/tantek/87059138/ 4. http://microformats.org/wiki/include-pattern-feedback ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
