From lists at iandavis.com Tue May 1 01:01:13 2007 From: lists at iandavis.com (Ian Davis) Date: Tue May 1 01:02:46 2007 Subject: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?) In-Reply-To: References: Message-ID: <4636F3C9.6060503@iandavis.com> On 01/05/2007 07:26, Tantek ?elik wrote: > It's been tried by numerous groups, before microformats, and after. It's > even been tried in the context of RSS and RDF, and in practice people write > scrapers that look for namespace prefixes as if they are part of the element > name, not as mere shorthands for namespace URIs. Isn't this a narrow view of namespaces, i.e. the XML viewpoint. There are many types of non-URI/QName namespacing mechanisms such as Java package name conventions, Perl module conventions etc. Are those offtopic too? > > If you want to carry on a theoretical discussion of namespaces, please do so > elsewhere, for in practice, discussing them is a waste of time, and > off-topic for microformats lists. Apologies for this post. If the answer to the above is yes then this will be the last from me on this topic. Ian From absalom at iinet.net.au Tue May 1 01:29:20 2007 From: absalom at iinet.net.au (Absalom Media) Date: Tue May 1 01:29:34 2007 Subject: [uf-discuss] Re: changing abbr-design-pattern to title-design-pattern? Message-ID: <4636FA60.6050905@iinet.net.au> Jon wrote: > To comment on the redundant span test-case... > A cursory test of that in context on absalom.biz using IE 7 resulted in > JAWS behaving strangely. I intend to test this more, but my observations > are as follows: > > JAWS wasn't reading out the title attribute in place of the element's > content (a human-readable date) when set to expand abbreviations. > Probing the element information (Ins+Shift+F1) didn't report a title > attribute on the element. After restarting JAWS and IE 7, the > not-so-nice ISO date in the title attribute was read out in place of the > human-readable date. The question then becomes why does it require a restart to negotiate to the ISO date ? Caveats: My JAWS testing has been Firefox 2 and IE6 based. I set it to read the entire document as a first pass, then focus on the content surrounding the date time elements and just let it repeat itself ad naseum. > The discrepancy seems to have indicated a false positive - the > human-readable date was heard when expecting the title expansion to be > spoken in its place. Both the redundant span and the abbreviation element itself have the same ISO date as title. > I figure it might be something to do with the sIFR in use on the page > tested on absalom.biz, as it was causing other issues when reading past > the

just above the microformatted date. It could be something to do > with using the redundant span, but it's unlikely. Interesting. I've had no trouble with JAWS 8, IE6 and sIFR. Could IE7 be to blame? Thanks Lawrence Meckan PS. Apologies for the UTF post previously. Webmail went a little leftfield. -- Lawrence Meckan Absalom Media Mob: (04) 1047 9633 ABN: 49 286 495 792 http://www.absalom.biz -- Lawrence Meckan Absalom Media Mob: (04) 1047 9633 ABN: 49 286 495 792 http://www.absalom.biz From tim at pollenation.net Tue May 1 01:46:08 2007 From: tim at pollenation.net (Tim Parkin) Date: Tue May 1 01:46:16 2007 Subject: [uf-discuss] Re: namespaces discussions off-topic In-Reply-To: <4636F3C9.6060503@iandavis.com> References: <4636F3C9.6060503@iandavis.com> Message-ID: <4636FE50.5090302@pollenation.net> Ian Davis wrote: > On 01/05/2007 07:26, Tantek ?elik wrote: >> It's been tried by numerous groups, before microformats, and after. It's >> even been tried in the context of RSS and RDF, and in practice people >> write >> scrapers that look for namespace prefixes as if they are part of the >> element >> name, not as mere shorthands for namespace URIs. > > Isn't this a narrow view of namespaces, i.e. the XML viewpoint. There > are many types of non-URI/QName namespacing mechanisms such as Java > package name conventions, Perl module conventions etc. Are those > offtopic too? > It would help to clarify the wiki page on namespacing as it seems to cover xml formal namespaces rather than namespacing by convention (to avoid name collision - my worry with the classnames like 'logo' for instance). I'm only an mf newb but I'm hoping my perspective may be useful. Tim Parkin From dotjay at november5th.net Tue May 1 01:52:41 2007 From: dotjay at november5th.net (Jon Gibbins (dotjay)) Date: Tue May 1 01:52:40 2007 Subject: [uf-discuss] changing abbr-design-pattern to title-design-pattern? In-Reply-To: References: Message-ID: <4636FFD9.5070805@november5th.net> Tantek ?elik wrote: > On 4/30/07 5:20 PM, "Jon Gibbins (dotjay)" wrote: > >> DD Month >> >> I'm guessing not, due to invalid characters. > > Worse, it hides data in the *rel* attribute which is an anti-design-pattern, > as is putting data in the *class* attribute. Both of these are designed for > limited sets of terms/properties, not for data values. Putting data in > 'rel' or 'class' is a non-starter. As I guessed, rel is only irrelevant for links anyway, so that's no use. Didn't intend to dredge up namespaces if it's already been discussed here and dismissed. My thoughts were really geared towards leveraging the very fact that the datetime data *is* hidden in an attribute using this method or a similar method. While I understand that a key-value pair is expected and desirable, an ISO formatted datetime is not meant for general human consumption - just for ?ber geeks like us. Devising such a mechanism for microformats would surely prove useful? >> An alternative would be to reference a unique meta element in the >> document head. > > Also bad - requiring access to head is a non-starter (many content scenarios > forbid head access). And meta, being both invisible and detached from > inline content, is ill suited for storing any informantion that has *any* > chance of being updated. I guess if we've got microformatted content in a feed, we don't have a head to refer to - good point. Detached is one thing, but you're yet to convince me on the visibility part. Jon -- gr0w.com dotjay.co.uk From dotjay at november5th.net Tue May 1 02:22:34 2007 From: dotjay at november5th.net (Jon Gibbins (dotjay)) Date: Tue May 1 02:22:33 2007 Subject: [uf-discuss] Re: changing abbr-design-pattern to title-design-pattern? In-Reply-To: <4636FA60.6050905@iinet.net.au> References: <4636FA60.6050905@iinet.net.au> Message-ID: <463706DA.3050706@november5th.net> Absalom Media wrote: > Jon wrote: >> To comment on the redundant span test-case... >> A cursory test of that in context on absalom.biz using IE 7 resulted in >> JAWS behaving strangely. I intend to test this more, but my observations >> are as follows: >> >> JAWS wasn't reading out the title attribute in place of the element's >> content (a human-readable date) when set to expand abbreviations. >> Probing the element information (Ins+Shift+F1) didn't report a title >> attribute on the element. After restarting JAWS and IE 7, the >> not-so-nice ISO date in the title attribute was read out in place of the >> human-readable date. > > The question then becomes why does it require a restart to negotiate to > the ISO date ? Hi Lawrence, It wasn't that I needed to restart to apply the settings in JAWS, rather that is required a restart for JAWS to refresh its model of the page I think. The verbose settings were applied, but JAWS could not extract the title attribute from your page. >> I figure it might be something to do with the sIFR in use on the page >> tested on absalom.biz, as it was causing other issues when reading past >> the

just above the microformatted date. It could be something to do >> with using the redundant span, but it's unlikely. > > Interesting. I've had no trouble with JAWS 8, IE6 and sIFR. Could IE7 be > to blame? Admittedly, my test with JAWS 8.0 and IE 6 worked far better than with IE 7, so yes, I do think the odd behaviour could be restricted to IE 7. However, when testing with IE 6 and JAWS set to announce expanded abbreviations, the non-human-friendly ISO date was read out as in my previous testing. If you are setting JAWS 8.0 to expand abbreviations and browsing with IE 6, I cannot explain this discrepancy. If you use JAWS 7.10 to test, however, there is a bug with the verbosity settings that means abbreviations are not actually expanded. The setting is effectively ignored. Jon -- gr0w.com dotjay.co.uk From dan at revish.com Tue May 1 02:22:23 2007 From: dan at revish.com (Dan Champion) Date: Tue May 1 02:22:36 2007 Subject: [uf-discuss] changing abbr-design-pattern to title-design-pattern? In-Reply-To: <4636FFD9.5070805@november5th.net> References: <4636FFD9.5070805@november5th.net> Message-ID: <463706CF.70403@revish.com> Jon Gibbins (dotjay) wrote: > Tantek ?elik wrote: >> On 4/30/07 5:20 PM, "Jon Gibbins (dotjay)" >> wrote: >> >>> DD >>> Month >>> >>> An alternative would be to reference a unique meta element in the >>> document head. >> >> Also bad - requiring access to head is a non-starter (many content >> scenarios >> forbid head access). And meta, being both invisible and detached from >> inline content, is ill suited for storing any informantion that has >> *any* >> chance of being updated. > > I guess if we've got microformatted content in a feed, we don't have a > head to refer to - good point. Detached is one thing, but you're yet > to convince me on the visibility part. If the aim is to retain the data in the body, yet render it invisible to all users, including those of assistive technologies, what about using a comment as the data container: DD Month This may be totally off the mark and considered a hack, but comments are markup and are parseable. Dan From dotjay at november5th.net Tue May 1 02:31:11 2007 From: dotjay at november5th.net (Jon Gibbins (dotjay)) Date: Tue May 1 02:31:08 2007 Subject: [uf-discuss] changing abbr-design-pattern to title-design-pattern? In-Reply-To: <463706CF.70403@revish.com> References: <4636FFD9.5070805@november5th.net> <463706CF.70403@revish.com> Message-ID: <463708DF.2020601@november5th.net> Dan Champion wrote: > If the aim is to retain the data in the body, yet render it invisible to > all users, including those of assistive technologies, what about using a > comment as the data container: > > DD Month > > This may be totally off the mark and considered a hack, but comments are > markup and are parseable. As I've mentioned, I would provide context to the datetime in some way, but it's not a bad suggestion in my view: DD Month Would there be specific difficulties with parsing something like this to extract the microformat data? Jon -- gr0w.com dotjay.co.uk From absalom at iinet.net.au Tue May 1 03:15:40 2007 From: absalom at iinet.net.au (Absalom Media) Date: Tue May 1 03:15:43 2007 Subject: [uf-discuss] Re: changing abbr-design-pattern to title-design-pattern? Message-ID: <4637134C.3070703@iinet.net.au> More investigative notes on the 'spacer gif'/IE6 hack solution for the date time design pattern: Markup is as follows: Monday, 30 April 2007 I've now got audio and text captures for Firevox and JAWS 8. I've also confirmed the siFR "effect" and diagnosed that JAWS spits the dumy due to some wonderful Javascript that's CMS dependent, not siFR dependent (Note to self: fix that.. soon) I set up JAWS to the letter (screen capture on Flickr for reference material sake) in terms of what Jon was looking for. http://www.flickr.com/photos/absalomedia/479697317/ The only thing I haven't done is turn "speak alphanumeric data" on (without phonetics) in any capacity. This begs the question: Would the combination of "speak alphanumeric data" and "expand abbreviations" produce the output seen by Jon, and explain why all results thus far (JAWS set at advanced verbosity and expanding abbreviations) give a different result ? Thanks Lawrence -- Lawrence Meckan Absalom Media Mob: (04) 1047 9633 ABN: 49 286 495 792 http://www.absalom.biz From gfraser at adaptavist.com Tue May 1 03:52:37 2007 From: gfraser at adaptavist.com (Guy Fraser) Date: Tue May 1 03:52:45 2007 Subject: Fwd: [uf-discuss] Legal implications of using Microformats In-Reply-To: <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> References: <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> Message-ID: <46371BF5.3070108@adaptavist.com> Joe Andrieu wrote: > My apologies to those who may be earnestly trying to come up with a viable solutions. If you are out there, please give us a report > on where things stand. > Our company has decided to avoid microformats.org like the plague for now as we feel something fishy is going on. The licensing/patenting/copyright/ownership issues are as blatant as the attempts to brush discussions about them under the carpet. This thread on the list would be an ideal place for such issues to be discussed and cleared up, but as usual - silence. One has no choice but to assume the worst. We also note that the requirement for all submissions to be fully researched is a common requirement for patent application. Guy From dotjay at november5th.net Tue May 1 03:55:56 2007 From: dotjay at november5th.net (Jon Gibbins (dotjay)) Date: Tue May 1 03:55:54 2007 Subject: JAWS abbr expansion discrepancy (was Re: [uf-discuss] Re: changing abbr-design-pattern to title-design-pattern?) In-Reply-To: <4637134C.3070703@iinet.net.au> References: <4637134C.3070703@iinet.net.au> Message-ID: <46371CBC.7090504@november5th.net> Absalom Media wrote: > I've also confirmed the siFR "effect" and diagnosed that JAWS spits the > dumy due to some wonderful Javascript that's CMS dependent, not siFR > dependent (Note to self: fix that.. soon) I suggest that you use a clean test page for these tests to minimise interference of such elements. > I set up JAWS to the letter (screen capture on Flickr for reference > material sake) in terms of what Jon was looking for. > http://www.flickr.com/photos/absalomedia/479697317/ > > The only thing I haven't done is turn "speak alphanumeric data" on > (without phonetics) in any capacity. This begs the question: > > Would the combination of "speak alphanumeric data" and "expand > abbreviations" produce the output seen by Jon, and explain why all > results thus far (JAWS set at advanced verbosity and expanding > abbreviations) give a different result ? I have "Spell alphanumeric data" switched off and get the same results as I did before (JAWS 8.0 / IE 6 / XP). For some reason, it seems like your set-up is just refusing to read the title attribute. Have you tried running a secondary test over a normal abbreviation like this: ISO With "expand abbreviations" set on, you should hear the expansion in place of the abbreviation. I've reset JAWS to my default config file, tested again and observe the same results as before. I've deleted my config files in enu*, tested again and observe the same results. Lawrence: Suggest you and I continue to investigate this off-list and report back when we can identify why we're observing different results. * Like a hard reset for JAWS config: http://www.freedomscientific.com/fs_support/BulletinView.cfm?QC=868 Jon -- gr0w.com dotjay.co.uk From tantek at cs.stanford.edu Tue May 1 08:01:30 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue May 1 08:01:21 2007 Subject: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?) In-Reply-To: <4636F3C9.6060503@iandavis.com> Message-ID: On 5/1/07 1:01 AM, "Ian Davis" wrote: > On 01/05/2007 07:26, Tantek ?elik wrote: >> It's been tried by numerous groups, before microformats, and after. It's >> even been tried in the context of RSS and RDF, and in practice people write >> scrapers that look for namespace prefixes as if they are part of the element >> name, not as mere shorthands for namespace URIs. > > Isn't this a narrow view of namespaces, i.e. the XML viewpoint. There > are many types of non-URI/QName namespacing mechanisms such as Java > package name conventions, Perl module conventions etc. Are those > offtopic too? This is why I precisely said (in the paragraph that was not quoted), with emphasis added: "Namespaced **content** on the Web has failed." AFAIK, Java package name conventions, Perl module conventions are *not* considered *content* that is served on the web. They're code. And they're not served, they're executed server-side. Namespaced **content** has failed because it encourages proprietary siloization of data, rather than interoperability. Namespaces perform a very different function in code (with different needs), despite the cosmetic similarities (use of ":" etc.). >> If you want to carry on a theoretical discussion of namespaces, please do so >> elsewhere, for in practice, discussing them is a waste of time, and >> off-topic for microformats lists. > > Apologies for this post. If the answer to the above is yes then this > will be the last from me on this topic. Why would a discussion of namespaced *code* be *on* topic? How is it relevant to microformats? At a minimum, it would be more appropriate for the microformats-dev list than the microformats-discuss list, but even then I fail to see how it is germane to the domain. Tantek From costello at mitre.org Tue May 1 08:12:22 2007 From: costello at mitre.org (Costello, Roger L.) Date: Tue May 1 08:12:26 2007 Subject: [uf-discuss] User Interface for Firefox/Operator In-Reply-To: References: <84ce626f0704271424t15e1b98bufdef1284868a280@mail.gmail.com> Message-ID: Hey Mike, Here's my "wish list" for Operator: 1. Suppose a web page has multiple geo Microformats. The Operator "Find a Google Map" currently allows only a mashup of one geo Microformat at a time with Google Maps. I would like an option that would display all the geo Microformats simultaneously. For example, a web page that shows the route of an airplane may have a geo Microformat for each waypoint. I would like to be able to view on Google Maps all the waypoints simultaneously. 2. Suppose the geo Microformat is part of an hCard. The "Find a Google Map" currently only shows the lat/lon values on the Google Map. It would be nice if Operator would scoop up some of the other information in the hCard, such as name and address, and display it on the Google Map. 3. An XHTML document is an XML document. Operator recognizes Microformats in XHTML XML documents, but not other XML documents. For example, here is an XML document that has an embedded hCard: Waldorf-Astoria 301 Park Ave. New York NY 10022 I would like to see Operator able to recognize Microformats in any XML document, not just XHTML XML documents. /Roger From tantek at cs.stanford.edu Tue May 1 08:17:30 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue May 1 08:17:20 2007 Subject: [uf-discuss] global editorial changes to the wiki - please avoid, and blocking Message-ID: Folks, Two individuals have recently made global editorial changes to the wiki which are far from optimal, were not even proposed before executed, and thus are tantamount to damage or an attack on the wiki. Unfortunately, that leaves me no choice but to immediately block both users until the admins can decide how to proceed. I'm hoping that this issue will be clarified in a matter of *hours* and that both blocks will be released when clarification is communicated, and various pages, e.g. "how-to-play" are updated accordingly. I apologize for the summary blocking without warning, but it is unfortunately the required response to summary global editing of the wiki without warning. Thanks, Tnatek From tantek at cs.stanford.edu Tue May 1 08:25:30 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue May 1 08:25:21 2007 Subject: [uf-discuss] Re: namespaces discussions off-topic In-Reply-To: <4636FE50.5090302@pollenation.net> Message-ID: On 5/1/07 1:46 AM, "Tim Parkin" wrote: > Ian Davis wrote: >> On 01/05/2007 07:26, Tantek ?elik wrote: >>> It's been tried by numerous groups, before microformats, and after. It's >>> even been tried in the context of RSS and RDF, and in practice people >>> write >>> scrapers that look for namespace prefixes as if they are part of the >>> element >>> name, not as mere shorthands for namespace URIs. >> >> Isn't this a narrow view of namespaces, i.e. the XML viewpoint. There >> are many types of non-URI/QName namespacing mechanisms such as Java >> package name conventions, Perl module conventions etc. Are those >> offtopic too? >> > > It would help to clarify the wiki page on namespacing as it seems to > cover xml formal namespaces rather than namespacing by convention (to > avoid name collision - my worry with the classnames like 'logo' for > instance). I'm only an mf newb but I'm hoping my perspective may be useful. It's not just formal XML namespacing, but rather any namespacing of content. However, there is a differnce between a *code* class of logo, and a *content* HTML class name of logo. I've added a sentence to the top of namespaces-considered-harmful to point out the distinction of content vs. code. Tantek From supercanadian at gmail.com Tue May 1 09:03:15 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Tue May 1 09:03:19 2007 Subject: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?) In-Reply-To: References: <4636F3C9.6060503@iandavis.com> Message-ID: <84ce626f0705010903x13e8ae19i74bd53b14246080a@mail.gmail.com> Hello Tantek, I think Ian may have meant... what about using (for Microformats) namespaces with pre-defined (and never changing) namespace prefixes (like in Java and Perl), instead of variable namespace prefixes (like in XML). See ya On 5/1/07, Tantek ?elik wrote: > On 5/1/07 1:01 AM, "Ian Davis" wrote: > > > On 01/05/2007 07:26, Tantek ?elik wrote: > >> It's been tried by numerous groups, before microformats, and after. It's > >> even been tried in the context of RSS and RDF, and in practice people write > >> scrapers that look for namespace prefixes as if they are part of the element > >> name, not as mere shorthands for namespace URIs. > > > > Isn't this a narrow view of namespaces, i.e. the XML viewpoint. There > > are many types of non-URI/QName namespacing mechanisms such as Java > > package name conventions, Perl module conventions etc. Are those > > offtopic too? > > This is why I precisely said (in the paragraph that was not quoted), with > emphasis added: > > "Namespaced **content** on the Web has failed." > > AFAIK, Java package name conventions, Perl module conventions are *not* > considered *content* that is served on the web. They're code. And they're > not served, they're executed server-side. > > Namespaced **content** has failed because it encourages proprietary > siloization of data, rather than interoperability. Namespaces perform a > very different function in code (with different needs), despite the cosmetic > similarities (use of ":" etc.). > > > >> If you want to carry on a theoretical discussion of namespaces, please do so > >> elsewhere, for in practice, discussing them is a waste of time, and > >> off-topic for microformats lists. > > > > Apologies for this post. If the answer to the above is yes then this > > will be the last from me on this topic. > > Why would a discussion of namespaced *code* be *on* topic? How is it > relevant to microformats? At a minimum, it would be more appropriate for > the microformats-dev list than the microformats-discuss list, but even then > I fail to see how it is germane to the domain. > > Tantek -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ From redux at splintered.co.uk Tue May 1 09:47:53 2007 From: redux at splintered.co.uk (Patrick H. Lauke) Date: Tue May 1 09:47:59 2007 Subject: [uf-discuss] hyperlink include-pattern - keyboard issue Message-ID: <46376F39.4070207@splintered.co.uk> I edited the page on the wiki, but thought I'd bring it up here as well http://microformats.org/wiki/include-pattern-feedback#Hyperlink_Include_-_issues_for_keyboard_users_.28including_Screen_Reader_users.29 "Although invisible in visual user agents, and (according to the JAWS 7.0 test below) not spoken by screen readers (at least not by JAWS 7.0), empty links are still contained in the normal tab cycle. Users navigating via keyboard (or equivalent, e.g. switch access, puff/blow devices, etc) will still need to tab through the empty links (tested in Firefox 2.0, IE 6, IE 7; Opera 9.2 seems to remove empty links from tab cycle). This can be verified by modifying the test page below, adding a regular link at the end of the 5 variations of empty links. It takes a user 6 tabs to arrive at the "real" link. It would therefore be advisable to rethink the approach, or scrap it completely." P -- Patrick H. Lauke ______________________________________________________________ re?dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ______________________________________________________________ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ ______________________________________________________________ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ ______________________________________________________________ From tantek at cs.stanford.edu Tue May 1 10:22:43 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue May 1 10:22:33 2007 Subject: [uf-discuss] hyperlink include-pattern - keyboard issue In-Reply-To: <46376F39.4070207@splintered.co.uk> Message-ID: On 5/1/07 9:47 AM, "Patrick H. Lauke" wrote: > It would therefore be advisable to > rethink the approach, Alternatives to the current include-pattern solutions, along with comparisons with existing techniques, are encouraged. > or scrap it completely. Currently it is the best we have, and the benefits (being able to markup content with shared chunks with microformats) greatly outweigh the costs. Microformats tends to take a positive attitude of developing and using the best techniques we can come up with, rather than banning/blocking techniques for reasons of fear or cost. To scrap something, there must be a better alternative provided which addresses the same problem(s) at least as well, with lower costs. Tantek From tantek at cs.stanford.edu Tue May 1 10:24:43 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue May 1 10:24:33 2007 Subject: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?) In-Reply-To: <84ce626f0705010903x13e8ae19i74bd53b14246080a@mail.gmail.com> Message-ID: On 5/1/07 9:03 AM, "Charles Iliya Krempeaux" wrote: > Hello Tantek, > > I think Ian may have meant... what about using (for Microformats) > namespaces with pre-defined (and never changing) namespace prefixes > (like in Java and Perl), instead of variable namespace prefixes (like > in XML). Even fixed namespace prefixes on content have the siloization/balkanization effects and are thus undesirable. Tantek From brian.suda at gmail.com Tue May 1 10:25:42 2007 From: brian.suda at gmail.com (Brian Suda) Date: Tue May 1 10:25:45 2007 Subject: Fwd: [uf-discuss] Legal implications of using Microformats In-Reply-To: <46371BF5.3070108@adaptavist.com> References: <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> <46371BF5.3070108@adaptavist.com> Message-ID: <21e770780705011025q63db32c2mef93d06d1d967cab@mail.gmail.com> On 5/1/07, Guy Fraser wrote: > Joe Andrieu wrote: > > My apologies to those who may be earnestly trying to come up with a viable solutions. If you are out there, please give us a report > > on where things stand. > > > > Our company has decided to avoid microformats.org like the plague for > now as we feel something fishy is going on. The > licensing/patenting/copyright/ownership issues are as blatant as the > attempts to brush discussions about them under the carpet. This thread > on the list would be an ideal place for such issues to be discussed and > cleared up, but as usual - silence. One has no choice but to assume the > worst. We also note that the requirement for all submissions to be fully > researched is a common requirement for patent application. --- i'm sorry you feel that way. Sometimes threads don't get much of a discussion because:1) people don't have any opinion 2) they are not lawyers 3) they don't have an issue with the topic 4) the signal-to-noise prevents people from reading all messages 5) we are all volunteers and can't reply right away. As one of the authors of the hCard and hCalendar specs, i personally have no intention of doing anything sneaky or under-handed. I'm sorry you feel that you need to "avoid microformats like the plague" they are one of the simplest things to add and back-out if there are issues. I would always assume the best, and if things get bad, then we as a community can take-up these issues. Rather than taking the negative approach, how about we take this thread and talk about constructive criticisms to make things better. I'm not a lawyer (nor do i play one on TV), so i can't give you the exact advice or suggestions about what you want, but i'm sure someone in the community can further explain some of the hang-ups. I know some are on the wiki already, but like i said - it is not my field of expertise. I keep going back to how companies like Microsoft and Yahoo have decided to use microformats, if they thought there were problems, they would have been the first to complain. Lets talk about what/if any changes could be made to make things more clear. I'm certainly up for clarifying things, as an author, i'm not trying to hide or do something sneaky. -brian -- brian suda http://suda.co.uk From microformats at kaply.com Tue May 1 10:58:03 2007 From: microformats at kaply.com (Mike Kaply) Date: Tue May 1 10:58:05 2007 Subject: [uf-discuss] User Interface for Firefox/Operator In-Reply-To: References: <84ce626f0704271424t15e1b98bufdef1284868a280@mail.gmail.com> Message-ID: Thanks Roger, I really want feedback like this! On 5/1/07, Costello, Roger L. wrote: > Hey Mike, > > Here's my "wish list" for Operator: > > 1. Suppose a web page has multiple geo Microformats. The Operator > "Find a Google Map" currently allows only a mashup of one geo > Microformat at a time with Google Maps. I would like an option that > would display all the geo Microformats simultaneously. For example, a > web page that shows the route of an airplane may have a geo Microformat > for each waypoint. I would like to be able to view on Google Maps all > the waypoints simultaneously. I'm pretty sure to do this, I'd have to have a website somewhere that accepted the points and displayed the page. Google Maps right now has no way to display multiple points at the same time from just a URL. Suggestions welcome. > 2. Suppose the geo Microformat is part of an hCard. The "Find a Google > Map" currently only shows the lat/lon values on the Google Map. It > would be nice if Operator would scoop up some of the other information > in the hCard, such as name and address, and display it on the Google > Map. The hCard also has a "Find with google maps". So you could use the address as well. Honestly, this is one of the things that always confused my about geo. How often to you need a geo vs an address? I understand if you are in the middle of the desert... > 3. An XHTML document is an XML document. Operator recognizes > Microformats in XHTML XML documents, but not other XML documents. For > example, here is an XML document that has an embedded hCard: > > > > Waldorf-Astoria > > 301 Park Ave. > New York > NY > 10022 > > > > I would like to see Operator able to recognize Microformats in any XML > document, not just XHTML XML documents. I think this one should be straightforward to fix.... Thanks! Mike From andy at pigsonthewing.org.uk Tue May 1 11:21:28 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue May 1 11:22:58 2007 Subject: [uf-discuss] global editorial changes to the wiki - please avoid, and blocking In-Reply-To: References: Message-ID: In message , Tantek ?elik writes >Two individuals have recently made global editorial changes to the wiki >which are far from optimal, were not even proposed before executed, and >thus are tantamount to damage or an attack on the wiki. I'm one of those editors; and once again this smacks of being an arbitrary, heavy-handed and unjust over-reaction. And to describe my edits as "tantamount to damage or an attack on the wiki" is utterly unacceptable. I made a total of just *twenty* edits today. One was to redirect the previously non-existent: to: Two were to redirect the previously non-existent: (as the former had over 300 other pages pointing to it). One removed two red links from the "main" page: All of the remaining 16 were (as clearly stated in edit summaries) to remove redundant red links (some of which had existed since 2005, and others for over a year), such as those to: /hbib /boom /microshow /microshow-parsing /hHistoricalCurrency /video-metadata-models (plus some *-fr equivalents; one of those edits also corrected some typos) This being, supposedly, a wiki, any of those links is easily reinstated. >Unfortunately, that leaves me no choice but to immediately block both >users No; you had *lots* of choices, and made a decision - please take responsibility for your own actions. >until the admins can decide how to proceed. Presumably, this means that discussion is taking place - and decisions being made - on the invitation-only admin mailing list, rather than openly and in public? Has recent discussion of "governance" issues changed nothing? Your edit summary when blocking me was: blocked "User:AndyMabbett" with an expiry time of 24 hours: global wiki edits outside of community policies/expectations without discussion Please explain: 1) What is a "global wiki edit" and how my edits meet that criteria. 2) The community policy(ies) contravened by my edits, and where on et wiki or else where they can be found. 3) How, if there was no discussion, you know that the edits were "outside community expectations". Or are your actions carried out without need for justification? You have previously threatened to ban me from this mailing list for discussing "meta" issues. I note that you have raised a meta issue here; and denied me access to the only alternative forum (the wiki) where I an able to raise them. [...] >I apologize for the summary blocking without warning, but it is >unfortunately the required response to summary global editing of the >wiki without warning. Apology not accepted; your response was not "required". -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From jcraig at apple.com Tue May 1 11:26:47 2007 From: jcraig at apple.com (James Craig) Date: Tue May 1 11:26:49 2007 Subject: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?) In-Reply-To: References: Message-ID: <49EABF2E-3C92-4291-9597-535AA1FF84BE@apple.com> Tantek ?elik wrote: > If you want to carry on a theoretical discussion of namespaces, > please do so > elsewhere, for in practice, discussing them is a waste of time, and > off-topic for microformats lists. Namespacing is not off-topic for Microformats. Note the hAudio proposal. http://microformats.org/wiki/grouping-brainstorming#Option_. 233:_Explicit_class-based_grouping
From andy at pigsonthewing.org.uk Tue May 1 11:26:38 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue May 1 11:28:23 2007 Subject: [uf-discuss] abbr debate and Accessify In-Reply-To: References: <97BFC6D4-8CB9-4B34-8CFF-A0AA536011D5@adactio.com> <21e770780704290744l6ea75a7bn4cc26888e1fe4230@mail.gmail.com> Message-ID: <07jXnMxeZ4NGFwun@pigsonthewing.org.uk> In message , Andy Mabbett writes >Note also that this issue was discussed previously And raised when the DTI, an arm of the UK government, rejected hCalendar: as noted in November last year: Nobody can say that we haven't tried to raise these issues already. It's both telling, and sad, that it took a high-profile embarrassment to generate a response. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Tue May 1 11:29:04 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue May 1 11:29:12 2007 Subject: Fwd: [uf-discuss] Legal implications of using Microformats In-Reply-To: <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> References: <46322354.6020409@digitalbazaar.com> <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> Message-ID: <4boUf2xwb4NGFwtw@pigsonthewing.org.uk> In message <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome>, Joe Andrieu writes >Having the IP in an ambiguous state is a mess. Each editing screen on the 'wiki' has, below the edit box: Please note that all contributions to Microformats may be edited, altered, or removed by other contributors. If you don't want your writing to be edited mercilessly, then don't submit it here. You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see Project:Copyrights for details). It's telling that the "Project:Copyrights" link is to a page which has yet to be created. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From lists at iandavis.com Tue May 1 11:30:47 2007 From: lists at iandavis.com (Ian Davis) Date: Tue May 1 11:31:05 2007 Subject: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?) In-Reply-To: <84ce626f0705010903x13e8ae19i74bd53b14246080a@mail.gmail.com> References: <4636F3C9.6060503@iandavis.com> <84ce626f0705010903x13e8ae19i74bd53b14246080a@mail.gmail.com> Message-ID: <46378757.2040608@iandavis.com> On 01/05/2007 17:03, Charles Iliya Krempeaux wrote: > Hello Tantek, > > I think Ian may have meant... what about using (for Microformats) > namespaces with pre-defined (and never changing) namespace prefixes > (like in Java and Perl), instead of variable namespace prefixes (like > in XML). > Yes. Of course I understand the distinction between code and content. But I suggested Java and Perl practices as illustrations of conventions for namespacing things. I'm interested in looking at patterns of naming that may allow more decentralised collaboration. Ian From andy at pigsonthewing.org.uk Tue May 1 11:31:40 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue May 1 11:33:15 2007 Subject: [uf-discuss] hyperlink include-pattern - keyboard issue In-Reply-To: References: <46376F39.4070207@splintered.co.uk> Message-ID: In message , Tantek ?elik writes >On 5/1/07 9:47 AM, "Patrick H. Lauke" wrote: > >> It would therefore be advisable to >> rethink the approach, >> or scrap it completely. >Microformats tends to take a positive attitude of developing and using >the best techniques we can come up with, rather than banning/blocking >techniques for reasons of fear or cost. Nobody was suggesting scrapping anything "for reasons of fear or cost" (leastways, not financial cost - there may certainly be said to be a practical "cost" to people using assistive technologies). -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Tue May 1 11:35:10 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue May 1 11:36:39 2007 Subject: [uf-discuss] changing abbr-design-pattern to title-design-pattern? In-Reply-To: <463706CF.70403@revish.com> References: <4636FFD9.5070805@november5th.net> <463706CF.70403@revish.com> Message-ID: In message <463706CF.70403@revish.com>, Dan Champion writes >If the aim is to retain the data in the body, yet render it invisible >to all users, including those of assistive technologies, what about >using a comment as the data container: > >DD Month > >This may be totally off the mark and considered a hack, but comments >are markup and are parseable. I'd been thinking about that, too, but, sadly, there is no guarantee that comments will be available to a parser - some CMSs (not least Wikipedia) remove them from the output HTML; as (I've read) do some web proxies, particularly those which compress pages for use on mobile devices or slow connections. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From redux at splintered.co.uk Tue May 1 11:38:19 2007 From: redux at splintered.co.uk (Patrick H. Lauke) Date: Tue May 1 11:38:22 2007 Subject: [uf-discuss] hyperlink include-pattern - keyboard issue In-Reply-To: References: <46376F39.4070207@splintered.co.uk> Message-ID: <4637891B.1080700@splintered.co.uk> Andy Mabbett wrote: > Nobody was suggesting scrapping anything "for reasons of fear or cost" > (leastways, not financial cost - there may certainly be said to be a > practical "cost" to people using assistive technologies). Not even limited to assistive technology. This affects all users without screen reader who just happen to use a keyboard (or equivalent), rather than a mouse, for navigation, in some of the major current browsers. P -- Patrick H. Lauke ______________________________________________________________ re?dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ______________________________________________________________ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ ______________________________________________________________ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ ______________________________________________________________ From ernest.prabhakar at gmail.com Tue May 1 11:57:23 2007 From: ernest.prabhakar at gmail.com (Dr. Ernie Prabhakar) Date: Tue May 1 11:57:29 2007 Subject: [uf-discuss] Legal implications of using Microformats In-Reply-To: <4boUf2xwb4NGFwtw@pigsonthewing.org.uk> References: <46322354.6020409@digitalbazaar.com> <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> <4boUf2xwb4NGFwtw@pigsonthewing.org.uk> Message-ID: <3DC2911B-C9CF-4A26-8B1A-DE023032BD57@gmail.com> Hi all, On May 1, 2007, at 11:29 AM, Andy Mabbett wrote: > It's telling that the "Project:Copyrights" link is to a page which > has yet to be created. Yeah, that's pretty embarrassing. Can anyone comment on whether the edit blurb is inaccurate, or someone just forgot to create the Copyright? -- Ernie P. From ernest.prabhakar at gmail.com Tue May 1 11:59:51 2007 From: ernest.prabhakar at gmail.com (Dr. Ernie Prabhakar) Date: Tue May 1 12:00:04 2007 Subject: [uf-discuss] global editorial changes to the wiki - please avoid, and blocking In-Reply-To: References: Message-ID: Hi Tantek, On May 1, 2007, at 8:17 AM, Tantek ?elik wrote: > I apologize for the summary blocking without warning, but it is > unfortunately the required response to summary global editing of > the wiki > without warning. I appreciate that these are difficult decisions to make, and that you at times need to make seemingly arbitrary decisions to protect the health of the community. However, while I appreciate the need to keep things as lightweight and agile as possible, I really do think it would be healthier if we some minimal but clear guidelines for what constituted appropriate behavior, so that you didn't need to act "summarily." Since this is clearly off-topic, I would love to hear what others think (either pro or con) on the wiki page: http://microformats.org/wiki/governance-issues#Petition Thanks, -- Ernie p. From tim at pollenation.net Tue May 1 12:03:10 2007 From: tim at pollenation.net (Tim Parkin) Date: Tue May 1 12:03:20 2007 Subject: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?) In-Reply-To: <46378757.2040608@iandavis.com> References: <4636F3C9.6060503@iandavis.com> <84ce626f0705010903x13e8ae19i74bd53b14246080a@mail.gmail.com> <46378757.2040608@iandavis.com> Message-ID: <46378EEE.9070808@pollenation.net> Ian Davis wrote: > On 01/05/2007 17:03, Charles Iliya Krempeaux wrote: >> Hello Tantek, >> >> I think Ian may have meant... what about using (for Microformats) >> namespaces with pre-defined (and never changing) namespace prefixes >> (like in Java and Perl), instead of variable namespace prefixes (like >> in XML). >> > > Yes. Of course I understand the distinction between code and content. > But I suggested Java and Perl practices as illustrations of conventions > for namespacing things. I'm interested in looking at patterns of naming > that may allow more decentralised collaboration. > I would also be good to ressurect the page called NamespacesChickenLittling, of which I can see no trace but is referred to in "vote-links-faq" i.e. "For followup Q&A about VoteLinks and namespaces, see NamespacesChickenLittling". this could probably cover the hAudio namespace useage also. Tim p.s. I'm not sure namespaces can be said to have failed when http://microformats.org has two of them.. From paul_wilkins at xtra.co.nz Tue May 1 12:10:55 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Tue May 1 12:10:58 2007 Subject: Fwd: [uf-discuss] Legal implications of using Microformats In-Reply-To: <46371BF5.3070108@adaptavist.com> References: <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> <46371BF5.3070108@adaptavist.com> Message-ID: <463790BF.5090100@xtra.co.nz> Brian Suda wrote: > I keep going back to how companies like Microsoft and Yahoo have > decided to use microformats, if they thought there were problems, they > would have been the first to complain. > > Lets talk about what/if any changes could be made to make things more > clear. I'm certainly up for clarifying things, as an author, i'm not > trying to hide or do something sneaky. What kind of copyright or licensing things are involved with microformats? I would have thought that there were none, as microformats are just an advisory on how to markup text. I compare it with, "Hey, here's an idea. Use the address tag so people know who to get in touch with to edit the page." Does the way that geo tags are put together, . . . require any form of copyright or license? I would hope not. -- Paul Wilkins From tantek at cs.stanford.edu Tue May 1 12:18:37 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue May 1 12:18:38 2007 Subject: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?) In-Reply-To: <49EABF2E-3C92-4291-9597-535AA1FF84BE@apple.com> Message-ID: On 5/1/07 11:26 AM, "James Craig" wrote: > Tantek ?elik wrote: > >> If you want to carry on a theoretical discussion of namespaces, >> please do so >> elsewhere, for in practice, discussing them is a waste of time, and >> off-topic for microformats lists. > > Namespacing is not off-topic for Microformats. Note the hAudio proposal. > > http://microformats.org/wiki/grouping-brainstorming#Option_. > 233:_Explicit_class-based_grouping > >
>
That is sufficient reason to reject the proposal. Thanks for bringing it to the attention of the list. In addition, that markup example places content in the class attribute which is also unacceptable. Tantek From scott at randomchaos.com Tue May 1 13:10:47 2007 From: scott at randomchaos.com (Scott Reynen) Date: Tue May 1 13:11:00 2007 Subject: [uf-discuss] Legal implications of using Microformats In-Reply-To: <3DC2911B-C9CF-4A26-8B1A-DE023032BD57@gmail.com> References: <46322354.6020409@digitalbazaar.com> <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> <4boUf2xwb4NGFwtw@pigsonthewing.org.uk> <3DC2911B-C9CF-4A26-8B1A-DE023032BD57@gmail.com> Message-ID: <020714A7-CF56-4A5E-B800-B68D3130BF3E@randomchaos.com> On May 1, 2007, at 1:57 PM, Dr. Ernie Prabhakar wrote: >> It's telling that the "Project:Copyrights" link is to a page which >> has yet to be created. > > Yeah, that's pretty embarrassing. Can anyone comment on whether the > edit blurb is inaccurate, or someone just forgot to create the > Copyright? Considering the 14,000 Google results for that phrase [1], I suspect it's boilerplate from somewhere (perhaps the default pages in MediaWiki), and no one cared enough to change it. Pretty much everything about this community is focused on solving problems only after they are made incredibly obvious, so it doesn't surprise me at all that something like this isn't yet fixed. [1] http://www.google.com/search?q=%22You%20are%20also%20promising% 20us%20that%20you%20wrote%20this%20yourself,%20or%20%20copied%20it% 20from%20a%20public%20domain%20or%20similar%20free%20resource%22 -- Scott Reynen Web Developer sreynen@integermidwest.com 515.710.2725 From scott at randomchaos.com Tue May 1 13:39:16 2007 From: scott at randomchaos.com (Scott Reynen) Date: Tue May 1 13:39:28 2007 Subject: [uf-discuss] Legal implications of using Microformats In-Reply-To: <020714A7-CF56-4A5E-B800-B68D3130BF3E@randomchaos.com> References: <46322354.6020409@digitalbazaar.com> <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> <4boUf2xwb4NGFwtw@pigsonthewing.org.uk> <3DC2911B-C9CF-4A26-8B1A-DE023032BD57@gmail.com> <020714A7-CF56-4A5E-B800-B68D3130BF3E@randomchaos.com> Message-ID: <4D8F4E6A-99AB-421D-9567-A21F87760EB8@randomchaos.com> On May 1, 2007, at 3:10 PM, Scott Reynen wrote: > Pretty much everything about this community is focused on solving > problems only after they are made incredibly obvious, so it doesn't > surprise me at all that something like this isn't yet fixed. On re-reading that, I realized one might infer that I think it's a bad thing this community is focused on solving incredibly obvious problems. I actually think it's generally a good thing. Peace, Scott From sjhobson at gmail.com Tue May 1 14:12:10 2007 From: sjhobson at gmail.com (Stephanie Hobson) Date: Tue May 1 14:12:13 2007 Subject: Fwd: [uf-discuss] Legal implications of using Microformats In-Reply-To: <463790BF.5090100@xtra.co.nz> References: <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> <46371BF5.3070108@adaptavist.com> <463790BF.5090100@xtra.co.nz> Message-ID: > Brian Suda wrote: > > What kind of copyright or licensing things are involved with microformats? > > I would have thought that there were none, as microformats are just an > advisory on how to markup text. My thoughts exactly. Are Microformats not just semantic CSS and HTML? I have trouble believing that could be patented at all (not that I know anything about patents). The controversy around Ajax might be a useful comparison for this. Does anyone know the outcomes of attempts to patent it? -Stephanie. From jackw-uf at jounce.net Tue May 1 15:23:34 2007 From: jackw-uf at jounce.net (M. Jackson Wilkinson ) Date: Tue May 1 15:24:02 2007 Subject: Fwd: [uf-discuss] Legal implications of using Microformats In-Reply-To: <463790BF.5090100@xtra.co.nz> References: <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> <46371BF5.3070108@adaptavist.com> <463790BF.5090100@xtra.co.nz> Message-ID: <4637BDE6.6040606@jounce.net> Paul Wilkins wrote: > Brian Suda wrote: >> I keep going back to how companies like Microsoft and Yahoo have >> decided to use microformats, if they thought there were problems, they >> would have been the first to complain. >> >> Lets talk about what/if any changes could be made to make things more >> clear. I'm certainly up for clarifying things, as an author, i'm not >> trying to hide or do something sneaky. > > What kind of copyright or licensing things are involved with microformats? > > I would have thought that there were none, as microformats are just an > advisory on how to markup text. > > I compare it with, "Hey, here's an idea. Use the address tag so people > know who to get in touch with to edit the page." > > Does the way that geo tags are put together, > . . . > require any form of copyright or license? I would hope not. > NB: I am not a lawyer. I was an intellectual property paralegal in DC for a time, and this is based on my experience with that. This is not legal advice, yadda yadda ;) One might not think that these things would be subject to copyright (or, more dangerously, as a potential submarine patent threat), but specific strings of tags and such may be considered as unique as specific strings of words can be in verse and prose and advertising. I don't know the current caselaw in this area, but I would be surprised if there is much precedent to assuage fears that copyright could be claimed on pieces of microformats. And in the US, absence of a copyright notice assumes some copyright protections. You have to explicitly release your rights if you wish to do so. More dangerous is the patent side, which is much more friendly to algorithms, processes, and the like. These could ostensibly be considered such things, and get past a patent examiner and be granted a patent. If a patent were granted, then the holders could approach users of the now-patented "process" and hold them accountable for royalties and licensing fees. All of a sudden, anyone from Microsoft to your small business can be threatened with, at minimum, a long legal battle. This fear can be soothed fairly simply by releasing all work on the wiki into the public domain, or something of the sort. All wiki pages could be under the LGPL, the GDL, or some other open licenses if not in the public domain. There are several options here. The challenge now is that every editor of the wiki would, I believe, need to either approve of the change in license, or their work would need to be stripped out of the wiki. This kind of process has happened several times in open source software projects. The microformats wiki may be sufficiently young as to make this somewhat possible, but it would certainly involve significant effort. It's one of those things that really needs to be handled right at the beginning. Again, this is all just based on my personal experience and research, and is not legal advice, but may be useful as a way of understanding why some may be concerned. Best, Jackson -- M. Jackson Wilkinson http://jounce.net | mobile: 207.841.9103 Grassroots Enterprise | http://grassroots.com From andy at pigsonthewing.org.uk Tue May 1 15:23:01 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue May 1 15:24:14 2007 Subject: [uf-discuss] Legal implications of using Microformats In-Reply-To: <4D8F4E6A-99AB-421D-9567-A21F87760EB8@randomchaos.com> References: <46322354.6020409@digitalbazaar.com> <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> <4boUf2xwb4NGFwtw@pigsonthewing.org.uk> <3DC2911B-C9CF-4A26-8B1A-DE023032BD57@gmail.com> <020714A7-CF56-4A5E-B800-B68D3130BF3E@randomchaos.com> <4D8F4E6A-99AB-421D-9567-A21F87760EB8@randomchaos.com> Message-ID: In message <4D8F4E6A-99AB-421D-9567-A21F87760EB8@randomchaos.com>, Scott Reynen writes >On May 1, 2007, at 3:10 PM, Scott Reynen wrote: > >> Pretty much everything about this community is focused on solving >>problems only after they are made incredibly obvious, so it doesn't >>surprise me at all that something like this isn't yet fixed. > >On re-reading that, I realized one might infer that I think it's a bad >thing this community is focused on solving incredibly obvious >problems. I actually think it's generally a good thing. Solving incredibly obvious problems is indeed a good thing. Not solving problems /until/ they become *incredibly* obvious is a bad thing. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Tue May 1 15:51:25 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Tue May 1 15:52:32 2007 Subject: [uf-discuss] namespaces discussions off-topic In-Reply-To: References: <4636F3C9.6060503@iandavis.com> Message-ID: <3Mfnqj9tR8NGFwsd@pigsonthewing.org.uk> In message , Tantek ?elik writes >Namespaced **content** has failed because it encourages proprietary >siloization of data, rather than interoperability. Namespaces perform >a very different function in code (with different needs), despite the >cosmetic similarities (use of ":" etc.). I note that you've added a note to that effect, to the 'wiki': but that you've overlooked point 3 in !"how to play": If you write something opinionated, sign it with your username. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From tantek at cs.stanford.edu Tue May 1 16:59:40 2007 From: tantek at cs.stanford.edu (Tantek =?ISO-8859-1?B?xw==?=elik) Date: Tue May 1 16:59:49 2007 Subject: UPDATE: Re: [uf-discuss] global editorial changes to the wiki - please avoid, and blocking In-Reply-To: Message-ID: On 5/1/07 8:17 AM, "Tantek ?elik" wrote: > Folks, > > Two individuals have recently made global editorial changes to the wiki > which are far from optimal, were not even proposed before executed, and thus > are tantamount to damage or an attack on the wiki. Any (presumably unintended, or innocent) damage has been repaired AFAIK. In addition, beneficial edits among those done were marked "patrolled". > Unfortunately, that leaves me no choice but to immediately block both users > until the admins can decide how to proceed. I'm hoping that this issue will > be clarified in a matter of *hours* and that both blocks will be released > when clarification is communicated, and various pages, e.g. "how-to-play" > are updated accordingly. http://microformats.org/wiki/how-to-play updated with some hastily written guidelines. Clearly we are still figuring all this out, please take a look. > I apologize for the summary blocking without warning, but it is > unfortunately the required response to summary global editing of the wiki > without warning. AndyMabbett and Gazza, apologies for the inconvenience of the temporary blocking. Thanks very much for your patience. Blocks have been removed. Thanks, Tantek From ernest.prabhakar at gmail.com Tue May 1 17:11:04 2007 From: ernest.prabhakar at gmail.com (Dr. Ernie Prabhakar) Date: Tue May 1 17:11:14 2007 Subject: UPDATE: Re: [uf-discuss] global editorial changes to the wiki - please avoid, and blocking In-Reply-To: References: Message-ID: Hi Tantek, On May 1, 2007, at 4:59 PM, Tantek ?elik wrote: > AndyMabbett and Gazza, apologies for the inconvenience of the > temporary > blocking. Thanks very much for your patience. Blocks have been > removed. Wow, that was fast. Thanks for the quick resolution. Best wishes, -- Ernie P. From microformats at 200ok.com.au Tue May 1 21:07:33 2007 From: microformats at 200ok.com.au (Ben Buchanan) Date: Tue May 1 21:07:36 2007 Subject: [uf-discuss] Expanding the abbr pattern In-Reply-To: <4B40B18D-AB1D-4FF6-AB4F-80C288AF212B@adactio.com> References: <4B40B18D-AB1D-4FF6-AB4F-80C288AF212B@adactio.com> Message-ID: <6ca82b0f0705012107g4f01d5cehf8c52bf6be797c2@mail.gmail.com> Hi Jeremy, > I'd be interested in hearing other arguments for or against this idea. I think it's a humans vs. machines issue. To my mind, the ABBR element is there to provide additional information to the user (the human). In this case, it's being used to add a timestamp in a format that I've never heard a human use. To put it another way, it's not adding information for the user; it's adding data for the machine. IMHO the ABBR title should always enrich, explain or disambiguate the contents of the ABBR tag. Using a full-string timestamp doesn't do that (nor does geo data, to touch on a related problem). Although it's tremendously useful for uf parsing, I think it's trumped by the problems it causes for screen reader users. So, I'd be happy to see the title shifted to a span - still not entirely perfect I suppose, but it leaves ABBR to the humans :) cheers, Ben -- --- --- The future has arrived; it's just not --- evenly distributed. - William Gibson From mdagn at spraci.com Wed May 2 00:11:54 2007 From: mdagn at spraci.com (Michael MD) Date: Wed May 2 00:11:59 2007 Subject: [uf-discuss] User Interface for Firefox/Operator References: <84ce626f0704271424t15e1b98bufdef1284868a280@mail.gmail.com> Message-ID: <0f4101c78c89$2a989780$116bacca@COMCEN> > > 1. Suppose a web page has multiple geo Microformats. The Operator > "Find a Google Map" currently allows only a mashup of one geo > Microformat at a time with Google Maps. >I would like an option that > would display all the geo Microformats simultaneously. For example, a > web page that shows the route of an airplane may have a geo Microformat > for each waypoint. I would like to be able to view on Google Maps all > the waypoints simultaneously. sounds nice but wouldn't Google's requirement for an API key make this difficult? A single point could be shown by just creating a link to Google Maps but to show multiple points would probably mean creating a page in the browser using the Google Maps API. (Microsoft's map API might be easier - they seem to have less red tape associated with showing a map and putting stuff on it) From supercanadian at gmail.com Wed May 2 00:36:31 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Wed May 2 00:36:34 2007 Subject: [uf-discuss] User Interface for Firefox/Operator In-Reply-To: <0f4101c78c89$2a989780$116bacca@COMCEN> References: <84ce626f0704271424t15e1b98bufdef1284868a280@mail.gmail.com> <0f4101c78c89$2a989780$116bacca@COMCEN> Message-ID: <84ce626f0705020036n9562403k80945accca1e354e@mail.gmail.com> Hello Michael, I think Mozilla Corporation (the main backers of Firefox) have a special relation with Google. So, it's probably not so much of an issue. See ya On 5/2/07, Michael MD wrote: > > > > 1. Suppose a web page has multiple geo Microformats. The Operator > > "Find a Google Map" currently allows only a mashup of one geo > > Microformat at a time with Google Maps. > > >I would like an option that > > would display all the geo Microformats simultaneously. For example, a > > web page that shows the route of an airplane may have a geo Microformat > > for each waypoint. I would like to be able to view on Google Maps all > > the waypoints simultaneously. > > sounds nice but wouldn't Google's requirement for an API key make this > difficult? > > A single point could be shown by just creating a link to Google Maps but to > show multiple points would probably mean creating a page in the browser > using the Google Maps API. > (Microsoft's map API might be easier - they seem to have less red tape > associated with showing a map and putting stuff on it) -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ From andy at pigsonthewing.org.uk Wed May 2 00:36:06 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed May 2 00:37:25 2007 Subject: UPDATE: Re: [uf-discuss] global editorial changes to the wiki - please avoid, and blocking In-Reply-To: References: Message-ID: In message , Tantek ?elik writes >AndyMabbett and Gazza, apologies for the inconvenience of the temporary >blocking. Thanks very much for your patience. Blocks have been >removed. You appear to have not received; to have overlooked; or to have deliberately ignored my e-mail on the subject: Please answer it, on this mailing list. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Wed May 2 00:40:16 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed May 2 00:41:25 2007 Subject: [uf-discuss] User Interface for Firefox/Operator In-Reply-To: References: <84ce626f0704271424t15e1b98bufdef1284868a280@mail.gmail.com> Message-ID: In message , Mike Kaply writes >Thanks Roger, I really want feedback like this! > >On 5/1/07, Costello, Roger L. wrote: >> Hey Mike, >> >> Here's my "wish list" for Operator: >> >> 1. Suppose a web page has multiple geo Microformats. The Operator >> "Find a Google Map" currently allows only a mashup of one geo >> Microformat at a time with Google Maps. I would like an option that >> would display all the geo Microformats simultaneously. For example, a >> web page that shows the route of an airplane may have a geo Microformat >> for each waypoint. I would like to be able to view on Google Maps all >> the waypoints simultaneously. > >I'm pretty sure to do this, I'd have to have a website somewhere that >accepted the points and displayed the page. Google Maps right now has >no way to display multiple points at the same time from just a URL. >Suggestions welcome. Offer "Export as KML", so that people can achieve the same result, in Google Earth. Please also offer "Export as GPX", at the same time, so that people can also import waymarks into GPS devices, as discussed previously, and on the 'wiki'. >> 2. Suppose the geo Microformat is part of an hCard. The "Find a Google >> Map" currently only shows the lat/lon values on the Google Map. It >> would be nice if Operator would scoop up some of the other information >> in the hCard, such as name and address, and display it on the Google >> Map. > >The hCard also has a "Find with google maps". So you could use the >address as well. Honestly, this is one of the things that always >confused my about geo. How often to you need a geo vs an address? I >understand if you are in the middle of the desert... Physical features (bridges, road junctions, etc.) can have hCards with fn and geo, but no address. -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From mail at ciaranmcnulty.com Wed May 2 00:53:32 2007 From: mail at ciaranmcnulty.com (Ciaran McNulty) Date: Wed May 2 00:53:36 2007 Subject: [uf-discuss] changing abbr-design-pattern to title-design-pattern? In-Reply-To: References: <4636FFD9.5070805@november5th.net> <463706CF.70403@revish.com> Message-ID: On 5/1/07, Andy Mabbett wrote: > In message <463706CF.70403@revish.com>, Dan Champion > writes > >If the aim is to retain the data in the body, yet render it invisible > >to all users, including those of assistive technologies, what about > >using a comment as the data container: > I'd been thinking about that, too, but, sadly, there is no guarantee > that comments will be available to a parser - some CMSs (not least > Wikipedia) remove them from the output HTML; as (I've read) do some web > proxies, particularly those which compress pages for use on mobile > devices or slow connections. I concur, an HTML parser should be allowed to ignore comments, and many will. The similar decision to 'hide' Javascript and other scripting languages inside HTML comments has been widely criticised and is no longer considered best practice in a lot of places, for similar reasons. -Ciaran McNulty From joe at andrieu.net Wed May 2 01:20:21 2007 From: joe at andrieu.net (Joe Andrieu) Date: Wed May 2 01:20:23 2007 Subject: [uf-discuss] Expanding the abbr pattern In-Reply-To: <6ca82b0f0705012107g4f01d5cehf8c52bf6be797c2@mail.gmail.com> Message-ID: <002301c78c92$bae4f730$0201a8c0@andrieuhome> Ben Buchanan wrote: > Hi Jeremy, > > > I'd be interested in hearing other arguments for or against > this idea. > > I think it's a humans vs. machines issue. To my mind, the > ABBR element is there to provide additional information to > the user (the human). In this case, it's being used to add a > timestamp in a format that I've never heard a human use. To > put it another way, it's not adding information for the user; > it's adding data for the machine. > > IMHO the ABBR title should always enrich, explain or > disambiguate the contents of the ABBR tag. Using a > full-string timestamp doesn't do that (nor does geo data, to > touch on a related problem). Although it's tremendously > useful for uf parsing, I think it's trumped by the problems > it causes for screen reader users. Ben, So, I started this response thinking "How does a full-string timestamp /not/ disambiguate a March 2 date in the following?"
May 2nd
Example
May 2nd is ambiguous regarding the year of the event. The timestamp is not. I think there are compatibility problems with screen readers that may be more important, but a lack of disambiguation doesn't seem to be the issue. The fact that a human doesn't use an ISO timestamp is a bit beside the point as the title is an attribute of the tag, not content on the page. The title isn't displayed to the user. It is interpreted by the renderer and displayed or output in some fashion. The problem may be that current readers don't handle timestamps very well, but that's a reader problem (one that we would do well to resolve). As I discovered later, the fact that it is not the normal version as would be seen in running text, is a problem. For a decent rant on why ABBR is for machines and not people see http://www.smackthemouse.com/20040108 But then I read the article referred to in Jeremy's post [1] and realized ABBR pattern is neither valid nor necessary, even if convenient. And that article also gave several examples where the ABBR pattern isn't necessarily disambiguation, making my example moot. Tantek also wrote: > If you must have pixel-perfect rendering for your content/site in older browsers that > don't support abbr, and you need abbr-specific styling, then yes, a workaround is to > add a element as a styling hook for those older browsers. However we MUST NOT > compromise microformats for browsers that failed to implement *an entire HTML4 element*. So much for the 80/20 rule. According to the link provided in Jeremy's post [1], the ABBR pattern is not valid HTML 4, which is especially ironic given Tantek's commitment to HTML4 as the baseline for judging IE's behavior. Here's the quote from the Web Standards Project article [1], itself quoting the spec [2]: > The content of the ABBR and ACRONYM elements specifies the abbreviated expression > itself, as it would normally appear in running text. The title attribute of these > elements may be used to provide the full or expanded form of the expression. > (HTML 4, ABBR) > Unlike the ISO date format, the "full or expanded form" is intended to be human-readable. > Yes, machine-readable, but for the consumption of a human, and in this case, spoken > literally to a human. The Web Content Accessibility Guidelines (WCAG) explicitly defines > the expansion of abbreviations as an accessibility advantage, and the most popular screen > readers do so. So, ABBR is unsupported in IE6 (without jumping through hoops to use special scripts). ABBR timestamps are problematic in leading screen readers. And ABBR timestamps violate the HTML 4 spec. How did it actually get adopted as a pattern for uF? Or more specifically, is there any way to fix that mistake? I would say we should at least avoid extending it into new areas, until and unless a formal standard body endorses a viable solution and that solution reaches viable 80/20 market share. The status of HTML5 and XHTML 2 are not worth getting into, but suffice to say such a trigger is likely to be far into the future. However, I do like Jeremy's suggestion for best-practices on the ABBR: > Would everyone agree that, for the sake of screen reader users, we > should update the wiki to strongly encourage this more verbose > version of datetimes and strongly discourage the contracted version? If we are going to continue to support a non-compliant use of ABBR, we may as well advocate a version of it that is more friendly to existing screen readers. That would also require updating the vCalendar Creator. Cheers, -j [1] http://www.webstandards.org/2007/04/27/haccessibility/ [2] http://www.w3.org/TR/html4/struct/text.html#edef-ABBR -- Joe Andrieu SwitchBook Software http://www.switchbook.com joe@switchbook.com +1 (805) 705-8651 From evan at prodromou.name Wed May 2 06:21:02 2007 From: evan at prodromou.name (Evan Prodromou) Date: Wed May 2 06:21:05 2007 Subject: [uf-discuss] RecentChangesCamp Montreal ("RoCoCoCamp"), 18-20 May 2007 Message-ID: <1178112062.27822.17.camel@zhora> Hello, all! I'm writing to let ?F folks know about this upcoming event. Some of you have already received personal invitations, but I wanted to send a broadcast for all the people I don't know personally. RecentChangesCamp is the international unconference for wiki developers, users, theorists and practitioners. It's been held for the last two years in Portland, OR; this year we're having it in Montreal, over the weekend of 18-20 May. http://www.recentchangescamp.org/ http://www.rocococamp.info/ There aren't scheduled speakers, keynotes, or panels -- as an "un-conference", the emphasis is on peer-to-peer communications, hands-on development, productive face-to-face meetings. The event is free of charge for all participants. I'm extending this personal invitation to microformats advocates for two reasons. First, there will be an opportunity to talk about ?Fs with project leads for some of the most important wiki software. Second, microformats are the only open standard I know of developed using a wiki; this is a practical experience that I think more wiki practitioners should know about. Registration is as simple as signing up on our wiki: http://www.rocococamp.info/Participants We've made some travel arrangements for out-of-town visitors; there's more info on the wiki. Feel free to email me off-list if you have any questions. Thanks, -Evan ________________________________________________________________________ Evan Prodromou http://evan.prodromou.name/ From msporny at digitalbazaar.com Wed May 2 07:36:20 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed May 2 07:36:23 2007 Subject: [uf-discuss] Legal implications of using Microformats In-Reply-To: <4637BDE6.6040606@jounce.net> References: <001601c78ba0$9f05e3a0$2cfa030a@andrieuhome> <46371BF5.3070108@adaptavist.com> <463790BF.5090100@xtra.co.nz> <4637BDE6.6040606@jounce.net> Message-ID: <4638A1E4.9070405@digitalbazaar.com> M. Jackson Wilkinson wrote: > If a patent were granted, then the holders could approach users of the > now-patented "process" and hold them accountable for royalties and > licensing fees. All of a sudden, anyone from Microsoft to your small > business can be threatened with, at minimum, a long legal battle. Exactly the point - the Microformats community is not doing enough to protect the implementors of their technology. > This fear can be soothed fairly simply by releasing all work on the wiki > into the public domain, or something of the sort. All wiki pages could > be under the LGPL, the GDL, or some other open licenses if not in the > public domain. There are several options here. Right on the money, again. > The challenge now is that every editor of the wiki would, I believe, > need to either approve of the change in license, or their work would > need to be stripped out of the wiki. This kind of process has happened > several times in open source software projects. The microformats wiki > may be sufficiently young as to make this somewhat possible, but it > would certainly involve significant effort. > > It's one of those things that really needs to be handled right at the > beginning. Another brilliant statement! Deal with the problem now while it is manageable - or later, when there are going to be multi-million dollar lawsuits being bandied about. The Microformats community WILL be blamed for not performing proper due diligence before placing their standards online. > Again, this is all just based on my personal experience and research, > and is not legal advice, but may be useful as a way of understanding why > some may be concerned. The reason this issue was raised was because we have authored and filed several patents and know what we are talking about regarding the dangers of submarine patents. If you want an "official" letter from a legal firm specializing in copyright and patent law, stating how tenuous the Microformats community's copyright and patent policy is - we could arrange that. However, it is going to cost us a sizeable chunk of change and we wanted to make sure that the community was listening before we went out and arranged to have that happen. -- manu -- Manu Sporny President/CEO, Digital Bazaar, Inc. http://blog.digitalbazaar.com/ From costello at mitre.org Wed May 2 10:18:28 2007 From: costello at mitre.org (Costello, Roger L.) Date: Wed May 2 10:18:38 2007 Subject: [uf-discuss] Migrating from Custom XML to XHTML to (XHTML + Microformats) Message-ID: Hi Folks, I have written a short wiki article describing how an information design may evolve from custom XML tags, to XHTML tags, to XHTML + Microformats: http://www.xfront-wiki.com/wiki/index.php?title=Alternative_Information _Designs Comments are welcome. /Roger From brian.suda at gmail.com Wed May 2 10:59:23 2007 From: brian.suda at gmail.com (Brian Suda) Date: Wed May 2 10:59:25 2007 Subject: [uf-discuss] Migrating from Custom XML to XHTML to (XHTML + Microformats) In-Reply-To: References: Message-ID: <21e770780705021059q7b03d4ccj186ea29e7e18c86c@mail.gmail.com> On 5/2/07, Costello, Roger L. wrote: > Hi Folks, > > I have written a short wiki article describing how an information > design may evolve from custom XML tags, to XHTML tags, to XHTML + > Microformats: > > http://www.xfront-wiki.com/wiki/index.php?title=Alternative_Information > _Designs --- excellent, glad to see it is a wiki where anyone can edit. I encouage you to add the information to the microformats wiki as well. Awhile ago i wrote some XSLT code to convert any XML into XOXO. http://suda.co.uk/projects/microformats/xoxo/ http://suda.co.uk/projects/microformats/xoxo/xml2xoxo.xsl (i hope it still works, it has been awhile). When converting the XML into XHTML if it is converted to XOXO as well, then XOXO aware apps and libraries can internalise the data into arrays easily. You should have an example for XOXO output as well. if you have any specific question about implementations and code to do this you should consider asking the dev list as well. -brian -- brian suda http://suda.co.uk From andy at pigsonthewing.org.uk Wed May 2 11:56:11 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed May 2 11:57:43 2007 Subject: [uf-discuss] microshow Message-ID: Two of my recent edits, soon reverted by Tantek, were to remove a red link, under the heading "see also" to from: and from: The red link was to: /microshow and had existed since 15/ 16 December 2005 - over 16 months ago The page: was created at the same time as those red links: but was deleted by Tantek less than one hour later: with the edit summary: deleted "microshow": 1. This is a shell page. 2. It is based on a premature *-brainstorming page. 3. It ignores existing media-metadata work. Tantek then noted, on both "/show-brainstroimng" and "/showroll-brainstorming": This page has been prematurely created ... Any microformat about a show, or video, or tv should be worked on within the context of media-metadata-examples, rather than creating new pages for it. I can find no other reference to "microshow" on IRC or the WIki. It was briefly discussed in this December 2005 mailing list thread: in which Tantek commented: I also noticed this: http://microformats.org/wiki/microshow [...] Please do not create a microformat page for something for which there isn't even a strawman specification in the *-brainstorming page. Shell pages like this one will be deleted.. Can anyone tell me why these red links should remain on the Wiki? What information do they convey, and what purpose do they serve, other than inviting and enticing people to create "/microshow", apparently outside the beloved "process"? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From andy at pigsonthewing.org.uk Wed May 2 11:58:09 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Wed May 2 11:59:41 2007 Subject: [uf-discuss] video-metadata-models Message-ID: <3zXXlRHB9NOGFwnv@pigsonthewing.org.uk> Two of my recent edits, soon reverted by Tantek, were to remove red links to: /video-metadata-models from: plus the French equivalents. The original red link had existed since December 2005 - over 16 months ago. There are no other "/video-metadata-* pages on the wiki, and no other "*-models" pages that I can find. "/video" redirects to: <>http://microformats.org/wiki/podcasts> which appears unrelated to the above. I can find no reference to "video-metadata-models" in the IRC or mailing list logs, and the page appears to have never existed. Can anyone tell me why these red links should remain on the Wiki? What information do they convey, and what purpose do they serve, other than inviting and enticing people to create "/video-metadata-models" and "/ video-metadata-models-fr", apparently outside the "process"? -- Andy Mabbett * Say "NO!" to compulsory ID Cards: * Free Our Data: * Are you using Microformats, yet: ? From msporny at digitalbazaar.com Wed May 2 12:41:29 2007 From: msporny at digitalbazaar.com (Manu Sporny) Date: Wed May 2 12:41:32 2007 Subject: [uf-discuss] video-metadata-models In-Reply-To: <3zXXlRHB9NOGFwnv@pigsonthewing.org.uk> References: <3zXXlRHB9NOGFwnv@pigsonthewing.org.uk> Message-ID: <4638E969.3010807@digitalbazaar.com> Andy Mabbett wrote: > /video-metadata-models > /microshow That's incredibly strange - both of these links appear under the "Related" and "See Also" sections of those pages. Should red-link items be placed under each of those sections? There isn't anything at the end of the links to "relate" to or "see"? The media-info examples page is the only one that is current. I see no reason to keep blank pages attached to abandoned/out-of-date initiatives around, especially since these red links are over 2 years old. Especially since there is no information that is being destroyed. -- manu From tim at pollenation.net Wed May 2 13:20:17 2007 From: tim at pollenation.net (Tim Parkin) Date: Wed May 2 13:20:31 2007 Subject: [uf-discuss] human readable date parsing Message-ID: <4638F281.1080703@pollenation.net> With all of the discussion about iso dates being unreadable and that an iso date isn't necessarily required when someone enters a date (i.e. saying 24th June doesn't translate into a single date, neither does 'thursday'). Shouldn't the focus be on trying to standardise date formats rather than trying to hide the iso date? If we can get a parser to recognise 'human readable' dates (which *is* possible, if not totally easy, http://labix.org/python-dateutil for a python version). Just a thought... Tim -- Tim Parkin, Pollenation Internet Ltd, Leeds, UK From jcraig at apple.com Wed May 2 13:56:54 2007 From: jcraig at apple.com (James Craig) Date: Wed May 2 13:57:21 2007 Subject: [uf-discuss] human readable date parsing In-Reply-To: <4638F281.1080703@pollenation.net> References: <4638F281.1080703@pollenation.net> Message-ID: <32BF40E6-6CE0-41B2-BF66-B7D4F0357743@apple.com> Tim Parkin wrote: > With all of the discussion about iso dates being unreadable and > that an > iso date isn't necessarily required when someone enters a date (i.e. > saying 24th June doesn't translate into a single date, neither does > 'thursday'). Shouldn't the focus be on trying to standardise date > formats rather than trying to hide the iso date? If we can get a > parser > to recognise 'human readable' dates (which *is* possible, if not > totally > easy, http://labix.org/python-dateutil for a python version). I disagree. If you try to make other, human readable formats into a standard, they will fall short when it comes time to internationaliz (s)e it. If you can come up with a better format readable to all machine and all humans in all languages, I'll recant. I think the ISO 8601 is the best machine data format for the job. I just don't think it should be in abbr. James From paul_wilkins at xtra.co.nz Wed May 2 14:37:25 2007 From: paul_wilkins at xtra.co.nz (Paul Wilkins) Date: Wed May 2 14:37:30 2007 Subject: [uf-discuss] human readable date parsing References: <4638F281.1080703@pollenation.net> <32BF40E6-6CE0-41B2-BF66-B7D4F0357743@apple.com> Message-ID: <003801c78d02$13a9e1e0$bc08a8c0@nzto22> From: "James Craig" To: "Microformats Discuss" Sent: Thursday, May 03, 2007 8:56 AM Subject: Re: [uf-discuss] human readable date parsing > Tim Parkin wrote: > >> With all of the discussion about iso dates being unreadable and that an >> iso date isn't necessarily required when someone enters a date (i.e. >> saying 24th June doesn't translate into a single date, neither does >> 'thursday'). Shouldn't the focus be on trying to standardise date >> formats rather than trying to hide the iso date? If we can get a parser >> to recognise 'human readable' dates (which *is* possible, if not totally >> easy, http://labix.org/python-dateutil for a python version). > > I disagree. If you try to make other, human readable formats into a > standard, they will fall short when it comes time to internationaliz (s)e > it. If you can come up with a better format readable to all machine and > all humans in all languages, I'll recant. > > I think the ISO 8601 is the best machine data format for the job. I just > don't think it should be in abbr. So as machine-readable information shouldn't be presented in a human-readable manner, that rules out having the information in-the-clear, and in title tags. This leads us to having a hidden class for machine-readable information that will be hidden by default and not presented to people. A class with a suitable name would have to be used, something like the existing "value" but modified to infer that it's for the computer only and isn't to be read. What if the value class was to be used with a hidden class. Then they would serve their purpose, they wouldn't interfere with existing styles and could be interpreted correctly. .hidden {display: hidden} Then the human-readable and machine-readable can be mashed together. If the screen-reading software honor hidden styles this could be the right path to take. Friday the 13th -- Paul Wilkins From redux at splintered.co.uk Wed May 2 14:58:39 2007 From: redux at splintered.co.uk (Patrick H. Lauke) Date: Wed May 2 14:58:41 2007 Subject: [uf-discuss] human readable date parsing In-Reply-To: <003801c78d02$13a9e1e0$bc08a8c0@nzto22> References: <4638F281.1080703@pollenation.net> <32BF40E6-6CE0-41B2-BF66-B7D4F0357743@apple.com> <003801c78d02$13a9e1e0$bc08a8c0@nzto22> Message-ID: <4639098F.1030500@splintered.co.uk> Paul Wilkins wrote: > What if the value class was to be used with a hidden class. Then they > would serve their purpose, they wouldn't interfere with existing styles > and could be interpreted correctly. > > .hidden {display: hidden} > > Then the human-readable and machine-readable can be mashed together. If > the screen-reading software honor hidden styles this could be the right > path to take. That would still render the machine-readable part in the clear on platforms with incomplete or missing support for CSS, such as some current mobile devices. Also, it feels conceptually wrong to have machine-readable stuff sprinkled into what should just be content. Note that, based on current practice adopted by screen readers, only TITLE on ABBR is explicitly being given status as "human-readable". "The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression." http://www.w3.org/TR/html401/struct/text.html#edef-ABBR So, although the spec tempers this with a "may", it does suggest this kind of use by screen readers. "Values of the title attribute may be rendered by user agents in a variety of ways. [...] For example, setting the attribute on a link allows user agents (visual and non-visual) to tell users about the nature of the linked resource:" http://www.w3.org/TR/html401/struct/global.html#adef-title There's a "may" here as well, but the generic definition for title (which could then be used on something like a span) seems far more lax to me, and in that respect more suited to be plied/bent for microformat data use. IMHO, of course. P -- Patrick H. Lauke ______________________________________________________________ re?dux (adj.): brought back; returned. used postpositively [latin : re-, re- + dux, leader; see duke.] www.splintered.co.uk | www.photographia.co.uk http://redux.deviantart.com ______________________________________________________________ Co-lead, Web Standards Project (WaSP) Accessibility Task Force http://webstandards.org/ ______________________________________________________________ Take it to the streets ... join the WaSP Street Team http://streetteam.webstandards.org/ ______________________________________________________________ From tim at pollenation.net Wed May 2 15:21:52 2007 From: tim at pollenation.net (Tim Parkin) Date: Wed May 2 15:22:03 2007 Subject: [uf-discuss] human readable date parsing In-Reply-To: <32BF40E6-6CE0-41B2-BF66-B7D4F0357743@apple.com> References: <4638F281.1080703@pollenation.net> <32BF40E6-6CE0-41B2-BF66-B7D4F0357743@apple.com> Message-ID: <46390F00.2010205@pollenation.net> James Craig wrote: > Tim Parkin wrote: > >> With all of the discussion about iso dates being unreadable and that an >> iso date isn't necessarily required when someone enters a date (i.e. >> saying 24th June doesn't translate into a single date, neither does >> 'thursday'). Shouldn't the focus be on trying to standardise date >> formats rather than trying to hide the iso date? If we can get a parser >> to recognise 'human readable' dates (which *is* possible, if not totally >> easy, http://labix.org/python-dateutil for a python version). > > I disagree. If you try to make other, human readable formats into a > standard, they will fall short when it comes time to internationaliz(s)e > it. If you can come up with a better format readable to all machine and > all humans in all languages, I'll recant. > > I think the ISO 8601 is the best machine data format for the job. I just > don't think it should be in abbr. > Yes, indeed.. And I was wrong to say "shouldn't the focus be".. I was just approaching the problem from a different angle to see if it looked more tractable, not from this angle obviously :-) In the vein of approaching things from a totally different angle, how about using hidden input field for the value? (I realise there are many problems with this but it might be worth documenting some of the negatives for future reference - I'm happy to start by saying Visual Developers propensity to formify the whole page could cause issues.. but then again VD may just be an issue in itself). Tim From microformats at gr0w.com Wed May 2 15:46:59 2007 From: microformats at gr0w.com (Jon Tan) Date: Wed May 2 15:47:04 2007 Subject: [uf-discuss] human readable date parsing In-Reply-To: <32BF40E6-6CE0-41B2-BF66-B7D4F0357743@apple.com> References: <4638F281.1080703@pollenation.net> <32BF40E6-6CE0-41B2-BF66-B7D4F0357743@apple.com> Message-ID: <463914E3.8020301@gr0w.com> James Craig wrote: > Tim Parkin wrote: > >> [...] Shouldn't the focus be on trying to standardise date >> formats rather than trying to hide the iso date? If we can get a parser >> to recognise 'human readable' dates (which *is* possible, if not totally >> easy, http://labix.org/python-dateutil for a python version). > > I disagree. If you try to make other, human readable formats into a > standard, they will fall short when it comes time to > internationaliz(s)e it. If you can come up with a better format > readable to all machine and all humans in all languages, I'll recant. > > I think the ISO 8601 is the best machine data format for the job. I > just don't think it should be in abbr. Agreed, James. ISO 8601 is the best format. There may be an option to have a space in the notation between the date and time thus removing the "T" [1],[2]. E.g: 2007-05-20 12:34 This is read by JAWS 8.0 in IE6 and IE7 as "two thousand seven dash zero five dash twenty twelve thirty-four" (via Jon Gibbins [3]). However, RFC 3339 [4] or W3C Date and Time format note [5] doesn't feature a space in the available examples. The issue for me is we're trying to fit a machine readable date in to a human readable form. All users (whether visually impaired or not) still need to know the format or learn it as they have to learn every interface element at first contact. No matter what the notation is, it will always be fairly ambiguous. Prepending the value still seems to me to be worthy of consideration in order to provide context and help users to learn the notation in a some way. After first coming across it, at least screen reader users (and everyone else) can choose not expand attribute values for dates and times (choosing not to learn it as irrelevant), or search to learn more about the notation. Jon Tan http://gr0w.com [1] http://www.cl.cam.ac.uk/~mgk25/iso-time.html ("Time of day" section) [2] http://www.cs.tut.fi/~jkorpela/iso8601.html (in the summary) [3] http://dotjay.co.uk/tests/screen-readers/microformats/datetime-design-pattern/YYYY-MM-DD%20HH-MM.php [4] http://www.ietf.org/rfc/rfc3339.txt [5] http://www.w3.org/TR/NOTE-datetime From microformats at 200ok.com.au Wed May 2 18:45:59 2007 From: microformats at 200ok.com.au (Ben Buchanan) Date: Wed May 2 18:46:02 2007 Subject: [uf-discuss] Expanding the abbr pattern In-Reply-To: <002301c78c92$bae4f730$0201a8c0@andrieuhome> References: <6ca82b0f0705012107g4f01d5cehf8c52bf6be797c2@mail.gmail.com> <002301c78c92$bae4f730$0201a8c0@andrieuhome> Message-ID: <6ca82b0f0705021845v46740986lf9d5440251145e20@mail.gmail.com> > So, I started this response thinking "How does a full-string timestamp /not/ disambiguate a March 2 date in the following?" My answer is: by not being human-readable :) The example in the original post shows the problem: March 12, 2007 at 5 PM, Central Standard Time When vocalised, that title is less useful than the text it potentially replaces (screen readers may read just the text, just the title or both). Perhaps I should have said "effective disambiguation, for all human users". At any rate, I think the main problem was referring to different examples - in yours, the shorter date probably would make sense to all users and yes it disambiguates. The datestamp in the microformat however, does not disambiguate for humans. ...and I think I've used up my quota for "disambiguate", so I'll end there ;) cheers, Ben -- --- --- The future has arrived; it's just not --- evenly distributed. - William Gibson From mdagn at spraci.com Wed May 2 23:21:21 2007 From: mdagn at spraci.com (Michael MD) Date: Wed May 2 23:21:25 2007 Subject: [uf-discuss] human readable date parsing References: <4638F281.1080703@pollenation.net> Message-ID: <003901c78d4b$44e96ac0$116bacca@COMCEN> > iso date isn't necessarily required when someone enters a date (i.e. > saying 24th June doesn't translate into a single date, neither does > 'thursday'). Shouldn't the focus be on trying to standardise date I'm normally all for liberalness in parsing but NOT when the intended meaning becomes ambiguous. I do not think we should encourage people to leave off the year unless it is absolutely necessary (such as for a recurring event and in that case it should be marked up in a way so that the intention is clear - rrule, etc) - otherwise how do we know if the author intended "24th June" to mean "24th June 2007" or "24th June 2006" or "the next occurrence of 24th June" (from what date?) or "24th June every year"? I have dabbled in trying to extract human-readable dates from rss feeds and this type of ambiguity is such a problem that I had to ignore any dates without the year! (those entries are unusable!) From supercanadian at gmail.com Wed May 2 23:50:41 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Wed May 2 23:50:44 2007 Subject: [uf-discuss] robots-nocontent Message-ID: <84ce626f0705022350o1f9c3141r73c6bd29361a6829@mail.gmail.com> Hello, Just an FYI. http://www.ysearchblog.com/archives/000444.html Basically, there's a class name "robots-nocontent" that marks a section of a webpage as not to be NOT "payed attention to" but Yahoo!'s webcrawler. Seems related to... http://microformats.org/wiki/robots-exclusion See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ From victor at carotena.net Thu May 3 01:40:16 2007 From: victor at carotena.net (victor jalencas) Date: Thu May 3 01:40:20 2007 Subject: [uf-discuss] human readable date parsing In-Reply-To: <003901c78d4b$44e96ac0$116bacca@COMCEN> References: <4638F281.1080703@pollenation.net> <003901c78d4b$44e96ac0$116bacca@COMCEN> Message-ID: <288c21070705030140o48a9997fsf496e1e18726863f@mail.gmail.com> Looks to me that we have these goals: * Specify a date in a format that a machine can understand (i.e. the ISO8601 format) * Stash it somewhere where it's legal to do so, and is not apparent to human readers I'm still undecided whether a full ISO date is abbreviable as a normal date, but looks like it won't matter in the end. Since the baseline is the HTML4 spec, I have been re-reading it to look where else we might put it. I know Tantek did so back in the day, but it's still a good exercise for the rest of us. Perhaps what I'm about to say doesn't make much sense, but for the sake of brainstorming, and perhaps because it might spark an idea on someone else's head, I won't refrain from chiming in ;) Since using ISO8601 is a w3c recommendation, I wondered where specifically they were recommending its use. Looks like there is an element (a couple of them, actually) with an attribute that can legally contain an ISO datetime: INS and DEL. Furthermore, the spec says "deleted text may not be shown at all ", which makes it sound like screen-readers should ignore it --however this might make them skip the human readable text as well. I know it's semantically dubious, but perhaps we might write Friday the 13th Another idea, that would make a bit more semantic sense perhaps, but wont' be acceptable to screen readers, would be something like CODE (after all, we are speaking about machien-readable text) or DT/DD (where the short form is the term and the ISO datetime is the definition). They don't exactly hide the information intended for the machines, but mark it up as such, so that it's easily ignorable. Other parts of the spec that look interesting, and that I had forgotten long ago, are script macros [1]; and perhaps even specifying datetime info as script data, put on an event handler (in the ABBR or SPAN element) that we know we won't trigger normally (for example, an onblur on an empty element). Just my 2c. Cheers, Victor [1] http://www.w3.org/TR/html401/appendix/notes.html#notes-specifying-data -- Victor Jalencas From lists at ben-ward.co.uk Thu May 3 02:02:02 2007 From: lists at ben-ward.co.uk (Ben Ward) Date: Thu May 3 02:02:10 2007 Subject: [uf-discuss] Regarding POSH and misuse of the microformats logo Message-ID: Hi all, I've obviously been following the recent push to have POSH adopted as a buzzword to discourage people from mis-using the term ?microformat? in their semantic endeavours. Now the whole point of this is to differentiate semantic HTML from microformats, discourage the further ambiguation of the terms. So to be honest I'm a bit put out by the badges that have been added to http://microformats.org/wiki/posh#POSH_Bling_for_your_Blog which include the microformats logo. As part of our ?community mark? experiment I'd like to object to that usage of the microformats logo and ask those badges be removed. Regardless of what anyone thinks of the term, POSH is explicitly supposed to be a super-set of microformats, a generic term invented to help protect the microformats name from being generalised. If the first thing people do ? on our own wiki, no less ? is tack the microformats logo to it then it will do absolutely nothing toward that goal, and with all the current hype will only accelerate the loss of ?microformat? as a name for the Process. POSH is not a microformat. The documented presence on our wiki is acceptable as ?microformat? mis-use is a common problem for us, but I object to it being presented as part of ?microformats? through association with the logo. It's just going to cause more confusion. Cheers, Ben From serdar at kilic.net Thu May 3 05:06:22 2007 From: serdar at kilic.net (=?ISO-8859-1?Q?Serdar_Kili=E7?=) Date: Thu May 3 05:06:26 2007 Subject: [uf-discuss] Regarding POSH and misuse of the microformats logo In-Reply-To: References: Message-ID: On 03/05/2007, at 7:02 PM, Ben Ward wrote: > As part of our ?community mark? experiment I'd like to object to > that usage of the microformats logo and ask those badges be > removed. Regardless of what anyone thinks of the term, POSH is > explicitly supposed to be a super-set of microformats, a generic > term invented to help protect the microformats name from being > generalised. If the first thing people do ? on our own wiki, no > less ? is tack the microformats logo to it then it will do > absolutely nothing toward that goal, and with all the current hype > will only accelerate the loss of ?microformat? as a name for the > Process. > > POSH is not a microformat. The documented presence on our wiki is > acceptable as ?microformat? mis-use is a common problem for us, but > I object to it being presented as part of ?microformats? through > association with the logo. It's just going to cause more confusion. > > Cheers, > Ben I agree, there shouldn't be an association with the Microformats logo with that of any POSH logo. As you say, it's important to be able to distinguish the two, which I believe is accomplished with the information found on the wiki page. Cheers, Serdar From bsittler at gmail.com Thu May 3 09:09:06 2007 From: bsittler at gmail.com (Ben Wiley Sittler) Date: Thu May 3 09:09:09 2007 Subject: [uf-discuss] Expanding the abbr pattern In-Reply-To: <6ca82b0f0705021845v46740986lf9d5440251145e20@mail.gmail.com> References: <6ca82b0f0705012107g4f01d5cehf8c52bf6be797c2@mail.gmail.com> <002301c78c92$bae4f730$0201a8c0@andrieuhome> <6ca82b0f0705021845v46740986lf9d5440251145e20@mail.gmail.com> Message-ID: i think the abbr pattern is a valid one. moving the unambiguous timestamp to some place humans can't see it is asking for it to be removed be a third party (whether that is a screenreader, an html sanitizer, or a web browser makes little difference.) and of course in some cases you can get away with not using abbr: Q1 '07: 2007-01-01 through 2007-04-01 with hyphens it's reasonably human-readable. i've been using fully punctuated iso 8601 date notation it everyday life (checks, contracts, even announcements) for years with no problems whatsoever. (e.g. 2007-03-12) this seems suitable for use in an abbr title. however, the combined datetime notation is a bit awkward due to the 'T' and time zone suffix (the former needed for separation from date and the latter needed for disambiguation -- the problem is that time zones are not widely understood regardless of notation.) treating whitespace as a field separator and so allowing