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
[uf-discuss] robots-nocontent
Hello, Just an FYI. http://www.ysearchblog.com/archives/000444.html Basically, there's a class name robots-nocontent that marks a section of a webpage as not to be NOT payed attention to but Yahoo!'s webcrawler. Seems related to... http://microformats.org/wiki/robots-exclusion See ya -- 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
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
[uf-discuss] Regarding POSH and misuse of the microformats logo
Hi all, I've obviously been following the recent push to have POSH adopted as a buzzword to discourage people from mis-using the term ‘microformat’ in their semantic endeavours. Now the whole point of this is to differentiate semantic HTML from microformats, discourage the further ambiguation of the terms. So to be honest I'm a bit put out by the badges that have been added to http://microformats.org/wiki/posh#POSH_Bling_for_your_Blog which include the microformats logo. As part of our ‘community mark’ experiment I'd like to object to that usage of the microformats logo and ask those badges be removed. Regardless of what anyone thinks of the term, POSH is explicitly supposed to be a super-set of microformats, a generic term invented to help protect the microformats name from being generalised. If the first thing people do — on our own wiki, no less — is tack the microformats logo to it then it will do absolutely nothing toward that goal, and with all the current hype will only accelerate the loss of ‘microformat’ as a name for the Process. POSH is not a microformat. The documented presence on our wiki is acceptable as ‘microformat’ mis-use is a common problem for us, but I object to it being presented as part of ‘microformats’ through association with the logo. It's just going to cause more confusion. Cheers, Ben ___ 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/2007, at 7:02 PM, Ben Ward wrote: As part of our ‘community mark’ experiment I'd like to object to that usage of the microformats logo and ask those badges be removed. Regardless of what anyone thinks of the term, POSH is explicitly supposed to be a super-set of microformats, a generic term invented to help protect the microformats name from being generalised. If the first thing people do — on our own wiki, no less — is tack the microformats logo to it then it will do absolutely nothing toward that goal, and with all the current hype will only accelerate the loss of ‘microformat’ as a name for the Process. POSH is not a microformat. The documented presence on our wiki is acceptable as ‘microformat’ mis-use is a common problem for us, but I object to it being presented as part of ‘microformats’ through association with the logo. It's just going to cause more confusion. Cheers, Ben 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. Cheers, Serdar ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Expanding the abbr pattern
i think the abbr pattern is a valid one. moving the unambiguous timestamp to some place humans can't see it is asking for it to be removed be a third party (whether that is a screenreader, an html sanitizer, or a web browser makes little difference.) and of course in some cases you can get away with not using abbr: Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span with hyphens it's reasonably human-readable. i've been using fully punctuated iso 8601 date notation it everyday life (checks, contracts, even announcements) for years with no problems whatsoever. (e.g. 2007-03-12) this seems suitable for use in an abbr title. however, the combined datetime notation is a bit awkward due to the 'T' and time zone suffix (the former needed for separation from date and the latter needed for disambiguation -- the problem is that time zones are not widely understood regardless of notation.) treating whitespace as a field separator and so allowing date time to be equivalent to dateTtime removes one of the complaints, and forcing the human-readable timestamp into GMT/UTC eliminates another (microformats and other broadly-consumed data should probably default to GMT when no timezone is specified.) however this leaves us with the still-difficult problem of explaining a time from another timezone. maybe we need a dhtml widget to localize times for display, while allowing the page to contain only GMT/UTC? anyhow, sorry for the slightly-off-topic brainstorming, -ben On 5/2/07, Ben Buchanan [EMAIL PROTECTED] wrote: So, I started this response thinking How does a full-string timestamp /not/ disambiguate a March 2 date in the following? My answer is: by not being human-readable :) The example in the original post shows the problem: abbr class=dtstart title=20070312T1700-06 March 12, 2007 at 5 PM, Central Standard Time /abbr When vocalised, that title is less useful than the text it potentially replaces (screen readers may read just the text, just the title or both). Perhaps I should have said effective disambiguation, for all human users. At any rate, I think the main problem was referring to different examples - in yours, the shorter date probably would make sense to all users and yes it disambiguates. The datestamp in the microformat however, does not disambiguate for humans. ...and I think I've used up my quota for disambiguate, so I'll end there ;) cheers, Ben -- --- http://weblog.200ok.com.au/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson ___ 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
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] Expanding the abbr pattern
Ben Wiley Sittler wrote: in some cases you can get away with not using abbr: Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span with hyphens it's reasonably human-readable. i've been using fully punctuated iso 8601 date notation it everyday life (checks, contracts, even announcements) for years with no problems whatsoever. Just want to raise, at this point, the problem an author might face with regards to an organisation's house styles. For instance, at my university, we have very specific guidelines for how dates and times etc should be written (hint: it ain't ISO-anything). 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] Regarding POSH and misuse of the microformats logo
In message [EMAIL PROTECTED], Ben Ward [EMAIL PROTECTED] writes I've obviously been following the recent push to have POSH adopted as a buzzword to discourage people from mis-using the term ‘microformat’ in their semantic endeavours. Now the whole point of this is to differentiate semantic HTML from microformats, discourage the further ambiguation of the terms. Is it? I've never seen that said before. If it is intended to be separate form microformats, then having so much about it on the microformat 'wiki' is somewhat misleading. POSH is explicitly supposed to be a super-set of microformats, a generic term invented to help protect the microformats name from being generalised. I think it's quite clear from the cited history that that's not why the term was coined; it certainly not why I added it to the glossary. POSH is not a microformat. Agreed, but microformats *are* POSH. The documented presence on our wiki is acceptable as ‘microformat’ mis-use is a common problem for us, The later claim does not justify the former assertion. but I object to it being presented as part of ‘microformats’ through association with the logo. It's just going to cause more confusion. I also agree with your later point; but I think the same applies to having POSH as part of the microformat 'wiki'. -- 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
Yes, standardization takes a long time, and it's only clear in retrospect that a standard has really stuck. In my opinion, the jury is still out on ISO 8601... However, using 8601 in an abbr title and your house style in the abbr content should work just fine, right? On 5/3/07, Patrick H. Lauke [EMAIL PROTECTED] wrote: Ben Wiley Sittler wrote: in some cases you can get away with not using abbr: Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span with hyphens it's reasonably human-readable. i've been using fully punctuated iso 8601 date notation it everyday life (checks, contracts, even announcements) for years with no problems whatsoever. Just want to raise, at this point, the problem an author might face with regards to an organisation's house styles. For instance, at my university, we have very specific guidelines for how dates and times etc should be written (hint: it ain't ISO-anything). 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] Expanding the abbr pattern
Ben Wiley Sittler wrote: However, using 8601 in an abbr title and your house style in the abbr content should work just fine, right? Yes, of course. Just wanted to add the concept that, as authors, sometimes the content part of pages isn't fully up to us either :) 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 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] abbr debate and Accessify
In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes Note also that this issue was discussed previously, in September 2006: And here, in early March 2007. as part of the tread starting with: http://microformats.org/discuss/mail/microformats-discuss/2007-March/008935.html I'd urge everyone participating now, to read that debate. Likewise. -- 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], Ben Wiley Sittler [EMAIL PROTECTED] writes Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span In addition to Patrick's valid concerns about house style; I would again point out that dtend is exclusive; microformats currently (and wrongly, from a semantic and accessibility PoV) require: Q1 '07: span class=dtstart2007-01-01/span through abbr class=dtend title=2007-04-022007-04-01/abbr I have proposed a solution to this problem: http://microformats.org/wiki/hcalendar-brainstorming#Simplification_of_date-end but it has, so far, been ignored. -- 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
Yes, hence all these tricks to communicate the same data in two different formats... On 5/3/07, Patrick H. Lauke [EMAIL PROTECTED] wrote: Ben Wiley Sittler wrote: However, using 8601 in an abbr title and your house style in the abbr content should work just fine, right? Yes, of course. Just wanted to add the concept that, as authors, sometimes the content part of pages isn't fully up to us either :) 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
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] Expanding the abbr pattern
just by the way, the current microformats behavior is in line with iso 8601's interval semantics from my reading of the specs. On 5/3/07, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Ben Wiley Sittler [EMAIL PROTECTED] writes Q1 '07: span class=dtstart2007-01-01/span through span class=dtend2007-04-01/span In addition to Patrick's valid concerns about house style; I would again point out that dtend is exclusive; microformats currently (and wrongly, from a semantic and accessibility PoV) require: Q1 '07: span class=dtstart2007-01-01/span through abbr class=dtend title=2007-04-022007-04-01/abbr I have proposed a solution to this problem: http://microformats.org/wiki/hcalendar-brainstorming#Simplification_of_date-end but it has, so far, been ignored. -- 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 ___ 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] Expanding the abbr pattern
From: Andy Mabbett [EMAIL PROTECTED] In addition to Patrick's valid concerns about house style; I would again point out that dtend is exclusive; microformats currently (and wrongly, from a semantic and accessibility PoV) require: Q1 '07: span class=dtstart2007-01-01/span through abbr class=dtend title=2007-04-022007-04-01/abbr My understanding here is that the date defaults to a time of midnight, so the end date must be exclusive otherwise a one-day event will last for no time at all. You're right to be concerned though. I suspect that it is too much to ask people marking up their code to understand such fine points. Not to mention the troubles involved with templated or scripted markup. I have proposed a solution to this problem: http://microformats.org/wiki/hcalendar-brainstorming#Simplification_of_date-end but it has, so far, been ignored. You may want to correct the proposition. 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 -- Paul Wilkins ___ 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] Expanding the abbr pattern
Q1 '07: span class=dtstart2007-01-01/span through abbr class=dtend title=2007-04-022007-04-01/abbr I have proposed a solution to this problem: http://microformats.org/wiki/hcalendar-brainstorming#Simplification_of_date-end I do agree that such counter-intuitive things could cause a lot of people to use it incorrectly I think the machine-readable part should match the human-headable part in meaning for the untrained human but I don't think a real world application could rely on it either way unless there is something visible there to state that it is exclusive or inclusive. I have found with other things where start and end dates are used I just can't trust the end date if there is only one day between them because users WILL use them differently. (In the real world I just have to assume that it's an event happening some time during the start date - possibly all-day - possibly longer - more likely shorter) ___ 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
