[uf-discuss] Developing a strategy for deployment of microformats
Hi all I've just subscribed to this list, so I hope I'm not repeating any previous discussions. Anyway, I first heard about microformats at WWW 2005, and heard much more at WWW 2006, including meeting Brian Suda, Ryan King and others at a microformats BOF in Edinburgh. I am a national Web adviser to UK Universities (HE) (and the cultural heritage sector). I'd like to help to support the takeup of microformats across the HE sector. We have an advantage in the UK with a sector which works well together with many Web managers in the community subscribed to the same mailing lists. In addition we have an additional 3 day event aimed at institutional Web managers. This year's event (the tenth in the series) attracted over 190 delegates (we have about 160 universities). We also made use of microformats on the event's Web site - see http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2006/microformat s/ I'd like to tap into the enthusiasm which the event generated by developing a strategy for deployment of microformats within the sector. My plans are three-fold: 1 Education: what are microformats; what are their limitations; etc. 2 Demonstrators: provide examples of uses of microformats; encourage others to engage in similar examples for themselves; look at ways in which third parties can exploit our microformats in ways which benefit the community. 3 Work with the wider micoformat community As part of (1) I've written an Introduction To Microformats briefing paper - see http://www.ukoln.ac.uk/qa-focus/documents/briefings/briefing-100/ In addition Phil Wilson (who is based here at Bath University) ran a workshop session on microformats - http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2006/sessions/wi lson-1/ As part of (2) I've been exploring the potential for using hCalendar microformats for my forthcoming events: http://www.ukoln.ac.uk/web-focus/events/ However I've encountered a number of irritating problems: Problems with British Summer Time (Daylight Saving Time). I've been told that this is a well-known problem in handling date and time information, and is not directly related to microformats or the software which processes microformats. However it strikes me that we will need to ensure that end users (and microformat maintainers) are aware of such limitations. It also strikes me that there's a need for consistency across the software vendors - which then leads on to (a) more rigorous documentation regarding what should be done and (b) test cases. Is anyone working on this? Whilst trying to resolve the problem with BST I also spent some time playing with the various date and time formats (i.e. using 2006-01-01T12:00:00+0100) with and without hyphens; with UK and US conventions for separators in time strings; etc. I understand that the ISO spec if flexible (is this correct). However, even if this is the case, there will still be a need to ensure software vendors implement the standard correctly - again a need for a test suite. As well as the issues regarding the spec and the hCard converters there are also the issues about limitations in the calendaring tools. I've read some messages about Outlook, for example, not processing telephone numbers in hCards correctly. In this case, I think there's a need for documentation on bugs in well-used software such as Outlook. There is also a need to define what hCard tools should do if they encounter multiple occurrences of hCards. I understand that Brian Suda's Web-based XSLT service processes the first occurrence on a page, whereas Tails displays all occurrences in a sidebar. Should the spec mandate what the software should do in such circumstances? I feel that these issues should be addressed when seeking to encourage takeup of microformats - so I've welcome comments. Once the educational aspect has been addressed, I'd like to look into recommendations for demonstrators which will best demonstrate the capabilities of microformats and encourage wider takeup. However I'll leave this to another posting. Thanks Brian --- Brian Kelly UK Web Focus UKOLN University of Bath BATH BA2 7AY Email: [EMAIL PROTECTED] Web: http://www.ukoln.ac.uk/ Phone: 01225 383943 FOAF: http://www.ukoln.ac.uk/ukoln/staff/b.kelly/foaf/bkelly-foaf.xrdf For info on FOAF see http://www.ukoln.ac.uk/ukoln/staff/b.kelly/foaf/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] X2V, technorati.com/events/, and MS Outlook 2003
Interesting. It seems that VERSION: 2.0 in an iCal export result makes MS Outlook 2003 fail to import an event, and throw up a somewhat insane error message about Lunar vs. Gregorian calendar: This error can appear if you have attempted to save a recurring Lunar appointment in iCalendar format. To avoid this error, set the appointment option to Gregorian instead of Lunar. Doh! Changing the line field to VERSION: 1.0 fixes the problem. Just a heads up. I am not sure if the VERSION field itself is the root of the problem. I'll be digging some more and posting this to http://microformats.org/wiki/icalendar-implementations :DG ___ 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] X2V converter bug?
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
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
[uf-discuss] Re: Developing a strategy for deployment of microformats
I began a separate wiki not too long ago for practical information about using and deploying microformats (http://microformats.pbwiki.com). It'd be great to see this wiki get some use -- and starting it off with a section on Microformats in Education might be just the thing to kickstart it. Note that while I don't want to take away from the mf dot org wiki, I do see a need for a looser place to experiment with recording 'hacks and hints' that are as necessarily authoritative as the main wiki. Tantek and I have discussed this and the hope is that we can develop this kind of practical/pragmatic information separately and then migrate back (or crosslink) the relevant bits. Chris On 7/3/06, Jesse Rodgers [EMAIL PROTECTED] wrote: Brian Kelly wrote: I'd like to tap into the enthusiasm which the event generated by developing a strategy for deployment of microformats within the sector. My plans are three-fold: 1 Education: what are microformats; what are their limitations; etc. 2 Demonstrators: provide examples of uses of microformats; encourage others to engage in similar examples for themselves; look at ways in which third parties can exploit our microformats in ways which benefit the community. 3 Work with the wider micoformat community Hi Brian, As part of a slow to start effort I have been trying to get a conversation going with the University Web Developers list (http://www.usask.ca/web_project/uwebd/index.html), which has a large amount of representation across North America, looking at particular formats for education. What I would also like to explore is if there are any changes might be needed to current formats to meet higher educations needs. I have been doing this as part of the WaSP Education task force: http://webstandards.org/action/edutf But I have not had the time to put into it until recently. A couple days ago I started collecting my own thoughts and invited others on the WaSP and uwebd list to contribute on a wiki here: http://web.uwaterloo.ca/wiki/index.php/Main_Page I am interested in achieving the same goals as yourself and perhaps there is a better way to achieve them than what I have started to do. Ideally a space in the MF wiki for higher education would be a great start. It wouldn't be something for a specific MF but instead a place to explore the application of MF in higher education and hopefully identify the key areas MF fall short which we would then end up with some suggested changes... maybe even a new MF or two. Any ideas from the community would be welcome... Jesse -- Jesse Rodgers Manager, Web Communications University of Waterloo http://www.uwaterloo.ca ___ 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
