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] Regarding POSH and misuse of the microformats logo
On 03/05/07, Andy Mabbett [EMAIL PROTECTED] wrote: If it is intended to be separate form microformats, then having so much about it on the microformat 'wiki' is somewhat misleading. I must admit that I have some qualms about having it on the microformats wiki also - if it's a term designed to disambiguate, it's highly confusing for it to stem from microformats (even if though they are POSH) and probably a bit counter-intuitive! -- Frances Berriman http://fberriman.com ___ 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
[uf-discuss] Expanding the abbr pattern: thoughts
I've done more testing with the spanned/title solution to an abbreviated date time pattern, and finally confirmed Jon Gibbins' report. It seems JAWS has a few nuances I didn't know about. I was planning to 'bake' a forum and comment system with microformats (hAtom hReview) and I'd prefer to get the date time pattern thing solved before I start coding. Breton's solution might work, but it just seems like too many spanned elements (spanitis?). Obviously, if we're going to run with ISO8601, we need to include the dashes as JAWS does read it better (which may require the usetitle solution). Any feedback on what would be an adequate common ground for this issue as I want to start developing ? Thanks Lawrence -- Lawrence Meckan Absalom Media Mob: (04) 1047 9633 ABN: 49 286 495 792 http://www.absalom.biz ___ 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] Expanding the abbr pattern: thoughts
Absalom Media wrote: Obviously, if we're going to run with ISO8601, we need to include the dashes as JAWS does read it better (which may require the usetitle solution). Any feedback on what would be an adequate common ground for this issue as I want to start developing ? While ISO 8601 is the right choice, reading it to a screen reader in any form is unacceptable. We're working on test of alternatives to the abbr-design-pattern for machine data. I encourage you to contribute: http://microformats.org/wiki/assistive-technology-abbr-results In the meantime, I would suggest using your best judgement with implementation. James ___ 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] Expanding the abbr pattern
In message [EMAIL PROTECTED], Paul Wilkins [EMAIL PROTECTED] writes The following from the proposal I suspect is errant. abbr class=enddate title=2007-03-3131 January 2007/abbr Were you after the following? abbr class=enddate title=2007-01-3131 January 2007/abbr Yes; I note that you've already fixed that on the 'wiki'. Thank you. -- 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
[uf-discuss] Yahoo introduces no-search microformat like function
This was a bit of a surprise on the yahoo search blog. Its using the word tag incorrectly. It seems the search department is adding a new microformat-like function that will allow us to tell spiders what parts of the page are insignificant to SEO. http://www.ysearchblog.com/archives/000444.html This sounds like a useful idea. It may even help us target phone devices and other alternative presentations. I watched a demo the other day of a voice activated browser for any phone. They were able to use algorithms to decide what parts of a web page were worth reading to a listener. This microformat spells it out pretty quickly. Whats the traction for something like this and no-follow to get integrated into the microformat platform? Ted Drake Yahoo! Answers Coming soon... European Finance - Paris Member of the Yahoo! Accessibility Stakeholders Group Enable Your Audience Are you serving the 55 millon kids and adults with disabilities in the United States? How about the 550 million around the world? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Yahoo introduces no-search microformat like function
http://microformats.org/discuss/mail/microformats-discuss/2007-May/009504.html On 5/4/07, Ted Drake [EMAIL PROTECTED] wrote: This was a bit of a surprise on the yahoo search blog. It's using the word tag incorrectly. It seems the search department is adding a new microformat-like function that will allow us to tell spiders what parts of the page are insignificant to SEO. http://www.ysearchblog.com/archives/000444.html This sounds like a useful idea. It may even help us target phone devices and other alternative presentations. I watched a demo the other day of a voice activated browser for any phone. They were able to use algorithms to decide what parts of a web page were worth reading to a listener. This microformat spells it out pretty quickly. What's the traction for something like this and no-follow to get integrated into the microformat platform? Ted Drake -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ 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] Regarding POSH and misuse of the microformats logo
Right, I've set up a vote for this on the Wiki. As explained in my Wiki commit comment, with the POSH page being something of a reference rather than a page of active microformat development, I judge it to be inappropriate to tack the vote on to the article itself and have created a Talk: page for the vote instead. If interested parties could please contribute and offer any objections by Wednesday evening (allowing the UK bank holiday weekend and two working days for collection). http://microformats.org/wiki/Talk:posh Cheers, Ben On 3 May 2007, at 13:06, Serdar Kiliç wrote: I agree, there shouldn't be an association with the Microformats logo with that of any POSH logo. As you say, it's important to be able to distinguish the two, which I believe is accomplished with the information found on the wiki page. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Yahoo introduces no-search microformat like function
On 4 May 2007, at 22:19, Ted Drake wrote: What’s the traction for something like this and “no-follow” to get integrated into the microformat platform? Well, robots-nocontent is not part of the the robots-exclusion draft, which in itself has not been updated for over 18 months. I contacted Priyank yesterday and he confirmed that Search have not implemented any of the robots-exclusion draft itself, nor have they implemented an opposite ‘robots-content’ class. I will email him again to see if we can get a concise specification of the indexing behaviour for robots-nocontent page sections so that it can at least be documented. If Peter Janes is still active here or if anyone else has an interest in picking up the robots-exclusion spec then it will be up to them and their work within the process to determine if the implementation can be documented as part of it. It seems like as good a time to ask; does anyone in the community still have an active interest in Robots-Exclusion? Are there any implementations? (Since I know disclosure is appreciated: If it's not already clear from the communications documented in this message, I recently started working for Yahoo! Europe. With relevance to this issue though, I am not in any way involved in Yahoo! Search. In a more general sense, at this time, none of my contributions to this list are representative of Yahoo! and so on and so forth yada yada) Regards, Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
