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
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] UID in iCalendar
According to the RFC 4.8.4.7 Unique Identifier, the only to requirements are: 1) Value Type: TEXT 2) Globally Unique Any URL fits the TEXT requirement. As for globally unique, all URL only resolve to a single location, so that makes it globally unique. The only caveat is that if you have two events, those each need to use a unique URL, not just http://events.example.org, but instead http://events.example.org/event/1234 The recommendation is just that, a recommendation, not a requirement. -brian Dimitri Glazkov wrote: Can UID in iCalendar be just a URL of the event? Do we have to adhere to the RFC2445's recommendation (http://rfc.net/rfc2445.html#s4.8.4.7), which is based on an email-style RFC822 addr-spec (http://rfc.net/rfc822.html#s6.1)? :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] UID in iCalendar
On 7/3/06, brian suda [EMAIL PROTECTED] wrote: According to the RFC 4.8.4.7 Unique Identifier, the only to requirements are: 1) Value Type: TEXT 2) Globally Unique Any URL fits the TEXT requirement. As for globally unique, all URL only resolve to a single location, so that makes it globally unique. The only caveat is that if you have two events, those each need to use a unique URL, not just http://events.example.org, but instead http://events.example.org/event/1234 Right. So, this falls right into place with the discussion of having id attribute on each hcard/hcalendar event, so that they could be uniquely identified. :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] UID in iCalendar
I do remember awhile ago we discussed using ID as UID, i can't find the archived message at the moment. The one concern was that UID is to be globally unique, whereas the ID attribute is only document unique, so if we are going to construct an implied UID, then we could look to the RFC recommendation and do something like: id@host-name where id is the fragment identifier for the page and host is the exact page where the id was found. For example, http://events.example.com/#123 would become [EMAIL PROTECTED] and http://events.example.com/europe/#123 would become [EMAIL PROTECTED]/europe we need to take the full URL so that there are not collisions in the UID when there might be IDs called 123 on two different pages. I need to now look to see if/what needs escaping in the URL string (slash '/' needs to become '\/') -brian 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. Thanks, Tantek On 7/3/06 12:17 PM, brian suda [EMAIL PROTECTED] wrote: According to the RFC 4.8.4.7 Unique Identifier, the only to requirements are: 1) Value Type: TEXT 2) Globally Unique Any URL fits the TEXT requirement. As for globally unique, all URL only resolve to a single location, so that makes it globally unique. The only caveat is that if you have two events, those each need to use a unique URL, not just http://events.example.org, but instead http://events.example.org/event/1234 The recommendation is just that, a recommendation, not a requirement. -brian Dimitri Glazkov wrote: Can UID in iCalendar be just a URL of the event? Do we have to adhere to the RFC2445's recommendation (http://rfc.net/rfc2445.html#s4.8.4.7), which is based on an email-style RFC822 addr-spec (http://rfc.net/rfc822.html#s6.1)? :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 ___ 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
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
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? :DG ___ 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
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
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] UID in iCalendar
Indeed! On 7/3/06, David Janes -- BlogMatrix [EMAIL PROTECTED] wrote: Dimitri Glazkov wrote: Sorry about that! :) But.. isn't that beside the point? Orthogonal! :DG ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] UID in iCalendar
I think that is up to specific implementation of a converter: I don't believe microformat spec should go as far as to instruct whether or how to auto-generate UID if it is missing. Perhaps a recommendation, based on exploration of existing implementations? :DG On 7/3/06, Marko Mrdjenovic [EMAIL PROTECTED] wrote: I think that the last option needs to change - even if there is no way to determine a UID I would like to be able to import it into the less friendly clients. If no UID is specified and UID is required the converter should provide one - obviously the author had no wish for people to be able to update the event... Marko Mrdjenovic 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
Re: [uf-discuss] UID in iCalendar
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
Re: [uf-discuss] UID in iCalendar
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
Re: [uf-discuss] UID in iCalendar
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 microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] UID in iCalendar
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 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
