Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
On 4/30/07 5:20 PM, Jon Gibbins (dotjay) [EMAIL PROTECTED] wrote: span class=dtstart rel=datetime:MMDDTHHMMSSZ+HHMMDD Month/span 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. 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. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
On 4/30/07 6:20 PM, James Craig [EMAIL PROTECTED] wrote: but this battle has been fought and lost before. If you want to mount another advance, my +1 will be right behind you, but my morale in the fight will not be very high. The target is very well-entrenched. Namespaced content on the Web has failed. This has nothing to do with any entrenchment. It's just the sad reality of namespaces. They suck in practice, and no amount of theoretical worship (+1ing etc.) will change that. 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. 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. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: changing abbr-design-pattern to title-design-pattern?
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 h3 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: namespaces discussions off-topic
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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
Tantek Çelik wrote: On 4/30/07 5:20 PM, Jon Gibbins (dotjay) [EMAIL PROTECTED] wrote: span class=dtstart rel=datetime:MMDDTHHMMSSZ+HHMMDD Month/span 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: changing abbr-design-pattern to title-design-pattern?
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 h3 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
Jon Gibbins (dotjay) wrote: Tantek Çelik wrote: On 4/30/07 5:20 PM, Jon Gibbins (dotjay) [EMAIL PROTECTED] wrote: span class=dtstart rel=datetime:MMDDTHHMMSSZ+HHMMDD Month/span 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: span class=dtstart!--MMDDTHHMMSSZ+HHMM--DD Month/span This may be totally off the mark and considered a hack, but comments are markup and are parseable. Dan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
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: span class=dtstart!--MMDDTHHMMSSZ+HHMM--DD Month/span 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: span class=dtstart!--datetime:MMDDTHHMMSSZ+HHMM--DD Month/span Would there be specific difficulties with parsing something like this to extract the microformat data? Jon -- gr0w.com dotjay.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Re: changing abbr-design-pattern to title-design-pattern?
More investigative notes on the 'spacer gif'/IE6 hack solution for the date time design pattern: Markup is as follows: abbr class=published title=2007-04-30T08:06:28Zspan class=abbr title=2007-04-30T08:06:28ZMonday, 30 April 2007/span/abbr 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Fwd: [uf-discuss] Legal implications of using Microformats
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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
JAWS abbr expansion discrepancy (was Re: [uf-discuss] Re: changing abbr-design-pattern to title-design-pattern?)
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: abbr title=International Standards OrganizationISO/abbr 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
On 5/1/07 1:01 AM, Ian Davis [EMAIL PROTECTED] 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] User Interface for Firefox/Operator
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: ?xml version=1.0? hotel class=vcard name class=fn orgWaldorf-Astoria/name location class=adr street class=street-address301 Park Ave./street city class=localityNew York/city state class=regionNY/state zipcode class=postal-code10022/zipcode /location /hotel I would like to see Operator able to recognize Microformats in any XML document, not just XHTML XML documents. /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] global editorial changes to the wiki - please avoid, and blocking
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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: namespaces discussions off-topic
On 5/1/07 1:46 AM, Tim Parkin [EMAIL PROTECTED] 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 [EMAIL PROTECTED] wrote: On 5/1/07 1:01 AM, Ian Davis [EMAIL PROTECTED] 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/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hyperlink include-pattern - keyboard issue
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/ __ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hyperlink include-pattern - keyboard issue
On 5/1/07 9:47 AM, Patrick H. Lauke [EMAIL PROTECTED] 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
On 5/1/07 9:03 AM, Charles Iliya Krempeaux [EMAIL PROTECTED] 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Fwd: [uf-discuss] Legal implications of using Microformats
On 5/1/07, Guy Fraser [EMAIL PROTECTED] 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] User Interface for Firefox/Operator
Thanks Roger, I really want feedback like this! On 5/1/07, Costello, Roger L. [EMAIL PROTECTED] 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: ?xml version=1.0? hotel class=vcard name class=fn orgWaldorf-Astoria/name location class=adr street class=street-address301 Park Ave./street city class=localityNew York/city state class=regionNY/state zipcode class=postal-code10022/zipcode /location /hotel 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] global editorial changes to the wiki - please avoid, and blocking
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] 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: http://microformats.org/wiki/mfo to: http://microformats.org/wiki/mfo-examples Two were to redirect the previously non-existent: http://microformats.org/wiki/Help to: http://microformats.org/wiki/Help:Contents (as the former had over 300 other pages pointing to it). One removed two red links from the main page: http://microformats.org/wiki?title=Main_Pagediff=nextoldid=16262 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: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 div class=haudio grouping.today-podcast.810-interview div class=haudio grouping.today-podcast.the-today-lead-interviews ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hyperlink include-pattern - keyboard issue
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] writes On 5/1/07 9:47 AM, Patrick H. Lauke [EMAIL PROTECTED] 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: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?
In message [EMAIL PROTECTED], Dan Champion [EMAIL PROTECTED] 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: span class=dtstart!--MMDDTHHMMSSZ+HHMM--DD Month/span 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: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hyperlink include-pattern - keyboard issue
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/ __ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Legal implications of using Microformats
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. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] global editorial changes to the wiki - please avoid, and blocking
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. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
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 QA 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.. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Fwd: [uf-discuss] Legal implications of using Microformats
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, span class=geo title=lat;long. . ./span require any form of copyright or license? I would hope not. -- Paul Wilkins ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: namespaces discussions off-topic (was Re: [uf-discuss] changing abbr-design-pattern to title-design-pattern?)
On 5/1/07 11:26 AM, James Craig [EMAIL PROTECTED] 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 div class=haudio grouping.today-podcast.810-interview div class=haudio grouping.today-podcast.the-today-lead-interviews 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Legal implications of using Microformats
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 [EMAIL PROTECTED] 515.710.2725 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Legal implications of using Microformats
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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Fwd: [uf-discuss] Legal implications of using Microformats
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, span class=geo title=lat;long. . ./span 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 [EMAIL PROTECTED] http://jounce.net | mobile: 207.841.9103 Grassroots Enterprise | http://grassroots.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Legal implications of using Microformats
In message [EMAIL PROTECTED], Scott Reynen [EMAIL PROTECTED] 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: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] namespaces discussions off-topic
In message [EMAIL PROTECTED], Tantek Çelik [EMAIL PROTECTED] 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': http://microformats.org/wiki?title=namespaces-considered-harmfuldiff=nextoldid=16289 but that you've overlooked point 3 in !how to play: If you write something opinionated, sign it with your username. http://microformats.org/wiki/how-to-play -- Andy Mabbett * Say NO! to compulsory ID Cards: http://www.no2id.net/ * Free Our Data: http://www.freeourdata.org.uk * Are you using Microformats, yet: http://microformats.org/ ? ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
UPDATE: Re: [uf-discuss] global editorial changes to the wiki - please avoid, and blocking
On 5/1/07 8:17 AM, Tantek Çelik [EMAIL PROTECTED] 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: UPDATE: Re: [uf-discuss] global editorial changes to the wiki - please avoid, and blocking
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. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Expanding the abbr pattern
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 -- --- http://weblog.200ok.com.au/ --- The future has arrived; it's just not --- evenly distributed. - William Gibson ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
