Re: [uf-discuss] human readable date parsing
MM/DD is bad! What's 07/05 ? Today is 05/04 ... or is it 04/05 ? Tomorrow is cool :) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On 04/05/07, Tantek Çelik [EMAIL PROTECTED] wrote: Human readable to one culture/language is not necessarily human readable to other cultures/languages. I agree that i18n is a stumbling block here. But, descriptions, titles and names aren't translated as well, why would the date need be? Let's put the smarts into the parsers and figure out which date we mean, and have the user confirm it. Yes, yes, I know that's not how it's supposed to work. But one can dream -- -- Victor Jalencas [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
And yet, to not do so means breaking another restriction. It's about give and take. Is it better to make it easier for publishers, and harder for parsers, or is it better to store the same date twice, and let one go out of sync? Another solution is to just store ISO dates free and clear, and offer a javascript library to parse it into a variety of common/ international date formats. My basic point is, that it is impossible to satisfy all the restrictions with one format. Perhaps it is better to have several ways to mark it up, depending on the situation. Which restriction is it important to NOT break for a particular situation? On 04/05/2007, at 12:42 PM, Michael MD wrote: I don't think this will work, for the same reason tel-type and adr- type don't work: l10n/i18n. They require displayed machine values to be in English. span class=vmonth lang=enJuly/span span class=vmonth lang=esjulio/span span class=vmonth lang=jp7 月/span span class=vmonth lang=ruиюль/span good point ... parsing it might end up needing a database of day and month names and character sets and numbers in every known language! (possibly also other types of calendars that might be used in some parts of the world ... this could get very complicated very quickly!) ___ 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] human readable date parsing
I agree that i18n is a stumbling block here. But, descriptions, titles and names aren't translated as well, why would the date need be? Let's put the smarts into the parsers and figure out which date we mean, and have the user confirm it. The place for such user confirmation is in authoring software not parsing software! eg how would something aggregating hcalendar data from multiple sources be able to ask for confirmation? It would just have to reject anything ambiguous. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On May 4, 2007, at 3:29 AM, Breton Slivka wrote: I don't think this will work, for the same reason tel-type and adr- type don't work: l10n/i18n. They require displayed machine values to be in English. span class=vmonth lang=enJuly/span span class=vmonth lang=esjulio/span span class=vmonth lang=jp7 月/span span class=vmonth lang=ruиюль/span good point ... parsing it might end up needing a database of day and month names and character sets and numbers in every known language! (possibly also other types of calendars that might be used in some parts of the world ... this could get very complicated very quickly!) And yet, to not do so means breaking another restriction. It's about give and take. Is it better to make it easier for publishers, and harder for parsers, or is it better to store the same date twice, and let one go out of sync? I'd invite you to document the list of every possible way to represent each month in plain text, and then let us know if you still think reading through such a list to figure out how to publish dates is easier for publishers. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On 5/3/07 7:10 PM, Patrick H. Lauke [EMAIL PROTECTED] wrote: But to bring it back to the original argument, the routine extraction does not necessarily have to equate to data visible in, say, a tooltip. The routine extraction may well be mediated via some machine interpretation. May is insufficient in this case, as such machine mediated interpretation is a theoretical (or certainly not available to many people) and thus insufficient. The tooltip is the only practical semi-visible method available currently. This could change in the future, but XHTML 2.0 might also be adopted in the future. Such theoreticals are not useful to solving our problems now. If you have a deployed practical semi-visibility alternative to the tooltip, I'm very much interested to hear it. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
(apologies for top posting but this is in response to Al's entire message, not to any specific point in particular) Al, VERY well written. That's perhaps the clearest explanation I have seen of why it is important to have visible information, even somewhat visible rather than invisible. May I quote what you wrote in part or in full on microformats wiki? Thanks, Tantek On 5/3/07 6:18 PM, Al Gilman [EMAIL PROTECTED] wrote: At 12:24 AM +0100 4 05 2007, Patrick H. Lauke wrote: Tantek Çelik wrote: 2. Keep both copies of the data at least somewhat visible to humans so that at least *some* human eyes/ears can easily inspect both copies and ensure that they have not diverged. For the sake of argument, though: assuming that those human eyes/ears use a microformat-consuming tool/extension/etc, this can still happen. If I have a page with, say, contact details marked as a hcard, and human users export it to Outlook, they'll be able to see (and ensure) whether or not the generated vcard details in the add to address book dialog match the page's visible details or not. After all, isn't that what microformats are there for? Being consumed by machines that can make something useful with them? Almost. They are there so that people and machines can share info. If the machineable info is not routinely passing through the consciousness of the communicating principals (that is, people), then it must be expected that the machine and the person will frequently have different values for the same datum. Not a good thing. The old saw is, out of sight, out of mind. In this case it is use it or lose it (it's validity) for data. Microformats are to eliminate the mumbo-jumbo quality of the data the machines deal with; rather to give them the same many-eyeballs 'bazaar' checking support as the virally-maintained meanings of plain English (Chinese, Arabic or what have you...). That's a little overstated, but the devil is in the details. If in some community of communication, the data is routinely extracted into view often enough so that bad data tend to get weeded out, then the storage or transmission form doesn't have to be directly comprehensible by people. But one of the virtues of markup languages is just how much of the info is directly under the quality control of people; expressed in as little-encoded form as can be gotten away with. Al ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
I almost completely disagree with this. If people are actually *using* Microformats as intended, there will be plenty of times when the machine data will pass in front of the user (in their calendar program for example) for verification. I do however, agree with the following. expressed in as little-encoded form as can be gotten away with. I concur, but what is in dispute here is what can be gotten away with. The abbr-design-pattern has failed for machine data. Copied the entire email below for context. Tantek, if you post this to the wiki, please note it as opinion and give a link to the thread. Marking this as fact would misrepresent the views of the Microformats group as a whole. On May 4, 2007, at 7:53 AM, Tantek Çelik wrote: (apologies for top posting but this is in response to Al's entire message, not to any specific point in particular) Al, VERY well written. That's perhaps the clearest explanation I have seen of why it is important to have visible information, even somewhat visible rather than invisible. May I quote what you wrote in part or in full on microformats wiki? Thanks, Tantek On 5/3/07 6:18 PM, Al Gilman [EMAIL PROTECTED] wrote: At 12:24 AM +0100 4 05 2007, Patrick H. Lauke wrote: Tantek Çelik wrote: 2. Keep both copies of the data at least somewhat visible to humans so that at least *some* human eyes/ears can easily inspect both copies and ensure that they have not diverged. For the sake of argument, though: assuming that those human eyes/ears use a microformat-consuming tool/extension/etc, this can still happen. If I have a page with, say, contact details marked as a hcard, and human users export it to Outlook, they'll be able to see (and ensure) whether or not the generated vcard details in the add to address book dialog match the page's visible details or not. After all, isn't that what microformats are there for? Being consumed by machines that can make something useful with them? Almost. They are there so that people and machines can share info. If the machineable info is not routinely passing through the consciousness of the communicating principals (that is, people), then it must be expected that the machine and the person will frequently have different values for the same datum. Not a good thing. The old saw is, out of sight, out of mind. In this case it is use it or lose it (it's validity) for data. Microformats are to eliminate the mumbo-jumbo quality of the data the machines deal with; rather to give them the same many-eyeballs 'bazaar' checking support as the virally-maintained meanings of plain English (Chinese, Arabic or what have you...). That's a little overstated, but the devil is in the details. If in some community of communication, the data is routinely extracted into view often enough so that bad data tend to get weeded out, then the storage or transmission form doesn't have to be directly comprehensible by people. But one of the virtues of markup languages is just how much of the info is directly under the quality control of people; expressed in as little-encoded form as can be gotten away with. Al ___ 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] human readable date parsing
Scott Reynen wrote: Tantek Çelik wrote: To minimize the negative impact of that violation, the datetime design pattern does two things: 1. Keep both copies of the data on the same element (the further apart two copies of data, the greater the chance that that copies will diverge). 2. Keep both copies of the data at least somewhat visible to humans so that at least *some* human eyes/ears can easily inspect both copies and ensure that they have not diverged. None of the markup possibilities in the wiki do #2 above (except the current recommendation): http://microformats.org/wiki/assistive-technology-abbr- results#Markup_Possibilities Look again. * Span with title property. It sounds like these aren't really possibilities at all. I don't see how we can possibly reach any sort of consensus solution here when we seem to have completely opposed goals intermingled as if they're the same. Some people are clearly trying to *minimize* the visibility while others are trying to *maximize* the visibility of machine-readable dates. Let's try to get everyone on the same page here. In addition to span[titile] existing Microformat plug-ins and parsers do the following quite nicely, making all of the listed markup formats very real possibilities. 2. Keep both copies of the data at least somewhat visible to humans ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On 5/4/07 8:19 AM, James Craig [EMAIL PROTECTED] wrote: Copied the entire email below for context. Tantek, if you post this to the wiki, please note it as opinion and give a link to the thread. Marking this as fact would misrepresent the views of the Microformats group as a whole. I disagree - Al's explanation provides good reasons *in general* why visible data works (and why invisible does not work), and so far, all that has been thrown up against his statements are a bunch of theoreticals, mostly centered around the tools will solve the problem fallacy that so many have fallen for historically (i.e. look at so many metadata like efforts before microformats that have failed miserably depending on such fallacies). Al's statements are well reasoned conclusions, not opinions. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On May 4, 2007, at 8:24 AM, Tantek Çelik wrote: On 5/4/07 8:19 AM, James Craig [EMAIL PROTECTED] wrote: I almost completely disagree with this. If people are actually *using* Microformats as intended, there will be plenty of times when the machine data will pass in front of the user (in their calendar program for example) No the in their calendar program is totally insufficient because it is nearly completely detached from the other representation of the data. In a separate window etc. etc. People don't tend to switch between two windows to check to see if the info was the same. I also mentioned Tails which displays the data in the same window. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes On 5/4/07 8:19 AM, James Craig [EMAIL PROTECTED] wrote: I almost completely disagree with this. If people are actually *using* Microformats as intended, there will be plenty of times when the machine data will pass in front of the user (in their calendar program for example) No the in their calendar program is totally insufficient because it is nearly completely detached from the other representation of the data. In a separate window etc. etc. People don't tend to switch between two windows to check to see if the info was the same. Isn't the later point exactly the kind of theoretical assertion that you complain about, when others use them? Or do you have some evidence to support it? It's certainly not my practice to save events to my calendar without double-checking the details as I do so. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes Al's explanation provides good reasons *in general* why visible data works (and why invisible does not work), Hmm. Consider: a href=cheese lang=frFromagea Where's the visible data there? By your logic, tags should only work on the anchor element's content, not the tail of it's URL. You appear to be operating double standards. -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
In message [EMAIL PROTECTED], Breton Slivka [EMAIL PROTECTED] writes It seems to me that in order to more effectively solve this problem, this set of restrictions should be clarified- Here's what I've got so far, correct me if I'm wrong. Date markup must: 1 be capable of marking up dates from multiple cultures and languages 2 Follow the DRY principle 3 Be completely visible 4 Follow common usage 5 Be machine readable 6 Be unambiguous and the unstated (and perhaps unconcious) restriction 7 Be as similar to iCalendar as possible in form and function. Not a correction but an addition - I'm surprised, in the light of the recent debate, that you omitted: Be accessible which might be more tightly worded as, say: Meet WCAG accessibility guidelines -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Andy Mabbett wrote: Tantek Çelik writes Al's explanation provides good reasons *in general* why visible data works (and why invisible does not work), Consider: a href=cheese lang=frFromagea Where's the visible data there? By your logic, tags should only work on the anchor element's content, not the tail of it's URL. You appear to be operating double standards. I agree. Using an optional title on the following would be a much better solution for rel-tag than the current implementation. Though, as indicated, the french tag should probably still remain in French. a rel=tag href=/username/tags/cheese title=CheeseYour Cheesea a rel=tag href=/tags/cheese title=CheeseEveryone's Cheesea a rel=tag href=/tags/fromage title=Fromage lang=frFromagea Using title would also allow proper internationalization of rel-tag. For example, the restful katakana tag space is readable only to machines. a rel=tag href=/tags/%u30D4%u30D5/ title=ピフピフ/a ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Scott Reynen wrote: I'd invite you to document the list of every possible way to represent each month in plain text, and then let us know if you still think reading through such a list to figure out how to publish dates is easier for publishers. Maybe I've lost track of the original issue here, but: publishers don't need to know all variations in all languages, just the version in the language they're authoring, no? P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On May 4, 2007, at 2:42 PM, Patrick H. Lauke wrote: I'd invite you to document the list of every possible way to represent each month in plain text, and then let us know if you still think reading through such a list to figure out how to publish dates is easier for publishers. Maybe I've lost track of the original issue here, but: publishers don't need to know all variations in all languages, just the version in the language they're authoring, no? Publishers need to know how to speak in a syntax parsers can understand. With plain text standards, that requires listing every understood term. In English, does the month standard use August, Aug, both? In Japanese, is it 八月, はち月, はちが つ, 八がつ, 葉月, some combination of these options? That's just one of twelve months in two of the hundreds of languages. I think this is clearly more complicated than ISO 8601, for both parsers and publishers. But if you think it can be easier, go ahead and write up the month syntax in each language so we can all compare the plain text standard with the current recommendation. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
iso date isn't necessarily required when someone enters a date (i.e. saying 24th June doesn't translate into a single date, neither does 'thursday'). Shouldn't the focus be on trying to standardise date I'm normally all for liberalness in parsing but NOT when the intended meaning becomes ambiguous. I do not think we should encourage people to leave off the year unless it is absolutely necessary (such as for a recurring event and in that case it should be marked up in a way so that the intention is clear - rrule, etc) - otherwise how do we know if the author intended 24th June to mean 24th June 2007 or 24th June 2006 or the next occurrence of 24th June (from what date?) or 24th June every year? I have dabbled in trying to extract human-readable dates from rss feeds and this type of ambiguity is such a problem that I had to ignore any dates without the year! (those entries are unusable!) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Looks to me that we have these goals: * Specify a date in a format that a machine can understand (i.e. the ISO8601 format) * Stash it somewhere where it's legal to do so, and is not apparent to human readers I'm still undecided whether a full ISO date is abbreviable as a normal date, but looks like it won't matter in the end. Since the baseline is the HTML4 spec, I have been re-reading it to look where else we might put it. I know Tantek did so back in the day, but it's still a good exercise for the rest of us. Perhaps what I'm about to say doesn't make much sense, but for the sake of brainstorming, and perhaps because it might spark an idea on someone else's head, I won't refrain from chiming in ;) Since using ISO8601 is a w3c recommendation, I wondered where specifically they were recommending its use. Looks like there is an element (a couple of them, actually) with an attribute that can legally contain an ISO datetime: INS and DEL. Furthermore, the spec says deleted text may not be shown at all , which makes it sound like screen-readers should ignore it --however this might make them skip the human readable text as well. I know it's semantically dubious, but perhaps we might write span class=dtstartFriday the 13th ins datetime=20070713 //span Another idea, that would make a bit more semantic sense perhaps, but wont' be acceptable to screen readers, would be something like CODE (after all, we are speaking about machien-readable text) or DT/DD (where the short form is the term and the ISO datetime is the definition). They don't exactly hide the information intended for the machines, but mark it up as such, so that it's easily ignorable. Other parts of the spec that look interesting, and that I had forgotten long ago, are script macros [1]; and perhaps even specifying datetime info as script data, put on an event handler (in the ABBR or SPAN element) that we know we won't trigger normally (for example, an onblur on an empty element). Just my 2c. Cheers, Victor [1] http://www.w3.org/TR/html401/appendix/notes.html#notes-specifying-data -- Victor Jalencas [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On 5/3/07 1:40 AM, victor jalencas [EMAIL PROTECTED] wrote: * Stash it somewhere where it's legal to do so valid would be more precise rather than legal and is not apparent to human readers To be clear, this clause, in the absolute, is undesirable. That is, in following the principles of microformats, the date needs to be at least somewhat *visible* to humans, rather than invisible. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Tantek Çelik wrote: To be clear, this clause, in the absolute, is undesirable. That is, in following the principles of microformats, the date needs to be at least somewhat *visible* to humans, rather than invisible. But not the machine-readable part, if it makes no sense to the human reader. P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On 03/05/07, Patrick H. Lauke [EMAIL PROTECTED] wrote: Tantek Çelik wrote: To be clear, this clause, in the absolute, is undesirable. That is, in following the principles of microformats, the date needs to be at least somewhat *visible* to humans, rather than invisible. But not the machine-readable part, if it makes no sense to the human reader. Exactly. I was still referring to the machine readable format. I don't think the human readable part causes many problems veing visible, not even to the machine. Victor -- Victor Jalencas [EMAIL PROTECTED] ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
victor jalencas wrote: Since using ISO8601 is a w3c recommendation, I wondered where specifically they were recommending its use. Looks like there is an element (a couple of them, actually) with an attribute that can legally contain an ISO datetime: INS and DEL. Technically, that should only be used when the textual content of the element has been inserted or deleted, but I don't have an issue with the empty ins or del. I've added it to the wiki test cases. Other parts of the spec that look interesting, and that I had forgotten long ago, are script macros [1]; and perhaps even specifying datetime info as script data, put on an event handler (in the ABBR or SPAN element) that we know we won't trigger normally (for example, an onblur on an empty element). onchange would be even less likely. I've added both the test cases. http://microformats.org/wiki/assistive-technology-abbr- results#Valid_HTML4 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Tantek Çelik wrote: and is not apparent to human readers To be clear, this clause, in the absolute, is undesirable. That is, in following the principles of microformats, the date needs to be at least somewhat *visible* to humans, rather than invisible. I still don't understand this part. Why would the ISO date need to be visible to users/humans? Does 'visible to humans' *really* equate to 'will definitely be available to parsers'? Jon -- gr0w.com dotjay.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On May 3, 2007, at 12:23 PM, Tantek Çelik wrote: and is not apparent to human readers To be clear, this clause, in the absolute, is undesirable. That is, in following the principles of microformats, the date needs to be at least somewhat *visible* to humans, rather than invisible. I think it's important to be clear about this and I find the date needs to be at least somewhat *visible* to humans still very ambiguous, as the responses so far seem to suggest. *Which* date are you talking about? The human-readable date obviously needs to be human-readable, but are you including the machine-readable date here? If so, which microformats principle suggests this? Designing for humans first suggests to me that we should give humans human- readable dates and keep the machine-readable dates for machines. I think this is what human readers generally prefer, and it must be what human publishers prefer, or we wouldn't have any need for the abbr design pattern in the first place. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On 5/3/07 10:48 AM, victor jalencas [EMAIL PROTECTED] wrote: On 03/05/07, Patrick H. Lauke [EMAIL PROTECTED] wrote: Tantek Çelik wrote: To be clear, this clause, in the absolute, is undesirable. That is, in following the principles of microformats, the date needs to be at least somewhat *visible* to humans, rather than invisible. But not the machine-readable part, No. microformats should not be encouraging *any* invisible data, because invisible data = inaccurate data. if it makes no sense to the human reader. Plenty of people can read and make sense of ISO dates. Exactly. I was still referring to the machine readable format. I don't think the human readable part causes many problems veing visible, not even to the machine. Human readable to one culture/language is not necessarily human readable to other cultures/languages. It might even make an interesting test to see what date format was more accurately readable to more readers world wide, e.g. -MM-DD or MM/DD for example. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On 5/3/07 2:50 PM, Scott Reynen [EMAIL PROTECTED] wrote: On May 3, 2007, at 12:23 PM, Tantek Çelik wrote: and is not apparent to human readers To be clear, this clause, in the absolute, is undesirable. That is, in following the principles of microformats, the date needs to be at least somewhat *visible* to humans, rather than invisible. I think it's important to be clear about this and I find the date needs to be at least somewhat *visible* to humans still very ambiguous, as the responses so far seem to suggest. *Which* date are you talking about? Any/all. The human-readable date obviously needs to be human-readable, but are you including the machine-readable date here? Yes. If so, which microformats principle suggests this? Visible data. Designing for humans first suggests to me that we should give humans human- readable dates and keep the machine-readable dates for machines. Making dates machine readable does not preclude making them at least *somewhat* visible. I think this is what human readers generally prefer, and it must be what human publishers prefer, or we wouldn't have any need for the abbr design pattern in the first place. The abbr design pattern balanced the visible data being the most human readable, and the somewhat visible (title attribute, visible only as a tooltip typically) data being the more machine readable version. No version of the data should be encourage to be invisible as it will simply become inaccurate as a result. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
On 5/3/07 1:14 PM, Jon Gibbins (dotjay) [EMAIL PROTECTED] wrote: Tantek Çelik wrote: and is not apparent to human readers To be clear, this clause, in the absolute, is undesirable. That is, in following the principles of microformats, the date needs to be at least somewhat *visible* to humans, rather than invisible. I still don't understand this part. Why would the ISO date need to be visible to users/humans? Does 'visible to humans' *really* equate to 'will definitely be available to parsers'? 'visible to humans' does equate to more accurate, more up-to-date data. It is bad enough that we are violating DRY by putting the same information in twice. The only justification for violating DRY in this case is the high principle of humans first, machines second. To minimize the negative impact of that violation, the datetime design pattern does two things: 1. Keep both copies of the data on the same element (the further apart two copies of data, the greater the chance that that copies will diverge). 2. Keep both copies of the data at least somewhat visible to humans so that at least *some* human eyes/ears can easily inspect both copies and ensure that they have not diverged. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Tantek Çelik wrote: 2. Keep both copies of the data at least somewhat visible to humans so that at least *some* human eyes/ears can easily inspect both copies and ensure that they have not diverged. For the sake of argument, though: assuming that those human eyes/ears use a microformat-consuming tool/extension/etc, this can still happen. If I have a page with, say, contact details marked as a hcard, and human users export it to Outlook, they'll be able to see (and ensure) whether or not the generated vcard details in the add to address book dialog match the page's visible details or not. After all, isn't that what microformats are there for? Being consumed by machines that can make something useful with them? P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
This is a very difficult problem. Difficult problems need as many potential solutions as possible to be presented- The more solutions, the more chance of arriving at a good one. The tricky part here is creating a solution which is in line with common usage. It seems to me that by basing hcalendar on a single existing format, then expecting it to conform to some wider sense of principles concieved well after that format was created- It's a bit counter productive. the ISO date format itself does not fall in line with common usage, unless you consider the iCalendar format- posted in the raw on an html page to be common, or any ISO date. So basically we are presented with a number of restrictions, which define the range of possible solutions. It seems to me that in order to more effectively solve this problem, this set of restrictions should be clarified- Here's what I've got so far, correct me if I'm wrong. Date markup must: 1 be capable of marking up dates from multiple cultures and languages 2 Follow the DRY principle 3 Be completely visible 4 Follow common usage 5 Be machine readable 6 Be unambiguous and the unstated (and perhaps unconcious) restriction 7 Be as similar to iCalendar as possible in form and function. At least two of these restrictions conflict. Most obvious is number 4 and 6. Common usage is frequently ambiguous, so we should perhaps acknowledge that a microformat that marks up a date is going to either force common usage to be unambiguous (By requiring the inclusion of a year in all dates) Or instead, allow ambiguity through sophisticated (or unsophisticated) guessing on the part of the parser. If this course is taken, this process of guessing should be documented and standardized Or, violate restrictions 2 and 3, which is the current solution. So, are those all the restrictions? In order to arrive at a solution, at least one of them must be violated- are we violating the right one? Here's my contribution to the solutions pool. Violate number 7. Example: July 26th, 2005 span class=vmonthJuly/span span class=vday26/spanth, span class=vyear2005/span This solution is certainly more verbose, but note that it follows all restrictions except for 7. Which restrictions do you want to violate? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
I should perhaps add that my solution must also violate either restriction 3, or 4- that is, you can hide the year element with CSS. If you leave it visible, then it may follow common usage in a lot of situations. Or you might end up using a year in situations where you may not usually specify a year, violating the common usage in that situation. If you hide it, then you violate 3. But, the choice of which principle to violate is left in the hands of the author. On 04/05/2007, at 9:49 AM, Breton Slivka wrote: This is a very difficult problem. Difficult problems need as many potential solutions as possible to be presented- The more solutions, the more chance of arriving at a good one. The tricky part here is creating a solution which is in line with common usage. It seems to me that by basing hcalendar on a single existing format, then expecting it to conform to some wider sense of principles concieved well after that format was created- It's a bit counter productive. the ISO date format itself does not fall in line with common usage, unless you consider the iCalendar format- posted in the raw on an html page to be common, or any ISO date. So basically we are presented with a number of restrictions, which define the range of possible solutions. It seems to me that in order to more effectively solve this problem, this set of restrictions should be clarified- Here's what I've got so far, correct me if I'm wrong. Date markup must: 1 be capable of marking up dates from multiple cultures and languages 2 Follow the DRY principle 3 Be completely visible 4 Follow common usage 5 Be machine readable 6 Be unambiguous and the unstated (and perhaps unconcious) restriction 7 Be as similar to iCalendar as possible in form and function. At least two of these restrictions conflict. Most obvious is number 4 and 6. Common usage is frequently ambiguous, so we should perhaps acknowledge that a microformat that marks up a date is going to either force common usage to be unambiguous (By requiring the inclusion of a year in all dates) Or instead, allow ambiguity through sophisticated (or unsophisticated) guessing on the part of the parser. If this course is taken, this process of guessing should be documented and standardized Or, violate restrictions 2 and 3, which is the current solution. So, are those all the restrictions? In order to arrive at a solution, at least one of them must be violated- are we violating the right one? Here's my contribution to the solutions pool. Violate number 7. Example: July 26th, 2005 span class=vmonthJuly/span span class=vday26/spanth, span class=vyear2005/span This solution is certainly more verbose, but note that it follows all restrictions except for 7. Which restrictions do you want to violate? ___ 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] human readable date parsing
At 12:24 AM +0100 4 05 2007, Patrick H. Lauke wrote: Tantek Çelik wrote: 2. Keep both copies of the data at least somewhat visible to humans so that at least *some* human eyes/ears can easily inspect both copies and ensure that they have not diverged. For the sake of argument, though: assuming that those human eyes/ears use a microformat-consuming tool/extension/etc, this can still happen. If I have a page with, say, contact details marked as a hcard, and human users export it to Outlook, they'll be able to see (and ensure) whether or not the generated vcard details in the add to address book dialog match the page's visible details or not. After all, isn't that what microformats are there for? Being consumed by machines that can make something useful with them? Almost. They are there so that people and machines can share info. If the machineable info is not routinely passing through the consciousness of the communicating principals (that is, people), then it must be expected that the machine and the person will frequently have different values for the same datum. Not a good thing. The old saw is, out of sight, out of mind. In this case it is use it or lose it (it's validity) for data. Microformats are to eliminate the mumbo-jumbo quality of the data the machines deal with; rather to give them the same many-eyeballs 'bazaar' checking support as the virally-maintained meanings of plain English (Chinese, Arabic or what have you...). That's a little overstated, but the devil is in the details. If in some community of communication, the data is routinely extracted into view often enough so that bad data tend to get weeded out, then the storage or transmission form doesn't have to be directly comprehensible by people. But one of the virtues of markup languages is just how much of the info is directly under the quality control of people; expressed in as little-encoded form as can be gotten away with. Al P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ ___ 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] human readable date parsing
Breton Slivka wrote: span class=vmonthJuly/span span class=vday26/spanth, span class=vyear2005/span This solution is certainly more verbose, but note that it follows all restrictions except for 7. I don't think this will work, for the same reason tel-type and adr- type don't work: l10n/i18n. They require displayed machine values to be in English. span class=vmonth lang=enJuly/span span class=vmonth lang=esjulio/span span class=vmonth lang=jp7 月/span span class=vmonth lang=ruиюль/span ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Al Gilman wrote: If the machineable info is not routinely passing through the consciousness of the communicating principals (that is, people), Who may, without the machine-mediated interpretation, not actually be able to make a qualitative judgement (e.g. if I see a geo lat/long value , I'm not enough of a walking map to instantly be able to review that data...so I will need to run it through something like google maps to work out if the data is duff or not)... If in some community of communication, the data is routinely extracted into view often enough so that bad data tend to get weeded out, then the storage or transmission form doesn't have to be directly comprehensible by people. But one of the virtues of markup languages is just how much of the info is directly under the quality control of people; expressed in as little-encoded form as can be gotten away with. But to bring it back to the original argument, the routine extraction does not necessarily have to equate to data visible in, say, a tooltip. The routine extraction may well be mediated via some machine interpretation. P -- Patrick H. Lauke __ re·dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com __ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ __ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ __ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
I don't think this will work, for the same reason tel-type and adr- type don't work: l10n/i18n. They require displayed machine values to be in English. span class=vmonth lang=enJuly/span span class=vmonth lang=esjulio/span span class=vmonth lang=jp7 月/span span class=vmonth lang=ruиюль/span good point ... parsing it might end up needing a database of day and month names and character sets and numbers in every known language! (possibly also other types of calendars that might be used in some parts of the world ... this could get very complicated very quickly!) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Tim Parkin wrote: With all of the discussion about iso dates being unreadable and that an iso date isn't necessarily required when someone enters a date (i.e. saying 24th June doesn't translate into a single date, neither does 'thursday'). Shouldn't the focus be on trying to standardise date formats rather than trying to hide the iso date? If we can get a parser to recognise 'human readable' dates (which *is* possible, if not totally easy, http://labix.org/python-dateutil for a python version). I disagree. If you try to make other, human readable formats into a standard, they will fall short when it comes time to internationaliz (s)e it. If you can come up with a better format readable to all machine and all humans in all languages, I'll recant. I think the ISO 8601 is the best machine data format for the job. I just don't think it should be in abbr. James ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
From: James Craig [EMAIL PROTECTED]
To: Microformats Discuss microformats-discuss@microformats.org
Sent: Thursday, May 03, 2007 8:56 AM
Subject: Re: [uf-discuss] human readable date parsing
Tim Parkin wrote:
With all of the discussion about iso dates being unreadable and that an
iso date isn't necessarily required when someone enters a date (i.e.
saying 24th June doesn't translate into a single date, neither does
'thursday'). Shouldn't the focus be on trying to standardise date
formats rather than trying to hide the iso date? If we can get a parser
to recognise 'human readable' dates (which *is* possible, if not totally
easy, http://labix.org/python-dateutil for a python version).
I disagree. If you try to make other, human readable formats into a
standard, they will fall short when it comes time to internationaliz (s)e
it. If you can come up with a better format readable to all machine and
all humans in all languages, I'll recant.
I think the ISO 8601 is the best machine data format for the job. I just
don't think it should be in abbr.
So as machine-readable information shouldn't be presented in a
human-readable manner, that rules out having the information in-the-clear,
and in title tags.
This leads us to having a hidden class for machine-readable information that
will be hidden by default and not presented to people.
A class with a suitable name would have to be used, something like the
existing value but modified to infer that it's for the computer only and
isn't to be read.
What if the value class was to be used with a hidden class. Then they would
serve their purpose, they wouldn't interfere with existing styles and could
be interpreted correctly.
.hidden {display: hidden}
Then the human-readable and machine-readable can be mashed together. If the
screen-reading software honor hidden styles this could be the right path to
take.
span class=dtstartFriday the 13th span class=hidden
value20070713/span/span
--
Paul Wilkins
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
Paul Wilkins wrote:
What if the value class was to be used with a hidden class. Then they
would serve their purpose, they wouldn't interfere with existing styles
and could be interpreted correctly.
.hidden {display: hidden}
Then the human-readable and machine-readable can be mashed together. If
the screen-reading software honor hidden styles this could be the right
path to take.
That would still render the machine-readable part in the clear on
platforms with incomplete or missing support for CSS, such as some
current mobile devices. Also, it feels conceptually wrong to have
machine-readable stuff sprinkled into what should just be content.
Note that, based on current practice adopted by screen readers, only
TITLE on ABBR is explicitly being given status as human-readable.
The content of the ABBR and ACRONYM elements specifies the abbreviated
expression itself, as it would normally appear in running text. The
title attribute of these elements may be used to provide the full or
expanded form of the expression.
http://www.w3.org/TR/html401/struct/text.html#edef-ABBR
So, although the spec tempers this with a may, it does suggest this
kind of use by screen readers.
Values of the title attribute may be rendered by user agents in a
variety of ways. [...] For example, setting the attribute on a link
allows user agents (visual and non-visual) to tell users about the
nature of the linked resource:
http://www.w3.org/TR/html401/struct/global.html#adef-title
There's a may here as well, but the generic definition for title
(which could then be used on something like a span) seems far more lax
to me, and in that respect more suited to be plied/bent for microformat
data use. IMHO, of course.
P
--
Patrick H. Lauke
__
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]
www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com
__
Co-lead, Web Standards Project (WaSP) Accessibility Task Force
http://webstandards.org/
__
Take it to the streets ... join the WaSP Street Team
http://streetteam.webstandards.org/
__
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
James Craig wrote: Tim Parkin wrote: With all of the discussion about iso dates being unreadable and that an iso date isn't necessarily required when someone enters a date (i.e. saying 24th June doesn't translate into a single date, neither does 'thursday'). Shouldn't the focus be on trying to standardise date formats rather than trying to hide the iso date? If we can get a parser to recognise 'human readable' dates (which *is* possible, if not totally easy, http://labix.org/python-dateutil for a python version). I disagree. If you try to make other, human readable formats into a standard, they will fall short when it comes time to internationaliz(s)e it. If you can come up with a better format readable to all machine and all humans in all languages, I'll recant. I think the ISO 8601 is the best machine data format for the job. I just don't think it should be in abbr. Yes, indeed.. And I was wrong to say shouldn't the focus be.. I was just approaching the problem from a different angle to see if it looked more tractable, not from this angle obviously :-) In the vein of approaching things from a totally different angle, how about using hidden input field for the value? (I realise there are many problems with this but it might be worth documenting some of the negatives for future reference - I'm happy to start by saying Visual Developers propensity to formify the whole page could cause issues.. but then again VD may just be an issue in itself). Tim ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] human readable date parsing
James Craig wrote: Tim Parkin wrote: [...] Shouldn't the focus be on trying to standardise date formats rather than trying to hide the iso date? If we can get a parser to recognise 'human readable' dates (which *is* possible, if not totally easy, http://labix.org/python-dateutil for a python version). I disagree. If you try to make other, human readable formats into a standard, they will fall short when it comes time to internationaliz(s)e it. If you can come up with a better format readable to all machine and all humans in all languages, I'll recant. I think the ISO 8601 is the best machine data format for the job. I just don't think it should be in abbr. Agreed, James. ISO 8601 is the best format. There may be an option to have a space in the notation between the date and time thus removing the T [1],[2]. E.g: 2007-05-20 12:34 This is read by JAWS 8.0 in IE6 and IE7 as two thousand seven dash zero five dash twenty twelve thirty-four (via Jon Gibbins [3]). However, RFC 3339 [4] or W3C Date and Time format note [5] doesn't feature a space in the available examples. The issue for me is we're trying to fit a machine readable date in to a human readable form. All users (whether visually impaired or not) still need to know the format or learn it as they have to learn every interface element at first contact. No matter what the notation is, it will always be fairly ambiguous. Prepending the value still seems to me to be worthy of consideration in order to provide context and help users to learn the notation in a some way. After first coming across it, at least screen reader users (and everyone else) can choose not expand attribute values for dates and times (choosing not to learn it as irrelevant), or search to learn more about the notation. Jon Tan http://gr0w.com [1] http://www.cl.cam.ac.uk/~mgk25/iso-time.html (Time of day section) [2] http://www.cs.tut.fi/~jkorpela/iso8601.html (in the summary) [3] http://dotjay.co.uk/tests/screen-readers/microformats/datetime-design-pattern/-MM-DD%20HH-MM.php [4] http://www.ietf.org/rfc/rfc3339.txt [5] http://www.w3.org/TR/NOTE-datetime ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
