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:[EMAIL PROTECTED]
Sent: 05 July 2006 22:36
To: [EMAIL PROTECTED]; 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: [EMAIL PROTECTED]
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
