[uf-discuss] Developing a strategy for deployment of microformats

[Brian Kelly]

Hi Ryan
   Sorry for the delay in replying to this.

> -----Original Message-----
> From: Ryan King [mailto:ryan at technorati.com] 
> Sent: 05 July 2006 22:36
> To: B.Kelly at ukoln.ac.uk; Microformats Discuss
> Subject: Re: [uf-discuss] Developing a strategy for 
> deployment of microformats 
> 
> On Jul 3, 2006, at 7:26 AM, Brian Kelly wrote:
> > However I've encountered a number of irritating problems:
> >
> > Problems with British Summer Time (Daylight Saving Time).
> 
> What problems, specifically?

Times being an hour out.  Not a hCalendar problem, I understand, but ba
complexiyty of processing times.  However I had expected that software would
have realised that BST was in operation - I understand that I have to use
the UTC time +1.00.00.00.

Another problem - going to, for example,
http://www.bath.ac.uk/whats-on/getevent.php?event_id=3010&catIds=ALL

Tails use the correct date (17 July) whereas the Google hCalendar
Greeasemonkey script uses a date of 16 July.   

> > 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?
> 
> Yes. hCalendar test cases are in progress at
http://hg.microformats.org/tests .

Is this the correct URL - it seems to be a change log rather than a page
described the test cases.
> 
> > ...
> >
> > 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.
> 
> We have some already:
> 
> http://microformats.org/wiki/vcard-implementations
> http://microformats.org/wiki/icalendar-implementations

Thanks  - it is aimed at programmers ... 
> Feel free to add more.

but I appreciate that I (and others) can help to give it more user-focussed
content.

> > 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,
> 
> No, it processes all of them.

If I use the bookmarklet on the
http://www.ukoln.ac.uk/web-focus/events/workshops/webmaster-2006/sessions/ke
lly/
I get one hCard, whereas Tails correctly displays two.
 
> > whereas Tails
> > displays all occurrences in a sidebar.  Should the spec 
> mandate what 
> > the software should do in such circumstances?
> 
> No. Each application has different constraints.

OK.  In which case ideally the application will document the constrainst (to
avoid users thinking that one ap[plication determines what the effect should
be).

Thanks agin.

Brian
 
> -ryan
> 
>