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 (sinc