RE: [uf-discuss] Human and machine readable data format
See below. Hope this helps, Charles Belov SFMTA Webmaster -- Message: 4 Date: Tue, 15 Jul 2008 00:36:07 +1000 From: Michael [EMAIL PROTECTED] Subject: Re: [uf-discuss] Human and machine readable data format To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed actually the suggestion of splitting the datetime into date, time and timezone marked up in separate elements seems to me like a good compromise. -mm-dd would certainly not be as scary for humans as a full datetime with timezone It would still not be pleasant. Month, day, year, hour, minute, second, time zone, and optional am/pm could all be split up, removing ambiguity. -- Message: 6 Date: Mon, 14 Jul 2008 21:54:57 +0100 From: Toby A Inkster [EMAIL PROTECTED] Subject: [uf-discuss] Human and machine readable data format To: microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Scott Reynen wrote: I'm assuming by different calendar, you mean non-Gregorian? If so, what are the use cases for non-Gregorian dates in hCalendar? It's not so much the case of wanting to encode non-Gregorian dates in hCalendar, but wanting to include non-Gregorian dates on the web page. abbr class=dtstart title=2008-07-1411 Rajab 1429/abbr Is '2008-07-14' to be considered an appropriate expansion of the abbreviation '11 Rajab 1429'? In case anyone is wondering whether non-Gregorian calendars are used in practice, the Islamic calendar (used in the example above) is the official calendar for Saudi Arabia, and used in religious contexts in many other countries; the Julian calendar is still used in religious contexts by Orthodox Christian churches, and frequently used by historians to refer to many older dates; the Chinese calendar is used for various religious and cultural reasons not just in China, but in some other Asian countries, but not for any official purposes. I would cite specific pages that use these calendars, but I don't speak Arabic, Russian or Mandarin, so don't know the correct terms to Google for. So there will be cases where people want to publish non-Gregorian dates, but for interoperability with iCalendar, they'll need to include a machine-readable Gregorian equivalent date. This is an example of where you're going to have very significant differences between the human and machine-readable representations of the same dates. Well, gee, if an Arabic screen reading program read out a Gregorian date where the author was expecting an Arabic date to be read, that could be pretty insulting. In any case, you seem to be assuming a human entering a non-Gregorian date (or, for that matter, a Gregorian date) can accurately transform the human-readable date into a machine-readable date. I can tell you right now that I personally am 24-hour-calendar challenged. I usually get the 12-to-24 hour conversion right, or vice versa, but now and then... And I wouldn't want a screen reader to read the time to me using the 24-hour clock on a U.S. website. I believe machines can do this translation more reliably than humans, provided they are asked to do so. In any case, there could be a parameter for alternate calendar. (It's also interesting to note that automatic translation from the Islamic calendar to Gregorian is impossible to perform reliably, as it is based on human observation of the movements of the sun and moon, not on the actual -- predictable -- movements of the sun and the moon. Thus the exact numbering of dates is not usually known very far in advance.) Then it seems there would be no way to provide a reliable ISO date for non-impending events; therefore, requiring ISO for the hCalendar record would prevent use of hCalendar for that event. (For that matter, you would need latitude and longitude to eventually resolve the date and time.) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Message: 3 Date: Thu, 26 Jun 2008 11:16:19 -0700 From: Guillaume Lebleu [EMAIL PROTECTED] Subject: Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Belov, Charles wrote: I'd suggest modifying that to not require the computer to parse the date. Something like: span class=dstartm lang=en-usOctober/span span class=dstartd5/span, span class=dstarty2004/span +1: DRY-, POSH- and humans first-compatible IMO. Maybe the following may be POSHer and backward-compatible with the existing dstart class name convention? span class=dtstart lang=en-usspan class=monthOctober/span span class=day5/span, span class=year2004/span/span By George, I think you've got it! Then there is the time issue, including 24-hour vs. 12-hour. So perhaps (with all characters outside the inner spans being optional for human readability): span class=dtstart lang=en-usspan class=monthOctober/span span class=day5/span, span class=year2004/span, span class=hhmm1740/span GMTspan class=tz-7/span/span would be equivalent to: span class=dtstart lang=en-usspan class=monthOctober/span span class=day5/span, span class=year2004/span, span class=hhmmampm5:40 a.m./span span class=tzabbrPDT/span/span noting that hhmmampm might be expressed with or without the m, or with n for noon (12n) or midnight (12m). Hope this helps, Charles Chas Belov SFMTA Webmaster ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
-Original Message- Message: 2 Date: Tue, 24 Jun 2008 15:17:24 -0700 From: Guillaume Lebleu [EMAIL PROTECTED] Subject: Re: [uf-discuss] RE: Microformats and RDFa not as far apart as previously thought To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Belov, Charles wrote: I feel it is unreasonable to ask a non-technical person to produce ISO-format dates/times, so microformats do not produce an acceptable solution at this time for marking up meeting announcements. I agree that only an editor extension would make writing ISO-format date/time practical by humans, which I never felt was compliant with designed for humans first, machine second. What about the idea of a plain old English microformat (POEM?) based on well-known practices in various languages [1], in the tradition of paving the cows path: these practices are pretty-well established IMO and used by authors in the newspapers, magazines, etc. For instance, in English: span class=dstart lang=en-usOctober 5, 2004/span span class=dstart lang=en-us10/5/2004/span span class=dstart lang=fr5 Octobre 2004/span span class=dstart lang=fr5/10/2004/span The locale could be specified locally (lang=en-us) or inherited from the HTML document or a containing div. Granted it would make the parsing more complex, but it would comply with designed for humans first, machine second. Also, additional class would be required to distinguish the date part from the time part in something like: span class=dstart lang=en-usspan class=dateOctober 5, 2004span at span class=time6PM/span/span I'd suggest modifying that to not require the computer to parse the date. Something like: span class=dstartm lang=en-usOctober/span span class=dstartd5/span, span class=dstarty2004/span Hope this helps, Charles Chas Belov SFMTA Webmaster ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] RE: Microformats and RDFa not as far apart as previously thought
Message: 8 Date: Tue, 24 Jun 2008 12:03:30 -0400 From: Manu Sporny [EMAIL PROTECTED] Subject: [uf-discuss] Microformats and RDFa not as far apart as previously thought To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=UTF-8 There have been some interesting blog posts by people at the BBC, Mozilla and W3C about Microformats and RDFa in the past two days. The first covers BBC's decision to drop support for the abbr-based design pattern written by Michael Smethurst (who worked with this community on hAudio among other things): Removing abbr-based Microformats from BBC http://www.bbc.co.uk/blogs/radiolabs/2008/06/removing_microformats_from _bbc.shtml I have come to a similar decision. In my case, I will split the human-readable portion entirely from the microformat portion, and the microformat portion will be entirely styled display:none. That applies to machine-intermediated content. I feel it is unreasonable to ask a non-technical person to produce ISO-format dates/times, so microformats do not produce an acceptable solution at this time for marking up meeting announcements. Charles Chas Belov SFMTA Webmaster www.sfmta.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: Request for help from screen reader users from the BBC
Hope this helps, Charles Belov SFMTA Webmaster -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, May 28, 2008 6:51 AM To: microformats-discuss@microformats.org Subject: microformats-discuss Digest, Vol 36, Issue 13 Send microformats-discuss mailing list submissions to microformats-discuss@microformats.org To subscribe or unsubscribe via the World Wide Web, visit http://microformats.org/mailman/listinfo/microformats-discuss or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of microformats-discuss digest... -- Message: 2 Date: Wed, 28 May 2008 13:41:25 +0100 From: Alasdair King [EMAIL PROTECTED] Subject: Re: [uf-discuss] Request for help from screen reader users from theBBC To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 (snip) 3 Working in web accessibility leads one to mix with highly-technical professional screenreader users. They should not, I argue, be your target audience. A highly-technical JAWS user will write a script to get round ABBR problems and distribute it to other users, or just use the webpages for sighted people, or turn off ABBR again. If microformats take off then Freedom Scientific will make sure that script ships with JAWS anyway, and all the vendors will follow suit. I am, therefore, as a professional working in software for vision- impaired people, not worried about the impact on screenreader users of the ABBR tag, since I think the temporary and minor disbenefits are outweighed by the major benefits. (snip) I am worried, because if ABBR titles are suppressed then they can't be used for their legitimate use to expand abbreviations, and we are left with a Gresham's Law of Attributes where nonstandard uses of attributes drive out standard uses of attributes. Hope this helps, Charles Chas Belov SFMTA Webmaster ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] RE: Request for help from screen reader users
Hope this helps, Charles Belov SFMTA Webmaster -- Message: 3 Date: Thu, 22 May 2008 19:49:17 +0100 From: Toby A Inkster [EMAIL PROTECTED] Subject: [uf-discuss] RE: microformats-discuss Digest, Vol 36, Issue 9 To: microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; format=flowed Charles Belov wrote: span class=humandtstartMay 12, 2008, 5:30pmabbr class=dtstart title=2008-05-12T17:30:00-0700 style=display:none/abbr/span Similar to my current compromise: span class=dtstart May 12, 2008, 5:30pm abbr class=value title=2008-05-12T17:30:00-0700 style=display:none/abbr /span Which seems to work in many current parsers. The most important common part is our use of style=display:none I respectfully suggest my parser, which places the class and the title attributes in the same tag, provides a simpler parse and does not require a change to current parsers. (humandtstart is only for the convenience of webmasters who want to style the human-readable date, and can be ignored by parsers.) There is no need for the parse to relate the human-readable date with the machine-readable date if any given audience is going to ignore one or the other. I do credit your work on this tag as an inspiration for my derivation. -- Toby A Inkster mailto:[EMAIL PROTECTED] http://tobyinkster.co.uk -Original Message- -- Message: 6 Date: Thu, 22 May 2008 18:17:00 +0100 From: Ben Ward [EMAIL PROTECTED] Subject: Re: [uf-discuss] Request for help from screen reader users from theBBC To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Recently, we've been discussing the issue of embedding machine-data as part of microformats on uf-dev, and debating possible alternative methods from a parser perspective (namely an empty element with a title attribute). I think the most important part of a solution is to add style=display:none to that empty element to guarantee that the title will not be read or displayed to humans. Hope this helps, Charles Chas Belov SFMTA Webmaster ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] RE: microformats-discuss Digest, Vol 36, Issue 9
-- Message: 3 Date: Wed, 21 May 2008 15:58:43 +0800 From: Zhang Zhen [EMAIL PROTECTED] Subject: Re: [uf-discuss] One more shot at accessible hCalendar To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=UTF-8 The whole abbr design pattern is not a very good idea because both the content of abbr element and the value of title attribute should be human-readable text. The right use of abbr element should be like this: abbr title=human-readable date2008-5-21T09:22+08:00/abbr I would hate to inflict an ISO date on my sighted readers either. -- Message: 4 Date: Wed, 21 May 2008 09:07:14 +0100 From: Ciaran McNulty [EMAIL PROTECTED] Subject: Re: [uf-discuss] One more shot at accessible hCalendar To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=UTF-8 On Wed, May 21, 2008 at 8:58 AM, Zhang Zhen [EMAIL PROTECTED] wrote: But someone might argue that 2008-5-21T09:22+08:00 wouldn't be a human-readable date. As far as I know, HTML4.01 doesn't offer an attribute for the machine-readable purpose and abbr design pattern seems relatively the best way to do the job, but it's not perfect. As another aside, HTML5 has the proposed TIME element for exactly this. time datetime=2008-05-23 17:00:00Friday 5pm/time So the site visitor problem is solved for HTML 5. We still have the coding issue for manually maintained pages by non-technical personnel. And even this techie doesn't have 24-hour time sufficiently internalized to accurately and consistently translate 12-hour times into 24-hour. -- Have you tried something like this: abbr class=dtstart title=2008-05-15T19:30:00+01:00 span title=Seven Thirty19:30/span /abbr There is more on this here: http://alistapart.com/articles/hattrick Still, any reader that reads the title of an abbr tag will read out the ISO date. -- Message: 8 Date: Thu, 22 May 2008 10:26:42 +0100 From: Frances Berriman [EMAIL PROTECTED] Subject: Re: [uf-discuss] Request for help from screen reader users from theBBC To: [EMAIL PROTECTED],Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 On 21/05/2008, Martin McEvoy [EMAIL PROTECTED] wrote: It's not so much about what to try as the BBC using the hCalendar on a new, very large site and not wanting to use a format that is either likely to change (if the abbr pattern is changed/dropped) or causes accessibility issues. They just want to help push through the current discussion with some real data. This would be a killer for us as well. Hopefully, this issue can be resolved *very soon* - I'd hate to see /programmes have to drop their microformat implementation because of one, relatively small, aspect of one format. Me too. I'm hoping someone can give feedback on my proposed solution, which is to hide the ISO date using style=display:none span class=humandtstartMay 12, 2008, 5:30pmabbr class=dtstart title=2008-05-12T17:30:00-0700 style=display:none/abbr/span Again, this is to solve the site visitor problem. The page producer problem still remains. Hope this helps, Charles Belov SFMTA Webmaster ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: One more shot at accessible hCalendar
Message: 1 Date: Sat, 17 May 2008 22:46:12 +0100 From: Toby A Inkster [EMAIL PROTECTED] Subject: [uf-discuss] Re: One more shot at accessible hCalendar To: microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed If the problem is 'machine readable dates get read out sometimes' I don't see how the data: prefix solves that. Screen readers may be configured to read out the title attribute for abbr and acronym; perhaps also a and img. But they don't automatically read out the contents of the title attribute in the general case. The title attribute on span or div or table or b or whatever will not be read out -- data can safely be kept there. The argument of whether or not screen readers are by default configured to read out title attributes is a bit of a red herring. As long as screen readers *can* be configured to read out title attributes, there is the issue that both human-friendly title attributes (having nothing to do with microformats) and non-human-friendly ISO dates will be exposed by the same setting. Hope this helps, Charles Chas Belov SFMTA Webmaster ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: One more shot at accessible hCalendar
Comments in-lined below. This message includes responses to two messages from the digest. Message: 5 Date: Wed, 14 May 2008 14:38:56 +0100 (BST) From: Toby Inkster [EMAIL PROTECTED] Subject: [uf-discuss] Re: One more shot at accessible hCalendar To: microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain;charset=iso-8859-1 Charles Belov wrote: Remember that any page these occur on would presumably have a language specification such as en-us so computers would be able to deal with standard month and day of week names and abbreviations. I'm sorry, but this sounds like a really bad idea. Parsers would need to maintain translation tables for day and month names, plus abbreviations for them, plus some sort of heuristic for figuring out the language of the page. (In practice, many authors leave out lang/xml:lang attributes, and Content-Language headers.) If the web page or RSS feed leaves out the language attribute, then the webmaster has not provided sufficient information to the parser and cannot be said to have implemented this alternative method. I do not expect any scrapers to intuit the origin language. Andy Mabbett's proposed data: prefix already solves the abbr design pattern accessibility issue and can be implemented in just a few lines of code. All we need to do is build support for it into parsers. (Cognition has supported it since alpha2.1.) Closest thing to a specification for the prefix: http://microformats.org/discuss/mail/microformats-discuss/2008 -February/011583.html That solution consists of title attribute contains readable text, followed by the word data followed by the actual data. The screen reader software will still read the data out loud, which, on a page full of calendar items, would be sheer torture for the listener. And it still begs the question as to how that data is going to get into the page in the first place when a static HTML page is being created manually by a non-technical person who has no access to the title tag. -- Message: 8 Date: Thu, 15 May 2008 19:57:49 +1000 From: Michael MD [EMAIL PROTECTED] Subject: Re: [uf-discuss] Re: One more shot at accessible hCalendar To: Microformats Discuss microformats-discuss@microformats.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Remember that any page these occur on would presumably have a language specification such as en-us so computers would be able to deal with standard month and day of week names and abbreviations. I'm sorry, but this sounds like a really bad idea. Parsers would need to maintain translation tables for day and month names, plus abbreviations for them, plus some sort of heuristic for figuring out the language of the page. (In practice, many authors leave out lang/xml:lang attributes, and Content-Language headers.) If machine-readable dates were removed from the hCalendar spec what would be the point of using it? Accuracy of dates is CRUCIAL for calendar applications and you would not want to end up using unreliable heuristics to extract them! I'm not sure what computer cannot read January, Jan, Jan., 1 or 01 when surrounded by span dtstartmm and /span and be able to figure out that it means the first month of the year. As with the previous post, it still begs the question as to how that computer-readable data is going to get into the page in the first place when a static HTML page is being created manually by a non-technical person who has no access to the title tag. Anyway, if you don't know what language the calendar item is in, how are you going to know whether the plain language description of the event needs to be translated? You could wind up displaying a page full of events that are perfectly timed but are described in plain text in 20 different languages. Accurate, but unusable by most people. Or you could choose to just show English events. Or just French. Or just Chinese. Etc. In which case you would not have to worry about multilingual heuristics. I acknowledge you would still have to worry about typos. Hope this helps, Charles Chas Belov SFMTA Webmaster http://www.sfmta.com/webmaster ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] RE: One more shot at accessible hCalendar
Possible alternatives: If the webmaster does use an empty span with a title tag to contain the ISO date, the webmaster could add a style=display: none attribute to it to ensure that screen readers did not read it. I came up with this format, using the microformats class names and titles, for pages that are computer-generated: Monday, January 5, 2008, 10:00pmspan class=dtstart style=display: none title=2008-01-05T22:00:00-0800/span This would hide the computer data from screen readers but make in available in the DOM. The issue remains for pages edited by non-technical humans. Hope this helps, Charles Chas Belov SFMTA Webmaster http://www.sfmta.com/webmaster ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] One more shot at accessible hCalendar
I'll try to keep this to new comments concerning the use of the ISO date in the hCalendar microformat. Please excuse me if I'm repeating something. At the moment, these are the things that would prevent me from implementing hCalendar on our website. - Site visitor accessibility: Even if a particular screen reader can disable abbreviations or titles so as not to hear ISO-format dates read, that means that screen reader would also not read human-friendly titles that have nothing to do with microformats. Even if your site does not use human-friendly title tags, there are sites in the wild that do, and having the screen readers suppress these would be a loss. Possible alternatives: If the webmaster does use an empty span with a title tag to contain the ISO date, the webmaster could add a style=display: none attribute to it to ensure that screen readers did not read it. - Site creator accessibility: 1. We have non-technical people creating and editing static HTML web pages using Adobe Contribute. There is no easy way in Contribute to insert a title tag. 2. Even if I were to be able to create a kludge to let the people enter a title tag, they would still have to create human-unfriendly ISO dates in those title tags. 3. These non-technical people would have to deal with a human-unfriendly spec that end dates without times end at the beginning, not the end, of the day in the ISO date. Possible alternatives: These tags could optionally be used in place of the class=dtstart and class=dtend: class=dtstart for year class=dtstartmmm for month as Jan, Feb, etc., or 01, 02, etc., or 1, 2, etc. class=dtstartdd for day as 01, 02, etc. or 1, 2, etc. class=dtstartdow for day as Mon, Tue, etc. or Monday, Tuesday, etc. class=dtstarttime for time as 10:12am, 10:12a, 10:12 am, 10:12 a, 1012, 10:12:01am, etc. Remember, these are humans entering these dates and they may not be consistent (as long as they don't misspell the month or day, the computers ought to be the ones who are forgiving). Replace start with end for human-unfriendly end date (ends at start of day 12:00:01am if no time given) or endfull for human-friendly end date (ends at end of full day 11:59:59pm if no time given) or startend or startendful for something that is used for start and end both. Example: Tuesday, May 13, 2008, 4:08pm would be human-friendly encoded for a start date as span class=dtstartdowTuesday/span, span class=dtstartmmmMay/span span class=dtstartdd13/span, span class=dtstart2008/span, span class=dtstarttime4:08pm/span Tuesday, May 13, through Friday, May 16, 2008 would be human-friendly encoded for a start and end date as span class=dtstartdowTuesday/span, span class=dtstartmmmMay/span span class=dtstartdd13/span, span class=dtstart2008/span, through span class=dtendfulldowFriday/span, span class=dtendfullmmmMay/span span class=dtendfulldd16/span, span class=dtstartendfull2008/span While I as webmaster would have to provide pre-set fill-ins for the non-technical content editor to drop a date into the pre-formatted span tags, it would protect the non-technical content editor from having to deal with the code. For example, in Contribute, I would code a template containing a table with repeating regions wrapped by the span tags. The non-technical content editor would drop a day-of-week, month, date, year, and time into the spaces provided. Remember that any page these occur on would presumably have a language specification such as en-us so computers would be able to deal with standard month and day of week names and abbreviations. - Hope this helps, Charles Belov SFMTA Webmaster http://www.sfmta.com/webmaster ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
