From msporny at digitalbazaar.com Thu May 1 19:34:45 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Thu May 1 19:35:28 2008 Subject: [uf-discuss] Digg Rolls Out DataPortability Enhancements Message-ID: <481A7DC5.9060408@digitalbazaar.com> Surprised the semantic story du jour hasn't been posted to this list yet. Congrats to the XFN, and hCard folks :) http://blog.digg.com/?p=120 PS: Steve Williams is a good guy - he really does care about this stuff. ------------------------------------------------------------------------ Digg Rolls Out DataPortability Enhancements by Steve Williams at 12pm, May 1st, 2008 in Digg Website Hey all, The Data Sharing Summit in San Francisco was a gas. It was a real pleasure to work with like-minded people from organizations, large and small, all supporting DataPortability. At the Summit I had the chance to show off Digg?s latest DataPortability enhancements. Although the enhancements are not visible on Digg.com, if you use Digg together with other social networks, these enhancements can make the Web more fun and useful. Among the recent enhancements: - We?ve added XFN to your user profile. XFN is an open standard that makes it easier for other social Web sites to recognize your Digg friends. - We?ve improved support for hCard, another open data format for communicating Digg user names, nicknames, and photos, so that your favorite friend-following tools can more easily display your friends? activity. - We?ve added RDFa, making Digg part of the ?semantic web? where Web pages become more sophisticated, beyond simply words and pictures. These efforts support our philosophy that you own your data. Thanks, sbw -------------------------------------------------------------------------- -- manu From ggarciab at itdeusto.com Fri May 2 05:46:49 2008 From: ggarciab at itdeusto.com (=?UTF-8?B?R3VpZG8gR2FyY8OtYSBCZXJuYXJkbw==?=) Date: Fri May 2 05:44:05 2008 Subject: [uf-discuss] microservices In-Reply-To: <47F8C8FB.202@tid.es> References: <47D76E8A.1080503@tid.es> <1005d65f0803120909t58710b22o5e87ddb268b85497@mail.gmail.com> <47F8C8FB.202@tid.es> Message-ID: <481B0D39.8050406@itdeusto.com> Killer idea. More information (still working on it) added here : http://microformats.org/wiki/OpenService_Extensions Regards, guido. Gustavo escribi?: > You can find a prototype implementation of this idea in this thread: > > https://labs.mozilla.com/forum/index.php/topic,654.0.html > > The idea behind this concept is for a website to be able to offer a > service that could be applied to a microformat just publishing an xml, > instead of developing and installing scripts/extensions for the firefox > operator addon (in the same way that a website nowadays offers > opensearch services) > > Any feedback on the interest of this topic would be very appreciated in > order to continue this work in a possible specification and also in the > implementation. > > BR, > G. > > > > Jason Karns wrote: > >> On Wed, Mar 12, 2008 at 1:47 AM, Gustavo wrote: >> >>> > I may be wrong - in which case, it's probably a good idea if we see if >>> > Microsoft's OpenService stuff gets implemented anywhere outside of >>> > Internet Explorer 8. >>> >> Mike Kaply has produced another microformats-related extension for >> Firefox that uses IE8's Activities. >> http://www.kaply.com/weblog/2008/03/07/microsoft-activities-for-firefox-new-version/ >> >> ~Jason >> _______________________________________________ >> 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 > From scott at randomchaos.com Fri May 2 06:27:53 2008 From: scott at randomchaos.com (Scott Reynen) Date: Fri May 2 06:28:02 2008 Subject: [uf-discuss] hatom sample - opinion? In-Reply-To: <4ceabae20804301508h39193111y313ac12f1505dd0e@mail.gmail.com> References: <4ceabae20804301508h39193111y313ac12f1505dd0e@mail.gmail.com> Message-ID: <08976F34-B1B0-4721-9CBB-76510D34E113@randomchaos.com> On Apr 30, 2008, at 4:08 PM, Suzy Loew wrote: > I've been tasked with converting some of our content with > microformats. I've already successfully worked with hCard to my > satisfaction, but now I'm attempting a hAtom entry. I'm still new to > this, but I would like your opinion of the following conversion for > our Guide Note located here: http://www.mahalo.com/2007_Energy_Bill > > >
>
title="2007-12-04T00:00:00-08:00">December 04, > 2007
>
> Associated Press >
>
WASHINGTON, D.C.
>
Congress is set to consider an > Energy Bill called the Energy Independence and > Security Act of 2007. The act's stated purpose is ...
>
> > > I feel it has all the required elements of an hatom, but I'm wondering > if this is properly formatted. Specifically for denoting the title of > the article, which I put in the initial hentry div. Hi Suzy, Here's how I would suggest doing this:

EnergyBill

December 04, 2007
Associated Press
WASHINGTON, D.C.
Congress is set to consider an Energy Bill called the Energy Independence and Security Act of 2007. The act's stated purpose is ...
What I changed: - Moved the title from a title attribute (I don't believe that means what you're trying to say) to an element with class="entry-title" - Changed class="fn n" to class="fn org", because it's an organization - Wrapped class="adr" around the address information for the hCard, and moved that within the hCard If any of this doesn't make sense, please let us know. Peace, Scott From lists at ben-ward.co.uk Sun May 4 08:11:29 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Sun May 4 08:11:40 2008 Subject: [uf-discuss] My inactivity Message-ID: <54559A03-ACD2-4F63-82F4-BA327EB52BFA@ben-ward.co.uk> Hi all, Just a little note to explain that my ?f tasks: hListing, ABBR- pattern, ?This Week? posts are on hold at the moment as I made a rather unexpected trip into hospital this week. No need to worry; after five days I've been released again (my appendix had gone rotten and has been removed). However, I'll be resting for most of this week, so doubt I'll be back onto my non-essential tasks list until next weekend at the earliest. Since we've not had one in a fortnight, if anyone else would like to put together a ?This Week? blog post in my absence, that would be great. Cheers, Ben From mail at tobyinkster.co.uk Sun May 4 14:46:33 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun May 4 14:55:29 2008 Subject: [uf-discuss] Cognition 0.1 alpha8 Message-ID: New version released today. Improvements related to microformats: * Support for xFolk * XFN improvements I've implemented Andy Mabbett's fn == address component suggestion . Also perhaps of interest: * Support for COinS * Support for http://buzzword.org.uk/cognition/ May the fourth be with you! -- Toby A Inkster From davidjanes at blogmatrix.com Sun May 4 16:44:24 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun May 4 16:50:51 2008 Subject: [uf-discuss] My inactivity In-Reply-To: <54559A03-ACD2-4F63-82F4-BA327EB52BFA@ben-ward.co.uk> References: <54559A03-ACD2-4F63-82F4-BA327EB52BFA@ben-ward.co.uk> Message-ID: <21e523c20805041644x7a103f9ar965486b44c874912@mail.gmail.com> Ouch! Get better. Regards, etc... On Sun, May 4, 2008 at 11:11 AM, Ben Ward wrote: > Hi all, > > Just a little note to explain that my ?f tasks: hListing, ABBR-pattern, > 'This Week' posts are on hold at the moment as I made a rather unexpected > trip into hospital this week. No need to worry; after five days I've been > released again (my appendix had gone rotten and has been removed). > However, I'll be resting for most of this week, so doubt I'll be back onto > my non-essential tasks list until next weekend at the earliest. > > Since we've not had one in a fortnight, if anyone else would like to put > together a 'This Week' blog post in my absence, that would be great. > > Cheers, > > Ben > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com From anabelen at gmail.com Sun May 4 21:09:01 2008 From: anabelen at gmail.com (=?ISO-8859-1?Q?Ana_Bel=E9n_Ram=F3n?=) Date: Sun May 4 21:09:03 2008 Subject: [uf-discuss] Geo microformat doubt Message-ID: <7ae0d60f0805042109w2c5f410fu5999ce2376a19e8@mail.gmail.com> Hi! Is this microformat right? Madrid, Spain I've tested it with Firefox plugin "Operator" (https://addons.mozilla.org/es-ES/firefox/addon/4106) and it doesn't detect it. Thanks! -- Ana Bel?n Ram?n From mail at tobyinkster.co.uk Mon May 5 02:28:55 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Mon May 5 02:29:01 2008 Subject: [uf-discuss] Geo microformat doubt Message-ID: Ana Bel?n Ram?n wrote: > Is this microformat right? > Madrid, Spain No ? the title attribute is only used for . There are alternative proposals to use the title attribute for other elements, but most parsers do not support those yet. Usage of the pattern should "work", although it is terrible semantically: Madrid, Spain Because "Madrid, Spain" really isn't an abbreviation for "42.3;-1.96667". If you use value excerpting you might be able to come up with something a bit more acceptable semantically: Madrid, Spain As it happens, Cognition will successfully parse your first, non-standard geo, because as a last ditch attempt at parsing a geo, it will simply look for two semi- colon or comma delimited numbers anywhere in the HTML code (including href attributes, comments, whatever!), but that is an extension of the geo spec ? it's not a standard part of it. -- Toby A Inkster From mail at tobyinkster.co.uk Tue May 6 04:50:17 2008 From: mail at tobyinkster.co.uk (Toby Inkster) Date: Tue May 6 04:50:25 2008 Subject: [uf-discuss] hCard label type Message-ID: <60769.81.2.120.180.1210074617.squirrel@goddamn.co.uk> The vCard spec allows types (e.g. "home", "postal", etc) to be specified for the LABEL property, but the hCard spec doesn't seem to allow this. The hCard examples page on the wiki (RFC 2426 examples) does include a label marked up with type+value, but that page is not considered normative. Is this an oversight in the spec, or was a conscious decision made not to allow types to be specified within labels? If the latter, what was the reasoning? Do any current parsers extend hCard and allow a type to be specified for labels? (I'm considering adding this feature to Cognition.) -- Toby Inkster From gordon at onlinehome.de Tue May 6 13:24:40 2008 From: gordon at onlinehome.de (Gordon Oheim) Date: Tue May 6 13:24:52 2008 Subject: [uf-discuss] rel="nsfw" Message-ID: <4820BE88.7060907@onlinehome.de> Hi all, I was just reading a blog about bad use of Photoshop that linked to "not-safe-for-work" sites every now and then. Made me wonder if we could use a microformat that indicates "non-suitable for work" links and the likes? I could imagine a FF plugin that recognizes page elements tagged as nsfw and changes their display to none or something like that when you are at work. Could also use nsfc (for children). Google could crawl this and protect my unborn kids. What do you think? Useful? http://en.wikipedia.org/wiki/Not_safe_for_work Cheers, Gordon From msporny at digitalbazaar.com Tue May 6 13:50:59 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Tue May 6 13:51:04 2008 Subject: [uf-discuss] rel="nsfw" In-Reply-To: <4820BE88.7060907@onlinehome.de> References: <4820BE88.7060907@onlinehome.de> Message-ID: <4820C4B3.5000608@digitalbazaar.com> Gordon Oheim wrote: > I was just reading a blog about bad use of Photoshop that linked to > "not-safe-for-work" sites every now and then. Made me wonder if we could > use a microformat that indicates "non-suitable for work" links and the > likes? I could imagine a FF plugin that recognizes page elements tagged > as nsfw and changes their display to none or something like that when > you are at work. Could also use nsfc (for children). Google could crawl > this and protect my unborn kids. What do you think? Useful? I certainly think that this is a very useful concept and merits further discussion on microformats-dev. -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Dynamic Spectrum Auctions and Digital Marketplaces http://blog.digitalbazaar.com/2008/04/24/dynamic-spectrum-auctions/ From bbtommorris at gmail.com Tue May 6 13:51:12 2008 From: bbtommorris at gmail.com (Tom Morris) Date: Tue May 6 13:51:15 2008 Subject: [uf-discuss] rel="nsfw" In-Reply-To: <4820BE88.7060907@onlinehome.de> References: <4820BE88.7060907@onlinehome.de> Message-ID: On Tue, May 6, 2008 at 9:24 PM, Gordon Oheim wrote: > Hi all, > > I was just reading a blog about bad use of Photoshop that linked to > "not-safe-for-work" sites every now and then. Made me wonder if we could use > a microformat that indicates "non-suitable for work" links and the likes? I > could imagine a FF plugin that recognizes page elements tagged as nsfw and > changes their display to none or something like that when you are at work. > Could also use nsfc (for children). Google could crawl this and protect my > unborn kids. What do you think? Useful? > > http://en.wikipedia.org/wiki/Not_safe_for_work > This has been discussed before, and there was a consensus against pushing it through the microformats process. Instead, I've started up an 'unofficial' format that uses the W3C's GRDDL profile specification to markup links which are not safe for work. See: http://tommorris.org/profiles/nsfw You shouldn't rely on a class name to protect children, though. It's not designed for that. No amount of semantic markup (or indeed any software mechanism) substitutes for parental responsibility. What NSFW is designed for is more so that you can have links marked in such a way that you might have a common interface element or scripted behaviour added to the page that warns you not to click on an NSFW link (on my site, I'm using a bold, red warning that's placed using generated content, although having recently started doing jQuery, I may change it to a little confirmation box). Yours, -- Tom Morris http://tommorris.org/ From supercanadian at gmail.com Tue May 6 13:51:39 2008 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Tue May 6 13:51:41 2008 Subject: [uf-discuss] rel="nsfw" In-Reply-To: <4820BE88.7060907@onlinehome.de> References: <4820BE88.7060907@onlinehome.de> Message-ID: <84ce626f0805061351i7d9635c8n76a3b6bf2580874e@mail.gmail.com> Hello Gordon, We had a discussion about this quite a while ago. (Nothing actionable really come out of it though, if I remember correctly.) You may want to search the Microformats mailing list for it. (Since it is quite relevant.) One thing though... having rel="nsfw" probably isn't the correct way to "mark" that, since "rel" has a very specific semantic meaning. (But that's just a detail. Maybe "class" would be more appropriate.) -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ Vlog Razor... Vlogging News... http://vlograzor.com/ On Tue, May 6, 2008 at 1:24 PM, Gordon Oheim wrote: > Hi all, > > I was just reading a blog about bad use of Photoshop that linked to "not-safe-for-work" sites every now and then. Made me wonder if we could use a microformat that indicates "non-suitable for work" links and the likes? I could imagine a FF plugin that recognizes page elements tagged as nsfw and changes their display to none or something like that when you are at work. Could also use nsfc (for children). Google could crawl this and protect my unborn kids. What do you think? Useful? > > http://en.wikipedia.org/wiki/Not_safe_for_work > > Cheers, Gordon From scott at randomchaos.com Tue May 6 14:10:22 2008 From: scott at randomchaos.com (Scott Reynen) Date: Tue May 6 14:10:29 2008 Subject: [uf-discuss] rel="nsfw" In-Reply-To: <4820BE88.7060907@onlinehome.de> References: <4820BE88.7060907@onlinehome.de> Message-ID: <8886798E-EE08-46A5-9920-AC00ADA2C71E@randomchaos.com> On May 6, 2008, at 2:24 PM, Gordon Oheim wrote: > Hi all, > > I was just reading a blog about bad use of Photoshop that linked to > "not-safe-for-work" sites every now and then. Made me wonder if we > could use a microformat that indicates "non-suitable for work" links > and the likes? I could imagine a FF plugin that recognizes page > elements tagged as nsfw and changes their display to none or > something like that when you are at work. Could also use nsfc (for > children). Google could crawl this and protect my unborn kids. What > do you think? Useful? Hi Gordon, This would be a new microformat, so I'm moving the discussion to the - new list. http://microformats.org/mailman/listinfo/microformats-new/ The idea of rel-nsfw has come up several times previously. I'd encourage everyone who is interested to review the previous discussion first, so we can avoid repeating it: http://www.mail-archive.com/search?q=nsfw&l=microformats-discuss%40microformats.org Peace, Scott From gordon at onlinehome.de Tue May 6 14:10:58 2008 From: gordon at onlinehome.de (Gordon Oheim) Date: Tue May 6 14:11:12 2008 Subject: [uf-discuss] rel="nsfw" In-Reply-To: References: <4820BE88.7060907@onlinehome.de> Message-ID: <4820C962.7060905@onlinehome.de> Tom Morris schrieb: > On Tue, May 6, 2008 at 9:24 PM, Gordon Oheim wrote: > >> Hi all, >> >> I was just reading a blog about bad use of Photoshop that linked to >> "not-safe-for-work" sites every now and then. Made me wonder if we could use >> a microformat that indicates "non-suitable for work" links and the likes? I >> could imagine a FF plugin that recognizes page elements tagged as nsfw and >> changes their display to none or something like that when you are at work. >> Could also use nsfc (for children). Google could crawl this and protect my >> unborn kids. What do you think? Useful? >> >> http://en.wikipedia.org/wiki/Not_safe_for_work >> >> > > This has been discussed before, and there was a consensus against > pushing it through the microformats process. > > Instead, I've started up an 'unofficial' format that uses the W3C's > GRDDL profile specification to markup links which are not safe for > work. See: > http://tommorris.org/profiles/nsfw > > You shouldn't rely on a class name to protect children, though. It's > not designed for that. No amount of semantic markup (or indeed any > software mechanism) substitutes for parental responsibility. What NSFW > is designed for is more so that you can have links marked in such a > way that you might have a common interface element or scripted > behaviour added to the page that warns you not to click on an NSFW > link (on my site, I'm using a bold, red warning that's placed using > generated content, although having recently started doing jQuery, I > may change it to a little confirmation box). > > Yours, > > I see. I have to read up on this. Thanks for all the replies :) From ryan at theryanking.com Tue May 6 14:41:12 2008 From: ryan at theryanking.com (Ryan King) Date: Tue May 6 14:41:21 2008 Subject: [uf-discuss] rel="nsfw" In-Reply-To: <4820BE88.7060907@onlinehome.de> References: <4820BE88.7060907@onlinehome.de> Message-ID: On May 6, 2008, at 1:24 PM, Gordon Oheim wrote: > Hi all, > > I was just reading a blog about bad use of Photoshop that linked to > "not-safe-for-work" sites every now and then. Made me wonder if we > could use a microformat that indicates "non-suitable for work" links > and the likes? I could imagine a FF plugin that recognizes page > elements tagged as nsfw and changes their display to none or > something like that when you are at work. Could also use nsfc (for > children). Google could crawl this and protect my unborn kids. What > do you think? Useful? As Charles also mentioned, there's been discussion of this on the mailing list before. The short story is this: everyone's work is different (I've actually had work were I *had* to look at at stuff which would be NSFW for most), so it wouldn't be very useful to try an encode a single standard. If you still want to capture the semantic of "I think this is NSFW" you could use xFolk or hReview and tag the link as 'nsfw'. -ryan From julian_bond at voidstar.com Wed May 7 00:56:30 2008 From: julian_bond at voidstar.com (Julian Bond) Date: Wed May 7 00:57:07 2008 Subject: [uf-discuss] meta: The dev list Message-ID: Is the dev list working correctly? A couple of posts have made it into the archive but I don't think they ever turned up as email. Do we actually need two lists? -- Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173 Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433 Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat Get _Sirius_ in 2008 From glenn.jones at madgex.com Wed May 7 03:39:16 2008 From: glenn.jones at madgex.com (Glenn Jones) Date: Wed May 7 03:39:25 2008 Subject: [uf-discuss] FW: New microformats test-suite idea Message-ID: <36A319113CF910438942741C4727ADFF01DE828E@MOBY.Clarence.local> As the dev list does not seem to be working at the moment, reposted here. Just added Operator to testrunner, but you have to use Firefox. > If you go to http://ufxtract.com/testsuite/hcard/1.0/hcard1.htm and press Alt X you can see a working demonstration of the testrunner. Glenn -----Original Message----- From: Glenn Jones Sent: 03 May 2008 12:11 To: 'microformats-dev@microformats.org' Subject: New microformats test-suite idea Hi all I have been working on a concept for a new microformats test-suite. I need a comprehensive test-suite before I can move the development of UfXtract forward. Rather than just build something in isolation I thought it would be nice to find a way to share this work with the community. I have written two POSH patterns "testsuite" and "testfixture". They follow the principles of microformats design: * They are self-describing and created with HTML ,with no hidden metadata * Building a test should be easy even for those who are HTML authors * They are not linked to any one programming language and should be easy to share * They allow for the creation of an in-browser Testrunner For example go to http://ufxtract.com/testsuite/hcard/1.0/ The earliest tests for hcard used vcards to describe the expected output. As the community has moved forward it has designed microformats which are independent of external specification. So this test-suite is designed around the concept of a standardised data structure. In this case, expressed in JSON, but they could be converted into XPaths to test XML or other languages. I have started to build a small console app, which will spider the HTML and create NUnit/C# class files for my build tests. Although this is specific to my own parsers development, it should be easy to do the same for other programming languages and projects. Parsing "testsuite" and "testfixture". I have already setup UfXtract to parse these patterns into JSON/XML. It would not take much for other microformats parser developers to construct profiles for these POSH patterns. Here is an example of the output. http://lab.backnetwork.com/ufXtract/?url=http%3A%2F%2Fufxtract.com%2Ftes tsuite%2Fhcard%2F1.0%2Fhcard1.htm&format=test-fixture&output=json The Testrunner If you go to http://ufxtract.com/testsuite/hcard/1.0/hcard1.htm and press Alt X you can see a working demonstration of the testrunner. I have observed that most parser developers are using comparative testing as their main tool to quickly understand how the complex rules and optimizations are applied. So I have built a JavaScript Testrunner which allows for simple comparative testing between parsers. It uses a number of techniques to standardise both access to the parsers API's and the JSON output. ***Please note that at this stage the JSON standardisation process can cause a test to be marked as failed when it could be judged to have passed***. Most of the current differences in parser output are down to whether a value is stored as single property or an array of properties. At the moment the Testrunner is only working with the testfixure , it would not take much to extend the Testrunner to run a whole test-suite. I would love to add Operator and other parsers to the Testrunner. Proof of concept This is very early proof of concept stuff. What I would like to ask is a number of questions before moving it forward. * Are people interested in the idea of shared test-suites? * What do you think to the approach? * Can you see any big issues with the concepts? * If you already have tests/test-suites, would you be willing to add them to the project? * Would you be interested in contributing to a project like this? Hope you like the idea. PS: the JavaScript needs serious re-factoring; I will simplify it soon. Glenn Jones From adam.craven at fourshapes.com Wed May 7 06:13:43 2008 From: adam.craven at fourshapes.com (Adam Craven - Four Shapes) Date: Wed May 7 07:13:48 2008 Subject: [uf-discuss] FW: New microformats test-suite idea In-Reply-To: <36A319113CF910438942741C4727ADFF01DE828E@MOBY.Clarence.local> References: <36A319113CF910438942741C4727ADFF01DE828E@MOBY.Clarence.local> Message-ID: <982D30B1-4C5D-4082-BA6A-6C5934D49E9F@fourshapes.com> Hi Glenn, It doesn't seem to work (Firefox 2/mac), Adam On 7 May 2008, at 11:39, Glenn Jones wrote: > As the dev list does not seem to be working at the moment, reposted > here. > > Just added Operator to testrunner, but you have to use Firefox. >> If you go to http://ufxtract.com/testsuite/hcard/1.0/hcard1.htm and > press Alt X you can see a working demonstration of the testrunner. > > Glenn > > -----Original Message----- > From: Glenn Jones > Sent: 03 May 2008 12:11 > To: 'microformats-dev@microformats.org' > Subject: New microformats test-suite idea > > Hi all > > I have been working on a concept for a new microformats test-suite. I > need a comprehensive test-suite before I can move the development of > UfXtract forward. Rather than just build something in isolation I > thought it would be nice to find a way to share this work with the > community. > > I have written two POSH patterns "testsuite" and "testfixture". They > follow the principles of microformats design: > * They are self-describing and created with HTML ,with no hidden > metadata > * Building a test should be easy even for those who are HTML > authors > * They are not linked to any one programming language and should > be easy to share > * They allow for the creation of an in-browser Testrunner > > For example go to http://ufxtract.com/testsuite/hcard/1.0/ > > The earliest tests for hcard used vcards to describe the expected > output. As the community has moved forward it has designed > microformats > which are independent of external specification. So this test-suite is > designed around the concept of a standardised data structure. In this > case, expressed in JSON, but they could be converted into XPaths to > test > XML or other languages. > > I have started to build a small console app, which will spider the > HTML > and create NUnit/C# class files for my build tests. Although this is > specific to my own parsers development, it should be easy to do the > same > for other programming languages and projects. > > Parsing "testsuite" and "testfixture". > I have already setup UfXtract to parse these patterns into JSON/XML. > It > would not take much for other microformats parser developers to > construct profiles for these POSH patterns. > Here is an example of the output. > http://lab.backnetwork.com/ufXtract/?url=http%3A%2F%2Fufxtract.com%2Ftes > tsuite%2Fhcard%2F1.0%2Fhcard1.htm&format=test-fixture&output=json > > > The Testrunner > > If you go to http://ufxtract.com/testsuite/hcard/1.0/hcard1.htm and > press Alt X you can see a working demonstration of the testrunner. > > I have observed that most parser developers are using comparative > testing as their main tool to quickly understand how the complex rules > and optimizations are applied. So I have built a JavaScript Testrunner > which allows for simple comparative testing between parsers. > > It uses a number of techniques to standardise both access to the > parsers > API's and the JSON output. ***Please note that at this stage the JSON > standardisation process can cause a test to be marked as failed when > it > could be judged to have passed***. Most of the current differences in > parser output are down to whether a value is stored as single property > or an array of properties. > > At the moment the Testrunner is only working with the testfixure , it > would not take much to extend the Testrunner to run a whole test- > suite. > > I would love to add Operator and other parsers to the Testrunner. > > Proof of concept > This is very early proof of concept stuff. What I would like to ask > is a > number of questions before moving it forward. > > * Are people interested in the idea of shared test-suites? > * What do you think to the approach? > * Can you see any big issues with the concepts? > * If you already have tests/test-suites, would you be willing to > add them to the project? > * Would you be interested in contributing to a project like this? > > Hope you like the idea. > > PS: the JavaScript needs serious re-factoring; I will simplify it > soon. > > > Glenn Jones > > > > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From davidjanes at blogmatrix.com Wed May 7 07:31:12 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Wed May 7 07:31:21 2008 Subject: [uf-discuss] Social Network Explorer -- please try & feedback Message-ID: <21e523c20805070731i53b0f01cx567ee1791b3a3aac@mail.gmail.com> Please come over to Onaswarm and try our Social Network Explorer. Here's the brief blurb Onaswarm is now provides a interface for finding out the social network connectivity of webpages. Connections are discovered using XFN, hCard, FOAF, optionally Google's SGN services and in some instances custom APIs if account information is available to Onaswarm. You can read all about it here [1] or you can just dive in and start trying URLs here [2]. Microformatted HTML results and JSON are available right now, perhaps FOAF in the future if there's demand. Regards, etc... [1] http://blogmatrix.blogmatrix.com/:entry:blogmatrix-2008-05-07-0000/ [2] http://onaswarm.com/admin/sgn-query/ -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com From davidjanes at blogmatrix.com Wed May 7 07:37:16 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Wed May 7 07:37:22 2008 Subject: [uf-discuss] Re: Social Network Explorer -- please try & feedback In-Reply-To: <21e523c20805070731i53b0f01cx567ee1791b3a3aac@mail.gmail.com> References: <21e523c20805070731i53b0f01cx567ee1791b3a3aac@mail.gmail.com> Message-ID: <21e523c20805070737s9289606sc36d21ff8e42648@mail.gmail.com> Oops ... a little bug if you're not logged in ... one second... On Wed, May 7, 2008 at 10:31 AM, David Janes wrote: > Please come over to Onaswarm and try our Social Network Explorer. > Here's the brief blurb > > Onaswarm is now provides a interface for finding out the social > network connectivity of webpages. Connections are discovered using > XFN, hCard, FOAF, optionally Google's SGN services and in some > instances custom APIs if account information is available to Onaswarm. > > You can read all about it here [1] or you can just dive in and start > trying URLs here [2]. Microformatted HTML results and JSON are > available right now, perhaps FOAF in the future if there's demand. > > Regards, etc... > > [1] http://blogmatrix.blogmatrix.com/:entry:blogmatrix-2008-05-07-0000/ > [2] http://onaswarm.com/admin/sgn-query/ > > -- > David Janes > Founder, BlogMatrix > http://www.blogmatrix.com > http://www.onaswarm.com > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com From davidjanes at blogmatrix.com Wed May 7 07:40:05 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Wed May 7 07:40:17 2008 Subject: [uf-discuss] Re: Social Network Explorer -- please try & feedback In-Reply-To: <21e523c20805070737s9289606sc36d21ff8e42648@mail.gmail.com> References: <21e523c20805070731i53b0f01cx567ee1791b3a3aac@mail.gmail.com> <21e523c20805070737s9289606sc36d21ff8e42648@mail.gmail.com> Message-ID: <21e523c20805070740g8a275f7j6859949a3b18e787@mail.gmail.com> That's better ... very embarrassing :-( Now please try it! Regards, etc... David On Wed, May 7, 2008 at 10:37 AM, David Janes wrote: > Oops ... a little bug if you're not logged in ... one second... > > > > On Wed, May 7, 2008 at 10:31 AM, David Janes wrote: > > Please come over to Onaswarm and try our Social Network Explorer. > > Here's the brief blurb > > > > Onaswarm is now provides a interface for finding out the social > > network connectivity of webpages. Connections are discovered using > > XFN, hCard, FOAF, optionally Google's SGN services and in some > > instances custom APIs if account information is available to Onaswarm. > > > > You can read all about it here [1] or you can just dive in and start > > trying URLs here [2]. Microformatted HTML results and JSON are > > available right now, perhaps FOAF in the future if there's demand. > > > > Regards, etc... > > > > [1] http://blogmatrix.blogmatrix.com/:entry:blogmatrix-2008-05-07-0000/ > > [2] http://onaswarm.com/admin/sgn-query/ > > > > -- > > David Janes > > Founder, BlogMatrix > > http://www.blogmatrix.com > > http://www.onaswarm.com > > > > > > -- > David Janes > Founder, BlogMatrix > http://www.blogmatrix.com > http://www.onaswarm.com > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com From florian.beer at gmail.com Wed May 7 07:49:41 2008 From: florian.beer at gmail.com (Florian Beer) Date: Wed May 7 07:49:51 2008 Subject: [uf-discuss] Microformats book in german Message-ID: <78A3C073-0ADE-45AA-A199-8416D62303A1@gmail.com> hi everyone, just wanted to let you know that my thesis about Microformats was published as a book and is now available via Amazon. http://www.amazon.de/Microformats-jedermann-semantische-Entwicklung-vorantreiben/dp/3836492210/ref=pd_rhf_p_t_1 as far as I see it, this is the first german publication about Microformats :) cheers, Florian Beer From glenn.jones at madgex.com Wed May 7 09:20:37 2008 From: glenn.jones at madgex.com (Glenn Jones) Date: Wed May 7 08:20:45 2008 Subject: [uf-discuss] FW: New microformats test-suite idea In-Reply-To: <982D30B1-4C5D-4082-BA6A-6C5934D49E9F@fourshapes.com> Message-ID: Adam I am sorry on a Mac its "ctrl alt x". http://ufxtract.com/testsuite/hcard/1.0/hcard1.htm Glenn On 07/05/2008 14:13, "Adam Craven - Four Shapes" wrote: > Hi Glenn, > > It doesn't seem to work (Firefox 2/mac), > > Adam > > On 7 May 2008, at 11:39, Glenn Jones wrote: > >> As the dev list does not seem to be working at the moment, reposted >> here. >> >> Just added Operator to testrunner, but you have to use Firefox. >>> If you go to http://ufxtract.com/testsuite/hcard/1.0/hcard1.htm and >> press Alt X you can see a working demonstration of the testrunner. >> >> Glenn >> >> -----Original Message----- >> From: Glenn Jones >> Sent: 03 May 2008 12:11 >> To: 'microformats-dev@microformats.org' >> Subject: New microformats test-suite idea >> >> Hi all >> >> I have been working on a concept for a new microformats test-suite. I >> need a comprehensive test-suite before I can move the development of >> UfXtract forward. Rather than just build something in isolation I >> thought it would be nice to find a way to share this work with the >> community. >> >> I have written two POSH patterns "testsuite" and "testfixture". They >> follow the principles of microformats design: >> * They are self-describing and created with HTML ,with no hidden >> metadata >> * Building a test should be easy even for those who are HTML >> authors >> * They are not linked to any one programming language and should >> be easy to share >> * They allow for the creation of an in-browser Testrunner >> >> For example go to http://ufxtract.com/testsuite/hcard/1.0/ >> >> The earliest tests for hcard used vcards to describe the expected >> output. As the community has moved forward it has designed >> microformats >> which are independent of external specification. So this test-suite is >> designed around the concept of a standardised data structure. In this >> case, expressed in JSON, but they could be converted into XPaths to >> test >> XML or other languages. >> >> I have started to build a small console app, which will spider the >> HTML >> and create NUnit/C# class files for my build tests. Although this is >> specific to my own parsers development, it should be easy to do the >> same >> for other programming languages and projects. >> >> Parsing "testsuite" and "testfixture". >> I have already setup UfXtract to parse these patterns into JSON/XML. >> It >> would not take much for other microformats parser developers to >> construct profiles for these POSH patterns. >> Here is an example of the output. >> http://lab.backnetwork.com/ufXtract/?url=http%3A%2F%2Fufxtract.com%2Ftes >> tsuite%2Fhcard%2F1.0%2Fhcard1.htm&format=test-fixture&output=json >> >> >> The Testrunner >> >> If you go to http://ufxtract.com/testsuite/hcard/1.0/hcard1.htm and >> press Alt X you can see a working demonstration of the testrunner. >> >> I have observed that most parser developers are using comparative >> testing as their main tool to quickly understand how the complex rules >> and optimizations are applied. So I have built a JavaScript Testrunner >> which allows for simple comparative testing between parsers. >> >> It uses a number of techniques to standardise both access to the >> parsers >> API's and the JSON output. ***Please note that at this stage the JSON >> standardisation process can cause a test to be marked as failed when >> it >> could be judged to have passed***. Most of the current differences in >> parser output are down to whether a value is stored as single property >> or an array of properties. >> >> At the moment the Testrunner is only working with the testfixure , it >> would not take much to extend the Testrunner to run a whole test- >> suite. >> >> I would love to add Operator and other parsers to the Testrunner. >> >> Proof of concept >> This is very early proof of concept stuff. What I would like to ask >> is a >> number of questions before moving it forward. >> >> * Are people interested in the idea of shared test-suites? >> * What do you think to the approach? >> * Can you see any big issues with the concepts? >> * If you already have tests/test-suites, would you be willing to >> add them to the project? >> * Would you be interested in contributing to a project like this? >> >> Hope you like the idea. >> >> PS: the JavaScript needs serious re-factoring; I will simplify it >> soon. >> >> >> Glenn Jones >> >> >> >> >> >> >> >> _______________________________________________ >> 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 From spike at tenbus.co.uk Wed May 7 12:03:20 2008 From: spike at tenbus.co.uk (Webadmin - Tenbus) Date: Wed May 7 12:03:26 2008 Subject: [uf-discuss] Microformats book in german In-Reply-To: <78A3C073-0ADE-45AA-A199-8416D62303A1@gmail.com> References: <78A3C073-0ADE-45AA-A199-8416D62303A1@gmail.com> Message-ID: <4821FCF8.5030307@tenbus.co.uk> Congratulations Florian! Spike Florian Beer wrote: > hi everyone, > > just wanted to let you know that my thesis about Microformats was > published as a book and is now available via Amazon. > http://www.amazon.de/Microformats-jedermann-semantische-Entwicklung-vorantreiben/dp/3836492210/ref=pd_rhf_p_t_1 > > > as far as I see it, this is the first german publication about > Microformats :) > > cheers, > Florian Beer From msporny at digitalbazaar.com Wed May 7 12:16:20 2008 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed May 7 12:16:24 2008 Subject: [uf-discuss] My inactivity In-Reply-To: <54559A03-ACD2-4F63-82F4-BA327EB52BFA@ben-ward.co.uk> References: <54559A03-ACD2-4F63-82F4-BA327EB52BFA@ben-ward.co.uk> Message-ID: <48220004.8060804@digitalbazaar.com> Ben Ward wrote: > Just a little note to explain that my ?f tasks: hListing, ABBR-pattern, > ?This Week? posts are on hold at the moment as I made a rather > unexpected trip into hospital this week. No need to worry; after five > days I've been released again (my appendix had gone rotten and has been > removed). > However, I'll be resting for most of this week Sorry to hear about your trip to the hospital. Hope all is going better and that you have a quick and speedy recovery. I'd be happy to put together a "This Week" blog post, who should I send it to? You, Tantek, or somebody else? -- manu -- Manu Sporny President/CEO - Digital Bazaar, Inc. blog: Dynamic Spectrum Auctions and Digital Marketplaces http://blog.digitalbazaar.com/2008/04/24/dynamic-spectrum-auctions/ From wilbanks at u.washington.edu Wed May 7 16:35:10 2008 From: wilbanks at u.washington.edu (Dylan Wilbanks) Date: Wed May 7 16:35:21 2008 Subject: [uf-discuss] contacts within hCal Message-ID: <004e01c8b09a$fda091b0$6a155f80@sphcm.washington.edu> Hi -- I'm new to the list, so if the following issue has been already been addressed, my apologies. I'm converting our homegrown events calendar display UI from its 2001-era HTML to microformatted XHTML. The problem I've run into is with event contact info. I'm not sure of what the contact on an event is -- a specific person, an organization, or even just a job title. (The form in our system has just three fields for a contact -- contact name, contact phone, contact email.) Because I don't know what kind of contact an event is, I'm not sure I can construct an hCard around the data. Must I construct contact as a vCard? That section of the wiki is a little vague, and from reading the iCal spec it doesn't seem like it's looking for a vCard style format of data. If I don't have to, has anyone else addressed this issue of not knowing whether the name is of a person, a job title, or an organization? Thanks. dw Dylan Wilbanks Web Producer School of Public Health and Community Medicine University of Washington F-350 Health Sciences Bldg 1959 NE Pacific St Box 357230 Seattle, WA 98195-7230 V: 206.221.6395 F: 206.543.3813 E: wilbanks@u.washington.edu From scott at randomchaos.com Wed May 7 17:09:30 2008 From: scott at randomchaos.com (Scott Reynen) Date: Wed May 7 17:09:34 2008 Subject: [uf-discuss] contacts within hCal In-Reply-To: <004e01c8b09a$fda091b0$6a155f80@sphcm.washington.edu> References: <004e01c8b09a$fda091b0$6a155f80@sphcm.washington.edu> Message-ID: <0CC3F6C8-B6C2-49E5-8C82-50CAC7F908D7@randomchaos.com> On May 7, 2008, at 5:35 PM, Dylan Wilbanks wrote: > Hi -- > > I'm new to the list, so if the following issue has been already been > addressed, my apologies. > > I'm converting our homegrown events calendar display UI from its > 2001-era HTML to microformatted XHTML. The problem I've run into is > with event contact info. I'm not sure of what the contact on an > event is -- a specific person, an organization, or even just a job > title. (The form in our system has just three fields for a contact > -- contact name, contact phone, contact email.) Because I don't know > what kind of contact an event is, I'm not sure I can construct an > hCard around the data. > > Must I construct contact as a vCard? No. "ATTENDEE, CONTACT, and ORGANIZER in iCalendar *may* be represented by an hCard in hCalendar" http://microformats.org/wiki/hcalendar#More_Semantic_Equivalents If you know the phone and email, you can mark those up without wrapping them in a vCard and still add some practical semantics, e.g. software can recognize phone numbers with class="tel" and use them in VOIP software without knowing who the number is calling. Peace, Scott From mark at markwunsch.com Fri May 9 10:06:18 2008 From: mark at markwunsch.com (Mark Wunsch) Date: Fri May 9 10:07:04 2008 Subject: [uf-discuss] hAtom and Optimus Message-ID: <1b7e4d860805091006i156712afof23dcada91f2e77f@mail.gmail.com> First time poster here. I am anxious to contribute what I can. Recently created my personal blog marked up in hAtom. When I tried to validate in Optimus: http://microformatique.com/optimus/?format=validate&uri=http%3A%2F%2Fmarkwunsch.com I see an error that required property author not specified, but I thought I marked it up correctly as hCard:

Mark Wunsch

This is my first implementation of hAtom, wanted to make sure I got it correct. Is Optimus a good tool for general validation of microformats? Thanks, Mark From mail at tobyinkster.co.uk Fri May 9 13:25:36 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri May 9 13:25:43 2008 Subject: [uf-discuss] hAtom and Optimus Message-ID: <04D31133-BF65-4C53-AA45-B2969CA21813@tobyinkster.co.uk> > I see an error that required property author not specified An author is "required" for *each* hentry, but the spec allows this "required" element to be missing and provides instructions for parsers to determine the author in these cases. -- Toby A Inkster From info at weborganics.co.uk Sun May 11 08:30:00 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sun May 11 08:36:38 2008 Subject: [uf-discuss] marking up a rel-enclosure length Message-ID: <1210519800.2709.11.camel@localhost.localdomain> Hello all, I have been wandering is there any way to mark up the file "length" or size of a rel="enclosure"[1], If not, Is there a best practice? or has anyone any thoughts on how to do this? [1] http://microformats.org/wiki/rel-enclosure Many thanks in advance Martin McEvoy From davidjanes at blogmatrix.com Sun May 11 08:45:36 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Sun May 11 08:45:38 2008 Subject: [uf-discuss] marking up a rel-enclosure length In-Reply-To: <1210519800.2709.11.camel@localhost.localdomain> References: <1210519800.2709.11.camel@localhost.localdomain> Message-ID: <21e523c20805110845i5b82ce1bqd27f1ff45b4716a7@mail.gmail.com> I think some work was done a while back here [1] but it didn't really go anywhere. Obliquely, [2] may also by of interest. Regards, etc... David [1] http://microformats.org/wiki/media-metadata-examples [2] http://oembed.com/ On Sun, May 11, 2008 at 11:30 AM, Martin McEvoy wrote: > Hello all, > > I have been wandering is there any way to mark up the file "length" or > size of a rel="enclosure"[1], If not, Is there a best practice? or has > anyone any thoughts on how to do this? > > [1] http://microformats.org/wiki/rel-enclosure > > Many thanks in advance > > > Martin McEvoy > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com From info at weborganics.co.uk Mon May 12 14:08:18 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Mon May 12 14:15:15 2008 Subject: [uf-discuss] marking up a rel-enclosure length In-Reply-To: <21e523c20805110845i5b82ce1bqd27f1ff45b4716a7@mail.gmail.com> References: <1210519800.2709.11.camel@localhost.localdomain> <21e523c20805110845i5b82ce1bqd27f1ff45b4716a7@mail.gmail.com> Message-ID: <1210626498.7734.2.camel@localhost.localdomain> On Sun, 2008-05-11 at 11:45 -0400, David Janes wrote: > I think some work was done a while back here [1] but it didn't really > go anywhere. Obliquely, [2] may also by of interest. > > Regards, etc... > David Thanks David for your pointers, I like the oembed url interesting stuff not exactly what I was thinking but Interesting for a future project. Martin > > [1] http://microformats.org/wiki/media-metadata-examples > [2] http://oembed.com/ > > On Sun, May 11, 2008 at 11:30 AM, Martin McEvoy wrote: > > Hello all, > > > > I have been wandering is there any way to mark up the file "length" or > > size of a rel="enclosure"[1], If not, Is there a best practice? or has > > anyone any thoughts on how to do this? > > > > [1] http://microformats.org/wiki/rel-enclosure > > > > Many thanks in advance > > > > > > Martin McEvoy > > > > _______________________________________________ > > microformats-discuss mailing list > > microformats-discuss@microformats.org > > http://microformats.org/mailman/listinfo/microformats-discuss > > > > > From supercanadian at gmail.com Mon May 12 14:21:42 2008 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Mon May 12 14:21:45 2008 Subject: [uf-discuss] marking up a rel-enclosure length In-Reply-To: <1210519800.2709.11.camel@localhost.localdomain> References: <1210519800.2709.11.camel@localhost.localdomain> Message-ID: <84ce626f0805121421q33aa95few5225b7af12b0d87c@mail.gmail.com> Hello Martin, On Sun, May 11, 2008 at 8:30 AM, Martin McEvoy wrote: > Hello all, > > I have been wandering is there any way to mark up the file "length" or > size of a rel="enclosure"[1], If not, Is there a best practice? or has > anyone any thoughts on how to do this? > > [1] http://microformats.org/wiki/rel-enclosure Couldn't you just do an HTTP "HEAD" request on the URL (for the rel-enclosure) to get the size of the file (if you really wanted to know)? -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ From scarle at praizedmedia.com Mon May 12 14:41:30 2008 From: scarle at praizedmedia.com (Sylvain Carle) Date: Mon May 12 14:41:40 2008 Subject: [uf-discuss] marking up a rel-enclosure length In-Reply-To: <84ce626f0805121421q33aa95few5225b7af12b0d87c@mail.gmail.com> References: <1210519800.2709.11.camel@localhost.localdomain> <84ce626f0805121421q33aa95few5225b7af12b0d87c@mail.gmail.com> Message-ID: <4828B98A.4040007@praizedmedia.com> Charles Iliya Krempeaux wrote: > Hello Martin, > > On Sun, May 11, 2008 at 8:30 AM, Martin McEvoy wrote: >> Hello all, >> >> I have been wandering is there any way to mark up the file "length" or >> size of a rel="enclosure"[1], If not, Is there a best practice? or has >> anyone any thoughts on how to do this? >> >> [1] http://microformats.org/wiki/rel-enclosure > > Couldn't you just do an HTTP "HEAD" request on the URL (for the > rel-enclosure) to get the size of the file (if you really wanted to > know)? Maybe, but what if you wanted to "declare" it in your markup? I know the format is a bit ugly, but MediaRSS [1] has interesting prior art for that, with filesize, bitrate (etc) attributes that could be used on an xhtml element (instead of the xml representation done in MediaRSS). 1. http://search.yahoo.com/mrss -- Sylvain Carle From info at weborganics.co.uk Mon May 12 14:50:09 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Mon May 12 14:56:59 2008 Subject: [uf-discuss] marking up a rel-enclosure length In-Reply-To: <84ce626f0805121421q33aa95few5225b7af12b0d87c@mail.gmail.com> References: <1210519800.2709.11.camel@localhost.localdomain> <84ce626f0805121421q33aa95few5225b7af12b0d87c@mail.gmail.com> Message-ID: <1210629009.7814.6.camel@localhost.localdomain> Hello Charles On Mon, 2008-05-12 at 14:21 -0700, Charles Iliya Krempeaux wrote: > Hello Martin, > > On Sun, May 11, 2008 at 8:30 AM, Martin McEvoy wrote: > > Hello all, > > > > I have been wandering is there any way to mark up the file "length" or > > size of a rel="enclosure"[1], If not, Is there a best practice? or has > > anyone any thoughts on how to do this? > > > > [1] http://microformats.org/wiki/rel-enclosure > > Couldn't you just do an HTTP "HEAD" request on the URL (for the > rel-enclosure) to get the size of the file (if you really wanted to > know)? Normally this would be ok, but I am trying to do this by just using xhtml, xslt and GRDDL so it would require that class="length" (as in the length of the stream in bytes) or something like be marked up explicitly in the source xhtml document. Thanks. Martin > From info at weborganics.co.uk Mon May 12 15:14:45 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Mon May 12 15:21:37 2008 Subject: [uf-discuss] marking up a rel-enclosure length In-Reply-To: <4828B98A.4040007@praizedmedia.com> References: <1210519800.2709.11.camel@localhost.localdomain> <84ce626f0805121421q33aa95few5225b7af12b0d87c@mail.gmail.com> <4828B98A.4040007@praizedmedia.com> Message-ID: <1210630485.7814.26.camel@localhost.localdomain> On Mon, 2008-05-12 at 17:41 -0400, Sylvain Carle wrote: > Charles Iliya Krempeaux wrote: > > Hello Martin, > > > > On Sun, May 11, 2008 at 8:30 AM, Martin McEvoy wrote: > >> Hello all, > >> > >> I have been wandering is there any way to mark up the file "length" or > >> size of a rel="enclosure"[1], If not, Is there a best practice? or has > >> anyone any thoughts on how to do this? > >> > >> [1] http://microformats.org/wiki/rel-enclosure > > > > Couldn't you just do an HTTP "HEAD" request on the URL (for the > > rel-enclosure) to get the size of the file (if you really wanted to > > know)? > > Maybe, but what if you wanted to "declare" it in your markup? I do :) > > I know the format is a bit ugly, but MediaRSS [1] has interesting prior > art for that, with filesize, bitrate (etc) attributes that could be used > on an xhtml element (instead of the xml representation done in MediaRSS). > > 1. http://search.yahoo.com/mrss Yes I looked into Media RSS some time ago, relevant to the discussion on file format's or hFileFormat [1] [1] http://microformats.org/wiki/file-format-examples what I am thinking is maybe something much more simple like 3.6M Hmm.. looks like this discussion needs to be re-raised on Microformats New. Thanks anyway. Martin > > -- > Sylvain Carle > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From Charles.Belov at sfmta.com Tue May 13 16:26:26 2008 From: Charles.Belov at sfmta.com (Belov, Charles) Date: Tue May 13 16:26:29 2008 Subject: [uf-discuss] One more shot at accessible hCalendar Message-ID: I'll try to keep this to new comments concerning the use of the ISO date in the hCalendar microformat. Please excuse me if I'm repeating something. At the moment, these are the things that would prevent me from implementing hCalendar on our website. ----- Site visitor accessibility: Even if a particular screen reader can disable abbreviations or titles so as not to hear ISO-format dates read, that means that screen reader would also not read human-friendly titles that have nothing to do with microformats. Even if your site does not use human-friendly title tags, there are sites "in the wild" that do, and having the screen readers suppress these would be a loss. Possible alternatives: If the webmaster does use an empty span with a title tag to contain the ISO date, the webmaster could add a style="display: none" attribute to it to ensure that screen readers did not read it. ----- Site creator accessibility: 1. We have non-technical people creating and editing static HTML web pages using Adobe Contribute. There is no easy way in Contribute to insert a title tag. 2. Even if I were to be able to create a kludge to let the people enter a title tag, they would still have to create human-unfriendly ISO dates in those title tags. 3. These non-technical people would have to deal with a human-unfriendly spec that end dates without times end at the beginning, not the end, of the day in the ISO date. Possible alternatives: These tags could optionally be used in place of the class="dtstart" and class="dtend": class="dtstartyyyy" for year class="dtstartmmm" for month as Jan, Feb, etc., or 01, 02, etc., or 1, 2, etc. class="dtstartdd" for day as 01, 02, etc. or 1, 2, etc. class="dtstartdow" for day as Mon, Tue, etc. or Monday, Tuesday, etc. class="dtstarttime" for time as 10:12am, 10:12a, 10:12 am, 10:12 a, 1012, 10:12:01am, etc. Remember, these are humans entering these dates and they may not be consistent (as long as they don't misspell the month or day, the computers ought to be the ones who are forgiving). Replace start with end for human-unfriendly end date (ends at start of day 12:00:01am if no time given) or endfull for human-friendly end date (ends at end of full day 11:59:59pm if no time given) or startend or startendful for something that is used for start and end both. Example: Tuesday, May 13, 2008, 4:08pm would be human-friendly encoded for a start date as Tuesday, May 13, 2008, 4:08pm Tuesday, May 13, through Friday, May 16, 2008 would be human-friendly encoded for a start and end date as Tuesday, May 13, 2008, through Friday, May 16, 2008 While I as webmaster would have to provide pre-set fill-ins for the non-technical content editor to drop a date into the pre-formatted span tags, it would protect the non-technical content editor from having to deal with the code. For example, in Contribute, I would code a template containing a table with repeating regions wrapped by the span tags. The non-technical content editor would drop a day-of-week, month, date, year, and time into the spaces provided. Remember that any page these occur on would presumably have a language specification such as "en-us" so computers would be able to deal with standard month and day of week names and abbreviations. ----- Hope this helps, Charles Belov SFMTA Webmaster http://www.sfmta.com/webmaster From bob_ngu at yahoo.com Tue May 13 21:00:04 2008 From: bob_ngu at yahoo.com (Bob) Date: Tue May 13 21:26:56 2008 Subject: [uf-discuss] XFN limitation Message-ID: <818183.56663.qm@web82705.mail.mud.yahoo.com> Hi, I have been working on a consuming app for XFN. I want to display human readable URL information for rel=me, rel="met ...", etc. While it seems like most of the XFN producers include human readable information along with rel URLs, unfortunately it isn't part of XFN and hence an XFN parser won't read it. Take for example, http://kevinmarks.com/. Kevin's rel=me URLs, note: some HTML characters like "<", ">"changed to "[", "]" to prevent HTML stripping in Yahoo mail [a href="http://epeus.blogspot.com/"; rel="me"]Blog[/a] [a href="http://www.flickr.com/photos/kevinmarks/"; rel="me"]Photos[/a] [a href="http://www.twitter.com/kevinmarks/"; rel="me"]Twitter[/a] Kevin's rel="met..." URLs [a class="fn url" href="http://factoryjoe.com"; rel="met colleague friend"]Chris Messina[/a] [a class="fn url" href="http://tantek.com"; rel="met colleague friend"]Tantek ?elik[/a] As a consuming app, I prefer not to display the entire URL because it can get long and unruly. However, I would like to get at the human readable values usually available next to "rel=me" and "rel="met ..." URLs, but there isn't an XFN standard for that. I feel that this is an XFN limitation, is it possible to to extend XFN to allow this information to be available? Like maybe add a rel attribute to a span or div element around the human readable text? I don't expect this to be a problem for FOAF though, however I am seeing examples in the wild that uses both XFN and FOAF, so my app should happily consume both but I am having some trouble with making the information consistent across both standards. Any help or insight is appreciated. Bob Ngu My Startup JiggyMe My Blog on Data Portability From info at weborganics.co.uk Wed May 14 03:35:46 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Wed May 14 03:36:05 2008 Subject: [uf-discuss] [ANN:] Hypertext Friend of a Friend (hFoaF) Message-ID: <1210761346.5281.6.camel@localhost.localdomain> Hello all, I am Pleased to announce Hypertext Friend of a Friend or hFoaF. hFoaF came to be because I noticed a patten of people trying to consolidate their identity's, express interests, and friends in their user profiles and homepages using hcard[1] and a url with the XFN[2] rel="me", marking up their friends and colleagues with simple anchor text links and other XFN values, and expressing their interests by using either xFolk[3] or hAtom[4]. How common is this pattern, well to be honest not many every user profile at Ma.Gnolia[5] is marked up in this way, and Tantek's homepage[6] is also marked up in this way. others are, Lasfm, twitter, and nsyght Profiles but the markup (for me) is so difficult to tidy and parse that with the exception of nsyght it is difficult extract anything useful :( examples: Using the transformer available at, http://weborganics.co.uk/hFoaf/?id= source: http://www.tantek.com/ output: http://tinyurl.com/3g4dv5 source: http://ma.gnolia.com/people/aarongustafson output: http://tinyurl.com/3eqzya Using GRDDL available at, http://www.w3.org/2007/08/grddl/?docAddr= profile: http://weborganics.co.uk/Profiles/hFoaF.xsl source: http://weborganics.co.uk/ output: http://tinyurl.com/3ucx9z If you are interested in the source code or would like to know a little more please visit http://weborganics.co.uk/hFoaf/ As usual comments constructive criticism welcome. Thanks. [1] http://microformats.org/wiki/hcard [2] http://microformats.org/wiki/xfn [3] http://microformats.org/wiki/xfolk [4] http://microformats.org/wiki/hatom [5] http://ma.gnolia.com/ [6] http://www.tantek.com/ Martin McEvoy http://weborganics.co.uk/ From andr3.pt at gmail.com Wed May 14 04:10:05 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Wed May 14 04:10:13 2008 Subject: [uf-discuss] [ANN:] Hypertext Friend of a Friend (hFoaF) In-Reply-To: <1210761346.5281.6.camel@localhost.localdomain> References: <1210761346.5281.6.camel@localhost.localdomain> Message-ID: I just tried on my own blog, without any changes to the current markup: http://xml.mfd-consult.dk/foaf/explorer/?foaf=http%3A%2F%2Fweborganics.co.uk%2FhFoaF%2F%3Fid%3Dhttp%3A%2F%2Fandr3.net%2Fblog It worked pretty well!! (I'm using xFolk to mark up the blog entries, but I'm considering changing to hAtom.) Just trying to contribute with an "example in the wild". I like the idea... basically you're just suggesting a way of putting hcard+xfn+(hatom/xfolk) together in a simple way. Having a specific format to aim for (and to call it) will surely help convergence in implementations. Looking forward to see what other fine folks have to say. Great work Martin. -- Andr? Lu?s On Wed, May 14, 2008 at 11:35 AM, Martin McEvoy wrote: > Hello all, > > I am Pleased to announce Hypertext Friend of a Friend or hFoaF. > > hFoaF came to be because I noticed a patten of people trying to > consolidate their identity's, express interests, and friends in their > user profiles and homepages using hcard[1] and a url with the XFN[2] > rel="me", marking up their friends and colleagues with simple anchor > text links and other XFN values, and expressing their interests by using > either xFolk[3] or hAtom[4]. > How common is this pattern, well to be honest not many every user > profile at Ma.Gnolia[5] is marked up in this way, and Tantek's > homepage[6] is also marked up in this way. others are, Lasfm, twitter, > and nsyght Profiles but the markup (for me) is so difficult to tidy and > parse that with the exception of nsyght it is difficult extract anything > useful :( > > examples: > > Using the transformer available at, http://weborganics.co.uk/hFoaf/?id= > > source: http://www.tantek.com/ > output: http://tinyurl.com/3g4dv5 > > source: http://ma.gnolia.com/people/aarongustafson > output: http://tinyurl.com/3eqzya > > Using GRDDL available at, http://www.w3.org/2007/08/grddl/?docAddr= > > profile: http://weborganics.co.uk/Profiles/hFoaF.xsl > source: http://weborganics.co.uk/ > output: http://tinyurl.com/3ucx9z > > If you are interested in the source code or would like to know a little > more please visit http://weborganics.co.uk/hFoaf/ > > As usual comments constructive criticism welcome. > Thanks. > > [1] http://microformats.org/wiki/hcard > [2] http://microformats.org/wiki/xfn > [3] http://microformats.org/wiki/xfolk > [4] http://microformats.org/wiki/hatom > [5] http://ma.gnolia.com/ > [6] http://www.tantek.com/ > > Martin McEvoy > http://weborganics.co.uk/ > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From info at weborganics.co.uk Wed May 14 04:35:56 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Wed May 14 04:36:14 2008 Subject: [uf-discuss] [ANN:] Hypertext Friend of a Friend (hFoaF) In-Reply-To: References: <1210761346.5281.6.camel@localhost.localdomain> Message-ID: <1210764956.5395.26.camel@localhost.localdomain> Hello Andr? On Wed, 2008-05-14 at 12:10 +0100, Andr? Lu?s wrote: > > I just tried on my own blog, without any changes to the current > markup: > > http://xml.mfd-consult.dk/foaf/explorer/?foaf=http%3A%2F% > 2Fweborganics.co.uk%2FhFoaF%2F%3Fid%3Dhttp%3A%2F%2Fandr3.net%2Fblog > > It worked pretty well!! Glad It did ;) Please can I add you to the example output section on the hFoaF page. Thanks Martin McEvoy From info at weborganics.co.uk Wed May 14 04:38:51 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Wed May 14 04:39:08 2008 Subject: [uf-discuss] [ANN:] Hypertext Friend of a Friend (hFoaF) In-Reply-To: References: <1210761346.5281.6.camel@localhost.localdomain> Message-ID: <1210765131.5395.30.camel@localhost.localdomain> On Wed, 2008-05-14 at 12:10 +0100, Andr? Lu?s wrote: > I like the idea... basically you're just suggesting a way of putting > hcard+xfn+(hatom/xfolk) together in a simple way. Having a specific > format to aim for (and to call it) will surely help convergence in > implementations. Yes I guess that's the Idea. Martin McEvoy From mail at tobyinkster.co.uk Wed May 14 06:38:56 2008 From: mail at tobyinkster.co.uk (Toby Inkster) Date: Wed May 14 06:40:18 2008 Subject: [uf-discuss] Re: One more shot at accessible hCalendar Message-ID: <62483.81.2.120.180.1210772337.squirrel@goddamn.co.uk> Charles Belov wrote: > Remember that any page these occur on would presumably have a language > specification such as "en-us" so computers would be able to deal with > standard month and day of week names and abbreviations. I'm sorry, but this sounds like a really bad idea. Parsers would need to maintain translation tables for day and month names, plus abbreviations for them, plus some sort of heuristic for figuring out the language of the page. (In practice, many authors leave out lang/xml:lang attributes, and Content-Language headers.) Andy Mabbett's proposed "data:" prefix already solves the abbr design pattern accessibility issue and can be implemented in just a few lines of code. All we need to do is build support for it into parsers. (Cognition has supported it since alpha2.1.) Closest thing to a "specification" for the prefix: http://microformats.org/discuss/mail/microformats-discuss/2008-February/011583.html -- Toby Inkster From andr3.pt at gmail.com Wed May 14 12:57:52 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Wed May 14 12:57:59 2008 Subject: [uf-discuss] [ANN:] Hypertext Friend of a Friend (hFoaF) In-Reply-To: <1210765131.5395.30.camel@localhost.localdomain> References: <1210761346.5281.6.camel@localhost.localdomain> <1210765131.5395.30.camel@localhost.localdomain> Message-ID: Ok just to clear it up, are you actually suggesting a new format? or are you suggesting a best-practice for publishers to implement these formats in such a way as to enable a more complete conversion to FOAF? -- Andr? Lu?s On Wed, May 14, 2008 at 12:38 PM, Martin McEvoy wrote: > > On Wed, 2008-05-14 at 12:10 +0100, Andr? Lu?s wrote: >> I like the idea... basically you're just suggesting a way of putting >> hcard+xfn+(hatom/xfolk) together in a simple way. Having a specific >> format to aim for (and to call it) will surely help convergence in >> implementations. > > Yes I guess that's the Idea. > > Martin McEvoy > > From info at weborganics.co.uk Wed May 14 14:17:46 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Wed May 14 14:18:09 2008 Subject: [uf-discuss] [ANN:] Hypertext Friend of a Friend (hFoaF) In-Reply-To: References: <1210761346.5281.6.camel@localhost.localdomain> <1210765131.5395.30.camel@localhost.localdomain> Message-ID: <1210799866.8533.22.camel@localhost.localdomain> On Wed, 2008-05-14 at 20:57 +0100, Andr? Lu?s wrote: > Ok just to clear it up, are you actually suggesting a new format? or > are you suggesting a best-practice for publishers to implement these > formats in such a way as to enable a more complete conversion to FOAF? > Im not sure yet there are more than a few people already publishing this way so at the moment I would say that its just best practice or you could say I am just recognising a design pattern in our own community. A hFoaF format certainly looks desirable FoaF basically is just a machine readable homepage so it would seem natural to want to embed FoaF in html and make it represent an actual homepage too, last time I looked according to ping the semantic web[1] there are around a million FoaF documents out there so yes I think this should maybe be a format what do you think? [1] http://pingthesemanticweb.com/stats/namespaces.php Thanks Martin McEvoy > -- > Andr? Lu?s > > On Wed, May 14, 2008 at 12:38 PM, Martin McEvoy wrote: > > > > On Wed, 2008-05-14 at 12:10 +0100, Andr? Lu?s wrote: > >> I like the idea... basically you're just suggesting a way of putting > >> hcard+xfn+(hatom/xfolk) together in a simple way. Having a specific > >> format to aim for (and to call it) will surely help convergence in > >> implementations. > > > > Yes I guess that's the Idea. > > > > Martin McEvoy > > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From mdagn at spraci.com Thu May 15 02:57:49 2008 From: mdagn at spraci.com (Michael MD) Date: Thu May 15 02:57:57 2008 Subject: [uf-discuss] Re: One more shot at accessible hCalendar References: <62483.81.2.120.180.1210772337.squirrel@goddamn.co.uk> Message-ID: <002101c8b672$2285cc20$116bacca@COMCEN> >> Remember that any page these occur on would presumably have a language >> specification such as "en-us" so computers would be able to deal with >> standard month and day of week names and abbreviations. > > I'm sorry, but this sounds like a really bad idea. Parsers would need to > maintain translation tables for day and month names, plus abbreviations > for them, plus some sort of heuristic for figuring out the language of the > page. (In practice, many authors leave out lang/xml:lang attributes, and > Content-Language headers.) If machine-readable dates were removed from the hCalendar spec what would be the point of using it? Accuracy of dates is CRUCIAL for calendar applications and you would not want to end up using unreliable heuristics to extract them! From supercanadian at gmail.com Thu May 15 13:13:15 2008 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Thu May 15 13:13:19 2008 Subject: [uf-discuss] Fwd: [whatwg] Removing @rev In-Reply-To: References: <482D35918D88499BAD7B08DEDA7A016A@IBM42F76C011DF> <4C393BDA-771A-49C1-8824-B088F0EDDC9C@nickshanks.com> <84ce626f0805151016m260429f4p2f3749d4866e7db5@mail.gmail.com> Message-ID: <84ce626f0805151313m7191fd97kadcde90dc750f32d@mail.gmail.com> Looks like the "rev" attribute is still being removed in HTML5. -- Charles Iliya Krempeaux, B.Sc. http://ChangeLog.ca/ ---------- Forwarded message ---------- From: Ian Hickson Date: Thu, May 15, 2008 at 1:04 PM Subject: Re: [whatwg] Removing @rev To: Charles Iliya Krempeaux Cc: Nicholas Shanks , whatwg@whatwg.org, lynx-dev@nongnu.org On Thu, 15 May 2008, Charles Iliya Krempeaux wrote: > > I thought the "rev" attribute was being added back? (Someone... I can't > remember who... came on the Microformats mailing list, a while ago, and > said something to that effect.) I have no plans to, evidence showed it was causing authors all kinds of problems, and had no practical benefits. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From Charles.Belov at sfmta.com Thu May 15 13:44:50 2008 From: Charles.Belov at sfmta.com (Belov, Charles) Date: Thu May 15 13:44:53 2008 Subject: [uf-discuss] Re: One more shot at accessible hCalendar In-Reply-To: <200805152015.m4FKFYkF026353@microformats.org> References: <200805152015.m4FKFYkF026353@microformats.org> Message-ID: Comments in-lined below. This message includes responses to two messages from the digest. > Message: 5 > Date: Wed, 14 May 2008 14:38:56 +0100 (BST) > From: "Toby Inkster" > Subject: [uf-discuss] Re: One more shot at accessible hCalendar > To: microformats-discuss@microformats.org > Message-ID: <62483.81.2.120.180.1210772337.squirrel@goddamn.co.uk> > Content-Type: text/plain;charset=iso-8859-1 > > Charles Belov wrote: > > > Remember that any page these occur on would presumably have > a language > > specification such as "en-us" so computers would be able to > deal with > > standard month and day of week names and abbreviations. > > I'm sorry, but this sounds like a really bad idea. Parsers > would need to maintain translation tables for day and month > names, plus abbreviations for them, plus some sort of > heuristic for figuring out the language of the page. (In > practice, many authors leave out lang/xml:lang attributes, > and Content-Language headers.) If the web page or RSS feed leaves out the language attribute, then the webmaster has not provided sufficient information to the parser and cannot be said to have implemented this alternative method. I do not expect any scrapers to intuit the origin language. > Andy Mabbett's proposed "data:" prefix already solves the > abbr design pattern accessibility issue and can be > implemented in just a few lines of code. All we need to do is > build support for it into parsers. (Cognition has supported > it since alpha2.1.) > > Closest thing to a "specification" for the prefix: > http://microformats.org/discuss/mail/microformats-discuss/2008 -February/011583.html That solution consists of title attribute contains readable text, followed by the word "data" followed by the actual data. The screen reader software will still read the data out loud, which, on a page full of calendar items, would be sheer torture for the listener. And it still begs the question as to how that data is going to get into the page in the first place when a static HTML page is being created manually by a non-technical person who has no access to the title tag. > > ------------------------------ > > Message: 8 > Date: Thu, 15 May 2008 19:57:49 +1000 > From: "Michael MD" > Subject: Re: [uf-discuss] Re: One more shot at accessible hCalendar > To: "Microformats Discuss" > Message-ID: <002101c8b672$2285cc20$116bacca@COMCEN> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > >> Remember that any page these occur on would presumably > have a language > >> specification such as "en-us" so computers would be able > to deal with > >> standard month and day of week names and abbreviations. > > > > I'm sorry, but this sounds like a really bad idea. Parsers > would need to > > maintain translation tables for day and month names, plus > abbreviations > > for them, plus some sort of heuristic for figuring out the > language of the > > page. (In practice, many authors leave out lang/xml:lang > attributes, and > > Content-Language headers.) > > > If machine-readable dates were removed from the hCalendar > spec what would be > the point of using it? > Accuracy of dates is CRUCIAL for calendar applications and > you would not > want to end up using unreliable heuristics to extract them! I'm not sure what computer cannot read "January", "Jan", "Jan.", "1" or "01" when surrounded by and and be able to figure out that it means the first month of the year. As with the previous post, it still begs the question as to how that computer-readable data is going to get into the page in the first place when a static HTML page is being created manually by a non-technical person who has no access to the title tag. Anyway, if you don't know what language the calendar item is in, how are you going to know whether the plain language description of the event needs to be translated? You could wind up displaying a page full of events that are perfectly timed but are described in plain text in 20 different languages. Accurate, but unusable by most people. Or you could choose to just show English events. Or just French. Or just Chinese. Etc. In which case you would not have to worry about multilingual heuristics. I acknowledge you would still have to worry about typos. Hope this helps, Charles "Chas" Belov SFMTA Webmaster http://www.sfmta.com/webmaster From dsmunger at gmail.com Thu May 15 13:48:27 2008 From: dsmunger at gmail.com (Dave Munger) Date: Thu May 15 13:48:34 2008 Subject: [uf-discuss] Using the hReview microformat for journal article reviews Message-ID: <87BC0F1E-1830-4692-B9A1-04CA89CE26CB@gmail.com> Hi, I'm new to the whole microformats thing, so excuse me if I'm repeating a question. fwiw I didn't find the answer in the FAQ. I run an aggregator of blog posts about journal articles (researchblogging.org). Technically these are all reviews, because the blogger is offering her/his opinion about the article. But they're not typical of the type of reviews the general public might be familiar with (e.g. movies, restaurants). Generally a reviewer of a journal article doesn't rate it on a star system -- simply by virtue of discussing it a blogger is indicating the article is worthwhile. That said, occasionally our users do take the opportunity to trash an article. I'd expect if we actually used a star rating system all our reviews would be either 0 or 5. But I see from the specs that star ratings are optional. We're more interested in using a microformat to give content tags to a post -- is it about biochemistry or astrophysics? While it seems to me that hReview can do this, perhaps some other microformat would be better suited to our needs. We also considered xFolk, but that seems even less relevant to our situation. Any suggestions? Any reason we *shouldn't* be using hReview? Thanks! Dave -- Dave Munger dsmunger@gmail.com http://researchblogging.org http://scienceblogs.com/cognitivedaily From Charles.Belov at sfmta.com Thu May 15 16:59:09 2008 From: Charles.Belov at sfmta.com (Belov, Charles) Date: Thu May 15 16:59:13 2008 Subject: [uf-discuss] RE: One more shot at accessible hCalendar References: <200805152015.m4FKFYkF026353@microformats.org> Message-ID: > Possible alternatives: > If the webmaster does use an empty span with a title tag to contain the ISO date, the > webmaster could add a style="display: none" attribute to it to ensure that screen readers > did not read it. I came up with this format, using the microformats class names and titles, for pages that are computer-generated: Monday, January 5, 2008, 10:00pm This would hide the computer data from screen readers but make in available in the DOM. The issue remains for pages edited by non-technical humans. Hope this helps, Charles "Chas" Belov SFMTA Webmaster http://www.sfmta.com/webmaster From mail at ciaranmcnulty.com Fri May 16 00:57:41 2008 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Fri May 16 00:57:44 2008 Subject: [uf-discuss] Re: One more shot at accessible hCalendar In-Reply-To: <62483.81.2.120.180.1210772337.squirrel@goddamn.co.uk> References: <62483.81.2.120.180.1210772337.squirrel@goddamn.co.uk> Message-ID: On Wed, May 14, 2008 at 2:38 PM, Toby Inkster wrote: > I'm sorry, but this sounds like a really bad idea. Parsers would need to > maintain translation tables for day and month names, plus abbreviations > for them, I agree that it sounds a bit over the top for hCalendar but it's not *that* ridiculous. Most languages have a toolkit for displaying dates in different languages, how is the reverse particularly harder? > plus some sort of heuristic for figuring out the language of the > page. (In practice, many authors leave out lang/xml:lang attributes, and > Content-Language headers.) As an aside, xml:lang and lang can apply to any element and inherit downwards, so aren't particularly more difficult to add to markup than, say, a @title.
is perfectly valid. > Andy Mabbett's proposed "data:" prefix already solves the abbr design > pattern accessibility issue and can be implemented in just a few lines of > code. All we need to do is build support for it into parsers. (Cognition > has supported it since alpha2.1.) If the problem is 'machine readable dates get read out sometimes' I don't see how the data: prefix solves that. I'd also like to see a bit more evidence of how common uFs are treated by screen readers - is there a wiki page somewhere? A lot of the talk about 'accessibility' that goes on on this list seems to come from non-experts making assumptions (that's not to say Charles Belov is doing this, I'm speaking generally). -Ciaran From leidl at tk.informatik.tu-darmstadt.de Fri May 16 01:24:07 2008 From: leidl at tk.informatik.tu-darmstadt.de (Martin Leidl) Date: Fri May 16 01:28:44 2008 Subject: [uf-discuss] Using the hReview microformat for journal article reviews In-Reply-To: <87BC0F1E-1830-4692-B9A1-04CA89CE26CB@gmail.com> Message-ID: Hi Dave - I (also new in this MF-business) would consider this application of hReview very useful. I am thinking about how to use hReview in the context of Peer-Reviewing in e-learning settings, what would be quite familiar... As far as I can see, you have optional TAGs in hReview (http://microformats.org/wiki/hreview). I suppose, what might be usful for your context would be an extension of the item type, eg "publication". So long, martin On 15.05.2008 22:48 Uhr, "Dave Munger" wrote: > Hi, > > I'm new to the whole microformats thing, so excuse me if I'm repeating > a question. fwiw I didn't find the answer in the FAQ. > > I run an aggregator of blog posts about journal articles > (researchblogging.org). Technically these are all reviews, because the > blogger is offering her/his opinion about the article. But they're not > typical of the type of reviews the general public might be familiar > with (e.g. movies, restaurants). Generally a reviewer of a journal > article doesn't rate it on a star system -- simply by virtue of > discussing it a blogger is indicating the article is worthwhile. > > That said, occasionally our users do take the opportunity to trash an > article. I'd expect if we actually used a star rating system all our > reviews would be either 0 or 5. But I see from the specs that star > ratings are optional. > > We're more interested in using a microformat to give content tags to > a post -- is it about biochemistry or astrophysics? While it seems to > me that hReview can do this, perhaps some other microformat would be > better suited to our needs. We also considered xFolk, but that seems > even less relevant to our situation. > > Any suggestions? Any reason we *shouldn't* be using hReview? > > Thanks! > > Dave > > > -- > Dave Munger > dsmunger@gmail.com > > http://researchblogging.org > http://scienceblogs.com/cognitivedaily > > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From bhawkeslewis at googlemail.com Sat May 17 10:37:47 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sat May 17 10:37:59 2008 Subject: [uf-discuss] Re: One more shot at accessible hCalendar In-Reply-To: <62483.81.2.120.180.1210772337.squirrel@goddamn.co.uk> References: <62483.81.2.120.180.1210772337.squirrel@goddamn.co.uk> Message-ID: <482F17EB.7050702@googlemail.com> Toby Inkster wrote: > Andy Mabbett's proposed "data:" prefix already solves the abbr design > pattern accessibility issue Andy made an honest stab at solving the issue; I don't think his proposal is workable however. In so far as end-users want to be able to ignore the data: 1. It requires ordinary users of text-to-speech or text-to-braille sofware to have special knowledge of microformats, if they are to skip the data when the title attribute is read. 2. The page is still littered with tooltips that may distract people with cognitive disabilities and may obscure the main content in a screen magnifier. In so far as end-users want to be able to actually read the data: 1. It doesn't help make the datetime read comprehensibly in (current) text-to-speech or text-to-braille software. 2. It doesn't help make the datetime comprehensible to ordinary users who don't understand ISO 8601 notation. 3. You still can't easily access the datetime without a mouse (keyboard, voice control, etc.). I think it's worth noting (again) that if end-users /really/ wanted to read the data directly, then the most appropriate place for it would be in the main content not quasi-hidden in an attribute. In addition to not solving the accessibility issues, the data: prefix doesn't solve the standards problem of misuse of @TITLE for machine, rather than human, friendly information. Making ISO 8601 annotations accessible to end-users and easily checkable by publishers necessitates special software to check the data is valid, convert it to a human friendly form appropriate to the user's locale, and display it alongside the human friendly, potentially lossy variation in the main content. This isn't (yet) done by mainstream user agents, but would be a useful task for tools like Operator. It makes a lot more sense to me to put the burden of adaptation on the (currently) rare consumers of microformats than on users and user agents in general. Given such problems and granted the potential for such tools, I believe that almost any of the alternative proposals (CLASS-based data hiding, SPAN element with TITLE surrounding human friendly date, empty SPAN element with TITLE, empty ABBR with TITLE, OBJECT element, and INPUT TYPE="HIDDEN" [3] ) would be preferable markup to the data: prefix. Frankly, /all/ of these options seem like a bit of an icky hack. :( It's a question of either giving up on a machine-readable alternative to human friendly information in the current versions of (X)HTML or choosing the option that does the least violence to the intention of the specs, can rely on the most standardized user agent behavior, and does the least harm to end-users. At the moment, I'm leaning a bit towards INPUT TYPE="HIDDEN" as a potential least worst option: http://microformats.org/discuss/mail/microformats-new/2008-March/001567.html The (X)HTML DTDs allow INPUT elements outside any FORM element. The HTML 4.01 spec says (17.2.1): > The elements used to create controls generally appear inside a FORM > element, but may also appear outside of a FORM element declaration > when they are used to build user interfaces. This is discussed in the > section on intrinsic events. Note that controls outside a form cannot > be successful controls. Of INPUT TYPE="HIDDEN", the spec says (17.2.1 again): > Authors may create controls that are not rendered but whose values > are submitted with a form. Authors generally use this control type to > store information between client/server exchanges that would > otherwise be lost due to the stateless nature of HTTP (see > [RFC2616]). Date time information stored in INPUT TYPE="HIDDEN" could be used to "build user interfaces" (e.g. Operator), though it wouldn't (normally) be "submitted with a form". I'm not sure how much weight should be placed on that qualification. "MAY" does not necessarily exclude other uses. Granted, you could make the same argument about the spec's allowances for @TITLE. The key difference here, I think, is how user agents are supposed to treat @TITLE (they may render it directly, whatever element it's on) and how user agents are supposed to treat INPUT TYPE="HIDDEN" (they must not render the control). I believe this makes INPUT TYPE="HIDDEN" safer in terms of potential harm to end-users. I strongly agree with the microformats principle that "visible data is much better for humans than invisible metadata". Now hiding the date time information will seem like a bad thing if you go further and hold that microformated data must /always/ be visible. But I think those who hold this position need to be clear about whether 1. Such data must really always be visible to users (in which case ABBR TITLE is a clear antipattern, since in typical implementations it hides the data unless specifically requested by users). OR 2. It must be possible for the user to make it visible (in which case any standard markup will do, since the information can be extracted and presented in much more human-friendly manner by a microformats-aware tool and the end result will be much better than a TITLE tooltip). To put that another way: visible data is much better for humans than invisible metadata, but human-friendly information that can be made visible is better than machine-friendly information that can be made visible. As some other of the other microformats principles say: "design for humans first, machines second" and "be presentable and parsable": http://microformats.org/wiki/principles -- Benjamin Hawkes-Lewis From mail at tobyinkster.co.uk Sat May 17 14:46:12 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat May 17 14:46:25 2008 Subject: [uf-discuss] Re: One more shot at accessible hCalendar Message-ID: <3B1347D5-EF34-4A02-9F80-EDFE0D09B49B@tobyinkster.co.uk> > If the problem is 'machine readable dates get read out sometimes' I > don't see how the data: prefix solves that. Screen readers may be configured to read out the title attribute for and ; perhaps also and . But they don't automatically read out the contents of the title attribute in the general case. The title attribute on or
or or or whatever will not be read out -- data can safely be kept there. What is needed is a signal to parsers to tell them when to use element content, and when to use the title attribute. The "traditional" microformats method is: * If element==, then title attribute * Else, element content. Adding support for the "data:" prefix, this becomes: * If title attribute contains 'data:', then the remainder of the title attribute * Else if element==, then title attribute * Else, element content. -- Toby A Inkster From adam.craven at fourshapes.com Sat May 17 15:14:22 2008 From: adam.craven at fourshapes.com (Adam Craven - Four Shapes) Date: Sat May 17 15:14:27 2008 Subject: [uf-discuss] Re: One more shot at accessible hCalendar In-Reply-To: <3B1347D5-EF34-4A02-9F80-EDFE0D09B49B@tobyinkster.co.uk> References: <3B1347D5-EF34-4A02-9F80-EDFE0D09B49B@tobyinkster.co.uk> Message-ID: <32068A96-7E9B-4D81-93DE-2A4CB95CEAD4@fourshapes.com> I'm wondering, can you also configure screen readers to expand out titles on any elements? Adam On 17 May 2008, at 22:46, Toby A Inkster wrote: >> If the problem is 'machine readable dates get read out sometimes' I >> don't see how the data: prefix solves that. > > Screen readers may be configured to read out the title attribute for > and ; perhaps also and . But they don't > automatically read out the contents of the title attribute in the > general case. The title attribute on or
or
or > or whatever will not be read out -- data can safely be kept there. > > What is needed is a signal to parsers to tell them when to use > element content, and when to use the title attribute. The > "traditional" microformats method is: > > * If element==, then title attribute > * Else, element content. > > Adding support for the "data:" prefix, this becomes: > > * If title attribute contains 'data:', then the remainder > of the title attribute > * Else if element==, then title attribute > * Else, element content. > > -- > Toby A Inkster > > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From mail at tobyinkster.co.uk Sat May 17 15:32:57 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sat May 17 15:33:06 2008 Subject: [uf-discuss] Re: One more shot at accessible hCalendar Message-ID: > I'm wondering, can you also configure screen readers to expand out > titles on any elements? Not any of which I'm aware. There is a good article on this issue here: http://www.paciellogroup.com/resources/articles/WE05/forms.html -- Toby A Inkster From jim at eatyourgreens.org.uk Sat May 17 15:39:26 2008 From: jim at eatyourgreens.org.uk (Jim O'Donnell) Date: Sat May 17 15:39:33 2008 Subject: [uf-discuss] Re: One more shot at accessible hCalendar In-Reply-To: <32068A96-7E9B-4D81-93DE-2A4CB95CEAD4@fourshapes.com> References: <3B1347D5-EF34-4A02-9F80-EDFE0D09B49B@tobyinkster.co.uk> <32068A96-7E9B-4D81-93DE-2A4CB95CEAD4@fourshapes.com> Message-ID: <9A8CAD69-2975-4849-B4E8-34FE5AF2FB5F@eatyourgreens.org.uk> On 17 May 2008, at 23:14, Adam Craven - Four Shapes wrote: > I'm wondering, can you also configure screen readers to expand out > titles on any elements? > Not as far as I'm aware. Titles may be read out for links, images, form elements and abbreviations and that's about it. I definitely remember Steve Faulkner saying that he's not aware of any AT that will read title on a span. Jim Jim O'Donnell jim@eatyourgreens.org.uk http://eatyourgreens.org.uk http://flickr.com/photos/eatyourgreens From bhawkeslewis at googlemail.com Sat May 17 16:08:09 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sat May 17 16:08:16 2008 Subject: [uf-discuss] Re: One more shot at accessible hCalendar In-Reply-To: References: Message-ID: <482F6559.6010606@googlemail.com> Toby A Inkster wrote: > Not any of which I'm aware. There is a good article on this issue here: > > http://www.paciellogroup.com/resources/articles/WE05/forms.html Be warned that the data presented there is very old. While there are plenty of people still using such old AT, Home Page Reader is no longer available, JAWS is on version 9 not 4, Window-Eyes on version 6 not 4, Supernova on version 9 not 6. -- Benjamin Hawkes-Lewis From julian_bond at voidstar.com Sun May 18 03:30:16 2008 From: julian_bond at voidstar.com (Julian Bond) Date: Sun May 18 03:31:00 2008 Subject: [uf-discuss] microformat evangelism - Adopt a blogger Message-ID: <$ap3K0H4UAMIFANt@jblaptop.voidstar.com> Was just looking at Scoble's scobleizer.com and the redesign. He's now got a "YASN-Roll" of external profiles but it's not marked up with XFN. Then I looked at Marc Canter's http://blog.broadbandmechanics.com/ and there's loads of rel= tags but no microformats. Perhaps it's time for a serious evangelism push and a program of "Adopt a blogger" where the community helps high profile bloggers to implement microformats? -- Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173 Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433 Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat Contains Flammable Gas Under Pressure From info at weborganics.co.uk Sun May 18 07:02:45 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sun May 18 07:03:50 2008 Subject: [uf-discuss] [Ann:] TransFormr. Message-ID: <1211119365.2763.16.camel@localhost.localdomain> I am Pleased to announce TransFormr. TransFormr is another Microformats Transformer. It works a little different to its predecessors ufExtract, Optimus and Cognition because it is mainly built around X2V and all the XSLT style sheets available at http://hg.microformats.org/x2v and a few others found at http://esw.w3.org/topic/CustomRdfDialects supported formats: hcard http://microformats.org/wiki/hcard hatom http://microformats.org/wiki/hatom hcalendar http://microformats.org/wiki/hcalendar hreview http://microformats.org/wiki/hreview geo http://microformats.org/wiki/geo haudio http://microformats.org/wiki/haudio as well as one or two other "experimental" formats. The best way to get going is to use auto detect, example: http://transformr.co.uk/detect/http://tantek.com/ for a full list of urls to extract individual formats please visit http://transformr.co.uk/ Thanks Martin McEvoy http://weborganics.co.uk/ From richard at cyganiak.de Sun May 18 09:51:11 2008 From: richard at cyganiak.de (Richard Cyganiak) Date: Sun May 18 09:51:16 2008 Subject: [uf-discuss] [Ann:] TransFormr. In-Reply-To: <1211119365.2763.16.camel@localhost.localdomain> References: <1211119365.2763.16.camel@localhost.localdomain> Message-ID: Martin, this is very cool. A tiny bug report: All RDF seems to be served with Content-Type: text/html, it should be application/rdf+xml. (Many RDF tools rely on this.) Best, Richard On 18 May 2008, at 15:02, Martin McEvoy wrote: > I am Pleased to announce TransFormr. > > TransFormr is another Microformats Transformer. > > It works a little different to its predecessors ufExtract, Optimus and > Cognition because it is mainly built around X2V and all the XSLT > style > sheets available at http://hg.microformats.org/x2v and a few others > found at http://esw.w3.org/topic/CustomRdfDialects > > supported formats: > > hcard http://microformats.org/wiki/hcard > hatom http://microformats.org/wiki/hatom > hcalendar http://microformats.org/wiki/hcalendar > hreview http://microformats.org/wiki/hreview > geo http://microformats.org/wiki/geo > haudio http://microformats.org/wiki/haudio > > > as well as one or two other "experimental" formats. > > The best way to get going is to use auto detect, example: > > http://transformr.co.uk/detect/http://tantek.com/ > > for a full list of urls to extract individual formats please visit > > http://transformr.co.uk/ > > > Thanks > > Martin McEvoy > http://weborganics.co.uk/ > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From info at weborganics.co.uk Sun May 18 11:30:33 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sun May 18 11:31:45 2008 Subject: [uf-discuss] [Ann:] TransFormr. In-Reply-To: References: <1211119365.2763.16.camel@localhost.localdomain> Message-ID: <1211135433.4557.1.camel@localhost.localdomain> Hello Richard, On Sun, 2008-05-18 at 17:51 +0100, Richard Cyganiak wrote: > Martin, this is very cool. A tiny bug report: All RDF seems to be > served with Content-Type: text/html, it should be application/rdf+xml. > (Many RDF tools rely on this.) Thanks for that, should be fixed now. Best Wishes Martin McEvoy > > Best, > Richard > > > On 18 May 2008, at 15:02, Martin McEvoy wrote: > > > I am Pleased to announce TransFormr. > > > > TransFormr is another Microformats Transformer. > > > > It works a little different to its predecessors ufExtract, Optimus and > > Cognition because it is mainly built around X2V and all the XSLT > > style > > sheets available at http://hg.microformats.org/x2v and a few others > > found at http://esw.w3.org/topic/CustomRdfDialects > > > > supported formats: > > > > hcard http://microformats.org/wiki/hcard > > hatom http://microformats.org/wiki/hatom > > hcalendar http://microformats.org/wiki/hcalendar > > hreview http://microformats.org/wiki/hreview > > geo http://microformats.org/wiki/geo > > haudio http://microformats.org/wiki/haudio > > > > > > as well as one or two other "experimental" formats. > > > > The best way to get going is to use auto detect, example: > > > > http://transformr.co.uk/detect/http://tantek.com/ > > > > for a full list of urls to extract individual formats please visit > > > > http://transformr.co.uk/ > > > > > > Thanks > > > > Martin McEvoy > > http://weborganics.co.uk/ > > > > > > > > > > _______________________________________________ > > microformats-discuss mailing list > > microformats-discuss@microformats.org > > http://microformats.org/mailman/listinfo/microformats-discuss From mail at tobyinkster.co.uk Sun May 18 14:18:38 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Sun May 18 14:19:21 2008 Subject: [uf-discuss] [Ann:] TransFormr. Message-ID: > The best way to get going is to use auto detect, example: > http://transformr.co.uk/detect/http://tantek.com/ Auto-detect... now that is a good idea... I'm going to copy you: http://srv.buzzword.org.uk/detect/tantek.com/ -- Toby A Inkster From info at weborganics.co.uk Sun May 18 15:16:02 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Sun May 18 15:17:10 2008 Subject: [uf-discuss] [Ann:] TransFormr. In-Reply-To: References: Message-ID: <1211148962.8851.1.camel@localhost.localdomain> On Sun, 2008-05-18 at 22:18 +0100, Toby A Inkster wrote: > > The best way to get going is to use auto detect, example: > > http://transformr.co.uk/detect/http://tantek.com/ > > Auto-detect... now that is a good idea... I'm going to copy you: > > http://srv.buzzword.org.uk/detect/tantek.com/ Great Toby! Im glad good ideas catch on ;) Martin > From Charles.Belov at sfmta.com Mon May 19 11:37:39 2008 From: Charles.Belov at sfmta.com (Belov, Charles) Date: Mon May 19 11:37:48 2008 Subject: [uf-discuss] Re: One more shot at accessible hCalendar In-Reply-To: <200805182218.m4IMIW3J013673@microformats.org> References: <200805182218.m4IMIW3J013673@microformats.org> Message-ID: > Message: 1 > Date: Sat, 17 May 2008 22:46:12 +0100 > From: Toby A Inkster > Subject: [uf-discuss] Re: One more shot at accessible hCalendar > To: microformats-discuss@microformats.org > Message-ID: <3B1347D5-EF34-4A02-9F80-EDFE0D09B49B@tobyinkster.co.uk> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > If the problem is 'machine readable dates get read out sometimes' I > > don't see how the data: prefix solves that. > > Screen readers may be configured to read out the title > attribute for and ; perhaps also and > . But they don't automatically read out the contents of > the title attribute in the general case. The title attribute > on or
or
or or whatever will not be > read out -- data can safely be kept there. The argument of whether or not screen readers are by default configured to read out title attributes is a bit of a red herring. As long as screen readers *can* be configured to read out title attributes, there is the issue that both human-friendly title attributes (having nothing to do with microformats) and non-human-friendly ISO dates will be exposed by the same setting. Hope this helps, Charles "Chas" Belov SFMTA Webmaster From info at weborganics.co.uk Tue May 20 09:05:54 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Tue May 20 09:07:25 2008 Subject: [uf-discuss] Re: [Ann:] TransFormr. In-Reply-To: <1211119365.2763.16.camel@localhost.localdomain> References: <1211119365.2763.16.camel@localhost.localdomain> Message-ID: <1211299554.31453.7.camel@localhost.localdomain> On Sun, 2008-05-18 at 15:02 +0100, Martin McEvoy wrote: > I am Pleased to announce TransFormr. > > TransFormr is another Microformats Transformer. ... For anyone who may be interested TransFormr is also available to download and run yourself at Google Code http://code.google.com/p/transformr/ either by via svn: svn co http://transformr.googlecode.com/svn/trunk/ transformr-read-only or by direct download: (only 85.6 KB) http://transformr.googlecode.com/files/transformr.zip Thanks. Martin McEvoy From lunaticsunblog at gmail.com Wed May 21 00:58:43 2008 From: lunaticsunblog at gmail.com (Zhang Zhen) Date: Wed May 21 00:58:48 2008 Subject: [uf-discuss] One more shot at accessible hCalendar In-Reply-To: References: Message-ID: <1f10388d0805210058u3c7c319fy4a12f4f408167218@mail.gmail.com> 2008/5/14 Belov, Charles : > Site visitor accessibility: > > Even if a particular screen reader can disable abbreviations or titles > so as not to hear ISO-format dates read, that means that screen reader > would also not read human-friendly titles that have nothing to do with > microformats. Even if your site does not use human-friendly title tags, > there are sites "in the wild" that do, and having the screen readers > suppress these would be a loss. The whole abbr design pattern is not a very good idea because both the content of abbr element and the value of title attribute should be human-readable text. The right use of abbr element should be like this: 2008-5-21T09:22+08:00 But someone might argue that "2008-5-21T09:22+08:00" wouldn't be a human-readable date. As far as I know, HTML4.01 doesn't offer an attribute for the machine-readable purpose and abbr design pattern seems relatively the best way to do the job, but it's not perfect. -- Zhang, Zhen http://www.lunaticsun.com ( in Chinese only ) From mail at ciaranmcnulty.com Wed May 21 01:07:14 2008 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Wed May 21 01:07:19 2008 Subject: [uf-discuss] One more shot at accessible hCalendar In-Reply-To: <1f10388d0805210058u3c7c319fy4a12f4f408167218@mail.gmail.com> References: <1f10388d0805210058u3c7c319fy4a12f4f408167218@mail.gmail.com> Message-ID: On Wed, May 21, 2008 at 8:58 AM, Zhang Zhen wrote: > But someone might argue that "2008-5-21T09:22+08:00" wouldn't be a > human-readable date. As far as I know, HTML4.01 doesn't offer an > attribute for the machine-readable purpose and abbr design pattern > seems relatively the best way to do the job, but it's not perfect. As another aside, HTML5 has the proposed TIME element for exactly this. -Ciaran McNulty From fberriman at gmail.com Wed May 21 01:27:44 2008 From: fberriman at gmail.com (Frances Berriman) Date: Wed May 21 01:27:47 2008 Subject: [uf-discuss] Re: One more shot at accessible hCalendar In-Reply-To: <9A8CAD69-2975-4849-B4E8-34FE5AF2FB5F@eatyourgreens.org.uk> References: <3B1347D5-EF34-4A02-9F80-EDFE0D09B49B@tobyinkster.co.uk> <32068A96-7E9B-4D81-93DE-2A4CB95CEAD4@fourshapes.com> <9A8CAD69-2975-4849-B4E8-34FE5AF2FB5F@eatyourgreens.org.uk> Message-ID: On 17/05/2008, Jim O'Donnell wrote: > > On 17 May 2008, at 23:14, Adam Craven - Four Shapes wrote: > > > > I'm wondering, can you also configure screen readers to expand out titles > on any elements? > > > > > Not as far as I'm aware. Titles may be read out for links, images, form > elements and abbreviations and that's about it. I definitely remember Steve > Faulkner saying that he's not aware of any AT that will read title on a > span. > As an aside to this - the BBC have put out a call for testers/information and we also have some internal testing (and results) that we hope to publish soon from testing on the new /programmes pages (containing hCal). http://www.bbc.co.uk/blogs/radiolabs/2008/05/microformats_and_accessibility.shtml -- Frances Berriman http://fberriman.com From fberriman at gmail.com Wed May 21 06:12:31 2008 From: fberriman at gmail.com (Frances Berriman) Date: Wed May 21 06:12:36 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC Message-ID: Hi everyone, I realise I mentioned this URL in the last thread I was active on, but I wanted to bring this to the attention to anyone not following that thread. http://www.bbc.co.uk/blogs/radiolabs/2008/05/microformats_and_accessibility.shtml The BBC is trialling microformats in the new programme support pages and are in need of lots of test data and research in order to a) help us make a more informed decision about the use of abbr design pattern in hCalendar here in the community, and b) for them to decide whether to use hCalendar at all (eek!). Please take a read if you are a screen reader user, or know some one who is. Thanks very much, Frances -- Frances Berriman http://fberriman.com From info at weborganics.co.uk Wed May 21 07:33:47 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Wed May 21 07:35:29 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: References: Message-ID: <1211380428.7835.3.camel@localhost.localdomain> Hi Frances On Wed, 2008-05-21 at 14:12 +0100, Frances Berriman wrote: > Hi everyone, > > I realise I mentioned this URL in the last thread I was active on, but > I wanted to bring this to the attention to anyone not following that > thread. > > http://www.bbc.co.uk/blogs/radiolabs/2008/05/microformats_and_accessibility.shtml > > The BBC is trialling microformats in the new programme support pages > and are in need of lots of test data and research in order to a) help > us make a more informed decision about the use of abbr design pattern > in hCalendar here in the community, and b) for them to decide whether > to use hCalendar at all (eek!). > > Please take a read if you are a screen reader user, or know some one who is. Have you tried something like this: 19:30 There is more on this here: http://alistapart.com/articles/hattrick Best Wishes Martin McEvoy > > Thanks very much, > > Frances > From fberriman at gmail.com Thu May 22 02:26:42 2008 From: fberriman at gmail.com (Frances Berriman) Date: Thu May 22 02:26:46 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: <1211380428.7835.3.camel@localhost.localdomain> References: <1211380428.7835.3.camel@localhost.localdomain> Message-ID: On 21/05/2008, Martin McEvoy wrote: > Have you tried something like this: > > > 19:30 > Hi Martin, It's not so much about "what to try" as the BBC using the hCalendar on a new, very large site and not wanting to use a format that is either likely to change (if the abbr pattern is changed/dropped) or causes accessibility issues. They just want to help push through the current discussion with some real data. Hopefully, this issue can be resolved *very soon* - I'd hate to see /programmes have to drop their microformat implementation because of one, relatively small, aspect of one format. Thanks, though! -- Frances Berriman http://fberriman.com From info at weborganics.co.uk Thu May 22 06:46:47 2008 From: info at weborganics.co.uk (Martin McEvoy) Date: Thu May 22 06:49:00 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: References: <1211380428.7835.3.camel@localhost.localdomain> Message-ID: <1211464007.19376.28.camel@localhost.localdomain> On Thu, 2008-05-22 at 10:26 +0100, Frances Berriman wrote: > On 21/05/2008, Martin McEvoy wrote: > > > Have you tried something like this: > > > > > > 19:30 > > > > > Hi Martin, > > It's not so much about "what to try" as the BBC using the hCalendar on > a new, very large site and not wanting to use a format that is either > likely to change (if the abbr pattern is changed/dropped) or causes > accessibility issues. They just want to help push through the current > discussion with some real data. > > Hopefully, this issue can be resolved *very soon* - I'd hate to see > /programmes have to drop their microformat implementation because of > one, relatively small, aspect of one format. > Hmm It seems to me that the microformats community seems to find it difficult to resolve the abbr design issue[1], its been over a year now? I cant see why we cant accept the hAccessibility[2] solution and be done with it and just use a , I believe most screen readers are not set up to read out loud the @title on a span by default. March 12, 2007 at 5 PM, Central Standard Time Another resolution I rather liked was to use [3] instead as it is unlikely the @title will ever be read out loud on a dfn tag, dfn is hardly ever used in the "real-world" but to me is an extremely useful and "posh" tag, perfect for a microformat. March 12, 2007 at 5 PM, Central Standard Time Oh well hopefully the abbr issue can be resolved amicably this time around as there seems to be a few "usable" resolutions[4], if not, lets all talk about it again Next Year :) [1] http://microformats.org/wiki/accessibility-issues#abbr-design-pattern [2] http://www.webstandards.org/2007/04/27/haccessibility/ [3] http://microformats.org/wiki/dfn-design-pattern [4] http://microformats.org/wiki/assistive-technology-abbr-results#Valid_HTML4 Thanks Martin > Thanks, though! > From scott at randomchaos.com Thu May 22 08:29:17 2008 From: scott at randomchaos.com (Scott Reynen) Date: Thu May 22 08:29:22 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: <1211464007.19376.28.camel@localhost.localdomain> References: <1211380428.7835.3.camel@localhost.localdomain> <1211464007.19376.28.camel@localhost.localdomain> Message-ID: On [May 22], at [ May 22] 7:46 , Martin McEvoy wrote: > Hmm It seems to me that the microformats community seems to find it > difficult to resolve the abbr design issue[1], its been over a year > now? This is difficult to solve because we lack the resources to do testing with screen reader users. The current pattern was established without such testing. If that was a mistake, let's not repeat it. (And if that wasn't a mistake, there's no need to change anything.) > I cant see why we cant accept the hAccessibility[2] solution and be > done > with it and just use a , I believe most screen readers are not > set > up to read out loud the @title on a span by default. Has anyone tested this in various screen readers? If not, on what basis would we accept it? > Oh well hopefully the abbr issue can be resolved amicably this time > around as there seems to be a few "usable" resolutions[4], if not, > lets > all talk about it again Next Year I don't think talking about it more is helping much at this point. We're mostly rehashing the same ideas over and over again. What we need, and what Frances is asking for, is help testing these various ideas. Peace, Scott From alasdairking at gmail.com Thu May 22 09:06:13 2008 From: alasdairking at gmail.com (Alasdair King) Date: Thu May 22 09:06:16 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: References: <1211380428.7835.3.camel@localhost.localdomain> <1211464007.19376.28.camel@localhost.localdomain> Message-ID: <7df2c90b0805220906n3ef8a18m6431befa46be440e@mail.gmail.com> >> I cant see why we cant accept the hAccessibility[2] solution and be done >> with it and just use a , I believe most screen readers are not set >> up to read out loud the @title on a span by default. > > Has anyone tested this in various screen readers? If not, on what basis > would we accept it? >From the BBC page linked: "We've looked at quite a few screen readers out of the box and by default they don't expand abbreviation elements so the user still hears 19:30 not 2008-05-15T19:30:00+01:00." I infer that they've tested the screenreaders, they're just worried there are lots of blind people who have turned on ABBR, and the BBC is a big, sensitive target. I know blind people are more annoyed about the lack of audio descriptions in iPlayer, but there'll be some uber-geek screenreader user in a well-off advocacy group who'll complain. People who have problems will be the subset of users who (use a screenreader) AND (have a screenreader that supports ABBR) AND (have turned on abbreviation elements) AND (come across hCalendar ABBR elements) AND (find this one thing the biggest headache in using the site.) Why not just offer to buy both those people a beer to make up? I'll mail my screenreader-using friends and ask them to respond anyway. -- Alasdair King From fberriman at gmail.com Thu May 22 09:14:50 2008 From: fberriman at gmail.com (Frances Berriman) Date: Thu May 22 09:14:55 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: <7df2c90b0805220906n3ef8a18m6431befa46be440e@mail.gmail.com> References: <1211380428.7835.3.camel@localhost.localdomain> <1211464007.19376.28.camel@localhost.localdomain> <7df2c90b0805220906n3ef8a18m6431befa46be440e@mail.gmail.com> Message-ID: On 22/05/2008, Alasdair King wrote: > >> I cant see why we cant accept the hAccessibility[2] solution and be done > >> with it and just use a , I believe most screen readers are not set > >> up to read out loud the @title on a span by default. > > > > Has anyone tested this in various screen readers? If not, on what basis > > would we accept it? > > > >From the BBC page linked: > "We've looked at quite a few screen readers out of the box and by > default they don't expand abbreviation elements so the user still > hears 19:30 not 2008-05-15T19:30:00+01:00." > > I infer that they've tested the screenreaders, they're just worried > there are lots of blind people who have turned on ABBR, and the BBC is > a big, sensitive target. I know blind people are more annoyed about > the lack of audio descriptions in iPlayer, but there'll be some > uber-geek screenreader user in a well-off advocacy group who'll > complain. There has been some testing, that will hopefully be published soon, but it's not definitive (since there's not much data on how most SR users have their setups). That's all :) > People who have problems will be the subset of users who (use a > screenreader) AND (have a screenreader that supports ABBR) AND (have > turned on abbreviation elements) AND (come across hCalendar ABBR > elements) AND (find this one thing the biggest headache in using the > site.) Why not just offer to buy both those people a beer to make up? Beer solves a lot, but unfortunately, it's not that viable this time. > I'll mail my screenreader-using friends and ask them to respond anyway. Fantastic :) -- Frances Berriman http://fberriman.com From Michael.Smethurst at bbc.co.uk Thu May 22 09:17:47 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu May 22 09:17:59 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: <7df2c90b0805220906n3ef8a18m6431befa46be440e@mail.gmail.com> Message-ID: On 22/5/08 17:06, "Alasdair King" wrote: >>> I cant see why we cant accept the hAccessibility[2] solution and be done >>> with it and just use a , I believe most screen readers are not set >>> up to read out loud the @title on a span by default. >> >> Has anyone tested this in various screen readers? If not, on what basis >> would we accept it? > >> From the BBC page linked: > "We've looked at quite a few screen readers out of the box and by > default they don't expand abbreviation elements so the user still > hears 19:30 not 2008-05-15T19:30:00+01:00." > > I infer that they've tested the screenreaders, they're just worried > there are lots of blind people who have turned on ABBR, and the BBC is > a big, sensitive target. I know blind people are more annoyed about > the lack of audio descriptions in iPlayer, but there'll be some > uber-geek screenreader user in a well-off advocacy group who'll > complain. > > People who have problems will be the subset of users who (use a > screenreader) AND (have a screenreader that supports ABBR) AND (have > turned on abbreviation elements) AND (come across hCalendar ABBR > elements) AND (find this one thing the biggest headache in using the > site.) Why not just offer to buy both those people a beer to make up? > > I'll mail my screenreader-using friends and ask them to respond anyway. Worth pointing out that we're also worried that the abbreviation design pattern will rule out future non-microformat use of abbreviations for screenreader users. We're talking to screenreader manufacturers about their plans And we're also concerned about the effects of wacky tool-tips on those with cognitive disabilities. Anyway, all evidence is good so thanks http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From alasdairking at gmail.com Thu May 22 09:23:29 2008 From: alasdairking at gmail.com (Alasdair King) Date: Thu May 22 09:24:31 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: References: <1211380428.7835.3.camel@localhost.localdomain> <1211464007.19376.28.camel@localhost.localdomain> <7df2c90b0805220906n3ef8a18m6431befa46be440e@mail.gmail.com> Message-ID: <7df2c90b0805220923g4a2a248an4445cca4e9d45b31@mail.gmail.com> > There has been some testing, that will hopefully be published soon, > but it's not definitive (since there's not much data on how most SR > users have their setups). That's all :) Sorry, I meant of course "I infer that they've tested the default settings of the screenreaders..." -- Alasdair King From fberriman at gmail.com Thu May 22 09:35:37 2008 From: fberriman at gmail.com (Frances Berriman) Date: Thu May 22 09:35:44 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: <7df2c90b0805220923g4a2a248an4445cca4e9d45b31@mail.gmail.com> References: <1211380428.7835.3.camel@localhost.localdomain> <1211464007.19376.28.camel@localhost.localdomain> <7df2c90b0805220906n3ef8a18m6431befa46be440e@mail.gmail.com> <7df2c90b0805220923g4a2a248an4445cca4e9d45b31@mail.gmail.com> Message-ID: On 22/05/2008, Alasdair King wrote: > > There has been some testing, that will hopefully be published soon, > > but it's not definitive (since there's not much data on how most SR > > users have their setups). That's all :) > > > Sorry, I meant of course "I infer that they've tested the default > settings of the screenreaders..." > > Ah - sorry. My mistake too :) -- Frances Berriman http://fberriman.com From Michael.Smethurst at bbc.co.uk Thu May 22 09:38:04 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu May 22 09:38:16 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: <7df2c90b0805220923g4a2a248an4445cca4e9d45b31@mail.gmail.com> Message-ID: On 22/5/08 17:23, "Alasdair King" wrote: >> There has been some testing, that will hopefully be published soon, >> but it's not definitive (since there's not much data on how most SR >> users have their setups). That's all :) > > Sorry, I meant of course "I infer that they've tested the default > settings of the screenreaders..." My screenreader knowledge is minimal but iplayer have tested hCal on a variety of outa the box screenreaders (sorry, can't give a full list - I'll try and hunt it down). By default they all had abbreviation expansion turned off and ufs passed with a clean bill of health I believe we also did very, very limited at home testing. Of 4 users 2 had abbreviation expansion turned on. It's a stupidly low sample size which is why we're appealing to screenreader users to help us out It wouldn't be so much of a problem if it was just one hCal per page but for a schedule day view we have quite a number: http://www.bbc.co.uk/radio4/programmes/schedules/fm http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From lists at ben-ward.co.uk Thu May 22 10:17:00 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Thu May 22 10:17:15 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: <7df2c90b0805220906n3ef8a18m6431befa46be440e@mail.gmail.com> References: <1211380428.7835.3.camel@localhost.localdomain> <1211464007.19376.28.camel@localhost.localdomain> <7df2c90b0805220906n3ef8a18m6431befa46be440e@mail.gmail.com> Message-ID: <0677454F-79E7-4C53-8A61-FDD1EEFCBF4E@ben-ward.co.uk> On 22 May 2008, at 17:06, Alasdair King wrote: >> From the BBC page linked: > "We've looked at quite a few screen readers out of the box and by > default they don't expand abbreviation elements so the user still > hears 19:30 not 2008-05-15T19:30:00+01:00." > > I infer that they've tested the screenreaders, they're just worried > there are lots of blind people who have turned on ABBR, and the BBC is > a big, sensitive target. I know blind people are more annoyed about > the lack of audio descriptions in iPlayer, but there'll be some > uber-geek screenreader user in a well-off advocacy group who'll > complain. > > People who have problems will be the subset of users who (use a > screenreader) AND (have a screenreader that supports ABBR) AND (have > turned on abbreviation elements) AND (come across hCalendar ABBR > elements) AND (find this one thing the biggest headache in using the > site.) Why not just offer to buy both those people a beer to make up? I don't think the ?what's the default? argument is an absolute decider either way with this. The behaviour is supported and used; we've not been able to get numbers on how many assistive technology users do turn it on, but I don't think it's right to dismiss an option of a browser which is acting legitimately with the semantics of the HTML it is parsing. Reading aloud abbreviations is a perfectly reasonable thing to do, whether it's a default, on-demand or whatever. As far as I can judge, assistive technology offering the ability to expand abbreviations is entirely in line with the intentions of the HTML4 specification, whereas stuffing illegible data into it is not. This is less an issue of accessibility as it is semantics. Where ABBR is being used incorrectly, there's no right to complain about a consuming tool treating your code in an undesired way. Recently, we've been discussing the issue of embedding machine-data as part of microformats on uf-dev, and debating possible alternative methods from a parser perspective (namely an empty element with a title attribute). Of interest here is the document now on the wiki covering all the uses of machine data in microformats, and covering all the currently supported means of including that alongside the publishers preferred formatting. http://microformats.org/wiki/machine-data At the moment, the data embedding solution proposed there is being discussed on -dev: (http://microformats.org/discuss/mail/microformats-dev/2008-May/000519.html ). It will move over to discuss once we're confident in it being reliably parsable. B From alasdairking at gmail.com Thu May 22 11:04:37 2008 From: alasdairking at gmail.com (Alasdair King) Date: Thu May 22 11:11:27 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: References: <7df2c90b0805220923g4a2a248an4445cca4e9d45b31@mail.gmail.com> Message-ID: <7df2c90b0805221104m5a0fdc79xebf351bdbacbae96@mail.gmail.com> Michael Smethurst wrote: "Of 4 users 2 had abbreviation expansion turned on." Ah, but what was your sample group? Were they, by any chance, highly-able professionals, probably with a business interest in web design and accessibility? Or were they little old ladies using Thunder or NVDA because those screenreaders are free? Apparently JAWS has ABBR support off but ACRONYM on by default, which surprised me. Anyway, I have one user whose screenreader doesn't support ABBR (Thunder), and one who uses JAWS and leaves it off so far. I'll mail you details privately. Interestingly, I think your "what about people with cognitive problems getting confused?" point might be of more real-world importance, but since people cognitive problems are not as powerful politically they probably aren't a problem for you. Best wishes, Alasdair King WebbIE On Thu, May 22, 2008 at 5:38 PM, Michael Smethurst wrote: > > > > On 22/5/08 17:23, "Alasdair King" wrote: > >>> There has been some testing, that will hopefully be published soon, >>> but it's not definitive (since there's not much data on how most SR >>> users have their setups). That's all :) >> >> Sorry, I meant of course "I infer that they've tested the default >> settings of the screenreaders..." > > My screenreader knowledge is minimal but iplayer have tested hCal on a > variety of outa the box screenreaders (sorry, can't give a full list - I'll > try and hunt it down). By default they all had abbreviation expansion turned > off and ufs passed with a clean bill of health > > I believe we also did very, very limited at home testing. Of 4 users 2 had > abbreviation expansion turned on. It's a stupidly low sample size which is > why we're appealing to screenreader users to help us out > > It wouldn't be so much of a problem if it was just one hCal per page but for > a schedule day view we have quite a number: > > http://www.bbc.co.uk/radio4/programmes/schedules/fm > > > http://www.bbc.co.uk/ > This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. > If you have received it in error, please delete it from your system. > Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. > Please note that the BBC monitors e-mails sent or received. > Further communication will signify your consent to this. > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- Alasdair King From Charles.Belov at sfmta.com Thu May 22 11:15:20 2008 From: Charles.Belov at sfmta.com (Belov, Charles) Date: Thu May 22 11:15:26 2008 Subject: [uf-discuss] RE: microformats-discuss Digest, Vol 36, Issue 9 In-Reply-To: <200805221351.m4MDpAeQ027854@microformats.org> References: <200805221351.m4MDpAeQ027854@microformats.org> Message-ID: > ------------------------------ > > Message: 3 > Date: Wed, 21 May 2008 15:58:43 +0800 > From: "Zhang Zhen" > Subject: Re: [uf-discuss] One more shot at accessible hCalendar > To: "Microformats Discuss" > Message-ID: > <1f10388d0805210058u3c7c319fy4a12f4f408167218@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > The whole abbr design pattern is not a very good idea because > both the content of abbr element and the value of title > attribute should be human-readable text. The right use of > abbr element should be like > this: > > 2008-5-21T09:22+08:00 I would hate to inflict an ISO date on my sighted readers either. > ------------------------------ > > Message: 4 > Date: Wed, 21 May 2008 09:07:14 +0100 > From: "Ciaran McNulty" > Subject: Re: [uf-discuss] One more shot at accessible hCalendar > To: "Microformats Discuss" > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > On Wed, May 21, 2008 at 8:58 AM, Zhang Zhen > wrote: > > But someone might argue that "2008-5-21T09:22+08:00" wouldn't be a > > human-readable date. As far as I know, HTML4.01 doesn't offer an > > attribute for the machine-readable purpose and abbr design pattern > > seems relatively the best way to do the job, but it's not perfect. > > As another aside, HTML5 has the proposed TIME element for > exactly this. > > So the site visitor problem is solved for HTML 5. We still have the coding issue for manually maintained pages by non-technical personnel. And even this techie doesn't have 24-hour time sufficiently internalized to accurately and consistently translate 12-hour times into 24-hour. > > ------------------------------ > > > Have you tried something like this: > > > 19:30 > > > There is more on this here: > > http://alistapart.com/articles/hattrick > Still, any reader that reads the title of an abbr tag will read out the ISO date. > > ------------------------------ > > Message: 8 > Date: Thu, 22 May 2008 10:26:42 +0100 > From: "Frances Berriman" > Subject: Re: [uf-discuss] Request for help from screen reader users > from the BBC > To: info@weborganics.co.uk, "Microformats Discuss" > > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On 21/05/2008, Martin McEvoy wrote: > > > It's not so much about "what to try" as the BBC using the hCalendar on > a new, very large site and not wanting to use a format that is either > likely to change (if the abbr pattern is changed/dropped) or causes > accessibility issues. They just want to help push through the current > discussion with some real data. This would be a killer for us as well. > Hopefully, this issue can be resolved *very soon* - I'd hate to see > /programmes have to drop their microformat implementation because of > one, relatively small, aspect of one format. Me too. I'm hoping someone can give feedback on my proposed solution, which is to hide the ISO date using style="display:none" May 12, 2008, 5:30pm Again, this is to solve the site visitor problem. The page producer problem still remains. Hope this helps, Charles Belov SFMTA Webmaster From mail at tobyinkster.co.uk Thu May 22 11:49:17 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu May 22 11:49:26 2008 Subject: [uf-discuss] RE: microformats-discuss Digest, Vol 36, Issue 9 Message-ID: Charles Belov wrote: > May 12, 2008, 5:30pm title="2008-05-12T17:30:00-0700" style="display:none"> Similar to my current compromise: May 12, 2008, 5:30pm Which seems to work in many current parsers. -- Toby A Inkster From mail at tobyinkster.co.uk Thu May 22 12:25:20 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu May 22 12:25:32 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC Message-ID: <2FF5B1E3-BA4D-4009-8487-41751B534270@tobyinkster.co.uk> Ben Ward wrote: > I don't think the ?what's the default? argument is an absolute decider > either way with this. Indeed. Even if no screen readers even *offered* the option of reading the title attribute of abbreviations, the abbr design pattern would still be a bad idea. Or rather,having it as the only supported method of supplying machine-readable data (short of making the machine-readable data available as normal page content) is a bad idea. In the case where the human readable data really is an abbreviation for the machine readable data, such as UK then the abbr pattern is appropriate, and it's good that it works. But when the machine readable data is not a legitimate expansion of the human readable text, then use of the abbr design pattern falls into an obvious discord with: http://microformats.org/wiki/semantic-xhtml-design-principles An author who was not using microformats could not legitimately claim to be using proper semantic HTML if they included samples like this in their pages: mobile phone end of December Adding classes ('type' and 'dtend') does not make things any better. The abbr design pattern is good and should work, but we really must have an alternative for those times when it doesn't make good semantic sense. -- Toby A Inkster From mdagn at spraci.com Thu May 22 21:10:29 2008 From: mdagn at spraci.com (Michael MD) Date: Thu May 22 21:10:34 2008 Subject: [uf-discuss] RE: microformats-discuss Digest, Vol 36, Issue 9 References: <200805221351.m4MDpAeQ027854@microformats.org> Message-ID: <006801c8bc8a$f01d9b40$116bacca@COMCEN> > > I would hate to inflict an ISO date on my sighted readers either. actually I don't mind sometimes showing people yyyy-mm-dd. The general public does need a bit of education about writing dates clearly! At least they can't be confused with some other date! ... but on many pages out in the big bad world I just see people writing stuff like "June 12th" or (worse) "12/6" .... I wouldn't really call those even human readable when you can't be sure whether they intended to say 12th June 2008, 12th June 2007 or 6th December 2006! From lists at ben-ward.co.uk Thu May 22 10:17:00 2008 From: lists at ben-ward.co.uk (Ben Ward) Date: Fri May 23 02:32:43 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: <7df2c90b0805220906n3ef8a18m6431befa46be440e@mail.gmail.com> References: <1211380428.7835.3.camel@localhost.localdomain> <1211464007.19376.28.camel@localhost.localdomain> <7df2c90b0805220906n3ef8a18m6431befa46be440e@mail.gmail.com> Message-ID: <0677454F-79E7-4C53-8A61-FDD1EEFCBF4E@ben-ward.co.uk> On 22 May 2008, at 17:06, Alasdair King wrote: >> From the BBC page linked: > "We've looked at quite a few screen readers out of the box and by > default they don't expand abbreviation elements so the user still > hears 19:30 not 2008-05-15T19:30:00+01:00." > > I infer that they've tested the screenreaders, they're just worried > there are lots of blind people who have turned on ABBR, and the BBC is > a big, sensitive target. I know blind people are more annoyed about > the lack of audio descriptions in iPlayer, but there'll be some > uber-geek screenreader user in a well-off advocacy group who'll > complain. > > People who have problems will be the subset of users who (use a > screenreader) AND (have a screenreader that supports ABBR) AND (have > turned on abbreviation elements) AND (come across hCalendar ABBR > elements) AND (find this one thing the biggest headache in using the > site.) Why not just offer to buy both those people a beer to make up? I don't think the ?what's the default? argument is an absolute decider either way with this. The behaviour is supported and used; we've not been able to get numbers on how many assistive technology users do turn it on, but I don't think it's right to dismiss an option of a browser which is acting legitimately with the semantics of the HTML it is parsing. Reading aloud abbreviations is a perfectly reasonable thing to do, whether it's a default, on-demand or whatever. As far as I can judge, assistive technology offering the ability to expand abbreviations is entirely in line with the intentions of the HTML4 specification, whereas stuffing illegible data into it is not. This is less an issue of accessibility as it is semantics. Where ABBR is being used incorrectly, there's no right to complain about a consuming tool treating your code in an undesired way. Recently, we've been discussing the issue of embedding machine-data as part of microformats on uf-dev, and debating possible alternative methods from a parser perspective (namely an empty element with a title attribute). Of interest here is the document now on the wiki covering all the uses of machine data in microformats, and covering all the currently supported means of including that alongside the publishers preferred formatting. http://microformats.org/wiki/machine-data At the moment, the data embedding solution proposed there is being discussed on -dev: (http://microformats.org/discuss/mail/microformats-dev/2008-May/000519.html ). It will move over to discuss once we're confident in it being reliably parsable. B From bhawkeslewis at googlemail.com Sat May 24 04:42:46 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Sat May 24 04:42:56 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: References: Message-ID: <4837FF36.60404@googlemail.com> Frances Berriman wrote: > I realise I mentioned this URL in the last thread I was active on, but > I wanted to bring this to the attention to anyone not following that > thread. > > http://www.bbc.co.uk/blogs/radiolabs/2008/05/microformats_and_accessibility.shtml > > The BBC is trialling microformats in the new programme support pages > and are in need of lots of test data and research in order to a) help > us make a more informed decision about the use of abbr design pattern > in hCalendar here in the community, and b) for them to decide whether > to use hCalendar at all (eek!). > > Please take a read if you are a screen reader user, or know some one who is. Hi Frances You might want to ask on screen reader user mailing lists if anyone would like to test the BBC's implementation. From what I've seen, users on such lists are very keen to try out things and give feedback. UK computer users who are blind or visually impaired: access-uk@freelists.org http://www.freelists.org/list/access-uk Freedom Scientific JAWS users: jaws-uk@freelists.org http://www.freelists.org/list/jaws-uk Dolphin HAL users: dolphinusers@yahoogroups.com http://tech.groups.yahoo.com/group/dolphinusers/ GW-Micro Window-Eyes users: gw-info@gwmicro.com http://www.gwmicro.com/Support/GW-Info_Archives/ Apple VoiceOver users: macvoiceover@freelists.org http://www.freelists.org/list/macvoiceover/ GNOME Orca users: orca-list@gnome.org http://mail.gnome.org/mailman/listinfo/orca-list NVDA users: nvda@freelists.org http://www.freelists.org/list/nvda Thunder users: thunder@freelists.org http://www.freelists.org/list/thunder (I'm not aware of an active mailing list or forum specific to System Access users.) You might also want to reach out to the screen magnification-using community: Screen magnifier users: magnifiers@yahoogroups.com http://tech.groups.yahoo.com/group/magnifiers/ ZoomText users: Ai Squared forums http://www.aisquared.com/forums/index.php Hope that helps. -- Benjamin Hawkes-Lewis From geraldbauer2007 at gmail.com Sun May 25 23:14:51 2008 From: geraldbauer2007 at gmail.com (Gerald Bauer) Date: Sun May 25 23:14:54 2008 Subject: [uf-discuss] [ANN] New Forum/Mailing List - Free Web Slide Show Alternatives - S5, S9, FullerScreen and Friends - Join Us Message-ID: <7e7cb8940805252314sad3bcc2xcad39bd5f1a12c3b@mail.gmail.com> Hello, Interested in the state-of-art of authoring and/or publishing slides/slide shows/presentations with Microformats or Plain Old Semantic Hypertext Markup (POSH)? If yes I invite you to join the new "Free Web Slide Show Alternatives" mailing list/forum that welcomes postings about open source package and/or formats such as S5, S9, FullerScreen, Opera Show Format (OSF) and friends. More @ http://groups.google.com/group/webslideshow Join us. Cheers. S9 Tip of the Day: Replace .html with .svg to check your background gradient theme. Try http://slideshow.rubyforge.org/microformats.svg -- Gerald Bauer - Internet Professional - http://geraldbauer.wordpress.com From Michael.Smethurst at bbc.co.uk Tue May 27 01:47:41 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Tue May 27 01:48:09 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: <7df2c90b0805221104m5a0fdc79xebf351bdbacbae96@mail.gmail.com> Message-ID: On 22/5/08 19:04, "Alasdair King" wrote: > Michael Smethurst wrote: > "Of 4 users 2 had abbreviation expansion turned on." > > Ah, but what was your sample group? Were they, by any chance, > highly-able professionals, probably with a business interest in web > design and accessibility? Or were they little old ladies using Thunder > or NVDA because those screenreaders are free? The honest answer is I don't know. But I'm not sure why highly-able professionals shouldn't be able to find out what's on telly tonight. > > Apparently JAWS has ABBR support off but ACRONYM on by default, which > surprised me. Anyway, I have one user whose screenreader doesn't > support ABBR (Thunder), and one who uses JAWS and leaves it off so > far. I'll mail you details privately. Thanks, any data appreciated Abbreviation expansion is not our only problem. Screenreaders can also be set up to read *all* title attributes - read tool tips and expand abbreviations settings are orthogonal. With tool tips reading turned on users get the full datetime read out when they float their mouse over the abbreviation. Anecdotally this seems to be a far more common configuration for partially sited users. > > Interestingly, I think your "what about people with cognitive problems > getting confused?" point might be of more real-world importance, but > since people cognitive problems are not as powerful politically they > probably aren't a problem for you. Don't want to sound prickly here but our intentions are strictly honourable. We're not doing this to pick holes with microformats or tick bbc boxes or avoid being sued. We're just a bunch of developers trying to do 'the right thing'. Whether people with cognitive problems are politically powerful or not if they can't use our site we're doing something wrong. http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From Charles.Belov at sfmta.com Tue May 27 11:10:25 2008 From: Charles.Belov at sfmta.com (Belov, Charles) Date: Tue May 27 11:10:27 2008 Subject: [uf-discuss] RE: Request for help from screen reader users In-Reply-To: <200805260618.m4Q6ICqt007862@microformats.org> References: <200805260618.m4Q6ICqt007862@microformats.org> Message-ID: Hope this helps, Charles Belov SFMTA Webmaster ------------------------------ >Message: 3 >Date: Thu, 22 May 2008 19:49:17 +0100 >From: Toby A Inkster >Subject: [uf-discuss] RE: microformats-discuss Digest, Vol 36, Issue 9 >To: microformats-discuss@microformats.org >Message-ID: >Content-Type: text/plain; charset=US-ASCII; format=flowed >Charles Belov wrote: >> May 12, 2008, 5:30pm> title="2008-05-12T17:30:00-0700" style="display:none"> >Similar to my current compromise: > > May 12, 2008, 5:30pm > style="display:none"> > >Which seems to work in many current parsers. The most important common part is our use of style="display:none" I respectfully suggest my parser, which places the class and the title attributes in the same tag, provides a simpler parse and does not require a change to current parsers. ("humandtstart" is only for the convenience of webmasters who want to style the human-readable date, and can be ignored by parsers.) There is no need for the parse to relate the human-readable date with the machine-readable date if any given audience is going to ignore one or the other. I do credit your work on this tag as an inspiration for my derivation. -- Toby A Inkster -----Original Message----- ------------------------------ >Message: 6 >Date: Thu, 22 May 2008 18:17:00 +0100 >From: Ben Ward >Subject: Re: [uf-discuss] Request for help from screen reader users > from the BBC >To: Microformats Discuss >Message-ID: <0677454F-79E7-4C53-8A61-FDD1EEFCBF4E@ben-ward.co.uk> >Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; > delsp=yes >Recently, we've been discussing the issue of embedding machine-data as >part of microformats on uf-dev, and debating possible alternative >methods from a parser perspective (namely an empty element with a >title attribute). I think the most important part of a solution is to add style="display:none" to that empty element to guarantee that the title will not be read or displayed to humans. Hope this helps, Charles "Chas" Belov SFMTA Webmaster From andr3.pt at gmail.com Tue May 27 14:30:33 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Tue May 27 14:30:37 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds Message-ID: Hello everyone, I've been preparing a presentation (in Portuguese) to help colleagues from work adopt and embrace microformats fully. So far I'm really enjoying doing it but I have come upon some doubts about hatom that I hope some of you can help me with. Here it goes. What is the rationale for providing an hAtom feed on a page for content that is also syndicated via a real Atom or RSS feed? Can someone provide me with a real use case? I've looked at the wiki and googled the archives of the mailing list... I didn't find anything, but if this has been discussed in the past, I apologize. Thanks, Andr? Lu?s From davidjanes at blogmatrix.com Tue May 27 14:45:56 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Tue May 27 14:46:01 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: References: Message-ID: <21e523c20805271445s16532ed7t39381fa3e389039f@mail.gmail.com> hAtom is microformat for adding semantic information to HTML microcontent, identifying information such as the content, summary, author, title and so forth. It is not and never has been intended to replace Atom or RSS feeds. Regards, etc... David On Tue, May 27, 2008 at 5:30 PM, Andr? Lu?s wrote: > > Hello everyone, > > I've been preparing a presentation (in Portuguese) to help colleagues > from work adopt and embrace microformats fully. So far I'm really > enjoying doing it but I have come upon some doubts about hatom that I > hope some of you can help me with. > Here it goes. > > What is the rationale for providing an hAtom feed on a page for > content that is also syndicated via a real Atom or RSS feed? > > Can someone provide me with a real use case? > > I've looked at the wiki and googled the archives of the mailing > list... I didn't find anything, but if this has been discussed in the > past, I apologize. > > Thanks, > Andr? Lu?s > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com From lunaticsunblog at gmail.com Tue May 27 18:03:35 2008 From: lunaticsunblog at gmail.com (Zhang Zhen) Date: Tue May 27 18:03:41 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: References: Message-ID: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com> 2008/5/28 Andr? Lu?s : > Can someone provide me with a real use case? http://msdn.microsoft.com/en-us/library/cc304073(VS.85).aspx -- Zhang, Zhen http://www.lunaticsun.com ( in Chinese only ) From mail at tobyinkster.co.uk Wed May 28 00:49:55 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Wed May 28 00:50:17 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds Message-ID: <48B740D4-03DD-4920-B62D-4414CE3B2811@tobyinkster.co.uk> Andr? Lu?s wrote: > What is the rationale for providing an hAtom feed on a page for > content that is also syndicated via a real Atom or RSS feed? > > Can someone provide me with a real use case? One idea that I've been playing with is removing a page's Atom feed, and replacing it with something like this: From mark at markng.me.uk Wed May 28 00:58:25 2008 From: mark at markng.me.uk (Mark Ng) Date: Wed May 28 00:58:29 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com> References: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com> Message-ID: > 2008/5/28 Andr? Lu?s : > > Can someone provide me with a real use case? One good use case is a API of sorts for historical information. A news site, for example, normally only gives you RSS/Atom for, lets say, the last week. hAtom provides structure for data older than that- archives, etc. From brian.suda at gmail.com Wed May 28 01:25:18 2008 From: brian.suda at gmail.com (Brian Suda) Date: Wed May 28 01:25:21 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: References: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com> Message-ID: <21e770780805280125r2ff97402kff4e46b390e98dce@mail.gmail.com> 2008/5/28, Mark Ng : > > 2008/5/28 Andr? Lu?s : > > > > Can someone provide me with a real use case? --- someone else can confirm the details, but sites like technorati (and/or google/yahoo!) crawl the HTML pages and attempt to use heuristics to determine what the title, summary, publication date and other entry items could be. By adding the additional semantics of hAtom, you are making things explicit and then they can avoid guessing at what you mean, and understand what you intended. Applications like Flock or Reblog could build plugins, so when you right-click on the HTML page on the hAtom entry, the context menu could understand where the post starts and stops, and extract other metadata. This interaction takes place on the page were you are viewing the text, rather than in some secondary RSS reading tool. -brian -- brian suda http://suda.co.uk From Michael.Smethurst at bbc.co.uk Wed May 28 03:27:47 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Wed May 28 03:27:57 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: <4837FF36.60404@googlemail.com> Message-ID: Thanks benjamin I had a quiet day lined up. Looks like I'll be subscribing to mailing list now ;-) On 24/5/08 12:42, "Benjamin Hawkes-Lewis" wrote: > Frances Berriman wrote: >> I realise I mentioned this URL in the last thread I was active on, but >> I wanted to bring this to the attention to anyone not following that >> thread. >> >> http://www.bbc.co.uk/blogs/radiolabs/2008/05/microformats_and_accessibility.s >> html >> >> The BBC is trialling microformats in the new programme support pages >> and are in need of lots of test data and research in order to a) help >> us make a more informed decision about the use of abbr design pattern >> in hCalendar here in the community, and b) for them to decide whether >> to use hCalendar at all (eek!). >> >> Please take a read if you are a screen reader user, or know some one who is. > > Hi Frances > > You might want to ask on screen reader user mailing lists if anyone > would like to test the BBC's implementation. From what I've seen, users > on such lists are very keen to try out things and give feedback. > > UK computer users who are blind or visually impaired: > access-uk@freelists.org > http://www.freelists.org/list/access-uk > > Freedom Scientific JAWS users: > jaws-uk@freelists.org > http://www.freelists.org/list/jaws-uk > > Dolphin HAL users: > dolphinusers@yahoogroups.com > http://tech.groups.yahoo.com/group/dolphinusers/ > > GW-Micro Window-Eyes users: > gw-info@gwmicro.com > http://www.gwmicro.com/Support/GW-Info_Archives/ > > Apple VoiceOver users: > macvoiceover@freelists.org > http://www.freelists.org/list/macvoiceover/ > > GNOME Orca users: > orca-list@gnome.org > http://mail.gnome.org/mailman/listinfo/orca-list > > NVDA users: > nvda@freelists.org > http://www.freelists.org/list/nvda > > Thunder users: > thunder@freelists.org > http://www.freelists.org/list/thunder > > (I'm not aware of an active mailing list or forum specific to System > Access users.) > > You might also want to reach out to the screen magnification-using > community: > > Screen magnifier users: > magnifiers@yahoogroups.com > http://tech.groups.yahoo.com/group/magnifiers/ > > ZoomText users: > Ai Squared forums > http://www.aisquared.com/forums/index.php > > Hope that helps. > -- > Benjamin Hawkes-Lewis > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From andr3.pt at gmail.com Wed May 28 05:12:55 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Wed May 28 05:12:57 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: <21e770780805280125r2ff97402kff4e46b390e98dce@mail.gmail.com> References: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com> <21e770780805280125r2ff97402kff4e46b390e98dce@mail.gmail.com> Message-ID: Thanks everyone. I'll try to reply to every comment individually. (removed original comments to keep it short) David: I wasn't suggesting "replacing" atom/rss... I wanted to ask for use-cases or motivation to markup content that is also available through atom/rss feeds with hatom. My English betrayed me on that title, I guess. :) Zhang Zhen: yes, hslices are a good reason. if nothing else, provides alternative ways of subscribing to content. via atom/rss feeds & hatom/hslice in IE8. Toby: I can see why you'd want to do that, in terms of proof of concept, but in the real world it's not a convincing "advantage". Unless you're limited in terms of features, like a blog @ wordpress.com. Mark Ng: Whoa! Never thought of that... it would be cool if there was a way to paginate hatom feeds like xfn with rel="next". Is there? Brian: That seems like a good argument... but only if crawlers actually use that increased semantic value. I have no data about that. If someone else still has more examples of use-cases, I'd be happy to hear them. -- Andr? Lu?s On Wed, May 28, 2008 at 9:25 AM, Brian Suda wrote: > 2008/5/28, Mark Ng : >> > 2008/5/28 Andr? Lu?s : >> > >> > Can someone provide me with a real use case? > > --- someone else can confirm the details, but sites like technorati > (and/or google/yahoo!) crawl the HTML pages and attempt to use > heuristics to determine what the title, summary, publication date and > other entry items could be. By adding the additional semantics of > hAtom, you are making things explicit and then they can avoid guessing > at what you mean, and understand what you intended. > > Applications like Flock or Reblog could build plugins, so when you > right-click on the HTML page on the hAtom entry, the context menu > could understand where the post starts and stops, and extract other > metadata. This interaction takes place on the page were you are > viewing the text, rather than in some secondary RSS reading tool. > > -brian > > -- > brian suda > http://suda.co.uk > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From alasdairking at gmail.com Wed May 28 05:41:25 2008 From: alasdairking at gmail.com (Alasdair King) Date: Wed May 28 05:41:27 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: References: <7df2c90b0805221104m5a0fdc79xebf351bdbacbae96@mail.gmail.com> Message-ID: <7df2c90b0805280541r1f0a7349y8f62b4aec838be50@mail.gmail.com> Hi Michael, I'm sorry, I didn't mean to imply any mendacity on your part. I'm fully appreciative and admiring of the BBC's long-term support for accessibility, including BETSIE, informal support for my BBC-using programs, and use of accessibility features like skiplinks. That said, I recognise the difficult legal, political and regulatory environment you're in: otherwise I'd be writing "Don't use microformats: publish a podcast of your programmes with DRM-free video and audio content with audio descriptions at the other end instead" and that wouldn't be helpful to you, right? Smile. I'm arguing the following: 1 You have a large potential base of non-technical, vision-impaired users. They really are not technical. They often don't understand the Windows Start menu, how Windows Explorer works, the difference between an executable and a shortcut on the desktop, the difference between HTML as opposed to text format email. They have a set of heuristic techniques and processes they have been shown by volunteers or nephews and follow them to perform the task they want to do. Some have JAWS, lots more have NVDA or Thunder, few know how to change their preferences or what that means. They turn on the computer and press the keys they have learned to press to do what they want, and that's it. If what they get out isn't what they expect, they'll try the keys again or restart the computer. It's incredibly time-consuming, but it's independent activity. 2 There was a recent discussion on the British Computer Association of the Blind mailing list about how hard blind users found the iPlayer pages: well-constructed, fully-accessible web pages, with accessible Flash embedded. Good, accessible design from the BBC as always, but still people having problems. Why? Because it's really difficult to use a screenreader, relative to a sighted person. The cost profile is higher and different, in formal usability terms. The solution (I believe) is to provide tools (programs) that let vision-impaired users do the things they want to do easily. For example, I have a well-regarded (free) Accessible BBC Listen Again program that scrapes your BBC Listen Again pages and presents the contents as an alphabetically-ordered list. Menus control the station. Hit Return to Play, Escape to Stop. Volume resets when you close the program in case the user accidentally turns it off and can't get any subsequent sound. The point is not to provide every feature of your Listen Again pages, like the links to the station websites, but to make it really really easy to do the core function: listen to the radio with just a few buttons. I'd like to do this with your television stations, and with your old archived output when it's available. If you end up with a bunch of web pages I'll write a scraper/crawler, but if you use microformats it'll make it much easier and more reliable for me to produce a putative "Accessible BBC Archive" program. And if microformats spread from you to other sites, then more data will become machine readable and more simple tools or scripts for vision-impaired users will be possible. Hence my support. 3 Working in web accessibility leads one to mix with highly-technical professional screenreader users. They should not, I argue, be your target audience. A highly-technical JAWS user will write a script to get round ABBR problems and distribute it to other users, or just use the webpages for sighted people, or turn off ABBR again. If microformats take off then Freedom Scientific will make sure that script ships with JAWS anyway, and all the vendors will follow suit. I am, therefore, as a professional working in software for vision-impaired people, not worried about the impact on screenreader users of the ABBR tag, since I think the temporary and minor disbenefits are outweighed by the major benefits. Finally, on people with cognitive problems: a significant proportion of the UK population has cognitive, literacy, and learning difficulties. How much time do you spend on their needs in web design? A far smaller proportion are screenreader users: how much time do you spend on their needs in web design - like now? There is a strong argument that the needs of people with cognitive problems are not properly addressed. I don't have any answers for that one, I must stress, but it does seem to me that the needs of screenreader users have historically been politically more important in web design - possibly because people with cognitive problems have more alternative technologies and sources of content, where for blind people the Internet is unique as a source of news, entertainment, communication and independence. All the best, Dr. Alasdair King WebbIE http://www.webbie.org.uk On Tue, May 27, 2008 at 9:47 AM, Michael Smethurst wrote: > > > > On 22/5/08 19:04, "Alasdair King" wrote: > >> Michael Smethurst wrote: >> "Of 4 users 2 had abbreviation expansion turned on." >> >> Ah, but what was your sample group? Were they, by any chance, >> highly-able professionals, probably with a business interest in web >> design and accessibility? Or were they little old ladies using Thunder >> or NVDA because those screenreaders are free? > > The honest answer is I don't know. But I'm not sure why highly-able > professionals shouldn't be able to find out what's on telly tonight. > >> >> Apparently JAWS has ABBR support off but ACRONYM on by default, which >> surprised me. Anyway, I have one user whose screenreader doesn't >> support ABBR (Thunder), and one who uses JAWS and leaves it off so >> far. I'll mail you details privately. > > Thanks, any data appreciated > > Abbreviation expansion is not our only problem. Screenreaders can also be > set up to read *all* title attributes - read tool tips and expand > abbreviations settings are orthogonal. With tool tips reading turned on > users get the full datetime read out when they float their mouse over the > abbreviation. Anecdotally this seems to be a far more common configuration > for partially sited users. >> >> Interestingly, I think your "what about people with cognitive problems >> getting confused?" point might be of more real-world importance, but >> since people cognitive problems are not as powerful politically they >> probably aren't a problem for you. > > Don't want to sound prickly here but our intentions are strictly honourable. > We're not doing this to pick holes with microformats or tick bbc boxes or > avoid being sued. We're just a bunch of developers trying to do 'the right > thing'. Whether people with cognitive problems are politically powerful or > not if they can't use our site we're doing something wrong. > > > http://www.bbc.co.uk/ > This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. > If you have received it in error, please delete it from your system. > Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. > Please note that the BBC monitors e-mails sent or received. > Further communication will signify your consent to this. > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- Alasdair King From mark at markng.me.uk Wed May 28 05:42:57 2008 From: mark at markng.me.uk (Mark Ng) Date: Wed May 28 05:43:00 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: References: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com> <21e770780805280125r2ff97402kff4e46b390e98dce@mail.gmail.com> Message-ID: 2008/5/28 Andr? Lu?s : > Mark Ng: Whoa! Never thought of that... it would be cool if there was > a way to paginate hatom feeds like xfn with rel="next". Is there? You just described it yourself ;). I'm not sure whether anyone is already doing it that way though. Mark From andr3.pt at gmail.com Wed May 28 06:07:29 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Wed May 28 06:07:32 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: References: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com> <21e770780805280125r2ff97402kff4e46b390e98dce@mail.gmail.com> Message-ID: I guess I did. :) I always thought of rel="next" as a xfn-only thing. Maybe rel="next" could be made a "recommendation" to establish links between pages containing streams of uf's. Generically. This is very infinite-loop-prone, though. Parsers could "allow" following that stream or not. I don't see Operator doing it, but I see Cognition, hKit et al allowing it. Thoughts? -- Andr? On Wed, May 28, 2008 at 1:42 PM, Mark Ng wrote: > 2008/5/28 Andr? Lu?s : >> Mark Ng: Whoa! Never thought of that... it would be cool if there was >> a way to paginate hatom feeds like xfn with rel="next". Is there? > > You just described it yourself ;). I'm not sure whether anyone is > already doing it that way though. > > Mark > From mark at markng.me.uk Wed May 28 06:19:30 2008 From: mark at markng.me.uk (Mark Ng) Date: Wed May 28 06:19:32 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: References: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com> <21e770780805280125r2ff97402kff4e46b390e98dce@mail.gmail.com> Message-ID: 2008/5/28 Andr? Lu?s : > I guess I did. :) I always thought of rel="next" as a xfn-only thing. > Maybe rel="next" could be made a "recommendation" to establish links > between pages containing streams of uf's. Generically. This is very It's already part of HTML : http://www.w3.org/TR/html401/types.html#type-links :) Mark From james at tartarus.org Wed May 28 06:49:21 2008 From: james at tartarus.org (James Aylett) Date: Wed May 28 06:49:27 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: References: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com> <21e770780805280125r2ff97402kff4e46b390e98dce@mail.gmail.com> Message-ID: <20080528134921.GH9247@tartarus.org> On Wed, May 28, 2008 at 02:07:29PM +0100, Andr? Lu?s wrote: > Maybe rel="next" could be made a "recommendation" to establish links > between pages containing streams of uf's. Generically. HTML defines rel='next' [1] in terms of the relationship between the HTML documents. There's a semantic concern here of the relationship between the microformat data embedded in the page and the HTML document. There may be more than one embedded collection of microformats in a single HTML document (indeed, this is a good thing :-). I suspect a generic recommendation here is unwise, as the implication (paged streams of microformats should be presented as HTML pages linked together using rel='next') is not reflexive (it is certainly not true that all HTML pages with rel='next' and containing microformats that /may/ be presented as paged streams actually embody a paged stream of microformats; consider for instance a paged preview of a year using hCalendar to point out conferences; those hCalendar instances might be in a sidebar and present on every page of the preview). The XFN pattern isn't so simplistic, of course: rel='me next' is different to rel='next'. (Although I'd consider this a slightly questionable reading of the definition of @rel, since the semantic relationship between multiple link-types on the same anchor or link is, I believe, not specified in HTML.) In the case of hAtom, rel='feed next' would achieve a similar distinction. A general recommendation could presumably be made that this approach is the correct one, if it is agreed that this approach is the correct one. James [1] -- /--------------------------------------------------------------------------\ James Aylett xapian.org james@tartarus.org uncertaintydivision.org From andr3.pt at gmail.com Wed May 28 09:09:20 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Wed May 28 09:09:27 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: <20080528134921.GH9247@tartarus.org> References: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com> <21e770780805280125r2ff97402kff4e46b390e98dce@mail.gmail.com> <20080528134921.GH9247@tartarus.org> Message-ID: *smacks forehead* Of course! Makes perfect sense. Why not extend this to other formats? hatom, rel="hfeed next" hcalendar, rel="hcalendar next" Since both formats have a root node to encapsulate several hentry|vevent, it would be (AFAIK) semantically correct. It would allow parsers to do a better job at parsing the entire "stream" of related Entries and Events. Is there any downside in this approach I'm not foreseeing? -- Andr? Lu?s On Wed, May 28, 2008 at 2:49 PM, James Aylett wrote: > On Wed, May 28, 2008 at 02:07:29PM +0100, Andr? Lu?s wrote: > >> Maybe rel="next" could be made a "recommendation" to establish links >> between pages containing streams of uf's. Generically. > > HTML defines rel='next' [1] in terms of the relationship between the > HTML documents. There's a semantic concern here of the relationship > between the microformat data embedded in the page and the HTML > document. There may be more than one embedded collection of > microformats in a single HTML document (indeed, this is a good thing > :-). > > I suspect a generic recommendation here is unwise, as the implication > (paged streams of microformats should be presented as HTML pages > linked together using rel='next') is not reflexive (it is certainly > not true that all HTML pages with rel='next' and containing > microformats that /may/ be presented as paged streams actually embody > a paged stream of microformats; consider for instance a paged preview > of a year using hCalendar to point out conferences; those hCalendar > instances might be in a sidebar and present on every page of the > preview). > > The XFN pattern isn't so simplistic, of course: rel='me next' is > different to rel='next'. (Although I'd consider this a slightly > questionable reading of the definition of @rel, since the semantic > relationship between multiple link-types on the same anchor or link > is, I believe, not specified in HTML.) > > In the case of hAtom, rel='feed next' would achieve a similar > distinction. A general recommendation could presumably be made that > this approach is the correct one, if it is agreed that this approach > is the correct one. > > James > > [1] > > -- > /--------------------------------------------------------------------------\ > James Aylett xapian.org > james@tartarus.org uncertaintydivision.org > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From scott at randomchaos.com Wed May 28 10:18:04 2008 From: scott at randomchaos.com (Scott Reynen) Date: Wed May 28 10:18:10 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: References: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com> <21e770780805280125r2ff97402kff4e46b390e98dce@mail.gmail.com> Message-ID: <565ECB62-CBE9-4453-AD75-343E69F13064@randomchaos.com> On [May 28], at [ May 28] 7:07 , Andr? Lu?s wrote: > I always thought of rel="next" as a xfn-only thing. I'm not seeing rel="next" in the XFN documentation. Unless I'm missing something, it's not only not XFN-only, it's not XFN at all. On [May 28], at [ May 28] 10:09 , Andr? Lu?s wrote: > hatom, rel="hfeed next" > hcalendar, rel="hcalendar next" > > Since both formats have a root node to encapsulate several > hentry|vevent, it would be (AFAIK) semantically correct. I don't believe those are appropriate uses of the rel attribute. Regardless, they're new uses, so if you're interested in pursuing this further, please take it to the -new list: http://microformats.org/mailman/listinfo/microformats-new/ Peace, Scott From Charles.Belov at sfmta.com Wed May 28 10:21:34 2008 From: Charles.Belov at sfmta.com (Belov, Charles) Date: Wed May 28 10:21:38 2008 Subject: [uf-discuss] Re: Request for help from screen reader users from the BBC In-Reply-To: <200805281350.m4SDogp4032090@microformats.org> References: <200805281350.m4SDogp4032090@microformats.org> Message-ID: Hope this helps, Charles Belov SFMTA Webmaster -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of microformats-discuss-request@microformats.org Sent: Wednesday, May 28, 2008 6:51 AM To: microformats-discuss@microformats.org Subject: microformats-discuss Digest, Vol 36, Issue 13 Send microformats-discuss mailing list submissions to microformats-discuss@microformats.org To subscribe or unsubscribe via the World Wide Web, visit http://microformats.org/mailman/listinfo/microformats-discuss or, via email, send a message with subject or body 'help' to microformats-discuss-request@microformats.org You can reach the person managing the list at microformats-discuss-owner@microformats.org When replying, please edit your Subject line so it is more specific than "Re: Contents of microformats-discuss digest..." ------------------------------ Message: 2 Date: Wed, 28 May 2008 13:41:25 +0100 >From: "Alasdair King" >Subject: Re: [uf-discuss] Request for help from screen reader users > from the BBC >To: "Microformats Discuss" >Message-ID: > <7df2c90b0805280541r1f0a7349y8f62b4aec838be50@mail.gmail.com> >Content-Type: text/plain; charset=ISO-8859-1 >(snip) >3 Working in web accessibility leads one to mix with highly-technical professional >screenreader users. They should not, I argue, be your target audience. A highly-technical >JAWS user will write a script to get round ABBR problems and distribute it to other users, or >just use the webpages for sighted people, or turn off ABBR again. If microformats take off >then Freedom Scientific will make sure that script ships with JAWS anyway, and all the >vendors will follow suit. I am, therefore, as a professional working in software for vision- >impaired people, not worried about the impact on screenreader users of the ABBR tag, since I >think the temporary and minor disbenefits are outweighed by the major benefits. >(snip) I am worried, because if ABBR titles are suppressed then they can't be used for their legitimate use to expand abbreviations, and we are left with a Gresham's Law of Attributes where nonstandard uses of attributes drive out standard uses of attributes. Hope this helps, Charles "Chas" Belov SFMTA Webmaster From davidjanes at blogmatrix.com Wed May 28 10:45:51 2008 From: davidjanes at blogmatrix.com (David Janes) Date: Wed May 28 10:45:59 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: <565ECB62-CBE9-4453-AD75-343E69F13064@randomchaos.com> References: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com> <21e770780805280125r2ff97402kff4e46b390e98dce@mail.gmail.com> <565ECB62-CBE9-4453-AD75-343E69F13064@randomchaos.com> Message-ID: <21e523c20805281045v5b5f503em4db1ed7a8806dc5c@mail.gmail.com> There's documented XFN examples of next/prev here [1] though I'm not sure what to make of the "officialness" of it. It would be cool this was formally documented in a way that could be used across microformats, though as Scott says in the -new mailing list. Regards, etc... David [1] http://microformats.org/wiki/hcard-xfn-supporting-friends-lists#Implement_hCard_XFN_supporting_friends_lists On Wed, May 28, 2008 at 1:18 PM, Scott Reynen wrote: > On [May 28], at [ May 28] 7:07 , Andr? Lu?s wrote: > >> I always thought of rel="next" as a xfn-only thing. > > I'm not seeing rel="next" in the XFN documentation. Unless I'm missing > something, it's not only not XFN-only, it's not XFN at all. > > On [May 28], at [ May 28] 10:09 , Andr? Lu?s wrote: > >> hatom, rel="hfeed next" >> hcalendar, rel="hcalendar next" >> >> Since both formats have a root node to encapsulate several >> hentry|vevent, it would be (AFAIK) semantically correct. > > > I don't believe those are appropriate uses of the rel attribute. > Regardless, they're new uses, so if you're interested in pursuing this > further, please take it to the -new list: > > http://microformats.org/mailman/listinfo/microformats-new/ > > Peace, > Scott > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com From glenn.jones at madgex.com Wed May 28 13:07:29 2008 From: glenn.jones at madgex.com (Glenn Jones) Date: Wed May 28 13:07:38 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSSfeeds In-Reply-To: <21e523c20805281045v5b5f503em4db1ed7a8806dc5c@mail.gmail.com> References: <1f10388d0805271803l14e56d0ai26560bad2c624a4c@mail.gmail.com><21e770780805280125r2ff97402kff4e46b390e98dce@mail.gmail.com><565ECB62-CBE9-4453-AD75-343E69F13064@randomchaos.com> <21e523c20805281045v5b5f503em4db1ed7a8806dc5c@mail.gmail.com> Message-ID: <36A319113CF910438942741C4727ADFF01EEFB1F@MOBY.Clarence.local> I did some experiments a while back which you may find interesting. It's a XFN parser which can spider pages following rel=next. http://lab.backnetwork.com/xfnpagination/ One of the more basic issues when using the web as an API is finding a method to interact with data split across multiple pages. We need a way of identifying additional information which is part of the current dataset, but on secondary pages. The rel attribute provides a practical standards based solution, which can be used to mark-up the next page in a series. We can do this with rel=me rel=next. Personal I think that microformats parser should support Url fragment. So you can mark-up groups of information and provide pagination in context of a page fragment. http://twitter.com/glennjones/#friends http://twitter.com/glennjones/#posts Targeting the second page of posts could look something like Glenn -----Original Message----- From: microformats-discuss-bounces@microformats.org [mailto:microformats-discuss-bounces@microformats.org] On Behalf Of David Janes Sent: 28 May 2008 18:46 To: Microformats Discuss Subject: Re: [uf-discuss] Rationale for providing hAtom instead of Atom/RSSfeeds There's documented XFN examples of next/prev here [1] though I'm not sure what to make of the "officialness" of it. It would be cool this was formally documented in a way that could be used across microformats, though as Scott says in the -new mailing list. Regards, etc... David [1] http://microformats.org/wiki/hcard-xfn-supporting-friends-lists#Implement_hCard_XFN_supporting_friends_lists On Wed, May 28, 2008 at 1:18 PM, Scott Reynen wrote: > On [May 28], at [ May 28] 7:07 , Andr? Lu?s wrote: > >> I always thought of rel="next" as a xfn-only thing. > > I'm not seeing rel="next" in the XFN documentation. Unless I'm missing > something, it's not only not XFN-only, it's not XFN at all. > > On [May 28], at [ May 28] 10:09 , Andr? Lu?s wrote: > >> hatom, rel="hfeed next" >> hcalendar, rel="hcalendar next" >> >> Since both formats have a root node to encapsulate several >> hentry|vevent, it would be (AFAIK) semantically correct. > > > I don't believe those are appropriate uses of the rel attribute. > Regardless, they're new uses, so if you're interested in pursuing this > further, please take it to the -new list: > > http://microformats.org/mailman/listinfo/microformats-new/ > > Peace, > Scott > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > -- David Janes Founder, BlogMatrix http://www.blogmatrix.com http://www.onaswarm.com _______________________________________________ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss From bjonkman at sobac.com Wed May 28 22:08:57 2008 From: bjonkman at sobac.com (Bob Jonkman) Date: Wed May 28 22:09:45 2008 Subject: [uf-discuss] Rationale for providing hAtom instead of Atom/RSS feeds In-Reply-To: <48B740D4-03DD-4920-B62D-4414CE3B2811@tobyinkster.co.uk> References: <48B740D4-03DD-4920-B62D-4414CE3B2811@tobyinkster.co.uk> Message-ID: <483E0229.32130.73890E@bjonkman.sobac.com> This is what Toby A Inkster said about "[uf-discuss] Rationale for providin" on 28 May 2008 at 8:49 > Andr? Lu?s wrote: > > > What is the rationale for providing an hAtom feed on a page for > > content that is also syndicated via a real Atom or RSS feed? > > > > Can someone provide me with a real use case? > > One idea that I've been playing with is removing a page's Atom feed, > and replacing it with something like this: > > href="hatom2atom.php?uri=http://example.org/page.html" That's exactly what I've been trying to do at http://sobac.com/pawha/ except that I have in the : (Thanx, Luke!) I code the page by hand, so creating an extra Atom feed is onerous. Much better to have some software do it for me. I tried to use the hatom parser at http://tools.blogmatrix.com/extract but it appears to be 404. I got that link from the second example at http://microformats.org/wiki/hatom#Implementations ; if anyone can confirm that this is really defunct I'll update the Wiki. --Bob. -- -- -- -- Bob Jonkman http://sobac.com/sobac/ SOBAC Microcomputer Services Voice: +1-519-669-0388 6 James Street, Elmira ON Canada N3B 1L5 Cel: +1-519-635-9413 Software --- Office & Business Automation --- Consulting From Michael.Smethurst at bbc.co.uk Thu May 29 02:26:04 2008 From: Michael.Smethurst at bbc.co.uk (Michael Smethurst) Date: Thu May 29 02:26:14 2008 Subject: [uf-discuss] Request for help from screen reader users from the BBC In-Reply-To: <7df2c90b0805280541r1f0a7349y8f62b4aec838be50@mail.gmail.com> Message-ID: On 28/5/08 13:41, "Alasdair King" wrote: Hi Alasdair Big thanks for this - really interesting and helpful. One or 2 comments inline > Hi Michael, > > I'm sorry, I didn't mean to imply any mendacity on your part. I'm > fully appreciative and admiring of the BBC's long-term support for > accessibility, including BETSIE, informal support for my BBC-using > programs, and use of accessibility features like skiplinks. That said, > I recognise the difficult legal, political and regulatory environment > you're in: otherwise I'd be writing "Don't use microformats: publish a > podcast of your programmes with DRM-free video and audio content with > audio descriptions at the other end instead" and that wouldn't be > helpful to you, right? Smile. Yeah, fair cop. It's what we'd like too but as you say "due to the unique way the bbc is funded etc etc etc" ;-) Apologies for getting snarky - we've been trying to get an answer to this for the last 6 months now > > I'm arguing the following: > > 1 You have a large potential base of non-technical, vision-impaired > users. They really are not technical. They often don't understand the > Windows Start menu, how Windows Explorer works, the difference between > an executable and a shortcut on the desktop, the difference between > HTML as opposed to text format email. They have a set of heuristic > techniques and processes they have been shown by volunteers or nephews > and follow them to perform the task they want to do. Some have JAWS, > lots more have NVDA or Thunder, few know how to change their > preferences or what that means. They turn on the computer and press > the keys they have learned to press to do what they want, and that's > it. If what they get out isn't what they expect, they'll try the keys > again or restart the computer. It's incredibly time-consuming, but > it's independent activity. Yup, point taken. Still it would be nice to have real data to point to about how users use screenreaders. Hopefully, we'll be doing this research soon > > 2 There was a recent discussion on the British Computer Association of > the Blind mailing list about how hard blind users found the iPlayer > pages: well-constructed, fully-accessible web pages, with accessible > Flash embedded. Good, accessible design from the BBC as always, but > still people having problems. Why? Because it's really difficult to > use a screenreader, relative to a sighted person. The cost profile is > higher and different, in formal usability terms. The solution (I > believe) is to provide tools (programs) that let vision-impaired users > do the things they want to do easily. For example, I have a > well-regarded (free) Accessible BBC Listen Again program that scrapes > your BBC Listen Again pages and presents the contents as an > alphabetically-ordered list. Menus control the station. Hit Return to > Play, Escape to Stop. Volume resets when you close the program in case > the user accidentally turns it off and can't get any subsequent sound. > The point is not to provide every feature of your Listen Again pages, > like the links to the station websites, but to make it really really > easy to do the core function: listen to the radio with just a few > buttons. It's tricky. Sometimes making a site accessible for one community makes it less useable for another. In general we try not to ghettoise users into areas of (dis)ability but this sounds like something the bbc should support on bbc.co.uk?!? Anyway it sounds cool. I'll mail you off list for the details. > > I'd like to do this with your television stations, and with your old > archived output when it's available. If you end up with a bunch of web > pages I'll write a scraper/crawler, but if you use microformats it'll > make it much easier and more reliable for me to produce a putative > "Accessible BBC Archive" program. And if microformats spread from you > to other sites, then more data will become machine readable and more > simple tools or scripts for vision-impaired users will be possible. > Hence my support. Bbc.co.uk/programmes is designed to be machine accessible. For now this just means schedules available as json and unflavoured xml: http://www.bbc.co.uk/radio4/programmes/schedules/fm.xml http://www.bbc.co.uk/bbcfour/programmes/schedules.json But over time we'll add json, xml, yaml, rdf, ical, xspf, rss2, atom across the app. So hopefully you'll never have to scrape screens again. It does raise the question of whether it's worth supporting microformats. At the moment the main driver for keeping them is the move towards indexing ufs and rdf-a by yahoo etc. I'll keep people informed if those talks progress A move toward rdf-a is still on the table > > 3 Working in web accessibility leads one to mix with highly-technical > professional screenreader users. They should not, I argue, be your > target audience. A highly-technical JAWS user will write a script to > get round ABBR problems and distribute it to other users, or just use > the webpages for sighted people, or turn off ABBR again. If > microformats take off then Freedom Scientific will make sure that > script ships with JAWS anyway, and all the vendors will follow suit. I > am, therefore, as a professional working in software for > vision-impaired people, not worried about the impact on screenreader > users of the ABBR tag, since I think the temporary and minor > disbenefits are outweighed by the major benefits. I guess we're worried about closing off the use of abbreviations in domains that need them. Things like share trading (stock ticker abbreviations), travel (airport abbreviations) etc We'd like to use microformats but with a more accessible alternative to the abbreviation design pattern. But that prospect never seems to move any closer. Ideally we'd favour a move towards hiding data intended for machines but know that that conflicts with the philosophy of microformats > > Finally, on people with cognitive problems: a significant proportion > of the UK population has cognitive, literacy, and learning > difficulties. How much time do you spend on their needs in web design? > A far smaller proportion are screenreader users: how much time do you > spend on their needs in web design - like now? There is a strong > argument that the needs of people with cognitive problems are not > properly addressed. I don't have any answers for that one, I must > stress, but it does seem to me that the needs of screenreader users > have historically been politically more important in web design - > possibly because people with cognitive problems have more alternative > technologies and sources of content, where for blind people the > Internet is unique as a source of news, entertainment, communication > and independence. All true. We do spend quite a lot of time considering users with cognitive difficulties. Although like you say probably a little less than time spent on screenreader users. Whether that's true for other web publishers I can't say There's a wider study going on about usability for people with cognitive difficulties on bbc.co.uk. We're planning to wrap some microformats research into this. Again I'll report back Anyway, thanks for your help. Much appreciated > > All the best, > Dr. Alasdair King > WebbIE > http://www.webbie.org.uk > > > > On Tue, May 27, 2008 at 9:47 AM, Michael Smethurst > wrote: >> >> >> >> On 22/5/08 19:04, "Alasdair King" wrote: >> >>> Michael Smethurst wrote: >>> "Of 4 users 2 had abbreviation expansion turned on." >>> >>> Ah, but what was your sample group? Were they, by any chance, >>> highly-able professionals, probably with a business interest in web >>> design and accessibility? Or were they little old ladies using Thunder >>> or NVDA because those screenreaders are free? >> >> The honest answer is I don't know. But I'm not sure why highly-able >> professionals shouldn't be able to find out what's on telly tonight. >> >>> >>> Apparently JAWS has ABBR support off but ACRONYM on by default, which >>> surprised me. Anyway, I have one user whose screenreader doesn't >>> support ABBR (Thunder), and one who uses JAWS and leaves it off so >>> far. I'll mail you details privately. >> >> Thanks, any data appreciated >> >> Abbreviation expansion is not our only problem. Screenreaders can also be >> set up to read *all* title attributes - read tool tips and expand >> abbreviations settings are orthogonal. With tool tips reading turned on >> users get the full datetime read out when they float their mouse over the >> abbreviation. Anecdotally this seems to be a far more common configuration >> for partially sited users. >>> >>> Interestingly, I think your "what about people with cognitive problems >>> getting confused?" point might be of more real-world importance, but >>> since people cognitive problems are not as powerful politically they >>> probably aren't a problem for you. >> >> Don't want to sound prickly here but our intentions are strictly honourable. >> We're not doing this to pick holes with microformats or tick bbc boxes or >> avoid being sued. We're just a bunch of developers trying to do 'the right >> thing'. Whether people with cognitive problems are politically powerful or >> not if they can't use our site we're doing something wrong. >> >> >> http://www.bbc.co.uk/ >> This e-mail (and any attachments) is confidential and may contain personal >> views which are not the views of the BBC unless specifically stated. >> If you have received it in error, please delete it from your system. >> Do not use, copy or disclose the information in any way nor act in reliance >> on it and notify the sender immediately. >> Please note that the BBC monitors e-mails sent or received. >> Further communication will signify your consent to this. >> >> _______________________________________________ >> microformats-discuss mailing list >> microformats-discuss@microformats.org >> http://microformats.org/mailman/listinfo/microformats-discuss >> > > http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. From mail at tobyinkster.co.uk Thu May 29 05:01:33 2008 From: mail at tobyinkster.co.uk (Toby Inkster) Date: Thu May 29 06:20:30 2008 Subject: [uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds] Message-ID: <64653.81.2.120.180.1212062493.squirrel@goddamn.co.uk> Two example pages: Page 1

Entry 1

Content.

Page 2

Entry 2

Content.

As I understand the semantics of next/prev, they indicate links to separate resources - not a continuation of the current resource. i.e. These pages represent two separate feeds, each of which contains a single entry. The reason some XFN parsers will recurse to rel="me next" and rel="me prev" links is not the next/prev relations, but rel="me" -- they can spider rel="me" links (presumably constrained to a particular depth limit) and consolidate the information into a single unified profile. -Toby From andr3.pt at gmail.com Thu May 29 07:46:20 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Thu May 29 09:38:30 2008 Subject: [uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds] In-Reply-To: <64653.81.2.120.180.1212062493.squirrel@goddamn.co.uk> References: <64653.81.2.120.180.1212062493.squirrel@goddamn.co.uk> Message-ID: Oh, I see. Thanks for clearing that up Toby. Still, do you see any way of tieing two hFeeds on separate pages together? Any way at all? I'm thiking in terms of data portability... If the service X doesn't provide an EXPORT your data but marks up content with hAtom, some parser could export all the archive by following that feed through multiple pages. -- Andr? On Thu, May 29, 2008 at 1:01 PM, Toby Inkster wrote: > Two example pages: > > > Page 1 > > >
>

Entry 1

>

Content.

>
> > > > > Page 2 > > >
>

Entry 2

>

Content.

>
> > > > As I understand the semantics of next/prev, they indicate links to > separate resources - not a continuation of the current resource. i.e. > These pages represent two separate feeds, each of which contains a single > entry. > > The reason some XFN parsers will recurse to rel="me next" and rel="me > prev" links is not the next/prev relations, but rel="me" -- they can > spider rel="me" links (presumably constrained to a particular depth limit) > and consolidate the information into a single unified profile. > > -Toby > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From mail at tobyinkster.co.uk Thu May 29 12:41:56 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Thu May 29 13:20:31 2008 Subject: [uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds] Message-ID: <67040F8D-8ACC-487A-A21F-0368AB64B177@tobyinkster.co.uk> Andr? Lu?s wrote: > Still, do you see any way of tieing two hFeeds on separate pages > together? Any way at all? The best way that I can come up with involves a slight extension to hAtom. The current hAtom spec only covers a subset of the full Atom spec. In particular, to cover feed consolidation, you'd want to implement in hAtom an equivalent to the element in Atom. Because class="id" or rel="id" look a bit confusing (confusion with the "id" attribute) I'd suggest: rel="feed-id" rel="entry-id" rel="entry-id" isn't really needed for this task, but if you're in a situation where the same entry could appear on several pages, then it may be useful. The feed assigns a unique ID (in the form of a URI) to a feed. If two hAtom feeds have the same ID, it should be safe to assume that they're different HTML representations of the same underlying logical feed. Going back to my original examples, this could become: Page 1

Entry 1

Content.

Page 2

Entry 2

Content.

OK, that solves part of the problem - a way of determining if two hAtom pages represent the same underlying feed. However, given that these pages may be on "opposite sides of the Internet", to consolidate the feed we need a way of finding them. For this, I'd suggest using rel="meta", an existing rel value which is used to link to additional metadata. Because rel="meta" is often used to link to RDF files, it may be helpful to RDF parsers to explicitly include the "type" attribute. Adding all this to the mix gives us: Page 1

Entry 1

Content.

Page 2

Entry 2

Content.

What do other people think? -- Toby A Inkster From lunaticsunblog at gmail.com Thu May 29 18:18:55 2008 From: lunaticsunblog at gmail.com (Zhang Zhen) Date: Thu May 29 18:19:00 2008 Subject: [uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds] In-Reply-To: <67040F8D-8ACC-487A-A21F-0368AB64B177@tobyinkster.co.uk> References: <67040F8D-8ACC-487A-A21F-0368AB64B177@tobyinkster.co.uk> Message-ID: <1f10388d0805291818k44e5416ds5f406bd4f2f88200@mail.gmail.com> 2008/5/30 Toby A Inkster : > What do other people think? When root element hfeed is missing, it is assumed to be the *document* In the following example when hfeed is missing Page 1

Entry 1

Content.

Page 2

Entry 2

Content.

rel="next" is a relationship between two documents, as well as *between two hfeed*. -- Zhang, Zhen http://www.lunaticsun.com ( in Chinese only ) From mail at tobyinkster.co.uk Fri May 30 01:09:12 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri May 30 01:09:35 2008 Subject: [uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds] Message-ID: Zhang Zhen wrote: > rel="next" is a relationship between two documents, as well as > *between two hfeed*. Yes, but rel="next" is a relationship between two documents, as well as between *two hfeeds*. ;-) -- Toby A Inkster From andr3.pt at gmail.com Fri May 30 07:14:10 2008 From: andr3.pt at gmail.com (=?ISO-8859-1?Q?Andr=E9_Lu=EDs?=) Date: Fri May 30 07:20:44 2008 Subject: [uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds] In-Reply-To: References: Message-ID: Toby, wasn't that what Zhang said? or did you just move the emphasis? :P I was trying to come up with some situations where people would put a to the next page within a document with an hAtom feed and NOT want to mean the next page (linked in the ) is also the next page of hatom. I couldn't. I think it makes sense to allow the inclusion of an A/LINK element with rel="next" inside the hAtom feed. If someone doesn't want to be considered for the hatom feed, just declare explicit the hFeed and leave the outside. If you want to declare the hfeed explicitly and you want to indicate the next page, put an inside of it. Using the ID to identify a feed doesn't sound too bad either... but I like the simplicity of the solution of linking hfeeds through rel="next"/rev="prev". (Also, should we take this discussion to uf-new as someone suggested? don't want to disturb the subscribers of uf-discuss ;) ) On Fri, May 30, 2008 at 9:09 AM, Toby A Inkster wrote: > > Zhang Zhen wrote: > >> rel="next" is a relationship between two documents, as well as >> *between two hfeed*. > > Yes, but rel="next" is a relationship between two documents, as well as between *two hfeeds*. ;-) > > -- > Toby A Inkster > > > > > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss From mail at tobyinkster.co.uk Fri May 30 09:40:33 2008 From: mail at tobyinkster.co.uk (Toby A Inkster) Date: Fri May 30 10:20:34 2008 Subject: [uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds] Message-ID: <6996B835-AFD1-4BBF-A846-EBE4C1DBC7F3@tobyinkster.co.uk> > Toby, wasn't that what Zhang said? or did you just move the > emphasis? :P Yes, the emphasis -- that rel=next/prev indicates relationships between *two* hAtom feeds. > I was trying to come up with some situations where people would put a > to the next page within a document with an hAtom feed and NOT > want to mean the next page (linked in the ) is also the next > page of hatom. I couldn't. I don't currently use hAtom on my site, out of concern for accessibility and the datetime pattern. However, imagine that I were to use hAtom to mark up the comments on my blog. Now, my blog articles include links to the next/prev articles in the side bar, marked up with rel=next/prev. I wouldn't want the hAtom comment feed for an article to automatically include comments from the next and previous articles! Each article has a separate comment feed -- rel=next/prev shouldn't join them together. > I think it makes sense to allow the inclusion of an A/LINK element > with rel="next" inside the hAtom feed. If someone doesn't want rel="next"> to be considered for the hatom feed, just declare explicit > the hFeed and leave the outside. Indeed, but rel=next/prev should indicate the next and previous feeds, not a continuation of the current feed. This would be more in line with the current meaning of rel=next/prev which indicate the next and previous pages in a sequence -- not a continuation of the current resource intended to be rendered as a single page. -- Toby A Inkster From lunaticsunblog at gmail.com Fri May 30 16:57:58 2008 From: lunaticsunblog at gmail.com (Zhang Zhen) Date: Fri May 30 16:58:02 2008 Subject: [uf-discuss] Next/Prev [was Rationale for providing hAtom instead of Atom/RSS feeds] In-Reply-To: <6996B835-AFD1-4BBF-A846-EBE4C1DBC7F3@tobyinkster.co.uk> References: <6996B835-AFD1-4BBF-A846-EBE4C1DBC7F3@tobyinkster.co.uk> Message-ID: <1f10388d0805301657o5da86d42o631f712b7f090716@mail.gmail.com> 2008/5/31 Toby A Inkster : > Yes, the emphasis -- that rel=next/prev indicates relationships between > *two* hAtom feeds. > Indeed, but rel=next/prev should indicate the next and previous feeds, not a > continuation of the current feed. This would be more in line with the > current meaning of rel=next/prev which indicate the next and previous pages > in a sequence -- not a continuation of the current resource intended to be > rendered as a single page. This is exactly what I want to say. They are two feeds but not seperated. And it would be a bad idea if the parser render all the related feeds on a single page, it'd be disturbing to render something user CANNOT see on the page. Corresponding pagination would be better. -- Zhang, Zhen http://www.lunaticsun.com ( in Chinese only )