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

[Brian Kelly]

Hi Ryan
    Thanks for the response.
    From my point of view (as a non-programmer looking to promote uf to 
a wider audience) I would argue that if uf applications are flawed or if 
processing time gives unexpectedresults, then even if the uf specs 
themselves are great, there will be understandable user reluctance to go 
down this path.
   So. for example, if users will have to manually add an hour when 
BST/DST is in operation, then there's a need to inform them of this.
   I therefore have an interest in test cases and in mechanisms for 
"approved uf-compliant" viewers, as well as in approaches to encouraging 
takeup of uf (hence the subject line of this email - a  strategy for 
deployment of microformats.  i.e. I think a response of 'if the code is 
buggy, take it up with the author' misses the point of encouraginng 
takeup by the average user.

Brian

PS - ukoln server has been down due to an air-conditioning problem.   
But Ciran has looked into that specific problem - see mt other email..


Ryan King wrote:
> On Jul 18, 2006, at 9:12 AM, Brian Kelly wrote:
>> 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.
>
> I'm not sure how BST can be assumed here?
>
>> 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'm not familiar that greasemonkey script. You may want to talk to its 
> author.
>
>>>> 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.
>
> Its a Mercurial repository. Hence the 'in progress' qualifier The 
> stable tests are published at http://microformats.org/tests/ .Of 
> course, that doesn't really have any explanatory material, either.
>
>>>> ...
>>>>
>>>> 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 ...
>
> Well, that's what we are. :D
>
>> ...
>>
>>>> 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/kelly/ 
>>
>> I get one hCard, whereas Tails correctly displays two.
>
> I can't currently access that URL. I'll try again later.
>
> -ryan


-- 
-----------------------------------
Brian Kelly
UK Web Focus, UKOLN, University of Bath, BATH, UK, BA2 7AY
Phone: +44 1225 383943
Email:  b.kelly at ukoln.ac.uk