[uf-discuss] New Member on the List
Hi all, I'm brand new to the list and would like to introduce myself. I saw Tantek give his talk at The Future of the Web Apps conference in San Fran last month, and I am sold on Microformats! (see: http://www.mikeschinkel.com/blog/MicroformatsHCard.aspx) This is great work and I'm so glad to see this initiative! Over the coming month I hope to contribute significantly, and I have some thoughts on some microformats I'd really like to see. However, I'm going to sit back and get a feel for the group and how things operate before I propose anything so as not to waste anybody's time. -Mike Schinkel President; Guides, Inc. http://www.guidesinc.com (404) 474-8948 (404) 276-1276 cell (404) 474-8949 fax skype: mike.schinkel [EMAIL PROTECTED] http://www.mikeschinkel.com/blog http://www.welldesignedurls.org/ http://www.linkedin.com/in/mikeschinkel ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Currency Quickpoll: Preliminary results
I want to vote on the poll but can you clarify what certain options mean exactly, maybe by hypothetical examples (quoted parts are what confuse me)? * Currency symbol identification from other part of the text * Global currency definition * Amount identification from other part of the text Thanks in advance. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume Lebleu Sent: Thursday, October 12, 2006 10:59 AM To: Microformats Discuss Subject: [uf-discuss] Currency Quickpoll: Preliminary results I thought I'd share these results with you. Voters were asked to select up to 4 features in a list of 8. We only had a handful of votes so far, so please cast yours at: http://www.vizu.com/poll-vote.html?n=15067 Features deemed most important: 1. (100%) Currency used identification (ex. US dollars versus Canadian dollars) 2. (83.3%) Currency unit/denomination used identification (ex. dollar versus cent, pound versus shilling) 3. (50%) * Amount identification from other part of the text * Support for combination with units (ex. $34 per gallon, $2 per miles) 4. (33.3%) Global currency definition (ex. all amounts in table are in US dollars) 5. (16.7%) Currency symbol identification from other part of the text (ex. $ is the dollar sign) 6. (0%) * Dated money amounts (ex. Five 1929 US dollars) * Support for non-numerical representation (ex. 10 dollars 99 cents, five pounds 23 pence) Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] new standard for product information
So, they typically resort to integration mechanism or other concepts (retailer-manager store-in-store) they can control and authorize for select e-retailers they work closely with. Which is why I think the ideas I have will be a lot like RSS; they are small, simple, and will really help retailers. And it doesn't have to be a manufacturer that maintains the original; if they won't, an industry aggregator can do that. I guess it's time I start putting my ideas on paper? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume Lebleu Sent: Thursday, October 12, 2006 4:50 PM To: Microformats Discuss Subject: Re: [uf-discuss] new standard for product information Ted Drake wrote: I would thin this standard could be adopted quickly via microformats. What are the thoughts? I think microformats would probably help adoption with the less sophisticated (smaller) retailers quickly, but would not satisfy all the business needs of more sophisticated manufacturers. More: Microformats can help for product content that is on the manufacturer's Web pages. But not all of the product content is on their Web pages, especially for sophisticated manufacturers. One example is pricing rules, which can be very complex. See the ARTS data model http://www.nrf-arts.org/xml_dictionary_5/XMLDictionary-NonMembers.html. Moreover, having worked on manufactuer/e-retailer collaboration software in the 90s, my experience is that some, if not most manufacturers are worried about how they differentiate on the electronic shelf (i.e. the comparison shopping site), how their brand is represented, and as a result are actually reluctant to making their Web site content easily scraped, taking the risk that their content end up in places they don't want to end up. So, they typically resort to integration mechanism or other concepts (retailer-manager store-in-store) they can control and authorize for select e-retailers they work closely with. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] new standard for product information
Wow. At 1.5MB of documentation, that's pretty much the antithesis of a microformat. Holy $h1t! Maybe we should call that one a Macroformat? Hehe. ;) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Thursday, October 12, 2006 5:21 PM To: Microformats Discuss Subject: Re: [uf-discuss] new standard for product information On Oct 12, 2006, at 3:49 PM, Guillaume Lebleu wrote: I think microformats would probably help adoption with the less sophisticated (smaller) retailers quickly, but would not satisfy all the business needs of more sophisticated manufacturers. I agree. See the ARTS data model http://www.nrf-arts.org/xml_dictionary_5/ XMLDictionary-NonMembers.html. Wow. At 1.5MB of documentation, that's pretty much the antithesis of a microformat. But if it gains any traction, the individual parts my be useful to look at for more specific microformats. For example, here's what they're doing with currency: http://www.nrf-arts.org/xml_dictionary_5/XMLDictionary- NonMembers.html#Currency Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Currency Quickpoll: Preliminary results
Thanks for considering my input. As for money vs. currency for some intangible reason I prefer currency, maybe because currency datatype always seemed more natural than money data type in programming, but I don't prefer it strongly enough to argue the point! :) P.S. I added my vote to your poll, but only selected three of eight thinking the rest shouldn't be included. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume Lebleu Sent: Friday, October 13, 2006 1:28 AM To: Microformats Discuss Subject: Re: [uf-discuss] Currency Quickpoll: Preliminary results Mike Schinkel wrote: This is a naïve question: Doesn't the ISO 4217 code *imply* a symbol? It appears so here: http://www.xe.com/symbols.htm Doesn't including this in the microformat create redundancy? Alternately, can't the symbols be extracted as not being alphanumeric characters? I tend to agree with you and see this as a bit redundant, but I felt I would reproduce the suggestion for the sake of not ignoring anyone's in the vote. I wouldn't have guessed that meaning; I thought your were talking worldwide, not document scope. :) So how would you mark up http://tonto.eia.doe.gov/dnav/pet/pet_pri_spt_s1_d.htm ? Can you show the actual HTML to help me better understand? (not for the entire file, just a snippet.) One solution is to use the include-pattern only; another solution is to use the th scope only (if the currency is present in the column header), or a combination of the two: amounts in span id=#u1 class=currencyUSD/span. ... tr th scope=colpricea href=#u1 class=include/a/th td24/td /tr If so, wouldn't that argue for combination with units (ex. $34 per gallon, $2 per miles) being out of scope and begging the need for a microformat that allows unit designation, i.e. hUnits? We came to the same conclusion. A separate measure effort was started: http://microformats.org/wiki/measure Anyway, I made a proposal here: http://microformats.org/wiki/currency-brainstorming#Mike_Schinkel with the idea of trying to minimize the burden placed on the author of the HTML, and only use lots of markup in the exceptional cases. You have some good points there. That said, I think that currency should not be the root class, money should be, since semantically (to me) $35 is not a currency, it is money, and currency is part of money. But I see the benefits of briefness. My last thought on the subject, is why are we using full names for currency and amount instead of cur and amt to minimize bloat when hCard uses names like fn? Good point too. I will try to document the different options presented over the last days. It does not seem that we will get a 100% on all feature implementations, so I guess it will be up for the community to decide through a vote, or limit the feature scope to what is 100% agreed, namely currency disambiguation. Thank you, Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Currency Quickpoll: Preliminary results
It's not just about identifying which symbol represents the currency, but also which currency that symbol represents. That's handled in my example. For a program to do so, it would have to be aware of every single alphanumeric character in Unicode. That does not just include [A-Za-z0-9]. It might be easier to do the reverse and know of every character that isn't a known currency symbol, but then even that list of symbols is missing some. Is there not a regular expression that can provide every single alphanumeric character? Alternately, wouldn't it be preferred to have minimal markup if [A-Za-z0-9] can be assumed and more complex markup if it cannot as opposed to having all cases be the more complex markup? However, the format could make provisions for some form of quantity, even if it doesn't explicitly define what such quantities are. I assume you are suggesting it would be optional, not required? OTOH, if there is another microformat planned for measure, is it advisable to design in overlap? One of the problems I have with hCard is that those abbreviated class names are difficult to comprehend and remember. In programming I generally prefer long well described names, but I called the question in case there would be people not implementing it just because they wanted to avoid bloat. I am not suggesting that I know that this is an issue, just posing the question. Abbreviations can be good in many cases, but you have to be careful not to introduce too much confusion or ambiguity for authors. However, I would disagree with abbreviations; the more ways it can be done, the more complexity in the spec and in the parser. Better to have just one way until desired functionality requires multiple ways. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt Sent: Friday, October 13, 2006 4:19 AM To: Microformats Discuss Subject: Re: [uf-discuss] Currency Quickpoll: Preliminary results Mike Schinkel wrote: Thanks for the clarification. Further questions (and forgive me if I missed any of this before I joined): Currency symbol identification This is a naïve question: Doesn't the ISO 4217 code *imply* a symbol? It appears so here: http://www.xe.com/symbols.htm Doesn't including this in the microformat create redundancy? It's not just about identifying which symbol represents the currency, but also which currency that symbol represents. Alternately, can't the symbols be extracted as not being alphanumeric characters? For a program to do so, it would have to be aware of every single alphanumeric character in Unicode. That does not just include [A-Za-z0-9]. It might be easier to do the reverse and know of every character that isn't a known currency symbol, but then even that list of symbols is missing some. e.g. * U+FE69 ﹩ (Small Dollar Sign) * U+FF04 ＄ (Fullwidth Dollar Sign) * U+FFE5 ￥ (Fullwidth Yen Sign) * etc. It's much easier for the author to explicitly state which character(s) represent the symbol, than implementing heuristics to guess. Broader Question: Isn't the idea behind Microformats to be as consise, cohesive, and single purposed as possible? If so, wouldn't that argue for combination with units (ex. $34 per gallon, $2 per miles) being out of scope and begging the need for a microformat that allows unit designation, i.e. hUnits? Yes. Tackling the problem of identifying specific units under the currency format is far too complicated when you consider the sheer number of units there are, including SI units, Imperial units and US customary units, used for various quantities including number of units, length, mass, time, volume, area, energy, etc. However, the format could make provisions for some form of quantity, even if it doesn't explicitly define what such quantities are. e.g. price per Litre: span class=money abbr class=currency unit title=AUD$/abbr1.23 span class=quantityL/span /span Or for each unit: span class=money abbr class=unit$/abbr4.95 span class=quantityeach/span /span That way, if and when a microformat for units of measurement is introduced, that could easily be expanded to the following. e.g. span class=quantity si-unitL/span My last thought on the subject, is why are we using full names for currency and amount instead of cur and amt to minimize bloat when hCard uses names like fn? One of the problems I have with hCard is that those abbreviated class names are difficult to comprehend and remember. e.g. It's easy to get confused about what 'fn' means, since it could easily stand for family name, though it doesn't. (I'm not exactly sure what it stands for, though I assume it means formatted name even though it's not explicitly stated as such in the vCard RFC) Abbreviations can be good in many cases, but you have to be careful not to introduce too much confusion or ambiguity for authors. -- Lachlan Hunt
RE: title attribute and abbreviated class names (Was: [uf-discuss]Currency Quickpoll: Preliminary results)
I think your use of the title attribute in these examples contains two bad practices Hmm. I see your point, and being new to this I'm learning from your examples. OTOH, I also see that the proposals I first viewed as being very complex and I'd fear many people simply won't implement them until there is a direct benefit, and there will likely be few direct benefits until lots of people start implementing them; a classic chick and egg problem. Is there not a way to significantly reduce complexity, at least in the 80 percentile case and still maintain proper semantics? I know I'm new and might be schooled to understand the downside of my current view, but currentky if I had to between the two, I'd vote for semantics that don't fit perfectly over significantly greater required complexity per each marked up amount. It's a minor problem, but it's also a minor solution - typing four extra letters. Point of note, my concern wasn't typing extra letters, it was the need to transmit extra bites over the wire. Imaging a very large volume site that has hundreds of prices to mark up per page, and they server millions of pages an hour. It might add up to be a concern. For example, why does google use q instead of query on it's search box? I'm assuming to reduce unnecessary characters. Thanks again for listening. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Friday, October 13, 2006 8:34 AM To: Microformats Discuss Subject: Re: title attribute and abbreviated class names (Was: [uf-discuss]Currency Quickpoll: Preliminary results) On Oct 12, 2006, at 10:34 PM, Mike Schinkel wrote: Anyway, I made a proposal here: http://microformats.org/wiki/currency-brainstorming#Mike_Schinkel with the idea of trying to minimize the burden placed on the author of the HTML, and only use lots of markup in the exceptional cases. I think your use of the title attribute in these examples contains two bad practices. The first is using title outside of abbr, which is effectively hiding data from humans, as this information is not human-readable in browsers, while abbr title is. The second is using title in abbr to surround data that is not meaningfully equivalent to the title. USD is a good abbr title for $ because they mean the same thing. USD is not a good abbr title for $12.57 because they do not mean the same thing. Imagine listening to that with a screen reader set to read titles instead of content for abbr tags. You'd hear Price: USD and have no idea what the price is, as opposed to a clear Price USD 12.57. Humans first, machines second. My last thought on the subject, is why are we using full names for currency and amount instead of cur and amt to minimize bloat when hCard uses names like fn? fn was taken directly from an existing vocabulary (vCard), so any change would make implementation more difficult for those familiar with that vocabulary. Without those constraints, we should use descriptive and human-readable class names to ease implementation and avoid name clashes. cur might mean current in another context, and this ambiguity is a problem for both publishers and parsers. It's a minor problem, but it's also a minor solution - typing four extra letters. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Casual Web Services and Well Designed Urls
To all: I just read the email about a Spread the Semantic Web campaign and it made me think it was important that I go ahead and present the following idea to the microformat group. I recently started working on a project I'm calling Well Designed Urls (http:///www.welldesignedurls.org/) that has been a pet issue of mine for a long time. See my Aug 2005 blog post: http://www.mikeschinkel.com/blog/welldesignedurlsarebeautiful.aspx The project includes a wiki like http://www.microformats.org/wiki and planned blog and it's mission is to: 1.) Promote the use of Well Designed Urls by website owners/developers, 2.) Promote having vendors design tools that make Well Designed Urls easy to implement, 3.) Provide best practices for URL structure design and implementation, and 4.) Provide resources to make it easy to implement Web Designed Urls in web apps. I think Well Designed Urls have a lot of benefits in general, but I believe they especially go hand-in-hand with Microformats. The reason I see those two aligned is I believe we'll soon see an evolution towards what I'll call: Casual Web Services (think: Structured Screen Scraping) I believe this evolution towards Casual Web Services will see the line between HTML web pages and REST-based web services blurring into no line at all. Since the URL structure of a REST-based web services typically becomes an important part of the API, HTML web pages will need Well Designed Urls in order to operate effectively as REST-based web services. If I am correct about this, it is important that we sooner than later start promoting Well Designed Urls as well as crystalizing a set of best practices for URL structure design. At least that my opinion and I am hoping you each concur. Thoughts? Questions? -Mike Schinkel http://www.mikeschinkel.com/blog/ P.S. One way to try and make a simple point about this is consider the rel-tag microformat. As per the spec: The last path component of the URL is the text of the tag. Are you aware this is very difficult if not impossible to implement on a standard Microsoft IIS5/6-based web server using ASP, ASP.NET, or even PHP without a 3rd party product (ISAPI Rewrite is one.) Unfortunately, and I'm only going by gut feeling here, over 90% of shared hosting companies on the web will not support ISAPI Rewrite or another other clean URL solution. Shining a light on the need for good clean URL design could create enough demand that hosting companies would look for a solution. Further, it could cause Microsoft, content management software vendors, and other web app vendors to realize they really do need to incorporate clean URLs into their products and stop treating URLs as if they were both invisible and irrelevent to end users. Again, I hope you share my opinion. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Currency Quickpoll: Preliminary results
[A-Za-z0-9] effectively only covers English. There are hundreds of languages and thousands of characters covered by Unicode. I concur, but your statement does not make my suggestion invalid. I was suggested (said a different way) a default that doesn't require the additional complexity of always having to define the currency symbol, letting it instead be assumed (i.e. if symbol is not specificed then assume that any non [A-Za-z0-9] characters comprise currency symbols), and if it is required then include the symbol. Complexity of implementation will be the bane of adoption; I'm pushing to reduce complexity. This after being someone the prior 20 years always advocated to approach perfection which increased complexity. I'm learning some valuable lessons from other's Web 2.0 successes. I don't see it as overlapping, but rather leaving room for future expansion. Okay. What? I have no idea what you're talking about, I think you misunderstood what I was saying. By abbreviations, I was referring to abbreviated class names, like those used in hCard. I may have misunderstood. I thought you were saying it would be possible to support *both* a long name and an abbreviation. If I misunderstood, sorry for my missing the point. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lachlan Hunt Sent: Saturday, October 14, 2006 6:41 AM To: Microformats Discuss Subject: Re: [uf-discuss] Currency Quickpoll: Preliminary results Mike Schinkel wrote: Lachlan Hunt wrote: For a program to do so, it would have to be aware of every single alphanumeric character in Unicode. That does not just include [A-Za-z0-9]. It might be easier to do the reverse and know of every character that isn't a known currency symbol, but then even that list of symbols is missing some. Is there not a regular expression that can provide every single alphanumeric character? No, that's my point. Have you seen how many characters there are in Unicode? It may be theoretically possible to write such a regular expression, but it would very complex. Alternately, wouldn't it be preferred to have minimal markup if [A-Za-z0-9] can be assumed and more complex markup if it cannot as opposed to having all cases be the more complex markup? [A-Za-z0-9] effectively only covers English. There are hundreds of languages and thousands of characters covered by Unicode. However, the format could make provisions for some form of quantity, even if it doesn't explicitly define what such quantities are. I assume you are suggesting it would be optional, not required? Yes. OTOH, if there is another microformat planned for measure, is it advisable to design in overlap? I don't see it as overlapping, but rather leaving room for future expansion. One of the problems I have with hCard is that those abbreviated class names are difficult to comprehend and remember... Abbreviations can be good in many cases, but you have to be careful not to introduce too much confusion or ambiguity for authors. However, I would disagree with abbreviations; the more ways it can be done, the more complexity in the spec and in the parser. Better to have just one way until desired functionality requires multiple ways. What? I have no idea what you're talking about, I think you misunderstood what I was saying. By abbreviations, I was referring to abbreviated class names, like those used in hCard. -- Lachlan Hunt http://lachy.id.au/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] First version of Currency proposal
The book costs $span class=USD5.99/span This gives me a chance to ask in a different way, why can we not assume type=USD, amount=5.99, and symbol=$ from the following? The book costs span class=currency title=USD$5.99/span I believe you answer will be what about unicode where we are not using [A-Za-z0-9] and if so, I would say that is when you add a symbol. In my example, symbol is the non-[A-Za-z0-9] character(s) *if* no symbol is explicitly specified. Can you give me an example where that would not work? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Saturday, October 14, 2006 6:53 AM To: Microformats Discuss Subject: Re: [uf-discuss] First version of Currency proposal In message [EMAIL PROTECTED], Emiliano Martinez Luque [EMAIL PROTECTED] writes Regarding the Straw man proposal, the symbol class seems to be unnecesary since the symbol in most price representations is just a convention to define which currency we are speaking of. Not so. Suppose there is a page with the markup (simplified): The book costs $span class=USD5.99/span and I have a user agent (a Firefox extension, say) which replaces the dollar value with the value in pounds sterling. I'd get: The book costs $£3.50 which is clearly nonsense. By wrapping the dollar sign in a span (or whatever) with the class symbol, the user agent is made aware of its presence, and can hide it when inserting the sterling value. Likewise for the unit in 50 span class-unitcents/span -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: title attribute and abbreviated class names (Was:[uf-discuss]Currency Quickpoll: Preliminary results)
Your examples seem to leave a lot of ambiguity about what things mean, I'm new to proposing microformats, so I clearly have a lot to learn, but that said I don't see where what I was proposing was ambiguous. Can you give me explicit examples where allowing default assumptions for the most common use cases will by necessity lead to ambiguity? It seems to me that either something will be specified or if not it will default? That seems non ambiguous to me. Am I wrong? There's no getting around that. Reducing this markup by making the class names more ambiguous isn't worth it. Okay. But one final point on this; has this been discussed this with those who make the decisions for markup used at the largest sites: Google, eBay, Amazon, etc.? Just curious? (and I don't mean to push this, it's just that being pedantic is in my nature, unfortunately. :) Do you know someone who actually has this problem? No, just bringing up something now that occurred to me rather than wishing I had brought it up later. And I don't see any other high-volume sites doing this kind of micro-optimizing for bandwidth. Okay. Maybe it was more of a concern a few years ago when bandwidth was more expensive. I'm happy to drop it now that I've had a chance to test the concern. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Saturday, October 14, 2006 11:42 AM To: Microformats Discuss Subject: Re: title attribute and abbreviated class names (Was:[uf-discuss]Currency Quickpoll: Preliminary results) On Oct 14, 2006, at 3:42 AM, Mike Schinkel wrote: I think your use of the title attribute in these examples contains two bad practices Hmm. I see your point, and being new to this I'm learning from your examples. OTOH, I also see that the proposals I first viewed as being very complex and I'd fear many people simply won't implement them until there is a direct benefit, and there will likely be few direct benefits until lots of people start implementing them; a classic chick and egg problem. Is there not a way to significantly reduce complexity, at least in the 80 percentile case and still maintain proper semantics? I know I'm new and might be schooled to understand the downside of my current view, but currentky if I had to between the two, I'd vote for semantics that don't fit perfectly over significantly greater required complexity per each marked up amount. We should minimize complexity, but not at the expense of clear useful semantics. Without clear useful semantics, there's no point in microformats. Your examples seem to leave a lot of ambiguity about what things mean, and this reduces the benefit of use, which will hurt adoption. Small businesses don't want to get a bunch of payments submitted in the wrong currency because some parser guessed wrong. A microformat should leave no room for guessing. It's a minor problem, but it's also a minor solution - typing four extra letters. Point of note, my concern wasn't typing extra letters, it was the need to transmit extra bites over the wire. This is also a good goal, but also a lower priority than clarity. Microformats are going to require some amount of additional markup. There's no getting around that. Reducing this markup by making the class names more ambiguous isn't worth it. Imaging a very large volume site that has hundreds of prices to mark up per page, and they server millions of pages an hour. It might add up to be a concern. Do you know someone who actually has this problem? For example, why does google use q instead of query on it's search box? I'm assuming to reduce unnecessary characters. Take a look at the HTML source of any Google page. It's full of comments that don't provide any functionality at all, and inline CSS and JavaScript, which could be cached separate from the HTML to significantly reduce bandwidth. I see no evidence unnecessary characters is a real concern for Google. And I don't see any other high-volume sites doing this kind of micro-optimizing for bandwidth. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] First version of Currency proposal
I believe you answer will be what about unicode where we are not using [A-Za-z0-9] and if so, I would say that is when you add a symbol. In my example, symbol is the non-[A-Za-z0-9] character(s) *if* no symbol is explicitly specified. Can you give me an example where that would not work? yy span class=currency title=USD$zz 5.99/span Where yy and zz are, say Japanese or Urdu characters (where zz might mean, again for example, approximately). I'm sorry, I made a mistake in my question. I didn't mean to say is non [digits+periods+commas] (I don't know how to write the regex at the moment.). So in your example, clearly it would require specifying the symbol. But when only digits and seperators? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Saturday, October 14, 2006 4:04 PM To: Microformats Discuss Subject: Re: [uf-discuss] First version of Currency proposal In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes This gives me a chance to ask in a different way, why can we not assume type=USD, amount=5.99, and symbol=$ from the following? The book costs span class=currency title=USD$5.99/span I believe you answer will be what about unicode where we are not using [A-Za-z0-9] and if so, I would say that is when you add a symbol. In my example, symbol is the non-[A-Za-z0-9] character(s) *if* no symbol is explicitly specified. Can you give me an example where that would not work? yy span class=currency title=USD$zz 5.99/span Where yy and zz are, say Japanese or Urdu characters (where zz might mean, again for example, approximately). -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Currency Quickpoll: Preliminary results
I'm not a retailer, but if I was, I'm sure I wouldn't consider the prospect of a 20% failure rate very satisfactory... I didn't imply that at all. Explicitly stated, I was saying that edge cases would be in the 20 percentile, not that we'd have a 20% failure rate. Further, I said I believe that it would be much more likely to see adoption if the 80 percentile case were much easier to implement. It is easier to get people to learn and adopt complexity if they can get started by not having to learn and use complexity. Once bought in to a concept, assuming the complexity slope is not to steep, people will incremetally accept complexity. But they won't accept complexity up front. It is a concept I learned from one of my college professors called transitionality. I blogged about it a few years ago: http://www.mikeschinkel.com/blog/DevelopmentToolsNeedTransitionality.aspx We can look look back at OS/2 and Windows; in the early days one was optimized for quality and one was optimized for adoption. Look which one won. That said, why not make the symbol markup optional? That's IMO is an additional good idea. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Saturday, October 14, 2006 4:22 PM To: Microformats Discuss Subject: Re: [uf-discuss] Currency Quickpoll: Preliminary results In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes £1 was worth 2.50 dollars Those are edge cases which require additional complexity. I'm advocating that edge cases, which are certainly in the 20 percentile or less have the complexity whereas the more common use-cases (certainly more than 80 percentile) should require less complex markup. Most of the time we see just $2.50 or just £1. My point is Why require all the overhead (which will likely cause this microformat not to get used very often) in order to support far less common use-cases with the same markup? From my experience of running a small internet retailer for 12 years I'm not a retailer, but if I was, I'm sure I wouldn't consider the prospect of a 20% failure rate very satisfactory... That said, why not make the symbol markup optional? -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] ANN: The Purpose of Microformats
Roger: Nit: Semantic Hooks mentions class, rel, and rev but not title. Next, my first thought was I found the beginning confusing. The first slide I read is Purpose of Microformats and the second is (X)HTML. As I read the second (and third) I'm trying to figure out where the microformat examples are. I guess I was expecting and introductory statement about the purpose and then an overview of what your are going to tell explain. You know, the old Tell 'em what you're going to tell 'em, then tell 'em, then tell 'em what you said. I understand why you are giving background on XHTML, but for someone who doesn't already understand the subject I think the current organization could be very disorienting. That said, I started jotting down notes until I had completely restructured your presentation (based on my 7+ years experience in developing programming courseware and delivering those courses.) I'll include my note below my signature, but please accept them as merely suggestions to consider and, as I have no price of authorship, feel free to incorporate or discard any of my suggestions. Also please note, I didn't flesh everything out, so if you do incorporate a significant number of my suggestions you'll certainly need to rework some of it as I didn't flesh it out exhaustively, and in two case I left to be written with notes. JMTCW. -Mike Schinkel http://www.mikeschinkel.com/blog http://www.welldesignedurls.org/ = * Title Slide * Purpose of Microformats -- The purpose of microformats is to enrich the semantics of web Pages * To be covered -- What Problem do Microformats Solve? - See USe-cases for Microformats below, To be written -- Background: Let's Define Web Pages - Use (X)HTML page, Browser Rendering, (X)Html Semantics -- Goals and Constraints Chosen for Microformats - Use Microformat Goals (See below, to be written) - These Constraints are Sacred (from below) -- Example Microformat - Use existing -- Benefits - Use Aggregating Microformats, Other? -- Summary - Use (edited version of) Purpose of Microformats (Revised) -- Brilliance of Microformats - Use existing * Use-cases for Microformats -- (I don't think I've an explicit list mentioned anywhere yet) -- (If would be good to get a common set of use-cases to help everyone target the same outcomes) * Microformat Goals -- (This I know instintively but can't put into words in the context of goals. -- (Nothing I could find on Microformats.org is explicit in defining goals) -- (If would be good if there were a consensus, or at least if we were all aware.) * These Constraints were considered Sacred: -- No Update to existing Browsers Required - Use No New Markup (Change Markup to (X)HTML Tags and add Required) - Use Semantic Hooks, rename to Enhancing Semantics using Existing (X)HTML Tags - Use Many Ways to Mark Up Information, rename to Any Element can be Described -- No Impact to Presentation - Use existing slide -- Controlled process to eliminate Chaos - Use Standardized Class Values = -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Costello, Roger L. Sent: Monday, October 16, 2006 7:28 AM To: Microformats Discuss Subject: RE: [uf-discuss] ANN: The Purpose of Microformats Thanks Rob. Good suggestion. I have added two new slides - one that shows an example Microformat, the second shows an aggregator collecting Microformats in Web pages. http://www.xfront.com/microformats/Purpose-of-Microformats.html Thanks! /Roger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Unsworth Sent: Sunday, October 15, 2006 7:56 PM To: Microformats Discuss Subject: RE: [uf-discuss] ANN: The Purpose of Microformats On Sun, 15 Oct 2006, Costello, Roger L. wrote: Thanks a lot Tantek. That's exactly the kind of feedback I was seeking. I have made a few changes (added a couple new slides, modified a few slides). Please let me know if this now captures the purpose of Microformats. http://www.xfront.com/microformats/Purpose-of-Microformats.html Roger, As someone new to microformats and normally just lurking and learning I did notice, at least to me, a flaw in your slides. At the beginning you give examples using divs and spans and also an unordered list. It would be more understandable if the presentation was rounded off by having a similar microformat example as part of the conclusion. Rob ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss
RE: [uf-discuss] currency quickpoll results and suggested next step
My opinion is this sounds like a great idea! Will you be doing the edit on the current proposal? I am surprised however at the number of people who felt Currency unit/denomination used identification was important and it seems like an edge case to me. I'm hoping that this become an optional aspect as opposed to always required, and the same with amount, actually. Also, will the current spec worry about the other concerns so as not to eliminate the possibility of including them later, or by asking am I just removing the benefit of focusing on the top 3 by asking? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume Lebleu Sent: Monday, October 16, 2006 6:07 PM To: Microformats Discuss Subject: [uf-discuss] currency quickpoll results and suggested next step See below the results for What do you think are the [4] most important features [out of 8] for the currency proposal? Thank you to all who have participated. My recommended next step is to edit the current proposal so that it focuses only on the 3 top features below, with the goal to get a first version, lean yet functional, officially approved as soon as possible, and push back the other features to a subsequent version. Let me know what you think. Guillaume --- Unanimity (100%): * Identification of currency used (ex. US dollars versus Canadian dollars) Majority (50% and more): * Currency unit/denomination used identification (ex. dollar versus cent, pound versus shilling) - 62.5% * Amount identification from other part of the text - 62.5% Divided (50%): * Global currency definition (ex. all amounts in table are in US dollars) * Support for combination with units (ex. $34 per gallon, $2 per miles) Minority (50% and less) * Currency symbol identification from other part of the text (ex. $ is the dollar sign) - 12.5% None (0%) * Dated money amounts (ex. Five 1929 US dollars) * Support for non-numerical representation (ex. 10 dollars 99 cents, five pounds 23 pence) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] currency quickpoll results and suggested next step
This may be a fact of test bias. I was wondering if that might not be the case. I actually only voted for 3 of 8 as I felt the other 5 were ideally out-of-scope. It seems to me that denomination or unit is about presentation, not the data. I concur. No offense, btw, to Guillaume regarding test bias. Ditto. But dare I ask if he should repoll and ask for up to four instead of four? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Andrieu Sent: Monday, October 16, 2006 10:17 PM To: 'Microformats Discuss' Subject: RE: [uf-discuss] currency quickpoll results and suggested next step Mike Schinkel wrote I am surprised however at the number of people who felt Currency unit/denomination used identification was important and it seems like an edge case to me. I'm hoping that this become an optional aspect as opposed to always required, and the same with amount, actually. This may be a fact of test bias. The test asked for four answers, so I selected four answers, and #4 for me was Currency unit/denomination used. I didn't really have my heart in it, so to speak. It seems to me that denomination or unit is about presentation, not the data. And I don't think we've had a case before where we defined the microformat to retain presentational aspects. For example, with hCalendar, we don't keep track of how the date/month/year is presented. We just capture the ISO version of the date. Seems we should do the same for the currency. Let the XHTML present the currency unit, but don't worry about it being semantically labelled as such. No offense, btw, to Guillaume regarding test bias. Almost all tests have built-in bias of some kind. It'll take a few revs to figure out the best way to poll for this kind of thing. Thanks for taking the first step. (At least, it is the first poll I've seen for uF.) Cheers, -j -- Joe Andrieu [EMAIL PROTECTED] +1 (805) 705-8651 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Wiki Editing and Process + Tone of Voice
Christopher: I concur and wanted to email something similar, but I didn't want to be the messenger that was shot. Thanks for interjecting! -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Rines Sent: Monday, October 16, 2006 6:51 PM To: microformats-discuss@microformats.org Subject: [uf-discuss] Wiki Editing and Process + Tone of Voice I've been reading with interest the discussion between Andy and Tantek and I need to make a comment, take it for what it is my thought and nothing more. Wiki Editing and Process: As I understand it a Wiki is a site which allows users to add and edit content collectively, but what this definition does not take into account is understood practices and processes within the community using the wiki. Just because everyone can edit a wiki page does not mean it's the best thing to do and just because there is some lightweight processes in place does not diminish from the value of having a wiki or an open community. A wiki is a tool, that's it! As far as I've seen the process involved in the microformats community has been incredibly lightweight and overall very cumbersome free. Now if we have a simple understood process that once a spec is in a fairly stable phase that if we want to add or edit it we should talk to the nominal editor (or x) first I personally see nothing wrong with that. We just need to communicate these understood norms which I think Tantek has done quite well. Tone Of Voice: I have been a sideline observer to the conversations between Tantek and Andy and as I am not involved I only have this to say... From my reading Tantek's tone has not been objectionable. It has been concise and straight to the point which is the way many people treat email conversations. In addition while I have never met or spoken to Tantek but from reputation I understand him to be an incredibly fair guy. Indeed I have learned some things about some of the processes that are implied in the community that I was unaware of before and this has been quite helpful. Any How, Christopher ___ $0 Web Hosting with up to 200MB web space, 1000 MB Transfer 10 Personalized POP and Web E-mail Accounts, and much more. Signup at www.doteasy.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] hCalendar spec- no specification included!
I agree that the current layout is confusing. After reading several of these email I would like to make a suggestion that is smaller scope than an entire reorganization (which still might be a good idea.) Tantek suggests that the specifications are not tutorials and others have said that they (think newbies would be) interested in authoring, not the specification and I concur. What if we use a convention that the entry page (i.e. http://microformats.org/wiki/hcard) would be an index into a list of (psuedo) standardized sub pages so that it would be very people to find what is important to them. For example, is a list of potential sub pages: * Specification * Tutorial * Examples * Use cases * Reference * Discussion * Brainstorming (might be combined w/Discussion) * Implementations * Related Pages * Further Reading * All (Uses Mediawiki's includes to create a page including all sub pages; very useful for printing reading offline) These pages would be located respectively at * http://microformats.org/wiki/hcard/Specification * http://microformats.org/wiki/hcard/Tutorial * http://microformats.org/wiki/hcard/Examples * http://microformats.org/wiki/hcard/Use_cases * http://microformats.org/wiki/hcard/Reference * http://microformats.org/wiki/hcard/Discussion * http://microformats.org/wiki/hcard/Brainstorming * http://microformats.org/wiki/hcard/Implementations * http://microformats.org/wiki/hcard/Related_Pages * http://microformats.org/wiki/hcard/Further_Reading * http://microformats.org/wiki/hcard/All Please note I am suggesting an architecture not a specific list of sub pages. The list of sub pages should be defined by both reviewing existing information during site reorganization, and then via discussion on the list in an attempt to discover and extract which sub pages are needed for most/all microformats. Hope this is useful... -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Monday, October 16, 2006 5:29 PM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! On 10/16/06, Justin Thorp [EMAIL PROTECTED] wrote: Ben, I really like your idea of giving the wiki a better sense of organization. Justin, thanks, but this isn't my idea. Many others have expressed their ideas and desires as well. Is it possible within MediaWiki to have some type of sidebar navigation with this site organization on it? Interesting idea. Would you mind suggesting this on the to-do page? You can create your own section or feel free to put it under mine. If enough people comment in my section, I'll split the whole section off as it's own Wiki Improvement section. Please add this to http://microformats.org/wiki/to-do#Ben_West_.28bewest.29 under information architecture. Be sure to leave your name. I think this would help users to better find the information that they are looking for. For example, I am a user who could care less about the specification and cares more about how to write an hCard or hCalendar. I want to see whats possible and some examples. So your first inclination is authoring? What kind of websites do you author? Are you more of a graphic designer or a web developer? If there were a landing page for a specific microformat (as Andy and cgriego have suggested. I beleive I'm hearing more and more consensus on this.) that had large items such as: * What is this? * What can I do here? * Show me a demo. * Create an hCard Which one would look most promising? If create an hcard went to the hcard creator, would this suprise you? I didn't even see that there was a page on authoring within the pages and pages of specification. Even with it at the top of the page. I glanced right over it. It seems like most tutorials on hCard or hCalendar point people to the spec to get more information. Should we be encouraging people to point to the authoring page? I think a newbie would be very very very intimidated being pointed right to the spec. Call me sick, but this is exactly the kind of thing I'm looking to collect. I've added it to http://microformats.org/wiki/wiki-feedback. Can everyone add their favorite complaint? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] hCard-o-matic toplevel div not address?
The address tag ... is designed to markup information related to the author of a particular page Too bad sites like the following don't make that more clear (reading it I never would have come to the conclusion that it was for the author of the current page): http://www.w3schools.com/tags/tag_address.asp Why do I bring this page up? This site is the first Google search result for HTML address tag and as such I'll bet a lot more people learn about it at places like this than the W3C specification which means probably tons of address tags used for reasons other than just the author of the current page. JMTCW, -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Robillard Sent: Monday, October 16, 2006 5:42 AM To: 'Microformats Discuss' Subject: RE: [uf-discuss] hCard-o-matic toplevel div not address? Jan, If I understand it correctly it comes down to the definition of the address tag. It is designed to markup information related to the author of a particular page (if this is true then you can use the address tag). I am sure if this is incorrect someone will correct me. HTH, Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jan Ptacek Sent: Monday, October 16, 2006 5:28 AM To: microformats-discuss@microformats.org Subject: [uf-discuss] hCard-o-matic toplevel div not address? hi, can someone pleas explain me why hCard creator uses a div as a toplevel element and not an address element? best regards jan ptacek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] ANN: The Purpose of Microformats
Another nit I just realized. I think you need to point out that it is legal to have more than one class in a class attribute (i.e. class=foo bar). I always assumed that you could have only have one class per element. My immediate reaction to Microformats was they were not practical until my misconception was cleared after which I became a convert. I would guess a lot of people might have a similar misconception. -Mike -Original Message- From: Mike Schinkel [mailto:[EMAIL PROTECTED] Sent: Monday, October 16, 2006 9:45 PM To: 'Microformats Discuss' Subject: RE: [uf-discuss] ANN: The Purpose of Microformats Roger: Nit: Semantic Hooks mentions class, rel, and rev but not title. Next, my first thought was I found the beginning confusing. The first slide I read is Purpose of Microformats and the second is (X)HTML. As I read the second (and third) I'm trying to figure out where the microformat examples are. I guess I was expecting and introductory statement about the purpose and then an overview of what your are going to tell explain. You know, the old Tell 'em what you're going to tell 'em, then tell 'em, then tell 'em what you said. I understand why you are giving background on XHTML, but for someone who doesn't already understand the subject I think the current organization could be very disorienting. That said, I started jotting down notes until I had completely restructured your presentation (based on my 7+ years experience in developing programming courseware and delivering those courses.) I'll include my note below my signature, but please accept them as merely suggestions to consider and, as I have no price of authorship, feel free to incorporate or discard any of my suggestions. Also please note, I didn't flesh everything out, so if you do incorporate a significant number of my suggestions you'll certainly need to rework some of it as I didn't flesh it out exhaustively, and in two case I left to be written with notes. JMTCW. -Mike Schinkel http://www.mikeschinkel.com/blog http://www.welldesignedurls.org/ = * Title Slide * Purpose of Microformats -- The purpose of microformats is to enrich the semantics of web Pages * To be covered -- What Problem do Microformats Solve? - See USe-cases for Microformats below, To be written -- Background: Let's Define Web Pages - Use (X)HTML page, Browser Rendering, (X)Html Semantics -- Goals and Constraints Chosen for Microformats - Use Microformat Goals (See below, to be written) - These Constraints are Sacred (from below) -- Example Microformat - Use existing -- Benefits - Use Aggregating Microformats, Other? -- Summary - Use (edited version of) Purpose of Microformats (Revised) -- Brilliance of Microformats - Use existing * Use-cases for Microformats -- (I don't think I've an explicit list mentioned anywhere yet) -- (If would be good to get a common set of use-cases to help everyone target the same outcomes) * Microformat Goals -- (This I know instintively but can't put into words in the context of goals. -- (Nothing I could find on Microformats.org is explicit in defining goals) -- (If would be good if there were a consensus, or at least if we were all aware.) * These Constraints were considered Sacred: -- No Update to existing Browsers Required - Use No New Markup (Change Markup to (X)HTML Tags and add Required) - Use Semantic Hooks, rename to Enhancing Semantics using Existing (X)HTML Tags - Use Many Ways to Mark Up Information, rename to Any Element can be Described -- No Impact to Presentation - Use existing slide -- Controlled process to eliminate Chaos - Use Standardized Class Values = -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Costello, Roger L. Sent: Monday, October 16, 2006 7:28 AM To: Microformats Discuss Subject: RE: [uf-discuss] ANN: The Purpose of Microformats Thanks Rob. Good suggestion. I have added two new slides - one that shows an example Microformat, the second shows an aggregator collecting Microformats in Web pages. http://www.xfront.com/microformats/Purpose-of-Microformats.html Thanks! /Roger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Unsworth Sent: Sunday, October 15, 2006 7:56 PM To: Microformats Discuss Subject: RE: [uf-discuss] ANN: The Purpose of Microformats On Sun, 15 Oct 2006, Costello, Roger L. wrote: Thanks a lot Tantek. That's exactly the kind of feedback I was seeking. I have made a few changes (added a couple new slides, modified a few slides). Please let me know if this now captures the purpose of Microformats. http://www.xfront.com/microformats/Purpose-of-Microformats.html Roger, As someone new to microformats and normally just lurking and learning I did notice, at least to me, a flaw in your slides. At the beginning you give examples using divs and spans and also
RE: [uf-discuss] hCalendar spec- no specification included!
Thanks. I subscribed to the page. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Tuesday, October 17, 2006 1:28 AM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! Mike, this is great. I really like it. Remember to check back and make sure progress is happening. Feel free to give me a nudge if I'm unresponsive. Ben On 10/16/06, Mike Schinkel [EMAIL PROTECTED] wrote: Would you mind confiming this on the to-do page under my name [1]? I added, see if it is what you were wanting... If it somehow differs from the suggestions there (under information architecture) would you please explain how it differs? Okay. Note I did not change anything outside my comments, I just added my comments. Also please list your specific suggestions, as well as, if possible, where content for the pages you suggest may be gleaned, The current microformat pages (i.e. http://microformats.org/wiki/hcard/) and any they reference. I think this will become obvious during reorganization. and which pages would need new content that doesn't yet exist. I think any list I create on my own (beyond my first list, which is just a starting point) will be ill-conceived and incomplete. They need to be gleened during the process of reorganization as a collective effort. I think you may have illuminated the intent more clearly than it has been explained so far, and so your refinement on the wiki would be very helpful. Thanks for the ack. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Tuesday, October 17, 2006 12:12 AM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! Mike, Thanks for you suggestion. I believe this is exactly what cgriego and Andy and I have just suggested. Would you mind confiming this on the to-do page under my name [1]? If it somehow differs from the suggestions there (under information architecture) would you please explain how it differs? Also please list your specific suggestions, as well as, if possible, where content for the pages you suggest may be gleaned, and which pages would need new content that doesn't yet exist. I think you may have illuminated the intent more clearly than it has been explained so far, and so your refinement on the wiki would be very helpful. Thanks, Ben [1] http://microformats.org/wiki/to-do#Information_Architecture On 10/16/06, Mike Schinkel [EMAIL PROTECTED] wrote: I agree that the current layout is confusing. After reading several of these email I would like to make a suggestion that is smaller scope than an entire reorganization (which still might be a good idea.) Tantek suggests that the specifications are not tutorials and others have said that they (think newbies would be) interested in authoring, not the specification and I concur. What if we use a convention that the entry page (i.e. http://microformats.org/wiki/hcard) would be an index into a list of (psuedo) standardized sub pages so that it would be very people to find what is important to them. For example, is a list of potential sub pages: * Specification * Tutorial * Examples * Use cases * Reference * Discussion * Brainstorming (might be combined w/Discussion) * Implementations * Related Pages * Further Reading * All (Uses Mediawiki's includes to create a page including all sub pages; very useful for printing reading offline) These pages would be located respectively at * http://microformats.org/wiki/hcard/Specification * http://microformats.org/wiki/hcard/Tutorial * http://microformats.org/wiki/hcard/Examples * http://microformats.org/wiki/hcard/Use_cases * http://microformats.org/wiki/hcard/Reference * http://microformats.org/wiki/hcard/Discussion * http://microformats.org/wiki/hcard/Brainstorming * http://microformats.org/wiki/hcard/Implementations * http://microformats.org/wiki/hcard/Related_Pages * http://microformats.org/wiki/hcard/Further_Reading * http://microformats.org/wiki/hcard/All Please note I am suggesting an architecture not a specific list of sub pages. The list of sub pages should be defined by both reviewing existing information during site reorganization, and then via discussion on the list in an attempt to discover and extract which sub pages are needed for most/all microformats. Hope this is useful... -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Monday, October 16, 2006 5:29 PM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! On 10/16/06, Justin Thorp [EMAIL PROTECTED] wrote: Ben, I really like your idea of giving the wiki a better sense of organization
[uf-discuss] Lightweight Data Access Services and Well Designed Urls
for search engines? Do not confuse Web Architecture with URLs. That's the part which is not understood from REST Web architecture style. I'm not sure I can confuse them yet because I don't really know what Web Architecture is other than a highly abstract term used to describe the collective technology architecture for all that is the web. Is is mean something else to which I am just ignorant? I encourage your to read this excellent series of posts by Joe Gregorio http://www.oreillynet.com/tags.csp?tag=rest I reviewed these but didn't find anything that was new to me as I've been collecting articles about REST and about building APIs. I include them so you can see my influences: About REST for Web Services * Building Web Services the REST Way http://www.xfront.com/REST-Web-Services.html * REST: Simplicity in Web Services design http://searchwebservices.techtarget.com/tip/0,289483,sid26_gci1148486,00.ht ml * Representational State Transfer (REST) http://en.wikipedia.org/wiki/Representational_State_Transfer at Wikipedia orld http://www.infoworld.com/ How to Build an API * How to Design a Good API and Why it Matters http://lcsd05.cs.tamu.edu/slides/keynote.pdf * How to design Good APIs and Why they Matter http://www.cincomsmalltalk.com/blog/blogView?showComments=trueentry=325815 8706 * How To Provide A Web API http://www.sourcelabs.com/blogs/ajb/2006/08/how_to_provide_a_web_api.html * How to Add an API to your Web Service http://particletree.com/features/how-to-add-an-api-to-your-web-service/ * Simple API Design http://loudcarrot.com/Blogs/dave/archive/2004/09/26/552.aspx * How To Design a (module) API http://openide.netbeans.org/tutorial/api-design.html%20 I am going to print and read your articles just in case I missed some things while scanning them over. I'm anxious to know your thoughts based on my clarification. Also, would there be sufficient interest for me to start a list now, and invite anyone interested to come on over? I'll need 5-10 interested parties otherwise it won't be time yet. -Mike Schinkel http://www.mikeschinkel.com/blog http://www.welldesignedurls.org/ P.S. I've also rethought the name Casual Web Services and think that is not the best. I'm now thinking Lightweight Data Access Services. (I changed the subject to recognize that.) Actually, I have an even more creative meme for it, but I'm not ready to reveal that yet. ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karl Dubost Sent: Tuesday, October 17, 2006 1:27 AM To: Microformats Discuss Subject: Re: [uf-discuss] Casual Web Services and Well Designed Urls Le 14 oct. 2006 à 18:02, Mike Schinkel a écrit : I recently started working on a project I'm calling Well Designed Urls (http:///www.welldesignedurls.org/) that has been a pet issue of mine for a long time. See my Aug 2005 blog post: http://www.mikeschinkel.com/blog/welldesignedurlsarebeautiful.aspx There are interesting things in your post BUT be careful of Well Known Location issues. Trying to standardize URLs would be very bad by limiting the choices of users. In these cases, there is a balance between what do we improve and what are the problems we create in the ecosystem. As an example Link Ranking Systems have increased spam on the Web and nofollow didn't solve it at all. Microformats have a poor man namespace mechanism which is the profile in the head. It helps people using the same class names to be free to use them without the same semantic (with the hope that search engines, do not index microformats not properly identified by the profile.) Do not confuse Web Architecture with URLs. That's the part which is not understood from REST Web architecture style. I encourage your to read this excellent series of posts by Joe Gregorio http://www.oreillynet.com/tags.csp?tag=rest -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: Know your stuff: (Was: [uf-discuss] hCard-o-matic toplevel div notaddress?)
I think the reorganization to create mini-home pages for each microformat will make it easy to find and remember those, i.e http://microformats.org/wiki/hcard/faq -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frances Berriman Sent: Tuesday, October 17, 2006 4:16 AM To: Microformats Discuss Subject: Know your stuff: (Was: [uf-discuss] hCard-o-matic toplevel div notaddress?) This is a good example of how we should be using the wiki better. I didn't realise that the hCard FAQ covered the address matter, which is one that is mentioned often. I think it would be valuable for people (including myself!!) who wish to help guide new people to get to know the FAQ pages well, and add to them as appropriate, and also then USE those resources as often as possible when helping people out. This in turn encourages everyone to document properly, I hope. F On 10/17/06, Chris Messina [EMAIL PROTECTED] wrote: This has been discussed previously and Steve is correct http://microformats.org/discuss/mail/microformats-discuss/2005-June/00 0013.html http://microformats.org/discuss/mail/microformats-discuss/2005-Novembe r/001870.html This has been previously codified on the wiki: http://microformats.org/wiki/hcard-faq#Should_I_use_ADDRESS_for_hCards Chris -- Frances Berriman http://www.fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Lightweight Data Access Services and Well DesignedUrls
education (like this initiative strives to provide) 3.) Lack of developer Best Practices (like this initiative strives to provide) 4.) Lack of software vendors realizing the benefits 5.) Lack of software vendors incorporating URL Best Practices as a key component of their software design 6.) Many developers views of URLs as something internal 7.) And more, but it's late and I'm no longer thinking clearly. I also think that a certain class of software architects have value certain attributes would prefer, in a perfect world, that URLs be hidden. But they are not; the permeate everything about the web. So I am advocating rather than procede with the way we want things to be we proceed with the way things are and embrace the power of clean and meaningful URLs; Sites like Amazon, Google, eBay, Flickr, and YouTube certainly have and I would argue that is an important part of their success. I know some people will point to the fact that a lot of users do not understand URLs and that is a reason to avoid them. Well, if we always avoided things users didn't understand we'd never introduce anything new. In the days before Starbucks almost nobody in the USA would believe anyone would ever pay $5 for a cup of coffee. Starbucks presented that value proposition and proved everyone wrong. I believe the same is true of clean and meaningful URLs. If we create a high value proposition and do a good job of implementing them, people will learn to use URLs and use them wisely. (Also remember that as more of the people who entered school after the mid 90's enter the workforce, a greater percentage of users will understand URLs without even having to give it a second thought.) One place where I think URLs can be incredibly valuable is in helping to fix key usability problems with AJAX. But that's a subject for a different venue (as the above probably should have been.) (long off topic debate possible here about the notion of opacity and privacy) Yes, I've been studying that in the past day here[2] and in the yahoo groups [1], thanks to Nick Gall. From what I read, whoever wrote [2] seems to have the same ideas that I do. REST ... is not related to URL design :) That is your opinion. :) Roy T. Fielding however does seems to think URL design is useful[1]. Even one of the articles you provided me argue for designing the URLs as the first step in creating an REST web service[3]. But I am always open to have my mind changed given a well-supported argument as, unlike some people, I don't stay the course when I learn that the course is wrong (hopefully you'll grok that little bit of US-centric satire... ;-) As I said there are very interesting things about your list, but maybe the list [EMAIL PROTECTED] is more appropriate for this. I agree we need to take this elsewhere. Repeating what I said above, can you give me any pointers for sending my first post to that list? In closing, even though I disagreed with you on some topics I respect you for your position in the W3C and I greatly appreciate the time you've given me thus far. -Mike Schinkel http://www.mikeschinkel.com/blog http://www.welldesignedurls.org/ [1] http://tech.groups.yahoo.com/group/rest-discuss/messages/3188?threaded=1m=e var=1tidx=1 [2] http://rest.blueoxen.net/cgi-bin/wiki.pl?RestAndUriOpacity#nid1SK [3] http://www.xml.com/pub/a/2004/12/01/restful-web.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Karl Dubost Sent: Tuesday, October 17, 2006 9:39 PM To: Microformats Discuss Subject: Re: [uf-discuss] Lightweight Data Access Services and Well DesignedUrls Le 17 oct. 2006 à 17:20, Mike Schinkel a écrit : Many thanks for commenting. BUT be careful of Well Known Location issues. Can you give me examples? I googled Well Known Location and didn't find anything that seemed relevent. http://example.org/robots.txt http://example.org/favicon.ico http://example.org/p3p/ All of these tend to reduces the freedom of users, plus do not make them independent. For example, in the case of robots.txt, that some search engines ignore (sigh), you can't do things like http://farm.example.org/weblogA/robots.txt http://farm.example.org/weblogB/robots.txt For favicon.ico you can add a link to your header in your HTML page, but still some user agents will stupidly make a request to http:// example.org/favicon.ico link rel=icon type=image/png href=/somewhere/myicon.png / http://www.w3.org/2005/10/howto-favicon Trying to standardize URLs would be very bad by limiting the choices of users. I don't think I'm trying to standardize URLs per se. I'm instead trying to collect up, codify, and recommend patterns and practices. Yes but you have to make a BIG warning about bad practices too. Because people will run into the illusion of practical well-known locations. Since you commented, did you read this first? http://www.mikeschinkel.com/blog/welldesignedurlsarebeautiful.aspx
RE: title attribute and abbreviated classnames(Was:[uf-discuss]Currency Quickpoll: Preliminary results)
span class=money title=USD$5.99/span I still think this is bad semantics. I don't think USD is really a title for $5.99. I'll accept that. I'd propose this as an alternative: abbr class=currency title=USD$/abbr5.99 Okay... But is it a good idea to have a microformat as a prefix/suffix instead of as a container? (general question - I hope it hasn't been answered before...) If so, you'll also need (note the space after 35.66): 35.66 abbr class=currency title=DKKkr/abbr However, at the risk of being shot for heresy, has anyone considered allowing this? abbr class=currency usd$5.99/abbr abbr class=currency dkk35.66 kr/abbr OR (something tells me this is even worse, but...): abbr class=money currency-usd$5.99/abbr abbr class=money currency-dkk35.66 kr/abbr I'm sure there is something just so wrong about this, but part of the reason I'm on this list is to learn. So why not? Additionally, that would allow: abbr class=currency usd title=5.99Five Dollars and 99 cents/abbr abbr class=currency dkk title=35.66Thirty Five point 66 Kroners/abbr OR (for orthogonality): abbr class=money currency-usd title=5.99Five Dollars and 99 cents/abbr abbr class=money currency-dkk title=35.66Thirty Five point 66 Kroners/abbr Just a thought...? -Mike P.S. Damn I wish HTML had allowed rel for all tags including span and abbr. Or that we could just use it anyway and not get shot for heresy. :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Tuesday, October 17, 2006 10:30 AM To: Microformats Discuss Subject: Re: title attribute and abbreviated classnames(Was:[uf-discuss]Currency Quickpoll: Preliminary results) I've starting replying to this a few times and become stuck in trying to fit what I'm trying to say in the existing thread, so I'm just going to make some points completely detached from the thread. First, I think Mike is right that the vast majority of published money formats allow parsers to infer the distinction between the currency symbol and the amount. But this inference is already possible without a microformat. What's missing currently is: 1) an indication of which specific currency the symbol refers to. 2) the ability to markup money that doesn't fit this pattern I think it's best to either cover #1 or both, but I think it's too complicated for publishers to provide what amounts to two distinct microformats depending on a relatively complex pattern definition. That is, if we're going simple (only #1), I think we should go only simple, and add the complex form to cover #2 later. So to cover #1, Mike has suggested: span class=money title=USD$5.99/span I still think this is bad semantics. I don't think USD is really a title for $5.99. I'd propose this as an alternative: abbr class=currency title=USD$/abbr5.99 That is, markup the currency as currency, and treat any adjacent numbers as the amount. To cover #2, I think we need an additional class=money container, and a class=amount markup for the amount, and this could be added without changing the parsing rules for the simple form I've suggested above. I think it would be best to start with either simple or complex and look at adding the alternative after the microformat has gained some adoption. I don't think regular expressions should be included in the spec at all. If we're going to define amounts based on character ranges, we should describe those character ranges in plain English because most people, even most tech geeks, don't understand regular expressions at all. Peace, Scott On Oct 15, 2006, at 4:40 PM, Mike Schinkel wrote: Scott: Thanks for the reply. If probably got confusing on my part; I will try to resolve that here if possible. I thought what you suggested was to allow for explicit differentiation between the currency identifier and the amount, but in certain cases where such differentiation can be made by matching a regular expression, allow for markup without explicit differentiation, leaving the differentiation implicitly to the parser to figure out. For example, this would be valid:... because it does follow the pattern, where everything that's not within a certain character group is considered a currency symbol (i.e. $). If this isn't what you're suggesting, then I'm not clear on what you're suggesting. You got it 100%. But I did make a mistake in my example as I didn't mean to include alpha [A-Za-z]. It should just have been digits, periods, and commas [0-9\.\,]; everything else would be the currency symbol. I wasn't explicit about the following, but I will be now; no spaces (or nbsp;) and the currency figure must be contiguous and either prefix or suffix a collection of digits. Anythings else, and you need the complexity. Although I am not good with regex, I opened my regex book and my regex test
RE: RE: [uf-discuss] Casual Web Services and Well Designed Urls
Thanks for the input. but beware of the costs of creating reserved/manditory structures. Can you elaborate? Maybe with examples? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Suda Sent: Tuesday, October 17, 2006 9:26 AM To: Microformats Discuss Subject: Re: RE: [uf-discuss] Casual Web Services and Well Designed Urls On 10/16/06, Mike Schinkel [EMAIL PROTECTED] wrote: But the reason I bring them up here on Microformats discuss as I see clean URLs as being important for being able to easily screen scrape microformats in a reliable manner for retrieving data programmatically as opposed to them being just useful for someone to click a bookmarklet and gather some information for personal use. Without clean understandable URLs, Microformats are far less useful, IMO. --- sorry, i can't find a reference, but somewhere there was a big discussion about ROBOTS.TXT, and FAVICON.ICO, while having a standard name is helpful, it has also created a reserved word out of those file names. I personally like the way RSS Autodiscovery works, you can name the file (or files) anything you want and simply point to those. I personally like clean well-structured URLs, but beware of the costs of creating reserved/manditory structures. That's just my two cents, -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] hCalendar spec- no specification included!
Benjamin: As one data point, I learned about Microformats[1] at a conference[2]. When I came to the site I wanted to learn how to author them. In addition, I wanted to learn how to get involved in the process of specifying new ones (although I doubt only a small percentage will be interested in that.) -Mike [1] http://www.mikeschinkel.com/blog/MicroformatsHCard.aspx [2] http://www.mikeschinkel.com/blog/CarsonWorkshopsFutureOfWebAppsConferenceWas Incredible.aspx -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Wednesday, October 18, 2006 1:00 PM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! Justin, Would you mind visiting http://microformats.org/wiki/to-do#Information_Architecture and adding your support? While we're on the subject of newbies, if they first hear about microformats from the sources you mentioned, what kind of people are they? Are they graphic designers? Web developers? Business people? It appears that microformat newbies are the kind of people that go to conventions. What do these people expect when they visit for the first time? Most web browsing is task-oriented. Do they want to find out how to author microformats? Learn more about what they are? Find out why they exist? Ben On 10/18/06, Justin Thorp [EMAIL PROTECTED] wrote: I really like this idea. What if the landing page for the microformat wasn't the spec but it was some warm and fuzzy intro for newbies? It could then link to the spec for those that were interested to it. A good example of this would be the W3C WAI's intro for WCAG that they give you before you get sent right into WCAG 1.0. http://www.w3.org/WAI/intro/wcag I would expect that a lot of newbies start off hearing about microformats on tutorials like: http://www.digital-web.com/articles/microformats_primer/ http://www.thinkvitamin.com/features/design/how-to-use-microformats Or from presentations like: http://tantek.com/presentations/2006/09/microformats-practices/ They get linked to the spec and then get offly confused. -justin thorp ** Justin Thorp Web Services - Office of Strategic Initiatives Library of Congress e - [EMAIL PROTECTED] p - 202/707-9541 [EMAIL PROTECTED] 10/17/06 3:39 PM In message [EMAIL PROTECTED], Benjamin West [EMAIL PROTECTED] writes Regarding the specs bit, I meant to refer to the various stages of the process. The spec landing page might contain the big questions, with a status section pointing to pages dedicated toward how the spec is moving through the process, and with the learn more section pointed at the spec itself. If the spec itself is on a secondary page, then the landing page isn't the spec. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] hCalendar spec- no specification included!
Actually this is already done. There are generators/creators/___-o-matics or whatever the current term is for hReview, hAtom, hCard, and hCalendar, AFAIK. I believe they are all linked to from their respective wiki page. The point is there isn't necessarily one for a new spec. Until someone builds one. So my point was I wouldn't see a generators/creators as the entry point for a microformat, that's all. I think we all agree that some parts of the wiki have room for a lot of improvement. I was addressing Andy's point, not the group in general. Yahoo is much more used than Google :-). However, that's irrelevant. But you use Gmail. Why not Yahoo mail? ;-) I believe the landing page for each format should answer the big questions common to all readers when they arrive at a landing page, and then quickly and thoughtlessly funnel readers into the sections most relevant to their interests. My point was simply to be careful not to overwhelm the user with text on a intro page as it has been proven people scan web pages instead of reading them[1]. Less will be more here. Justin presents this[2] as an example, but I find it to be far too much information on an intro page. This is a general principle, of course, not true in all cases but likely true for an intro page. Os I would highly suggest that whoever is involved in creating intro pages first read this[1]; it was eye opening when I first read it. This includes information how authoring, principles of creation, what the format is suited for, and of course the spec itself. I don't mean that these resources are on the landing page, but rather that the landing page should act as a funnel, quickly allowing the reader to sort out which direction has the scent of information they are looking for. I completely agree. Let's be careful to not exclusively talk about the specs. The wiki contains many kinds of information. While the specs are arguably the most important kind, they aren't the only kind. There is a lot of supporting material, including web authoring tips, faqs, principles, community information, discussions of goals... I want to make sure we can identify what's on the wiki in terms of larger categories, AND organize the specs. The two categorization efforts should inform each other. Again I agree. I think specs are *the most important thing* to one class of people, i.e. those specifying the spec. As such it's no surprise that the spec gets primary focus, at least initially. But it needs to be balanced because there are many classes of people and for each of them there is potentially a different most important thing. So it needs to all be easily accessible and findable understanding how users read web pages[1]. And sorry if I'm overstating that which everyone may already be agreeing on. :) -Mike [1] http://www.useit.com/alertbox/9710a.html [2] http://www.w3.org/WAI/intro/wcag -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Wednesday, October 18, 2006 5:06 PM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! On 10/18/06, Mike Schinkel [EMAIL PROTECTED] wrote: A form would be nice, but it takes time to develop and we can't expect they will be developed before people are interested. Actually this is already done. There are generators/creators/___-o-matics or whatever the current term is for hReview, hAtom, hCard, and hCalendar, AFAIK. I believe they are all linked to from their respective wiki page. OTOH, most people can't read a spec and make heads nor tails of it (I know that I struggle with W3C specs), so there is the spec and then there is the tutorial (or similar.) All can be clearly linked from the mini-home page. This is just like Creative Commons where they have the human readable license and then you can see the lawyese if you really want. I've never even looked at the lawyered one, have you? I don't need to; the simple version works much better for me and is all I need. Something that tells the average Joe how to author in simple language with good examples is what will be most beneficial for most people. I think we all agree that some parts of the wiki have room for a lot of improvement. Reasonable, but it needs some content, so as not to appear dry and unwelcoming. Not to be contrary, but see How Users Read on the Web[1]. Content for content sake is less than useful. Google's home page is dry but it's used by more people than any other (or if not, I don't know what is) because it meets people's needs better than the alternative (or they would switch.) Yahoo is much more used than Google :-). However, that's irrelevant. I believe the landing page for each format should answer the big questions common to all readers when they arrive at a landing page, and then quickly and thoughtlessly funnel readers into the sections most relevant to their interests
RE: [uf-discuss] hCalendar spec- no specification included!
We can't expect people to use something for which there is no spec! And we can't expect a form to be developed when there isn't a spec either. I don't need to; the simple version works much better for me and is all I need. Something that tells the average Joe how to author in simple language with good examples is what will be most beneficial for most people. Agreed. Did I say otherwise? My memory was that you did. If you didn't, then forgive me for bringing it up. Indeed. Did I ask for content for content's sake? Honestly, as we are now spending more time on discussing our discussions, I am starting to think we are just debating for the purpose debate. I think it's time to wind down (my participation in) this thread. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Wednesday, October 18, 2006 5:40 PM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes I don't think anyone has said that. I certainly don't think people should be encouraged to begin authoring before first understanding what the are nad are not allowed to do (unless by authoring you mean fill in a form and let a machine do the authoring for you) A form would be nice, It might be; note that I wasn't calling for one. but it takes time to develop and we can't expect they will be developed before people are interested. We can't expect people to use something for which there is no spec! [...] This is just like Creative Commons where they have the human readable license and then you can see the lawyese if you really want. I've never even looked at the lawyered one, have you? Yup. I don't need to; the simple version works much better for me and is all I need. Something that tells the average Joe how to author in simple language with good examples is what will be most beneficial for most people. Agreed. Did I say otherwise? Reasonable, but it needs some content, so as not to appear dry and unwelcoming. Not to be contrary, but see How Users Read on the Web[1]. What, again? Content for content sake is less than useful. Indeed. Did I ask for content for content's sake? Once they standard is set, the brainstorming (and related examples) is only of archival interest. Note that I said my list was just a set to start discussion Note that I was discussing it. I note that your list does not include an explanation of Semantic XHTML... Again, as I said, my list was just a set to start discussion... Note that I wasn't criticising you for omitting it. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Size considerations
Has there been any thought to try and survey the web development community at large on these types of issues? I could see the value of having a lot of these types of questions answered if we were do present surveys (of course hopefully we could find a surveying expert to help us make sure we were writing our questions so as not to bias the answers.) We might be able to get places like SitePoint to promote the surveys if we created them. Just a thought? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Roper Sent: Wednesday, October 18, 2006 2:17 PM To: Microformats Discuss Subject: Re: [uf-discuss] Size considerations Scott Reynen wrote: I agree with all of this, but I think a more fundamental issue is that this problem is always presented as a hypothetical, and we shouldn't spend out time trying to solve hypothetical problems. We know readability is a problem when someone can't understand something. We'll know size is a problem when someone says they can't implement microformats due to size. No one has ever said that, as far as I know. It's hypothetical because not many people are using microformats yet. However, we *do* know that people are concerned with file sizes and html bloat as this was one of the main selling points of switching to tableless CSS designs was that of reducing file size [1]. Javascripters also go to extreme lengths to compress their large libraries, often using cryptic variable and object names to shave off a few more bytes. The (lack of) size in a js library has become a feature. I don't happen agree with the practice of sacrificing readability for file size and others seem to agree [2]. [1] http://www.stopdesign.com/articles/throwing_tables/ [2] http://tinyurl.com/y2twvy The thing is, I don't think it's as black or white as saying one can/can't implement microformats due to size. Size should be a *consideration*, surely, and compromises need to be made. I just think, given the balance of pros and cons for longer, more readable, attributes, I'd go with longer. Cheers, Charles -- Charles Roper www.charlesroper.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] hCalendar spec- no specification included!
Justin: Very good organization! JMTCW. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Justin Thorp Sent: Wednesday, October 18, 2006 4:57 PM To: microformats-discuss@microformats.org Subject: Re: [uf-discuss] hCalendar spec- no specification included! Ben, I will try and get to the IA page tonite and see if I can add some comments and thoughts. I think the people reading the articles about microformats and jumping into the spec cold are the early adoptor web developers. My uneducated opinion is that microformats is a fairly new movement. Regardless, it seems like it would be in the best interest of what we are trying to do to write all of our stuff and organize it so that it also works for the 50 year old web systems programmer who may be slow to adopting (stubborn) new technologies but was told by his boss he has to look at the business applications of adopting microformats. If I land on Microformats.org for the first time, just wanting to learn, I am going to be looking for something that says intro or new or tutorial. It needs to answer the who, what, when, where, why, and how. It shouldn't use jargonny language. If I am new and reading about hCard or hCalendar for the first time. I want to figure out BRIEFLY what the background is. I don't need a history of vCard. I'd want some examples. Id want to know about what sites use them. I'd want tools to help build them. Id want a list of all the different class names and where I can and can not use them (the rules). I'd leave semantic principles in a doc that you can link to. Maybe mention it briefly. Hope this helps. Cheers, Justin Thorp ** Justin Thorp Web Services - Office of Strategic Initiatives Library of Congress e - [EMAIL PROTECTED] p - 202/707-9541 [EMAIL PROTECTED] 10/18/06 12:59 PM Justin, Would you mind visiting http://microformats.org/wiki/to-do#Information_Architecture and adding your support? While we're on the subject of newbies, if they first hear about microformats from the sources you mentioned, what kind of people are they? Are they graphic designers? Web developers? Business people? It appears that microformat newbies are the kind of people that go to conventions. What do these people expect when they visit for the first time? Most web browsing is task-oriented. Do they want to find out how to author microformats? Learn more about what they are? Find out why they exist? Ben On 10/18/06, Justin Thorp [EMAIL PROTECTED] wrote: I really like this idea. What if the landing page for the microformat wasn't the spec but it was some warm and fuzzy intro for newbies? It could then link to the spec for those that were interested to it. A good example of this would be the W3C WAI's intro for WCAG that they give you before you get sent right into WCAG 1.0. http://www.w3.org/WAI/intro/wcag I would expect that a lot of newbies start off hearing about microformats on tutorials like: http://www.digital-web.com/articles/microformats_primer/ http://www.thinkvitamin.com/features/design/how-to-use-microformats Or from presentations like: http://tantek.com/presentations/2006/09/microformats-practices/ They get linked to the spec and then get offly confused. -justin thorp ** Justin Thorp Web Services - Office of Strategic Initiatives Library of Congress e - [EMAIL PROTECTED] p - 202/707-9541 [EMAIL PROTECTED] 10/17/06 3:39 PM In message [EMAIL PROTECTED], Benjamin West [EMAIL PROTECTED] writes Regarding the specs bit, I meant to refer to the various stages of the process. The spec landing page might contain the big questions, with a status section pointing to pages dedicated toward how the spec is moving through the process, and with the learn more section pointed at the spec itself. If the spec itself is on a secondary page, then the landing page isn't the spec. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org
RE: [uf-discuss] hCalendar spec- no specification included!
That's actually not true. The spec is the most important thing to people *implementing* the spec. Opps, you caught my lack of meticulousness! I was focusing on making the point that where were many classes of people each potentially interested in something different and was otherwise being casual. Please forgive my being careless regarding who was interested in what. :) Thanks for this feedback Mike - you make very good points. Thanks in return. It is nice to know when one's efforts are appreciated. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç elik Sent: Wednesday, October 18, 2006 7:13 PM To: microformats-discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! On 10/18/06 4:04 PM, Mike Schinkel [EMAIL PROTECTED] wrote: My point was simply to be careful not to overwhelm the user with text on a intro page as it has been proven people scan web pages instead of reading them[1]. Less will be more here. Justin presents this[2] as an example, but I find it to be far too much information on an intro page. This is a general principle, of course, not true in all cases but likely true for an intro page. Os I would highly suggest that whoever is involved in creating intro pages first read this[1]; it was eye opening when I first read it. This is an excellent point Mike, and one I strongly agree with. I have taken it to heart and will seek to simplify/reduce the text on intro type pages as much as possible without losing meaning/utility. Again I agree. I think specs are *the most important thing* to one class of people, i.e. those specifying the spec. That's actually not true. The spec is the most important thing to people *implementing* the spec. Implementers need to be able to read very precise descriptions of what they are implementing in order to maximize the chances of them implementing it correctly and interoperably. As such it's no surprise that the spec gets primary focus, at least initially. But it needs to be balanced because there are many classes of people and for each of them there is potentially a different most important thing. So it needs to all be easily accessible and findable understanding how users read web pages[1]. Strongly agreed. Thanks for this feedback Mike - you make very good points. Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] hCalendar spec- no specification included!
See my todo list. Suggestion: can you be sure to include the actual URL of any referenced item in any emails to make sure I can actually find it. :) Do you think you can do a refinement of your categories on the to-do list? Can you also enumerate the categories of content generally available on the wiki? Again, same comment... And was this for me, or everyone? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Wednesday, October 18, 2006 7:24 PM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! The point is there isn't necessarily one for a new spec. Until someone builds one. No worries here. I'm commited to doing this. See my todo list. Is there any that are missing? So my point was I wouldn't see a generators/creators as the entry point for a microformat, that's all. Ah, ok. Summary: * Support Scanning * Don't overwhelm with resources/text * Provide strong scents for where relevant information lives. And sorry if I'm overstating that which everyone may already be agreeing on. Building consensus and making sure we understand one another isn't a waste of time. But now that we all agree, let's please start taking notes and mentally sifting through everything. Do you think you can do a refinement of your categories on the to-do list? Can you also enumerate the categories of content generally available on the wiki? I'm thinking: * Advocacy of Best Practices ( Do we really want to do this? there are other places that do this) * FAQ ( Both general and specific to each format. how do we present this?) * Spec Materials (Landing page, getting started, guides, and spec.) Can we somehow fit all the content on the wiki into these areas? Would it address the concerns on the wiki-feedback page? Are there categories missing? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Size considerations
?pagegid=%7BDDFB039D-A90D-41E3-8A37-F3B4966 A98C7%7D http://www-304.ibm.com/jct03001c/services/learning/ites.wss/us/en?pageType=p agec=a0006661 http://www.rosicrucian.com/docs/pricelist.pdf http://www.guitar9.com/pricelistinstr.html -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Wednesday, October 18, 2006 7:52 PM To: Microformats Discuss Subject: Re: [uf-discuss] Size considerations On Oct 18, 2006, at 6:34 PM, Mike Schinkel wrote: The following is 6 characters: $54.97 This is 151 characters (according to MS-Word's stats dialog): span class=money span class=symbol title=dollar$/span abbr class=currency title=USD span class=amount54.97/span /abbr /span So let's think about a price matrix with 10 columns and 100 rows. Without markup it would be 6000 bytes or 5.85Kb just for the 1000 prices. With markup it would be 151,000 bytes, or 147.5Kb just for the prices. Who is publishing 10 columns and 100 rows of prices or something similar? It would be helpful to look at some real-world markup so we can come up with practical ways to address this concern. If it's in rows and columns, I would assume each price to be in a td, so span class=money becomes just td class=money, removing 14 characters by my count. But it's hard to know if this is a realistic assumption when we're dealing with hypothetical markup. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] hCalendar spec- no specification included!
Point taken, I'll include more URI's when I should. Thanks. If there is a creator missing, I'll gladly come up with something. That said, I'll use this as an opening to pose a question that I've been wanting to pose since I haven't gotten all my thoughts 100% sorted on the subject, but I can do it less formally tagging onto this thread... It seems to me that a spec in a necessary but not sufficient condition for maximum adoption. Additionally I see these things as needed: * Reference implementation in Javascript for add-ins to web-based text editors for blog, forum, and wiki software * Reference implementations in Java, .NET, Ruby, PHP, Python, etc. as Windows, Mac, and Linux components for add-ins to desktop web publishing apps * Reference implementations in Java, .NET, Ruby, PHP, Python, etc. for parsing HTML pages in Microformats * Evangelism to Website owners * Evangelism to Software Platform and Tool vendors I'm sure there are more, but I see these as critical, and I'm not sure what level of efforts or even awareness there are towards these ends. I'd love to be involved in some of these efforts although currently I personally don't have enough consulting revenue to support such efforts and no one is currently sponsoring me to be involved here (this is just a personal interest I have.) What's more, I'm not sure what everyone view the goals of Microformats and the envisioned use-cases. I'm coming to believe that there are some very different assumed goals use-cases among the people in discussions (not because of anything specific, just a feeling I have.) Without clarifying these, I think we'll be at cross purposes long term. I guess I should probably have started a new thread on this...? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Wednesday, October 18, 2006 8:08 PM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! Mike, But I'm so lazy. Point taken, I'll include more URI's when I should. Mike, your comments are under http://microformats.org/wiki/to-do#Information_Architecture. I did the hAtom creator and am interested in further work on the creators. http://microformats.org/wiki/to-do#Creators If there is a creator missing, I'll gladly come up with something. Ben On 10/18/06, Mike Schinkel [EMAIL PROTECTED] wrote: See my todo list. Suggestion: can you be sure to include the actual URL of any referenced item in any emails to make sure I can actually find it. :) Do you think you can do a refinement of your categories on the to-do list? Can you also enumerate the categories of content generally available on the wiki? Again, same comment... And was this for me, or everyone? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Wednesday, October 18, 2006 7:24 PM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! The point is there isn't necessarily one for a new spec. Until someone builds one. No worries here. I'm commited to doing this. See my todo list. Is there any that are missing? So my point was I wouldn't see a generators/creators as the entry point for a microformat, that's all. Ah, ok. Summary: * Support Scanning * Don't overwhelm with resources/text * Provide strong scents for where relevant information lives. And sorry if I'm overstating that which everyone may already be agreeing on. Building consensus and making sure we understand one another isn't a waste of time. But now that we all agree, let's please start taking notes and mentally sifting through everything. Do you think you can do a refinement of your categories on the to-do list? Can you also enumerate the categories of content generally available on the wiki? I'm thinking: * Advocacy of Best Practices ( Do we really want to do this? there are other places that do this) * FAQ ( Both general and specific to each format. how do we present this?) * Spec Materials (Landing page, getting started, guides, and spec.) Can we somehow fit all the content on the wiki into these areas? Would it address the concerns on the wiki-feedback page? Are there categories missing? Ben ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats
RE: title attribute and abbreviatedclassnames(Was:[uf-discuss]Currency Quickpoll: Preliminary results)
What happened to: span class=moneyabbr class=currency title=USD$/abbrspan class=amount5.99/span/span I brought up the issue of the markup being large and complex to implement, and so we were discussing suggestions about how to potential streamline the markup. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Paul Weber Sent: Wednesday, October 18, 2006 7:55 PM To: Microformats Discuss Subject: Re: title attribute and abbreviatedclassnames(Was:[uf-discuss]Currency Quickpoll: Preliminary results) On 10/18/06, Mike Schinkel [EMAIL PROTECTED] wrote: span class=money title=USD$5.99/span I still think this is bad semantics. I don't think USD is really a title for $5.99. I'll accept that. I'd propose this as an alternative: abbr class=currency title=USD$/abbr5.99 What happened to: span class=moneyabbr class=currency title=USD$/abbrspan class=amount5.99/span/span Does that solve the whole problem and give us an extra usefulness at the same time (sorry for leaving a discussion and then just jumping back in again. Ignore me if I make no sense.) Okay... But is it a good idea to have a microformat as a prefix/suffix instead of as a container? (general question - I hope it hasn't been answered before...) If so, you'll also need (note the space after 35.66): 35.66 abbr class=currency title=DKKkr/abbr However, at the risk of being shot for heresy, has anyone considered allowing this? abbr class=currency usd$5.99/abbr abbr class=currency dkk35.66 kr/abbr OR (something tells me this is even worse, but...): abbr class=money currency-usd$5.99/abbr abbr class=money currency-dkk35.66 kr/abbr I'm sure there is something just so wrong about this, but part of the reason I'm on this list is to learn. So why not? Additionally, that would allow: abbr class=currency usd title=5.99Five Dollars and 99 cents/abbr abbr class=currency dkk title=35.66Thirty Five point 66 Kroners/abbr OR (for orthogonality): abbr class=money currency-usd title=5.99Five Dollars and 99 cents/abbr abbr class=money currency-dkk title=35.66Thirty Five point 66 Kroners/abbr Just a thought...? -Mike P.S. *** I wish HTML had allowed rel for all tags including span and abbr. Or that we could just use it anyway and not get shot for heresy. :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Tuesday, October 17, 2006 10:30 AM To: Microformats Discuss Subject: Re: title attribute and abbreviated classnames(Was:[uf-discuss]Currency Quickpoll: Preliminary results) I've starting replying to this a few times and become stuck in trying to fit what I'm trying to say in the existing thread, so I'm just going to make some points completely detached from the thread. First, I think Mike is right that the vast majority of published money formats allow parsers to infer the distinction between the currency symbol and the amount. But this inference is already possible without a microformat. What's missing currently is: 1) an indication of which specific currency the symbol refers to. 2) the ability to markup money that doesn't fit this pattern I think it's best to either cover #1 or both, but I think it's too complicated for publishers to provide what amounts to two distinct microformats depending on a relatively complex pattern definition. That is, if we're going simple (only #1), I think we should go only simple, and add the complex form to cover #2 later. So to cover #1, Mike has suggested: span class=money title=USD$5.99/span I still think this is bad semantics. I don't think USD is really a title for $5.99. I'd propose this as an alternative: abbr class=currency title=USD$/abbr5.99 That is, markup the currency as currency, and treat any adjacent numbers as the amount. To cover #2, I think we need an additional class=money container, and a class=amount markup for the amount, and this could be added without changing the parsing rules for the simple form I've suggested above. I think it would be best to start with either simple or complex and look at adding the alternative after the microformat has gained some adoption. I don't think regular expressions should be included in the spec at all. If we're going to define amounts based on character ranges, we should describe those character ranges in plain English because most people, even most tech geeks, don't understand regular expressions at all. Peace, Scott On Oct 15, 2006, at 4:40 PM, Mike Schinkel wrote: Scott: Thanks for the reply. If probably got confusing on my part; I will try to resolve that here if possible. I thought what you suggested was to allow for explicit differentiation between the currency identifier and the amount, but in certain cases where
RE: [uf-discuss] Size considerations
The point I am trying to make is this: file size *is* an issue, but it is not an insurmountable problem and can be solved through technology and good design; file size shouldn't compromise the semantics and design of a microformat. Since I was the one that originally called the question I want to also point out that, related to size of the microformat, if a microformat is too conceptually large (and complex) it is less likely to be applied than if it is simple and easy. Remember, there are lots of people publishing web pages that are far from technical... (Sorry if I'm belaboring the point...) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Roper Sent: Thursday, October 19, 2006 3:41 AM To: Microformats Discuss Subject: Re: [uf-discuss] Size considerations Scott Reynen wrote: Who is publishing 10 columns and 100 rows of prices or something similar? It would be helpful to look at some real-world markup so we can come up with practical ways to address this concern. If it's in rows and columns, I would assume each price to be in a td, so span class=money becomes just td class=money, removing 14 characters by my count. But it's hard to know if this is a realistic assumption when we're dealing with hypothetical markup. Here's an example of a page that would be made larger if a species microformat were applied to it that used the longer class names (they're pretty long already): http://www.sxbrc.org.uk/biodiversity/speciesinventories/psrlist.php It's not a great example as it's a short list without much detail. The scientific community often share long lists such as this, although web users outside of this field probably don't come across them often. HOWEVER, there are design and implementation decisions on my part as the developer and designer of a site I would take *before* I ruled out using uFs due to their size. (I would consider 100K to long, btw) These are: 1. I would apply output compression (which I have done in the example above, taking it from 17835 bytes down to 3972 bytes) 2. If the list were to grow much longer than it already is, I would consider it a bad fit for a one page design and redesign with a paging and search mechanism. 3. If #2 came into effect, and visitors required one long list (which I know they do), then I would offer a variety of download options *including* the big HTML version. The point I am trying to make is this: file size *is* an issue, but it is not an insurmountable problem and can be solved through technology and good design; file size shouldn't compromise the semantics and design of a microformat. -- Charles Roper www.charlesroper.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Size considerations
Okay... Did I just make more work for myself? :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Roper Sent: Thursday, October 19, 2006 3:45 AM To: Microformats Discuss Subject: Re: [uf-discuss] Size considerations Mike Schinkel wrote: Has there been any thought to try and survey the web development community at large on these types of issues? I could see the value of having a lot of these types of questions answered if we were do present surveys (of course hopefully we could find a surveying expert to help us make sure we were writing our questions so as not to bias the answers.) We might be able to get places like SitePoint to promote the surveys if we created them. I think that's a *great* idea, Mike. -- Charles Roper www.charlesroper.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Size considerations (or how to choose abbreviations)
The point I am trying to make is abbreviations can be very dangerous and are very easy to mis-interpret so I think we need to think long and hard before choosing and implementing them. I am not arguing against them in specific cases but very well thought out cases. I have a question about that. I'll use the example of money because it's one I'm more familiar with. In this particular case, we have money, currency, and amount: span class=money abbr class=currency title=USD$/abbr span class=amount5.99/span /span However, and this is an honest question, isn't currency and amount really only valid in context with money? Wouldn't that make it okay to abbreviate the children of money, like so?: span class=money abbr class=cur title=USD$/abbr span class=amt5.99/span /span -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Rines Sent: Thursday, October 19, 2006 10:45 PM To: microformats-discuss@microformats.org Subject: Re: [uf-discuss] Size considerations (or how to choose abbreviations) In message [EMAIL PROTECTED] Charles Roper [EMAIL PROTECTED] in addition to other things said: Should bin, var, cult, etc., be written in full? (I think not, to save bloating file sizes) These abbreviations are absolutely fine within the very narrow domain of biological nomenclature and taxonomy, but expanded out into the wider domain, then they become horribly generic and lose their meaning. Same with using sci. In message [EMAIL PROTECTED] Andy Mabbett [EMAIL PROTECTED] in addition to other things said: And yet we have geo. I think comparing geo and sci, etc. is not a great example as I think geo can be thought of as a well known abbreviation. As with much other microformat work a well known standard or abbreviation like vcard I think geo can is a (or close to) standard so it is a safe abbreviation which I think is what we should be aiming for when creating an abbreviation of any type. I do realize GEO is being used by others such as the Gene Expression Omnibus (GEO) but I THINK what I say holds as geo being an implied abbreviation standard. The point I am trying to make is abbreviations can be very dangerous and are very easy to mis-interpret so I think we need to think long and hard before choosing and implementing them. I am not arguing against them in specific cases but very well thought out cases. As microformats are human-readable first I think size is a secondary consideration. Are there any stats about how many sites are compression enabled vs. not? Thank You, Christopher ___ $0 Web Hosting with up to 200MB web space, 1000 MB Transfer 10 Personalized POP and Web E-mail Accounts, and much more. Signup at www.doteasy.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Microformats vs. CalDAV?
Hi all: I was just emailing with someone who's company offers software as a service and I was encouraging him to adopt Microformats including hCard and hCalendar. His response to me was: The good news is Apple in on our board, which means CalDAV would be the standard we'd employ. CalDEV: http://ietf.osafoundation.org/caldav/ Now, it's my understanding that one of the benefits of Microformats is that it co-exists nicely with other standards, and often even augments them quite well. But I'm still new enough at this I didn't want to stumble in trying to explain and advocate Microformats to someone who thinks CalDAV is the only thing they need to support. Can I get some help with this? -Mike Schinkel P.S. Also, I think a great addition to the FAQ would be to list of standard like vCard and CalDAV etc. and give arguments for why Microformats should be considering in parallel as opposed to an alternate. Tantek explained these things in his presentation where I got my first Aha regarding Microformats, but I'm still weak on the justification for each case. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: RE: title attribute and abbreviatedclassnames(Was:[uf-discuss]Currency Quickpoll: Preliminary results)
/;Mike Schinkel/a a target=_blank href=http://www.guidesinc.com;Guides, Inc./a a target=_blank href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a Atlanta, Georgiabr/ USAbr/ 404-474-8948 (w)br/ 404-276-1276 (c)br/ /address And MS-Word's statistics quotes me 682 vs 400, or just a little more than 70% bloat. That's probably acceptable. However, for money we have: span class=money abbr class=currency title=USD$/abbr span class=amount5.99/span /span Versus: $5.99 Or (to give it a fighting chance) span class=money$5.99/span Where MS-Word quotes: 108, 6, and 33, or between 1800% bloat and 327% bloat, respectively. Now call me pedantic, but I just don't think that is going to be well received in the general web development community and w/o good reception we won't be taken seriously and won't get adoption. I really think it would make sense to see what a broad cross section of web developers feel about this issue via a non-biasing survey before carving a bloated standard like this in stone. However, I didn't come here to make waves. If I'm the only one bothered by it I will acquiesce and hope we don't end up with a situation where my fears are revealed to have been significant and we wish we had heeded them. If so, I'll do my damnedest not to say I told you so (honestly.) -Mike P.S. Another option is to seriously consider a page-global aspect for markup. Then it could be a lot smaller for default cases, even in multibyte character sets. P.P.S. Sure we can't just lobby the W3C to approve REL tags and maybe a few more for all (X)HTML elements? :-) :-) :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Suda Sent: Thursday, October 19, 2006 11:06 AM To: Microformats Discuss Subject: Re: RE: title attribute and abbreviatedclassnames(Was:[uf-discuss]Currency Quickpoll: Preliminary results) On 10/18/06, Mike Schinkel [EMAIL PROTECTED] wrote: However, at the risk of being shot for heresy, has anyone considered allowing this? abbr class=currency usd$5.99/abbr abbr class=currency dkk35.66 kr/abbr --- one of the main goals of microformats is to make data Human Readable. Which means visible. In your examples the USD and DKK values are no longer human readbable values - we use the abbr element alot of the time to get the Machine readable portion way from users, and give them the more friendly human-readble string. Jan 1st 2006 is much more human readable than 20060101T00+00Z but with the abbr we still have something which the users can see. (i that case Jan 1st 2006). With your example, the USD doesn't really have an equivalent human-readable value, well it does, and would be $5.99 or 35.66 kr, you even agreed that I still think this is bad semantics. I don't think USD is really a title for $5.99 So hooking usd, dkk, or other currency TYPE in the class around the whole value is not ideal, semantically or for human-readablity. OR (something tells me this is even worse, but...): abbr class=money currency-usd$5.99/abbr abbr class=money currency-dkk35.66 kr/abbr --- from a parsing stand point, this gets to be a tricky issue as well. Besides the reasons mentioned above, there is another issue with '-' seperated values. What you are attempting to accomplish is to sort of double-pack the value currency-XYZ, by saying that this is a currency AND it is of a given type. The trouble with this is that when we mint an XMDP file for the microformat we have an enumerated list of values for each class. So we would have to have a value for each 'currency-ABC' to 'currency-XYZ'. If/When we add a new currency or a ABC value changed (not likely, but hey, they introduced the Euro!) we would have to go back and edit the XMDP and since parsers are to use that as WHAT are legal values, we'd have to then extend/update the XMDP to account for the new currency-ZZZ value, then increment the version number and all the parsers would have to be update with the new information, etc it is much easier to say class=type then leave the VALUE of that element to be open-ended rather than an enumerated list of values. the other bonus is that it doesn't force authors into one way of doing things, both of the following are still valid: abbr class=type title=usd$/abbr3.99 3.99span class=typeUSD/span I'm sure there is something just so wrong about this, but part of the reason I'm on this list is to learn. So why not? --- the previous answers were sort of techy, do they make sense? or are you looking for a more concrete explaination? I personally like this idea: span class=moneyabbr class=currency title=USD$/abbrspan class=amount5.99/span/span It has worked well for ADR, TEL, EMAIL in hCard and is also being explored for UIDs. span class=uidspan class=typeISBN/span:span
RE: [uf-discuss] Microformats vs. CalDAV?
I spoke to the CalDAV chaps at Apple about this, they have hCalendar support as a ticket in their db: http://trac.macosforge.org/projects/calendarserver/ticket/19 Cool! Thanks. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Marks Sent: Friday, October 20, 2006 12:00 AM To: Microformats Discuss Subject: Re: [uf-discuss] Microformats vs. CalDAV? On Oct 19, 2006, at 8:18 PM, Mike Schinkel wrote: The good news is Apple in on our board, which means CalDAV would be the standard we'd employ. CalDEV: http://ietf.osafoundation.org/caldav/ Now, it's my understanding that one of the benefits of Microformats is that it co-exists nicely with other standards, and often even augments them quite well. But I'm still new enough at this I didn't want to stumble in trying to explain and advocate Microformats to someone who thinks CalDAV is the only thing they need to support. I spoke to the CalDAV chaps at Apple about this, they have hCalendar support as a ticket in their db: http://trac.macosforge.org/projects/calendarserver/ticket/19 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] IRC Chat Client?
I tend to prefer the combination of IRC+wiki, Slightly off topic, but can anyone recommend a good free IRC client for WinXP? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç elik Sent: Thursday, October 19, 2006 6:49 PM To: microformats-discuss Subject: Re: [uf-discuss] hResume - Marking up experience and presentdate On 10/19/06 3:27 PM, Jeremy Boggs [EMAIL PROTECTED] wrote: Agreed, for now, this is an excellent point to start: http://microformats.org/wiki/hresume-issues Thanks for setting this up, Tantek. So, if we want to discuss further issues with this problem, should we post them there, on that wiki page, or continue making comments through email? A while ago I responded to Ciaran's last message in this thread, but if that response (or at least some form of it) should go on the wiki, I'll be glad to do that. Excellent questions Jeremy. There is no simple hard and fast rule, but I have found that the following guidelines seem to help. 1. Discussions work better on the email list (or IRC channel - which is often faster than email). 2. Conclusions/opinions are better recorded on the wiki. In general, I tend to prefer the combination of IRC+wiki, but that is largely my personal preference - YMMV. Clearly email works better for discussing more in depth issues. I've simply found that I am often unable to keep up with all the different threads, and thus end up not replying to some for many days (weeks, months), and then important concluding points get lost because they are never persisted in any form in a place where people can easily find them. That is, the wiki is more reader friendly than email because you can go to the wiki and understand the current state of things, whereas email archives are both hard to search and you have to typically read through a whole thread to understand what points were resolved and how. Thus even for issues - if you believe you have a solid understanding of what an issue is, and that it is an issue, you could add it directly to the appropriate *-issues page. You could then use email as a notification mechanism that you have raised the issue and provide a URL to it on the wiki. OTOH if you're not certain about an issue, then posting to the list can help to clarify/refine it at which point it should probably be captured on the wiki - in the hopes that it will be resolved and respective changes incorporated, and serve as documentation for those who would raise the same issue in the future. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] hCalendar spec- no specification included!
FYI, I have in mind a proposed list of goals I plan to send out for everyone to comment on, but I will be away from the computer for 2-3 days so I want to wait until I get back. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Thursday, October 19, 2006 3:49 PM To: Microformats Discuss Subject: Re: [uf-discuss] hCalendar spec- no specification included! In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes I'm coming to believe that there are some very different assumed goals use-cases among the people in discussions (not because of anything specific, just a feeling I have.) Without clarifying these, I think we'll be at cross purposes long term. I think you're absolutely right. It's important to be able to walk a mile in the other person's shoes. We have one 'wiki' page, for instance, which refers to the use of a uF by bloggers, when the usage described could be by any web publisher, on any web age, not just a blog. We have pages which refer to the need to use Z part of XHTML when Z is also a component of perfectly acceptable and valid HTML. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] First version of Currency proposal
span class=currency title=USD$1,000/span In the US that will mean one dollar, in Argentina (where I'm from) it will mean a thousand dollars. I believe you misunderstood what I was proposing; a shorthand for cases where it was unambiguous. When it was ambiguous it would require more. Unless I misunderstand, you would almost never use three decimal places for money and if you did you'd need to use the unambiguous version. Right? I do agree though that there should be some sort of optimization. It's becoming clearer and clearer to me that this is essential. Question: How does a human currently interpret a website that is have values such as $1,000 when it it was designed by a US company with US customers in mind? Is there something in the HTTP headers that makes this explicit that a machine could read, or does the Argentine viewing the web page just have to figure it out in context? If not, then we'd need a page-global currency seperator too... -Mike P.S. I apologize on behalf of myself and my countrymen for us being so USA-centric, but we unfortunately are. Hopefully globalization will open our eyes and change that before much longer. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Emiliano Martinez Luque Sent: Friday, October 20, 2006 12:29 AM To: Microformats Discuss Subject: Re: [uf-discuss] First version of Currency proposal This gives me a chance to ask in a different way, why can we not assume type=USD, amount=5.99, and symbol=$ from the following? The book costs span class=currency title=USD$5.99/span That example in particular might not be a problem but consider the following: span class=currency title=USD$1,000/span In the US that will mean one dollar, in Argentina (where I'm from) it will mean a thousand dollars. And tying this to the currency identification (even though the first 2 letters represent a country) will not solve the issue, since I should be able to markup values in different currencies within a single web page. I do agree though that there should be some sort of optimization. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Page-Global solution to Size Considersations (was Size considerations (or how to choose))
Maybe the size per amount marked-up can be addressed by focusing on providing a page-global solution? I don't know what's been discussed along those lines but here are my three cents: 1.) It seems like it should be a Design Pattern and not just something for a single Microformat 2.) I think it should allow multiple defaults; consider a page with 1500 money values where 500 are in USD, 500 are in GBP, and 500 are in EUR. Plus satisfying #1 would require multiples. 3.) I think it should be able to be applied anywhere in the document; i.e. inside the body tag. Consider a Wiki or a CMS that doesn't allow a page author to modify the headers of a page. JM3CW. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Rines Sent: Friday, October 20, 2006 12:58 AM To: microformats-discuss@microformats.org Subject: RE: [uf-discuss] Size considerations (or how to choose) Hey Mike, This is an very good/interesting example... In my opinion amount is a really difficult one to abbreviate (or any measure for that matter) as it can be used to describe a lot of other things for which there is not yet a microformat but cur (for currency) is interesting as just off the top of my head I don't think currency is used in a lot of other situations but could we abbreviate current (if we did something electrical) with cur? I guess this reinforces my point that while useful abbreviations in human-readable things are tricky at best. Just like acronyms can be an insiders language, abbreviations can obfuscate meaning. To reiterate my position I love abbreviations but anywhere they are used really need to be studied. :-) Cheers, Christopher In message [EMAIL PROTECTED] Mike Schinkel [EMAIL PROTECTED] in addition to other things said: I have a question about that. I'll use the example of money because it's one I'm more familiar with. In this particular case, we have money, currency, and amount: span class=money abbr class=currency title=USD$/abbr span class=amount5.99/span /span However, and this is an honest question, isn't currency and amount really only valid in context with money? Wouldn't that make it okay to abbreviate the children of money, like so?: span class=money abbr class=cur title=USD$/abbr span class=amt5.99/span /span ___ $0 Web Hosting with up to 200MB web space, 1000 MB Transfer 10 Personalized POP and Web E-mail Accounts, and much more. Signup at www.doteasy.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] IRC Chat Client?
Thanks for the all input on chat programs! I'll check'em out and get on the IRC after I come back from this long weekend. -Mike ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] First version of Currency proposal
Cool, thanks. html lang=en-gb Question: how would someone implement a wiki with different pages in different languages since they don't have access to changing the header or HTML element for each wiki page? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ciaran McNulty Sent: Friday, October 20, 2006 4:34 AM To: Microformats Discuss Subject: Re: [uf-discuss] First version of Currency proposal On 10/20/06, Mike Schinkel [EMAIL PROTECTED] wrote: Question: How does a human currently interpret a website that is have values such as $1,000 when it it was designed by a US company with US customers in mind? Is there something in the HTTP headers that makes this explicit that a machine could read, or does the Argentine viewing the web page just have to figure it out in context? If not, then we'd need a page-global currency seperator too... The @lang attribute specifies an ISO639[1] or ISO3166[2] country code for the element it's applied to (and any descendant elements. The W3C recommend[3] that the HTML element have this for every page. You could easily, for instance have: html lang=en-gb [...] pThis product is $1,000 (span lang=fr-pr1.500€/span)/p [...] /html And hopefully a user agent would know how to parse the numbers. @lang also has benefits for things like screen readers and so on. -Ciaran McNulty [1] http://ftp.ics.uci.edu/pub/ietf/http/related/iso639.txt [2] http://ftp.ics.uci.edu/pub/ietf/http/related/iso3166.txt [3] http://www.w3.org/International/O-HTML-tags.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: RE: title attribute and abbreviatedclassnames(Was:[uf-discuss]Currency Quickpoll: Preliminary results)
we could introduce the implied optimisation that if there is no explicit 'amount' then the amount could be taken to be everything inside the 'money' that isn't the 'currency' That would simplify the markup in a large number of the cases, and I don't think would complicate the parsing *too* much. I definitely like that optimization, assuming we can't get it any better and it causes no unforeseen problems. But also please see my comments on page-global. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ciaran McNulty Sent: Thursday, October 19, 2006 12:18 PM To: Microformats Discuss Subject: Re: RE: title attribute and abbreviatedclassnames(Was:[uf-discuss]Currency Quickpoll: Preliminary results) On 10/19/06, Brian Suda [EMAIL PROTECTED] wrote: I personally like this idea: span class=moneyabbr class=currency title=USD$/abbrspan class=amount5.99/span/span It has worked well for ADR, TEL, EMAIL in hCard and is also being explored for UIDs. I like that idea too, there've been a few similar variations suggested and they seem the right general approach. I think it would also make sense to add some rules that could compact the markup in common cases. For instance, we could introduce the implied optimisation that if there is no explicit 'amount' then the amount could be taken to be everything inside the 'money' that isn't the 'currency'. i.e. span class=moneyabbr class=currency title=USD$/abbr5.99/span would be equivalent to your example above. That would simplify the markup in a large number of the cases, and I don't think would complicate the parsing *too* much. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] IRC Chat Client?
Sure then, next week. :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç elik Sent: Friday, October 20, 2006 5:01 AM To: microformats-discuss Subject: Re: [uf-discuss] IRC Chat Client? On 10/20/06 1:52 AM, Mike Schinkel [EMAIL PROTECTED] wrote: Thanks for the all input on chat programs! I'll check'em out and get on the IRC after I come back from this long weekend. Mike, perhaps you could add a page to the wiki irc-clients listing the recommendations so far and adding your experiences? http://microformats.org/wiki/irc-clients Then we could even add an FAQ regarding IRC clients. Even if it is not specific to microformats, IRC is very frequently used by the community to rapidly discuss and make progress on various topics/issues and thus having such a resource is a nice convenience. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] First version of Currency proposal
I'm not that familiar with Wikis, they could probably implement a per-page language setting. The problem is not whether they can or cannot, but whether they will or won't and whether the user (who won't be the developer in almost all cases) will have the skill and/or motivation to make the change. Same is true of Content management systems (CMS) and Forums. See here for how many Wikis and CMS and Forums would need to get updated: http://www.wikimatrix.org/ http://www.cmsmatrix.org/ http://www.forummatrix.org/ I see it like how Microformats fundamental constraint is to not have to change HTML so we can use them *now*. I believe we've got to go with what people can actually use today given the tools they are currently using w/o fundamental change. The @lang doesn't have to be on the HTML element really. As long as it's on *an* element that contains your content, a user-agent should know what's going on. If that's true, then that works! An author could enclose everything they type into a wiki page, CMS page, or forum post using a div like so: DIV @lang=en-us The rain in Spain stays mainly in the plain. /DIV -Mike P.S. BTW, the issues with conent on Wikis and CMS and Forums is why this proposal concerns me: http://gmpg.org/xmdp/ I have been planning to ask about it as soon as I had a chance to study it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ciaran McNulty Sent: Friday, October 20, 2006 5:14 AM To: Microformats Discuss Subject: Re: [uf-discuss] First version of Currency proposal On 10/20/06, Mike Schinkel [EMAIL PROTECTED] wrote: Question: how would someone implement a wiki with different pages in different languages since they don't have access to changing the header or HTML element for each wiki page? I'm not that familiar with Wikis, they could probably implement a per-page language setting. The @lang doesn't have to be on the HTML element really. As long as it's on *an* element that contains your content, a user-agent should know what's going on. -Ciaran McNulty ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Advocacy Page on Wiki
I created an Advocacy page on the Wiki. http://microformats.org/wiki/Advocacy If it's not the right place for it, of course please move it... -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kevin Marks Sent: Friday, October 20, 2006 12:00 AM To: Microformats Discuss Subject: Re: [uf-discuss] Microformats vs. CalDAV? On Oct 19, 2006, at 8:18 PM, Mike Schinkel wrote: The good news is Apple in on our board, which means CalDAV would be the standard we'd employ. CalDEV: http://ietf.osafoundation.org/caldav/ Now, it's my understanding that one of the benefits of Microformats is that it co-exists nicely with other standards, and often even augments them quite well. But I'm still new enough at this I didn't want to stumble in trying to explain and advocate Microformats to someone who thinks CalDAV is the only thing they need to support. I spoke to the CalDAV chaps at Apple about this, they have hCalendar support as a ticket in their db: http://trac.macosforge.org/projects/calendarserver/ticket/19 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Visible Data...a Microformat requirement?
Brian Suda recently said: the problem with using Meta elements is that they are out-side of human-readable realm. One of the key factors in microformats is to keep the data visible, it keeps it fresh, prevents many of the abuses that have befallen meta-keywords, and also allows for microformats to be fully emebedded in other formats like Atom, RSS, etc. My question is this: What about when what you have is really metadata and not anything (currently, at least) stored on the HTML page? (I'm asking because several things I want to propose will fit into that category...) -Mike ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Microformats vs. CalDAV?
There is no http://microformats.org/wiki/related-formats page but I had already started one here: http://microformats.org/wiki/Advocacy -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan King Sent: Friday, October 20, 2006 1:55 PM To: Microformats Discuss Subject: Re: [uf-discuss] Microformats vs. CalDAV? On Oct 19, 2006, at 8:18 PM, Mike Schinkel wrote: P.S. Also, I think a great addition to the FAQ would be to list of standard like vCard and CalDAV etc. and give arguments for why Microformats should be considering in parallel as opposed to an alternate. Tantek explained these things in his presentation where I got my first Aharegarding Microformats, but I'm still weak on the justification for each case. Go for it! Maybe we could start a page like http://microformats.org/ wiki/related-formats for this? -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Page-Global solution to Size Considersations (wasSize considerations (or how to choose))
1.) It seems like it should be a Design Pattern and not just something for a single Microformat --- we do, ... Point of clarification, I meant that we specify a solution that could be used multiple places as opposed to one that just applied to money. The include pattern is a syntax for which we still need to define the semantics. It's a conduit, not a solution. ... If you are trying to shave off bits, then this doesn't do much for you, because you replace, span class=typeUSD/span, with a href=#id-ref class=include /, not much saving for a single value, but good for referencing full hCards for people and organizations. Actually if you use my examples from prior email in the case of money, that can shave off a *lot*. Plus it can make the file much easier to maintain. --- this is starting to sound like a solution to a non-problem. Nada! In previous email I gave numerous examples that people are publishing and several of them had lots of different currencies marked up with *lots* of prices. Par exemple: http://www.oxfordjournals.org/access_purchase/2007/institution_price_list.ht ml There are more where that came from if needed. Note I do my best to give real world usage examples on this list, not just hypotheticals. --- i would agree, we are bound to the semantics of HTML - we want as much interoperablity as possible, so you'd have to find elements that already exist that can serve this purpose. Anything wrong with div and span enclosing the entire user-supplied content? do we have a solution to a problem, or are we find a problem for a solution? Hopefully you see from my example we have the former, no? -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Suda Sent: Friday, October 20, 2006 8:38 AM To: Microformats Discuss Subject: Re: [uf-discuss] Page-Global solution to Size Considersations (wasSize considerations (or how to choose)) On 10/20/06, Mike Schinkel [EMAIL PROTECTED] wrote: Maybe the size per amount marked-up can be addressed by focusing on providing a page-global solution? I don't know what's been discussed along those lines but here are my three cents: 1.) It seems like it should be a Design Pattern and not just something for a single Microformat --- we do, the include pattern allows you to specify data, and then throughout the rest of the page, reference it. If you are trying to shave off bits, then this doesn't do much for you, because you replace, span class=typeUSD/span, with a href=#id-ref class=include /, not much saving for a single value, but good for referencing full hCards for people and organizations. 2.) I think it should allow multiple defaults; consider a page with 1500 money values where 500 are in USD, 500 are in GBP, and 500 are in EUR. Plus satisfying #1 would require multiples. --- this is starting to sound like a solution to a non-problem. We should really try to stick with what people are ALREADY publishing, making-up theorietical issues and solutions isn't the best use of our time. 3.) I think it should be able to be applied anywhere in the document; i.e. inside the body tag. Consider a Wiki or a CMS that doesn't allow a page author to modify the headers of a page. --- i would agree, we are bound to the semantics of HTML - we want as much interoperablity as possible, so you'd have to find elements that already exist that can serve this purpose. We have explored object and a, link and @profile are good, but like you said they are somewhat outside of what normal CMSs handle. Ultimately, this also refers back to the question, do we have a solution to a problem, or are we find a problem for a solution? -brian -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] [admin] mailing list policies reminder
Rather than including policies suggestions only in an email, can we please make sure that all policies make their way to http://microformats.org/mailinglists-policies/ I don't want to be liable for having studied all emails on this subject, and I doubt any newbies will go back into the email archives to dig them out. I also don't want to have to decide which are policies and which are someone's singular opinions; the wiki process will weed out the latter. -Mike Schinkel http://www.mikeschinkel.com/blog http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Saturday, October 21, 2006 7:22 AM To: Microformats Discuss Subject: Re: [uf-discuss] [admin] mailing list policies reminder In message [EMAIL PROTECTED], Ryan King [EMAIL PROTECTED] writes This is a just a friendly reminder for everyone to read our mailing list policies - http://microformats.org/mailinglists-policies/ . The reason for the reminder is that this list has grown, ema lot/em and many of the policies are meant to help everyone deal with and minimize overload. That's very useful, thank you. Here're some suggested additions: ... ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
It is most often simply properties of the information which are still relevant to the user and thus should be visible. Okay, I think I can probably agree while still holding out the potential to uncover needs in the future that do not fit that pattern. If it is not worth or appropriate to make the information visible, then it is not worth trusting the information and certainly not worth the time to make a microformat for it. But what if the website publisher (or graphic designer) does not want that information to be visible on the page? Some may, but other's may not. I'm trying to follow the principle that Microformats should not require the user to really change anything beyond adding Microformat functionality. If they don't currently display this metadata, are you saying that a Microformat should force them to do so? Have you tried using as many existing microformats as you can on your current sites? O Yeah! I've been combing through even Microformat you have listed and reading each in-depth. Sad to say, but I've probaby got more than twice as many in mind as you currently have listed... But I don't want to propose anything until I've got time to flesh them out otherwise I'll be in a bloodbath of trying to justify them before I've done all the required research. That said, what if I have a need for a microformat but have no idea what the best name for it would be? Ideally I'd like to present the concept and get help with naming. But currently the process seems to be to give is a name on a wiki page and document it? How can I do that w/o a name (I know I'm being pedantic, but I'm actually trying to call the question of how to consistantly go about using the community to help find a name for a potential uF.) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç elik Sent: Monday, October 23, 2006 2:16 AM To: microformats-discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On 10/22/06 11:10 PM, Mike Schinkel [EMAIL PROTECTED] wrote: Brian Suda recently said: the problem with using Meta elements is that they are out-side of human-readable realm. One of the key factors in microformats is to keep the data visible, it keeps it fresh, prevents many of the abuses that have befallen meta-keywords, and also allows for microformats to be fully emebedded in other formats like Atom, RSS, etc. My question is this: What about when what you have is really metadata and not anything (currently, at least) stored on the HTML page? Rarely is metadata actually metadata. It is most often simply properties of the information which are still relevant to the user and thus should be visible. If it is not worth or appropriate to make the information visible, then it is not worth trusting the information and certainly not worth the time to make a microformat for it. Note that in addition to visible text, visibility can be in the form of a the interactivity of a hyperlink (its URL), or in the CSS used to style something with a particular attribute (e.g. XFN), or in the tooltip shown for title attributes. (I'm asking because several things I want to propose will fit into that category...) Have you tried using as many existing microformats as you can on your current sites? Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Then it is not worth trusting the information nor worth the time making a microformat for it. Respectfully, I disagree. I'm also a bit allergic to statements asserting the absoluteness of a concept especially when it is *harder* to prove there is not a needle in a haystack than it is to find one in the haystack if it is known to be there; itself a very difficult task. There can be drivers that can encourage people to maintain information even if not the content is not visible; to achieve a higher search engine ranking could be a good example. I've been very attracted to Microformats because them as being able to solve many problems I've identified. Just a point of note but if I can't use Microformat for them, then that just means the need for another initiative that can solve those problems. I hope that won't be required. BTW, I'm not saying there would not be value in making such information visible, I just didn't want to assume it would be a requirement. Let me go ahead and give you a hypothetical example (I have had the exact problem in the past, so it is a real problem, it's just that explain in hypotheical requires less background explanation): http://www.wiki-info.org/platforms/linux/php/ http://www.software-info.org/wikis/platforms/linux/php/ Both those URLs are different and have different bread crumbs but otherwise the same content. Search engines do not *know* they are the same, but may determine they are similar enough that it will only include one of the URLs in it's index (Google frequently did this to us at VBxtras Xtras.Net back when there were two sites.) However, the search engines may choose to include the page from software-info.org when I'd rather have him include the page from wiki-info.org or vice-versa. So, I would like to be able to define in the software-info.org page that the wiki-info.org page is content-duplicate and authoritative over the existing page. Microformats seem perfect for this, but I can see where website owners may not want to make this type of information visible. So, what if your take on this problem and use-case? It doesn't matter how many you may have in mind. The question remains - have you tried using *just* the existing microformats to at least add some more semantics to your pages? I'm confused. I have numerous use-cases where have a microformat would either solve problems or create infrastructure to empower solutions that currently cannot exist. How does my using existing microformat for use-cases I don't currently have specific need for have any relevence? Respectfully speaking, that is like asking the guy who comes to you needing a wrench if he has tried using a screwdriver yet for other needs (which he may not currently have.) -Mike P.S. I'm coming to this working group with a entire series of problems that I experienced trying to run Xtras.Net as well as things I wanted to implement but couldn't because the infrastructure didn't exist. When I ran Xtras.Net I often tried to use technology to solve business problems. That's the perspective with which I come to this, not being just a technologist and thinking wouldn't if be cool if...? but instead a technically-saavy business person envisioning things that could empower solutions with a keen eye towards what will actually be used (because if it won't be used, it won't be beneficial.) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç elik Sent: Monday, October 23, 2006 3:25 AM To: microformats-discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On 10/23/06 12:11 AM, Mike Schinkel [EMAIL PROTECTED] wrote: If it is not worth or appropriate to make the information visible, then it is not worth trusting the information and certainly not worth the time to make a microformat for it. But what if the website publisher (or graphic designer) does not want that information to be visible on the page? Then it is not worth trusting the information nor worth the time making a microformat for it. Some may, but other's may not. I'm trying to follow the principle that Microformats should not require the user to really change anything beyond adding Microformat functionality. That's right. If they don't currently display this metadata, are you saying that a Microformat should force them to do so? No, I am saying that the microformat shouldn't bother representing it. Keep microformats as simple and as minimal as possible. That means invisible data and properties are left out of microformats. Have you tried using as many existing microformats as you can on your current sites? O Yeah! I've been combing through even Microformat you have listed and reading each in-depth. Sad to say, but I've probaby got more than twice as many in mind as you currently have listed... It doesn't matter how many you may have in mind. The question remains - have you tried using *just
RE: RE: RE: title attribute andabbreviatedclassnames(Was:[uf-discuss]Currency Quickpoll:Preliminary results)
Brian Suda wrote: --- there are elements in HTML which convay more semantic information. Gotcha, thanks. The next step is to explicitly label that abbr so parser know it is the TYPE. span class=currencyabbr class=type title=USD$/abbr5.99/span This gets back to what I was trying to get away from in the first place: bloat and complexity (difficult for the newbie to do the markup correctly.) --- i'm not going to debate the additional mark-up, at the end of the day, adding semantic meaning and metadata into a page is not free. You can't have your cake and eat it too. I think that others have shown that with gzip the additional markup that was added and zipped is actually smaller than the original source file anyway. And (this is completly unsubstanciated) i would guess MOST folks don't even optimize their images, which would give you a MUCH greater bandwidth savings than 1-2KB of semantic plain-text. It's not about size from a machine standpoint (although at first I asked about that concern bit I already accepting it was not an issue.) It is about conceptual complexity of markup for the newbie and average joe html coder. That's what I'm most concerned about. I think what you are showing will cause them to just not do it unless their boss is forcing them to do it to solve a specific business need and not just because bots might be able to do cool things with it. IOW, I think it will significantly impact adoption and/or end up with lots of wrongly implemented markup. But, as I said before if I'm the only one concerned about it then I won't try to continue to fight this battle... --- you don't need the W3C in this situation, Atom which is an IETF standard has introduced several new rel values. So it would be possible to introduce values through RFCs as well as W3C Recommendations. So we can add REL attributes to (X)HTML elements that are not currently defined to contain them? Wouldn't that cause an XTML document so marked up to failed a validity test? -Mike ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] [admin] mailing list policies reminder
Good point. Then I would ask whoever maintains that to incorporate suggestions somehow. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Monday, October 23, 2006 3:19 AM To: Microformats Discuss Subject: Re: [uf-discuss] [admin] mailing list policies reminder In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes can we please make sure that all policies make their way to http://microformats.org/mailinglists-policies/ I also don't want to have to decide which are policies and which are someone's singular opinions; the wiki process will weed out the latter. That page isn't part of the Wiki. -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Advocacy Page on Wiki
One minor nit - please use all lowercase names for wiki pages, see: Funny. I first did it in lowercase and then though, Oh, I better capitalize it so I moved to the capitalized equivalent. :) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç elik Sent: Saturday, October 21, 2006 5:52 PM To: microformats-discuss Subject: Re: [uf-discuss] Advocacy Page on Wiki On 10/20/06 2:58 PM, Mike Schinkel [EMAIL PROTECTED] wrote: I created an Advocacy page on the Wiki. http://microformats.org/wiki/Advocacy If it's not the right place for it, of course please move it... Thanks Mike. It makes sense and I have expanded upon and added some sections. One minor nit - please use all lowercase names for wiki pages, see: http://microformats.org/wiki/naming-conventions I have moved the page to the lowercase version and put a redirect in the old location. Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
I'm not Tantek, but you're use-case seems eminently reasonable, and Thanks! I'd suggest could be solved using an appropriate new [EMAIL PROTECTED], and then convicing the search engines to pay attention to it ;-) Do you mean in head? Did you see my earlier comments about wikis, CMS, and forums, where the user often may not have control of putting things in head? It's very hard to follow the Microformats principle of 'pave the cowpaths' if the information you're trying to enrich isn't currently present in the documents, which means hidden data is fairly heavily discouraged. I understand. Personally, I have need for it in a project I'm planning and will use it in my project. Although I really don't want to say this because it sounds so un-humble, but if my project achieves my vision which I think it can, it will be significant enough by itself to drive interest in the conventions it uses. I can do two things; implement it and probably get it wrong because I'd not have the benefit of feedback from the so many skilled people involved in Microformats, or include in the Microformats process and get the feedback to make it (and others) the best they can be. However, it doesn't really fit in with the aims of Microformats with a big 'M', which are Designed for humans first and machines second Here's just a question: Is it possible to interpret that to mean When there is a conflict, design for humans trumps design for machines? If so, that doesn't *preclude* designing for machines where there isn't a conflict with humans, right? Just another way to look at it...? Again, that's not to say it's not a good idea, it's something I'd be quite interested in too. And there are several more where that one came from. :) Maybe if Tantek vetos you can help me go create yet another initiative for hidden Microformat-like metadata? :-) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ciaran McNulty Sent: Monday, October 23, 2006 4:26 AM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On 10/23/06, Mike Schinkel [EMAIL PROTECTED] wrote: So, what if your take on this problem and use-case? I'm not Tantek, but you're use-case seems eminently reasonable, and I'd suggest could be solved using an appropriate new [EMAIL PROTECTED], and then convicing the search engines to pay attention to it ;-) However, it doesn't really fit in with the aims of Microformats with a big 'M', which are Designed for humans first and machines second [1]. The scope of what's considered a Microformat is deliberately narrow, and is primarily aimed at adding extra semantics to data that's already present in documents. XFN, for instance, defines a set of @rel values to enrich the semantics of linking to other people's sites/blogs/etc., but it's unlikely that XFN would have been proposed if there wasn't already a huge precendent of people linking to each other's sites, and a percieved need for that extra information to be added to the existing links. It's very hard to follow the Microformats principle of 'pave the cowpaths' if the information you're trying to enrich isn't currently present in the documents, which means hidden data is fairly heavily discouraged. Again, that's not to say it's not a good idea, it's something I'd be quite interested in too. -Ciaran McNulty [1] http://microformats.org/about/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Search engines make use of shingles to identify pages and their aliases. What's a shingle? As far as I can tell, this isn't in the same class of problems that microformats solve. Is there a clear and definitive objective statement that explains the class of problems that microformats are intended to solve? Further, if there is such a statement, is there a reason to limit Microformats to only be used to solve that class of problems when they otherwise can solve additional problems? This probably best resolved by agreeing what we mean by metadata, Because of judicious editing required by forum policy, I've lost the prior of the discussion so I'm not sure the context in which I mentioned metadata. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Benjamin West Sent: Monday, October 23, 2006 2:01 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? So, what if your take on this problem and use-case? Search engines make use of shingles to identify pages and their aliases. Some search engines employ teams of editors and solicit feedback from the web community to ensure their aliasing techniques are correct. As far as I can tell, this isn't in the same class of problems that microformats solve. This probably best resolved by agreeing what we mean by metadata, as the scope of definition and contents of that term seem to be somewhat disputed and/or misunderstood as well as the scope of the problem space of microformats. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
It'd take a lot to convince me that HEAD isn't the place for meta-data, for a start ;-) I agree with you in concept, but the problem is that (I'm guessing) 99% of wiki, cms, and forum users will have no access to adding information into the HEAD so you are leaving all of them out in the cold. And I'll bet that the comprise the vast majority of content creators on the web. You could potentially use that in your markup, but using it with an 'empty' link wouldn't be something that I'd find appealing, I agree. I think a div encapsulting the user's content should do just fine, no? The microformats list and/or IRC channel are, I've found, a great place to discuss semantic XHTML in general. I'd encourage you to publish your data using whatever sensible scheme you deem appropriate, maybe after some discussion here and elsewhere. I'll be happy to do that, assuming I don't get shot down for posting discussions on the list for topics the group has decided not to support. :) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ciaran McNulty Sent: Monday, October 23, 2006 6:08 AM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On 10/23/06, Mike Schinkel [EMAIL PROTECTED] wrote: I'd suggest could be solved using an appropriate new [EMAIL PROTECTED], and then convicing the search engines to pay attention to it ;-) Do you mean in head? Did you see my earlier comments about wikis, CMS, and forums, where the user often may not have control of putting things in head? I did, I'm not sure what to think about it. It'd take a lot to convince me that HEAD isn't the place for meta-data, for a start ;-) The similarities between this and [EMAIL PROTECTED]alternate are particularly striking, and so that's the solution that would immediately suggest itself to me. [EMAIL PROTECTED]bookmark [1] encapsulates some of the semantics of being an 'authoritative version' of an item (for instance in hAtom[2]). You could potentially use that in your markup, but using it with an 'empty' link wouldn't be something that I'd find appealing, YMMV. I can do two things; implement it and probably get it wrong because I'd not have the benefit of feedback from the so many skilled people involved in Microformats, or include in the Microformats process and get the feedback to make it (and others) the best they can be. The microformats list and/or IRC channel are, I've found, a great place to discuss semantic XHTML in general. I'd encourage you to publish your data using whatever sensible scheme you deem appropriate, maybe after some discussion here and elsewhere. -Ciaran McNulty [1] http://microformats.org/wiki/rel-bookmark#rel.3D.22bookmark.22 [2] http://microformats.org/wiki/hatom#Entry_Permalink ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Mailing list debate moved new proposal
Andy Mabbett Why not create a new mailing list for each proposal, once it's reached a certain stage? I tend to really like this proposal. I've been thinking about if and how Microformats can evolve and grow. I can see Microformats being potentially much larger helping to create tags in many different areas vertical but the current process can't scale. For example, if someone might want to create microformats to identify auto parts but I'm sure there are thousands of other areas too. How can we keep up with them all? It seems that having a central registry for approving subject areas and then creating a list for that area could grow microformats exponentially. Of course then the question becomes, how to avoid conflicts. I would suggest that every microformat should have a unique name, and then within that Microformat the subclasses would be free of namespace collisions. And maybe having a well-known prefix like uf- so that general microformats could be referred to within other Microsformats: span class=auto-parts div class=sku12345/div div class=manufacturerMopar/div div class=descriptionExhaust System/div div class=uf-money abbr class=symbol title=USD$/abbr span class=amount199/span /div /span This was just off the top of my head, but I wanted to get the discussion started... I will close with a quote from Tantek[1] quoting and commenting on Weaving the Web by TBL: WTW Chapter 12 page 175 We could allow a set of working groups that can be shown to form a tight self-reliant cluster to secede and form a new peer clone consortium. ... anyone could start a consortium, when the conditions were right, by pushing a few buttons on the Web page of a virtual consortium factory This is a fascinating set of ideas. But why a peer consortium? The W3C did not start as a peer to those that came before it. I think if anything, we'll see the tiniest of efforts, that start quite small, and perhaps stay small, or perhaps slowly grow into something that could be said to be a peer. -Mike [1] (http://tantek.com/log/2003/0813t1158.html) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Thanks Charles. However I still have no idea why these things apply to specifying which page among of group of equivalent pages is authoritative and why Microformats do not. The latter seem a perfect fit to me, and what you listed either don't apply to general web pages, are years off and can't be used today, are not related, or don't provide the features needed. The microformat concept would work perfectly for this (and similar problems.) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Wednesday, October 25, 2006 5:58 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hello Mike, XML, Semantic HTML, and RDF are closely related to what is being done here. But there's alot of other technologies for specific areas. Like with multimedia type thigns we have SMIL, XSPF, etc etc. For databases like things we have CSV, TSV, HTML tables, etc etc. (Obviously I'm not going to try to enumerate every area and every technology... but hopefully this will give you an idea.) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Your always welcome to use HTML class name semantics or other microformat-inspired technologies in your private applications. However, that is a different thing that calling it a microformat and engaging this whole group in vetting and supporting it. If you think this could be a great solution to an existing problem, I encourage to just go ahead and implement it. As long as you don't call it a microformat, feel free to experiment. :-) Well, why I'd prefer not to go it alone is for the very fact of not having the whole group in vet and support it... -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Ernie Prabhakar Sent: Wednesday, October 25, 2006 6:44 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hi Mike, Your always welcome to use HTML class name semantics or other microformat-inspired technologies in your private applications. However, that is a different thing that calling it a microformat and engaging this whole group in vetting and supporting it. If you think this could be a great solution to an existing problem, I encourage to just go ahead and implement it. As long as you don't call it a microformat, feel free to experiment. :-) - Ernie P. On Oct 25, 2006, at 3:15 PM, Mike Schinkel wrote: Thanks Charles. However I still have no idea why these things apply to specifying which page among of group of equivalent pages is authoritative and why Microformats do not. The latter seem a perfect fit to me, and what you listed either don't apply to general web pages, are years off and can't be used today, are not related, or don't provide the features needed. The microformat concept would work perfectly for this (and similar problems.) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Wednesday, October 25, 2006 5:58 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hello Mike, XML, Semantic HTML, and RDF are closely related to what is being done here. But there's alot of other technologies for specific areas. Like with multimedia type thigns we have SMIL, XSPF, etc etc. For databases like things we have CSV, TSV, HTML tables, etc etc. (Obviously I'm not going to try to enumerate every area and every technology... but hopefully this will give you an idea.) ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Scott: I'm still not convinced. I've only heard generalities and no specifics on anything I've heard regarding my use-case. RDF is far to complicated for the average person creating HTML; one reason why I don't think it will ever fly. I still know of nothing else besides Microformats that can fill this role; can you give me some specifics that: * Is very simple to add * Doesn't require access to head * Can be done today -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Wednesday, October 25, 2006 7:31 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On Oct 25, 2006, at 5:15 PM, Mike Schinkel wrote: Thanks Charles. However I still have no idea why these things apply to specifying which page among of group of equivalent pages is authoritative and why Microformats do not. The latter seem a perfect fit to me, and what you listed either don't apply to general web pages, are years off and can't be used today, are not related, or don't provide the features needed. The microformat concept would work perfectly for this (and similar problems.) I think the key difference is the subject of this thread. Microformats are good for visible data. Other formats are good for invisible data. Most of what Charles listed is in wide use today. You just don't see it because it's not on the visible web. If the data you want to describe is also not on the visible web, it's probably more appropriate for one of these invisible data formats. Consider reuse of the data. Microformats have less invisible reuse potential because they don't fit a general schema like RDF or XSD. But microformats have more visible reuse potential because, well, the data is visible. If your data is invisible and you tried to format it with microformats, you'd be losing both invisible reuse potential and visible reuse potential. You can pound that nail with a screwdriver, but why would you? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] how do i submit something for consideration?
Charles, Funny, I've been planning to write a blog post entitled something like What's the one thing wrong with Open-Source? Forking! :) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Thursday, October 26, 2006 4:45 PM To: Microformats Discuss Subject: Re: [uf-discuss] how do i submit something for consideration? Hello Jonathan, (This does NOT have anything to do with the Microformats aspect of it, but) Just out of curiousity, why the No Derivative part for the license for the specification? (To be open wouldn't anybody need to be able to make derivatives, and not just one person or more group of people?) Here's a good article on openness and specifications... http://goland.org/buyingopenstandards (I'd probably go further than this article... but it's a good start.) See ya On 10/26/06, Jonathan Vanasco [EMAIL PROTECTED] wrote: Hi. I've recently soft-launched a distributed identity webapp that I've split out of another project, and released several aspects of that application as open standards ( Creative Commons Attribution-No Derivative Works 2.5 License ) I don't know how / where to submit it for potential consideration as a microformat , or even if they qualify ( one supports human readable , but is geared to be machine readable ; the other is more of an interchange format , but works well as semantic markup ) - so I came here. The summaries: findmeon design: essentially a subset of XML-DSIG with some FOAF / XFN semantics tossed in , and coerced to validate in XHTML strict designed for machine readability , but supports human readability (90% of content would usually be hidden though) unfortunately must support a non-standard 'compressed' url- encoding to let it clear as validated text on several social networks and forum software ( required because certain tags/attributes were often stripped ) usage: openly claim / verify / link multiple websites together via RSA 1024 public key pairings within a distributed self-sufficient framework hopefully will end proprietary 'i own this blog/whatever' codes designed so that resources do not need to know about one another or a central server in order to be linked/verified by a public key originated from: a need to map artist/label/venue/etc information on a music site to official sites / online profiles ; map users of a music site onto other sites for verifiability in trading concert tickets or making online requests / contest entries specification status: the current release works as it should, so any feedback/changes would be merged into a future release open_sn design: a dirty dirty hack standardizes the most common social network / dating site / online account profile fields that do not natively appear in existing specifications its really quite a bad 'standard' -- but it serves its purpose primarily designed as an interchange format, but works pretty well in terms of semantic markup usage: mostly an interchange format for migrating data between accounts specification status: very much open for immediate improvement / replacement. its a dirty dirty hack. The full text / description of both standards are available at http://findmeon.org I'd welcome any feedback. Thanks, // Jonathan Vanasco | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | FindMeOn.com - The cure for Multiple Web Personality Disorder Web | Identity Management and 3D Social Networking | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - | RoadSound.com - Tools For Bands, Stuff For Fans Collaborative Online | Management And Syndication Tools | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] include-pattern support for data outside of the current page? [Was: Visible Data...a Microformat requirement?]
Is it good for the interpretation of the data on one page to rely on data on another page? anyone has an opinion? My knee-jerk reaction is that it is very bad practice to have what would essentially be the legend to be on a separate page. Very, very bad. When I use to teach programming, one of the things I always pointed out was that proximity increases maintainability. This is kinda similar. (Of course I'm open to someone explaining a use-case and/or rationale for this situation that I had not previously considered.) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guillaume Lebleu Sent: Thursday, October 26, 2006 2:23 PM To: Microformats Discuss Subject: [uf-discuss] include-pattern support for data outside of the current page? [Was: Visible Data...a Microformat requirement?] The thread around invisble microformats reminded me of this example from the visible Web. Maybe relevant to this discussion, if not relevant to the include-pattern. An index page (http://www.eia.doe.gov/emeu/international/oilprice.html) contains currency information that applies to all pages it indexes. For instance, in this data page (http://quotes.ino.com/exchanges/?r=NYMEX_CL), there is no unit/currency defined, and we only know the numbers are U.S. Dollars per barrel b/c it was defined in the separate page we came from. Should my data page contains an include-pattern link to the currency definition from the other page? Is it good for the interpretation of the data on one page to rely on data on another page? anyone has an opinion? I'm asking since I haven't seen on the include-pattern page any clear direction on this. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Because it hasn't gone through the (fairly rigorous) demands of the uF process -- the process page on the wiki[1] outlines this. But what I'm hearing is that if it's not visible it cannot go through that process... -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Colin Barrett Sent: Thursday, October 26, 2006 1:38 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On Oct 26, 2006, at 7:28 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Dr. Ernie Prabhakar [EMAIL PROTECTED] writes As long as you don't call it a microformat, feel free to experiment. :-) Why shouldn't he call it a microformat? Because it hasn't gone through the (fairly rigorous) demands of the uF process -- the process page on the wiki[1] outlines this. -Colin [1] http://microformats.org/wiki/process ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
Yes I was joking, but in the sense of Many a truth said in jest. In my 20+ years in the tech industry I don't think I've a group of people who can be more religious than those discussing technical matters, excepting fundamentalists in any real religion. :) And because religions tend to promote absolutes, they create lots of problems and impede the forward progress of pragmatists. Thus I was trying to make a point without being too pointed. ;) -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Thursday, October 26, 2006 1:28 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes cardinal sin Is this a pragmatic group that I'm working with, or a bunch of religious zealots that I've managed to get entangle with? [assuming you're not joking] cardinal in this sense means: essential; of foremost importance; paramount and cardinal sin is a common idiom. See, for example: http://www.answers.com/cardinalr=67 -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
that is *only* for machine consumption Conversely, if he's unsure whether the metadata *has* to be invisible, then perhaps this is still a worthwhile discussion. For clarity, there is nothing that says that the metadata I was proposing and am additionally envisioning couldn't be visible. It might even become a best practice to make it visible. But in current practice today the data typically isn't visible (if it is there, which is unlikely) and some people might not want to make it visible (probably because they have a pre-Web 2.0 mentality, IMO.) However, if the end result is *outside* the scope of how we as a community understand microformats, don't expect to get a lot of official support Without support, it make little sense to do it, which IMO means creating a parallel initiative which is duplicated effort, will confuse the public, and is just not a good idea all round. But if I can't convince the group that it makes sense, I certainly can't berate the group into doing it. So if I get a consistent no then that's that (kinda funny how in the early days of the web everyone wanted to splinter. :) In particular, it would be confusing for him to call his proposal a microformat if it did not go through the documented microformat process Agreed. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dr. Ernie Prabhakar Sent: Thursday, October 26, 2006 1:38 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? Hi Andy, On Oct 26, 2006, at 10:28 AM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Dr. Ernie Prabhakar [EMAIL PROTECTED] writes As long as you don't call it a microformat, feel free to experiment. :-) Why shouldn't he call it a microformat? Sorry, I may have conflated too many issues. The point I wanted to make (which I communicated poorly) is: a) If he's committed to marking up *invisible* metadata that is *only* for machine consumption, then [IMHO] that's beyond the scope of what this group was constituted to do. b) Conversely, if he's unsure whether the metadata *has* to be invisible, then perhaps this is still a worthwhile discussion. c) Either way, he's welcome to experiment with microformat-derived ideas d) However, if the end result is *outside* the scope of how we as a community understand microformats, don't expect to get a lot of official support e) In particular, it would be confusing for him to call his proposal a microformat if it did not go through the documented microformat process http://microformats.org/wiki/process I apologize if that came across as needlessly confrontational. Best, -- Ernie P. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Visible Data...a Microformat requirement?
My suggestion to use invisible data formats was prefaced with the scenario that your data is invisible, based on the subject of this thread. The above criteria seem to contradict the subject of this thread. If that is the case, I apologize. I envision several different needs although not all of them are fleshed out yet. And these are not needs I just think people might have, they are needs that I've envision I will need in order to optimize some projects I have planned. Is the data published on the web today or not? If it is, you should start collecting it and analyzing to see if it's suitable for a microformat. It is possible. I'm doing tons of research right now (killing many trees printing off documents at the W3.org and elsewhere). But maybe not. If it's not published, we can't research the publishing, so we'd be creating a microformat based on assumptions. The example I gave is straightforward, and respectfully I don't think there would be a lot of assumptions. Let me give another example for this use-case (although I'm learning there may be existing things in HTML to resolve this one specific use case.) Consider these three URLs: http://www.foo.com/toyota/4runner/1999/ http://www.foo.com/toyota/1999/4runner/ http://www.foo.com/1999/toyota/4runner/ Assuming they point to the same basic content but have different breadcrumbs: Home Toyota 4Runner 1999 Home Toyota 1999 4Runner Home 1999 Toyota 4Runner However, there really are the same page and I'd like to be able to say that one of them is the primary or authoritative one (the website owner would decide which one) and in the two that are not primary or authoritative they would point to the one that is. It's possible that you could have the following visible on the page: This page is a duplicate of a href=http://www.foo.com/toyota/4runner/1999/; rel=primarywww.foo.com/toyota/4runner/1999//a. As I said, this is but one example of data that helps describe a page that I can envision I will need and that I believe could benefit the web in general if it exists. I wish I had fleshed out my other examples at this point but I haven't yet, and I certainly don't want to get the shot down because I present them prematurely prepared. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Reynen Sent: Thursday, October 26, 2006 1:46 PM To: Microformats Discuss Subject: Re: [uf-discuss] Visible Data...a Microformat requirement? On Oct 26, 2006, at 3:07 AM, Mike Schinkel wrote: I'm still not convinced. I've only heard generalities and no specifics on anything I've heard regarding my use-case. RDF is far to complicated for the average person creating HTML; one reason why I don't think it will ever fly. I still know of nothing else besides Microformats that can fill this role; can you give me some specifics that: * Is very simple to add * Doesn't require access to head * Can be done today My suggestion to use invisible data formats was prefaced with the scenario that your data is invisible, based on the subject of this thread. The above criteria seem to contradict the subject of this thread. Is the data published on the web today or not? If it is, you should start collecting it and analyzing to see if it's suitable for a microformat. If it's not published, we can't research the publishing, so we'd be creating a microformat based on assumptions. Such an assumption-based process doesn't meet the standards we've been applying to the word microformat. We're not changing that standard because we, as a community, believe that basing formats on existing behavior is an important practice. There are other formats that are based on assumptions, and the complication you don't like is largely a result of that practice. Pick your poison. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Internet Explorer 8.0 will support microformats
I've got a question about this. To say IE8 will support Microsformats doesn't make sense to me, unless they means it will support the Microformats agreed to at the point IE8 is made feature complete. But what about those that come after? Or, is this saying that IE8 will have a capability to process Microformats abstractly so that new ones can be added after IE8 has shipped? And if that is possible, wouldn't it make sense for us as a group to go ahead and specify a standard way to define that abstraction? -Mike Schinkel http://www.mikeschinkel.com/blog http://www.welldesignedurls.org/ P.S. If this makes no sense it's because I haven't had enough sleep lately... :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Sunday, October 29, 2006 8:52 PM To: Microformats Discuss Subject: [uf-discuss] Internet Explorer 8.0 will support microformats FYI: http://factoryjoe.com/blog/2006/10/29/internet-explorer-80-will-support-micr oformats/ ;) Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [X] bloggable[ ] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Mailing list debate moved new proposal
list integration module (http://www.vbulletin.org/forum/showthread.php?t=65152) so we could have the best of both worlds. The envelope pushers could have their forum, and the lluddites could stick with email. ;-) Colin Barrett Plus, the UI in my email client is much nicer than that of most forums. vBulletin can be configured to send posts to your email, so you'll be able to still use your email client for reading if you like. Colin Barrett There are a host of other Colin Barrett disadvantages to using a forum. Can you detail those disadvantages for us to discuss/debate? Colin Barrett Granted, mailing lists aren't perfect, but we have one now and it works. A vBulletin forum can be set up in a two hours max. I'll run it if that's an option so it would only be my time. Colin Barrett Forums also require a bit more administration Colin Barrett than a mailing list, and our list administrators Colin Barrett are already over-worked, it seems. How does it take more admin? I administer a vBulletin forum right now and it takes almost no time at all. You don't have to worry about issues with POP3 and SMTP so it IMO is actually easier. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Mailing list debate moved new proposal
I just don't want to be checking a mailing list, wiki AND a forum. On that point I've proposed integrating the mailing list AND the forum, to give people the option of which of the two to use. So you wouldn't have to check all three. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frances Berriman Sent: Friday, November 03, 2006 4:15 AM To: Microformats Discuss Subject: Re: [uf-discuss] Mailing list debate moved new proposal On 11/3/06, Benjamin West [EMAIL PROTECTED] wrote: If people want to filter things out, or draw particular attention to a thread being related to a specific proposal, using the [hCard] notation (for example) works quite well in the subject field. I concur. Filtering features are well supported on many of the mail clients I've seen, and a simple filter with the convention of tagging threads with square brackets would probably work fine. I like simple solutions. :) To be honest, I just don't want to be checking a mailing list, wiki AND a forum. Selfish, selfish of me. -- Frances Berriman http://fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Mailing list debate moved new proposal
Colin: I'm going to reply to you point for point because, frankly after reading your reply I felt like you were dredging up excuses, not reasons and I just feel compelled to challege your assertions. To the rest of you, please feel free it ignore the rest of my email if you would rather not be bothered with this issue. I'd love to see a forum but could live without one too. But I just couldn't help myself but go into pedantic mode given his arguments. ;) Perhaps you should try a different email client, then? So you are suggesting that I should change the application I spend 60% of my business day which meets many other needs besides just email so that I may accomodate your dislike for a forum? I wouldn't actually think you'd want to impose that on someone else, but it rather sounds that way. The only reason I say Often, is because the version of Safari I'm using allows you to resize text entry elements. I don't follow your reasoning. I use a vBulliten based forum every day and it's torture. I really dislike forums, but the people and issues I discuss on the forum outweigh my dislike of forums. To-may-to, To-mah-to. Er, I know that was meant as a joke, but calling someone you're trying to win to your side a luddite isn't the best way to do so. You mean there was more than a 0.1% chance I'd change your mind? Mailing list vs. forum is a religion just like Windows vs. Linux or Mac, REST vs SOAP, Java vs. .NET, Perl vs. Python. Conservative vs. Liberal. (US) Republican vs. Democrat. Christianity vs. Islam vs. Judiasm. And so on. There is rarely rational thought involved when discussing those kind of issues. So, I had zero expectation of converting you at all; I was making arguments for the rest of the list participants. Anywho, as has been said many times before; best not to take personal offense at what people say on the list because its far too easy to misinterpret. I've frequently had to count to 100 before typing, and I just joined recently. Can I *reply* from it? I'm pretty sure the answer is no, and the composing interface of my email client is much nicer. If you have an email client that accepts HTML mail and the admin configures the forum for that you can. Sure. User names. I hate them. Theyr'e tolerable on IRC, but in an area as permanent and public as a mailinglist/forum I'd rather have my full name associated with my (and others) posts, especially a technical discussion. It's a chore to keep track of remembering what crazy nick name corresponds to which person. I agree with you. That's why I have a policy on a forum I administer for my condo community that everyone uses real names. And I also have the same policy here: http://wiki.welldesignedurls.org/The_Rules There's nothing that says we couldn't (and shouldn't) have the same policy for a Microformats forum. Mailing lists also allow you to use an already established identity -- your email. On a forum, you have to create a completely new web presence and identity. I don't see why one would have to create a completely new identity. I almost always use MikeSchinkel or Mike Schinkel as applicable except in the rare cases I want to be anonymous. Not so helpful for John Smith, but for most of us it's not an issue. You can link it to your other ones with signatures and profiles, etc, but still, it's another login and another identity. Vs. another mailing list subscription to manage. To-may-to, To-mah-to. The above username/identity debacle a pretty huge one, and probably my number one complaint. Maybe we are getting some where; has my real name policy not addressed your concern? BBcode is a secondary one. It's awful. I hate having to deal with [quote] tags. Chevrons for quoting is so easier. Plain text email for the win. If you use the quote button instead of the reply button vBulletin quotes it for you. That said you can always use the same style quoting on a forum as you do in email if that your style. I find quoting in email much more or a PITA because I have to quote every line instead of just the begin and end of the quote. And if the person quoting is not careful (and who is?) the quotes will be too long and then you get an absolutely visual mess which is almost impossible to read. What's more, mailing list is plain text and makes it infinitely harder to present information in a understandable form than on a forum where you have lots of formatting options. And vBulletin has an optional WYSIWYG editor now so BBCode's not an issue. It also costs money. Who's going to pay for that? vB $85? Are you for real? $85 is pocket change for almost anyone with the technical skill to be active on this list. I'm currently unsure who my next client or revenue source will be (long story; after 12 years running Xtras.Net, I need a break and am being very selective), and *I'd* pay for the damn thing if that's what it took. is also not exactly slim in the markup it generates. Who would pay
RE: Re: [uf-discuss] Mailing list debate moved new proposal
Chris: I mean, once you're into personal preferences, Just a point of note, I brought my preferences up only to show that there were counter preferances and that one-sided preferences shouldn't be the driving factor. Which was a much more verbose way of saying what you just said. But rather than host it all here on the microformats-discuss list, there's no reason why folks can't go off and start their own efforts, as others have (see: Social Media Club). You are right, there is no reason people can't, but respectfully I think it's not a good idea for them or for the Microformats initiative. There would be a HUGE duplication of effort, and I don't mean related to technical work; I mean related to the branding and marketing and PR of the proposed new efforts. I think haven't splinter groups would also potentially confuse the web development public for which 99% have yet to learn of Microformats. Mindshare and attention are in finite supply and any similar initiatives would take away from the mindshare and atttention related to Microformats. For example, if we had two oor three other groups vying for media attention (or eventually 50+ other groups) then the Microformat message could easily get diluted, obscured, or become invisible. And for splinter groups we'd have no control how they position themselves and/or we'd have to pay lawyers to tell them to stop using the Microformat term if we didn't like how they were using it. And on and on and on. So I think it would be much much better to scale up the process so that lots of people can involved all under the marketing and PR of the Microformat brand. And frankly I don't think it would be that hard to manage. It would primarily take specifying a process by which these other groups get formed and what activity and quality they need to achieve and then maintain, and then som ongoing monitoring. Chris, don't get me wrong; I respect your opinion greatly. I can see how your idea seemed good at the time, but don't you now agree that it could be a minefield of unexploded IEDs? Hopefully you see my point now, and concur? -Mike P.S. BTW, I've been advocating vBulletin, but I also have a Community Server forum up and running RIGHT NOW that also (could) integrate with a mailing list (I'd have to buy the add-on first) and we could use it for those who like forums, everyone else would be unaffected assuming we all agree. The forum us located at http://www.MashupTalk.com and I plan to get it going in the near future. Having a section on Microformats would fit perfectly into it's mission. What do you think? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Friday, November 03, 2006 4:44 AM To: Microformats Discuss Subject: Re: Re: [uf-discuss] Mailing list debate moved new proposal Wow. This thread spiraled into nowhere land quickly. I mean, once you're into personal preferences, you know that you're never going to win. Some prefer email, some forums, some RSS -- hell -- it's just the *display* of data. Thank g*d we separated those two a long time ago so that people can have their way! (Just for notes, Google Groups Beta is kind of the ideal merger of forums, email and RSS, if you haven't tried it yet). Anyway, let me throw out something controversial to steer this back. So there's been discussion about creating new lists for every new microformat that's proposed. Well, that sounds like a very fractious action, that could really undermine the authority of the group. Or not. But rather than host it all here on the microformats-discuss list, there's no reason why folks can't go off and start their own efforts, as others have (see: Social Media Club). I'm not advocating the splitting of the community, but I am advocating for folks to see to their own desires, interests and verticals and take the model, spirit and goals of microformats and strike out on your own and work to get your own microformats adopted. Because it's true, this form of dialogue doesn't scale well -- and the only way to advance is to farm out the work to distributed nodes in the system, let them focus hard and work hard, and then return back with their findings, implementations and/or adoptions. No one's stopping you. As far as I'm concerned, have at. Chris On 11/3/06, Frances Berriman [EMAIL PROTECTED] wrote: On 11/3/06, Benjamin West [EMAIL PROTECTED] wrote: If people want to filter things out, or draw particular attention to a thread being related to a specific proposal, using the [hCard] notation (for example) works quite well in the subject field. I concur. Filtering features are well supported on many of the mail clients I've seen, and a simple filter with the convention of tagging threads with square brackets would probably work fine. I like simple solutions. :) To be honest, I just don't want to be checking a mailing list, wiki AND a forum. Selfish, selfish of me. --
RE: [uf-discuss] Best Practice for fn and n?
Maybe I'm missing something, but wouldn't you have to include white-space for a visible display anyway? i.e. span class=vcard span class=n fn span class=honorific-prefixMr./spannbsp; span class=given-nameJohn/spannbsp; abbr class=additional-name title=QuinlinQ./abbrnbsp; span class=family-namePublic/span,nbsp; span class=honorific-suffixM.D./span/ /span /span -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Costello, Roger L. Sent: Sunday, November 05, 2006 9:49 AM To: Microformats Discuss Subject: RE: [uf-discuss] Best Practice for fn and n? Thanks Brian. I intuitively figured there was something wrong with using an empty abbr element. In fact, my first attempt was to do just as you suggest. However, I realized that there is a problem with that. Namely, when all the values are concatenated together we get this value for fn: Mr.JohnQ.PublicM.D. That is, no space between the parts. One solution would be to add a space after each part: span class=vcard span class=n fn span class=honorific-prefixMr. /span span class=given-nameJohn /span abbr class=additional-name title=QuinlinQ. /abbr span class=family-namePublic /span, span class=honorific-suffixM.D./span/ /span /span Then the concatenation of the values will yield the desired fn: Mr. John Q. Public, M.D. However, I don't like that solution either, because now the given name is John , rather than John, and the family name is Public , rather than Public. This extra whitespace could be a killer for tools that do value-added hCard services. Any suggestions on how to solve this problem? /Roger -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Suda Sent: Sunday, November 05, 2006 9:13 AM To: Microformats Discuss Subject: Re: [uf-discuss] Best Practice for fn and n? Having empty elements is a bad idea. TIDY will outright remove empty abbr/ elements, plus it goes against Human-readablity. For all the same reasons META elements get state, empty inline elements will get state as well. Why not just use class=n fn, you are displaying all of the 'n' data inside your empty 'abbr', so why not just remove the 'abbr' and move the class='fn' to the same data as the class='n' span class=vcard span class=n fn span class=honorific-prefixMr./span span class=given-nameJohn/span abbr class=additional-name title=QuinlinQ./abbr span class=family-namePublic/span, span class=honorific-suffixM.D./span/ /span /span On 11/5/06, Costello, Roger L. [EMAIL PROTECTED] wrote: Hi Folks, Here is some HTML text that I want to markup using the hCard fn and n properties: Today's speaker is Mr. John Q. Public, M.D. I propose marking it up in this fashion: Today's speaker is span class=vcard abbr class=fn title=Mr. John Q. Public, M.D. / span class=n span class=honorific-prefixMr./span span class=given-nameJohn/span abbr class=additional-name title=QuinlinQ./abbr span class=family-namePublic/span, span class=honorific-suffixM.D./span/ /span /span Notice that I am using an empty abbr element to store the value for fn. Is this sensible? Is there a better way to markup the HTML text? Is this Best Practice? /Roger ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] MicroFormat Ltd
Ouch. Sounds like a trademark fight might occur, as commercial entities lawyer's tend to recommend that kind of thing... -Mike Schinkel President; Guides, Inc. http://www.guidesinc.com (404) 474-8948 (404) 276-1276 cell (404) 474-8949 fax skype: mike.schinkel [EMAIL PROTECTED] http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ http://www.linkedin.com/in/mikeschinkel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Sunday, November 05, 2006 1:01 AM To: Microformats Discuss Subject: [uf-discuss] MicroFormat Ltd Have you guys ever heard of MicroFormat Ltd? Microformat has a long and proud history of involvement in preservation microfilming, and I am wholly delighted that we have been entrusted with this most important and exacting project'. It seems fitting, for some reason, since they're into the preservation of data: http://microformat.co.uk Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Mailing list debate moved new proposal
You seem to assume that we want to scale. :D However, those solutions are against the grain of microformats. They'd no longer be simple, they'd no longer work together. There would be too many of them. Then I am getting more and more disenchanted with the whole MicroFormat concept. Microformats will be nowhere nearly as useful I as first assumed it to be. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan King Sent: Monday, November 06, 2006 2:31 PM To: Microformats Discuss Subject: Re: [uf-discuss] Mailing list debate moved new proposal On Nov 2, 2006, at 5:37 AM, Mike Schinkel wrote: I'm going to reply to several responses at once. Why not create a new mailing list for each proposal, once it's reached a certain stage? Ryan King Because that's more administrative overhead for Ryan King admin's who're already overloaded. The problem is that the current Microformat process is not at all scalable. It is much like having you managing a file containing all domain names, and anytime someone wants a new domain name or subdomain, or make a change, they have to get your time and attention. I think we all know what a boon DNS was. We should look to benefit from prior knowledge and organize the Microformat inititive so it can scale. You seem to assume that we want to scale. :D The beauty of DNS is that you can divide up the process of minting domain names in a way that it's impossible for people to step on each other's toes. With microformats, we don't have such technology. We could use URI namespaces (which, ironically, leverage DNS), or we could do prefixing of property names or something else. However, those solutions are against the grain of microformats. They'd no longer be simple, they'd no longer work together. There would be too many of them. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] MicroFormat Ltd
that would make it unlikely that they could sue anyone since Anybody can sue anyone for anything and hence eat up lots of lawyer bills. Whether they'd win is another subject. ;) Chris said that it is similar, and if MicroFormat Ltd's lawyer think it *might* confuse (and what lawyer's wouldn't think that when it is the most conservative option and they get to bill them to advise their client of such), they could send a cease and desist letter causing this group some pain. Anyway, either it will or will not happen; remains to be seen if it does. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Tuesday, November 07, 2006 12:57 PM To: Microformats Discuss Subject: Re: [uf-discuss] MicroFormat Ltd Hello, They are in an entirely different industries. From my understanding of Trademark law... that would make it unlikely that they could sue anyone since (from the law's point-of-view) there is little chance of confusion between the 2 names (since they are in different industries). (Oh yeah... IANAL. But unless trademarks law has radically changed. I think AL would say something to that effect too.) See ya On 11/7/06, Colin Barrett [EMAIL PROTECTED] wrote: Perhaps we could trademark µformat (greek-letter-mu format) and say that the term microformat is just an expansion / alternate name for it. I don't even know if that would work, IANAL. -Colin On Nov 6, 2006, at 3:36 PM, Mike Schinkel wrote: Ouch. Sounds like a trademark fight might occur, as commercial entities lawyer's tend to recommend that kind of thing... -Mike Schinkel President; Guides, Inc. http://www.guidesinc.com (404) 474-8948 (404) 276-1276 cell (404) 474-8949 fax skype: mike.schinkel [EMAIL PROTECTED] http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ http://www.linkedin.com/in/mikeschinkel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Sunday, November 05, 2006 1:01 AM To: Microformats Discuss Subject: [uf-discuss] MicroFormat Ltd Have you guys ever heard of MicroFormat Ltd? Microformat has a long and proud history of involvement in preservation microfilming, and I am wholly delighted that we have been entrusted with this most important and exacting project'. It seems fitting, for some reason, since they're into the preservation of data: http://microformat.co.uk Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private -- 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Re: MicroFormat Ltd
I highly doubt that it will cause real confusion; furthermore, who would be sued? No one owns the microformats name besides the community -- which is why it's a community mark. We really don't have any assets or formal structure, so it would be rather difficult to bring this to court. The registered owner of the domain. It would be a cease-and-desist suit, not necessarily a suit for damages. I wouldnt contact them. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Tuesday, November 07, 2006 1:18 PM To: Microformats Discuss Subject: [uf-discuss] Re: MicroFormat Ltd I highly doubt that it will cause real confusion; furthermore, who would be sued? No one owns the microformats name besides the community -- which is why it's a community mark. We really don't have any assets or formal structure, so it would be rather difficult to bring this to court. But that's highly unlikely as it is, since their name is singular. I mean, we could do the right thing and contact them to let them know that we're not looking to encrouch and maybe we'll be rewarded with good karma... Or we could just fuggetaboutit. ;) Chris On 11/7/06, Mike Schinkel [EMAIL PROTECTED] wrote: that would make it unlikely that they could sue anyone since Anybody can sue anyone for anything and hence eat up lots of lawyer bills. Whether they'd win is another subject. ;) Chris said that it is similar, and if MicroFormat Ltd's lawyer think it *might* confuse (and what lawyer's wouldn't think that when it is the most conservative option and they get to bill them to advise their client of such), they could send a cease and desist letter causing this group some pain. Anyway, either it will or will not happen; remains to be seen if it does. -Mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Iliya Krempeaux Sent: Tuesday, November 07, 2006 12:57 PM To: Microformats Discuss Subject: Re: [uf-discuss] MicroFormat Ltd Hello, They are in an entirely different industries. From my understanding of Trademark law... that would make it unlikely that they could sue anyone since (from the law's point-of-view) there is little chance of confusion between the 2 names (since they are in different industries). (Oh yeah... IANAL. But unless trademarks law has radically changed. I think AL would say something to that effect too.) See ya On 11/7/06, Colin Barrett [EMAIL PROTECTED] wrote: Perhaps we could trademark µformat (greek-letter-mu format) and say that the term microformat is just an expansion / alternate name for it. I don't even know if that would work, IANAL. -Colin On Nov 6, 2006, at 3:36 PM, Mike Schinkel wrote: Ouch. Sounds like a trademark fight might occur, as commercial entities lawyer's tend to recommend that kind of thing... -Mike Schinkel President; Guides, Inc. http://www.guidesinc.com (404) 474-8948 (404) 276-1276 cell (404) 474-8949 fax skype: mike.schinkel [EMAIL PROTECTED] http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ http://www.linkedin.com/in/mikeschinkel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Messina Sent: Sunday, November 05, 2006 1:01 AM To: Microformats Discuss Subject: [uf-discuss] MicroFormat Ltd Have you guys ever heard of MicroFormat Ltd? Microformat has a long and proud history of involvement in preservation microfilming, and I am wholly delighted that we have been entrusted with this most important and exacting project'. It seems fitting, for some reason, since they're into the preservation of data: http://microformat.co.uk Chris -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private -- 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 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- Chris Messina Citizen Provocateur Open Source Ambassador-at-Large Work: http://citizenagency.com Blog: http://factoryjoe.com/blog Cell: 412 225-1051 Skype: factoryjoe This email is: [ ] bloggable[X] ask first [ ] private ___ microformats-discuss mailing list microformats-discuss
RE: [uf-discuss] Mailing list debate moved new proposal
microformats have always been intended to simply solve common real-world problems in an 80/20 fashion. This limitation is quite deliberate, and is key to microformats being *actually* useful in the immediate/nearterm future, as opposed to *theoretically* useful in some ideal/imaginary world where boil the ocean (BTO) solutions have some how magically altered human culture and society as a whole to radically change behavior and adopt them wholesale. There is nothing in what I'm envisioning or proposing that would make them theoretical. I would just like to address more areas that it appears you want to address. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç elik Sent: Tuesday, November 07, 2006 1:22 PM To: microformats-discuss Subject: Re: [uf-discuss] Mailing list debate moved new proposal On 11/7/06 9:59 AM, Mike Schinkel [EMAIL PROTECTED] wrote: You seem to assume that we want to scale. :D However, those solutions are against the grain of microformats. They'd no longer be simple, they'd no longer work together. There would be too many of them. Then I am getting more and more disenchanted with the whole MicroFormat concept. Microformats will be nowhere nearly as useful I as first assumed it to be. To be clear Mike, microformats were never envisioned to solve all format problems, or metaformat problems etc. That ocean boiling is better left to many others who are pursuing those goals. microformats have always been intended to simply solve common real-world problems in an 80/20 fashion. This limitation is quite deliberate, and is key to microformats being *actually* useful in the immediate/nearterm future, as opposed to *theoretically* useful in some ideal/imaginary world where boil the ocean (BTO) solutions have some how magically altered human culture and society as a whole to radically change behavior and adopt them wholesale. http://microformats.org/wiki/microformats Thanks, Tantek ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Re: MicroFormat, Ltd.
suggest we all calm down Just for the record, I was never no calm about it. I only brought it up as something to be aware of and then several people responded that (in essense) my concerns were invalid, and I was simply replying that I disagreed and felt that it was a potential issue. I'm totally calm about it; I just felt them need to clarify things so as to be lucid about the situation. this list is *not* the place to begin throwing around legal concerns. That feels like a slap at me, so I'm going to slap back. You may feel that way, but there has been no related-guidance prior to this email. As sich I do not appreciate being chastized in a public forum for voilating your choice of how you would like things to be handled when your guidance on how to handle the situation was given in retrospect. Respectfully, -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rohit Khare Sent: Wednesday, November 08, 2006 12:08 PM To: microformats-discuss@microformats.org Subject: [uf-discuss] Re: MicroFormat, Ltd. The registered owner of the domain Umm, as the owner, I'd like to suggest we all calm down and let things lie. As the actual registrant of the domains microformats.org/com under the auspices of CommerceNet, LLC, I'm sure that any issues of our proper use of it would fall under the rubric of our continued informal support of the microformats community. (We're an independent think tank that grew out of a nonprofit membership consortium in the 90's - for more, check out our website ) But more prosaically, one of the achievements of the cooperative microformats effort is that it *has not* required a lot of 'process' -- and that, even so, this list is *not* the place to begin throwing around legal concerns. This is a public, archived forum, and without reference to the merits of anyone's points made today, this is one of the very few categories of things that I suggest should be addressed directly to me (or Tantek) before escalating to the community. Thanks, Dr. Rohit Khare Director, CommerceNet Labs (Consulting) --- Via BlackBerry ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Proposal: wine
Andy Mabbett wrote: c/f recent discussion about uF mailing lists, and my comment: For example, several academic and professional taxonomists have told me in e-mail that they would be interested in the species proposal, (and one astronomer, likewise, for mars/ luna), but do not have the time to follow a general mailing list; indeed, a couple asked me specifically if I would set up a separate mailing list for the subject. Funny how we get to have deja vi all over again, eh? ;-) -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Proposal: wine
Frances Berriman wrote: On 11/17/06, Mike Schinkel [EMAIL PROTECTED] wrote: Andy Mabbett wrote: c/f recent discussion about uF mailing lists, and my comment: For example, several academic and professional taxonomists have told me in e-mail that they would be interested in the species proposal, (and one astronomer, likewise, for mars/ luna), but do not have the time to follow a general mailing list; indeed, a couple asked me specifically if I would set up a separate mailing list for the subject. Funny how we get to have deja vi all over again, eh? ;-) Lets not (cross posting). Keep the discussion about mailing lists to the mailing list thread. What cross posting? Are you trying to say it's inappropropriate to bring up a prior discussion when it is relevant to the current discussion? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] hThing microformat ... or design pattern
=productAudi Q7 3.6 Premium/span span class=price$42,900/span (SRP: span class=srp$45,900/span ) div class=descriptionThe power, control, performance and design of the Audi Q7 3.6, enhanced with luxurious extras: a Bose Premium sound system and MMI Advanced with color screen are just the beginning./div /div /li li div class=saleable span class=productAudi Q7 4.2/span span class=price$45,900/span (SRP: span class=srp$49,900/span ) div class=descriptionA true milestone that combines unforgettable Audi performance, safety, design, and versatility with the best qualities of an SUV, including off-road capabilities, a high seating position, and interior spaciousness and flexibility. The Audi Q7 makes the impossible possible./div /div /li li div class=saleable span class=productAudi Q7 4.2 Premium/span span class=price$52,900/span (SRP: span class=srp$59,900/span ) div class=descriptionWith a host of innovative, standard extras including Rear View Camera with Acoustic Parking, Audi Side Assist, and Advanced Key, the Audi Q7/div /div /li /ul /div = From my experience of literally thousands of hours trying to taxonify product information in order to automate the business and improve the company's website, this is what I think is needed. Now I haven't tried to reconcile any of this to hlisting or anything else more than just a cursory glance. I look forward to everyone's thoughts and input. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Gustafson Sent: Friday, November 17, 2006 7:38 PM To: Microformats-Discuss Subject: Re: [uf-discuss] hThing microformat ... or design pattern David Janes wrote: I'm not sure if I'm that excited :-) but I definitely think there's a gap that can be filled (i.e. that hReview/hListing identify people directly but only things indirectly). It's possible, but this is very speculative, that this could simplify the path for creating new microformats like hWine. I am just joining the discussion list, so forgive me if what I rehash older discussions. Craig Cook and I had been working on hProduct somewhat in isolation and thought we should post the information we've created to get our ideas and thoughts out there. I see some sililarities with what is up on hItem, though I agree hItem may be a little too broad (see the earlier 'what is an item?' comments). I'd definitely advocate for hItem including information about its creator, and optionally its producer and vendor. These of course could be hCard entries or links, and I think it would give us a flexible way to include much of the information that felt very wine specific such as Vintage (aka, producer and production date). It seems as though an hItem's production and creation could also be considered events, so reusing hEvent here seems to make a lot of sense. What do you think? Is this more complicated than it needs to be, or is the reuse of other microformats here a good thing? Let's go through the examples and see what's frequently used, somewhat used and rarely or sporadically used. That will point the right direction I think. And, as per usual, I encourage everyone to contribute to the examples because that's one of the hardest and least thanked parts. Hmm, I think we really need to boil this down to its essence. With products, unless you want to go the route niche microformats like hWine or hBook, it makes sense to stick to a few key, repeatable fields, for example: * name * description * image * msrp * uri * brand The rest could be handled by a generic property value construct which we've called 'p-v' (and may honestly have usefulness outside the hProduct/hItem concept). Also, is this ground already being covered by hListing (which seems to be looking to include some of this info), or would you simply have hListings of events (hEvent), people (hCard), and things (hItem)? The latter, but we're data mining hListing/hReview to maximize reuse. IMHO, there are a few places I think hListing (and hReview for that matter) are reaching a bit beyond what should be their scope. This is where
[uf-discuss] Cite rev-reply
Hi all: I'm trying to figure out how best to use cite rev-reply in the case of replying to a commentor on a blog post. Using the example from http://microformats.org/wiki/cite-rel as a guide: In reply to cite class=rev-reply a href=http://Example.com/your-blog-annoys-me; this post/a/cite by a href=http://theRyanKing.com/; Ryan King /a. *INSERT FLAME HERE* I don't want to say that the blog post annoys me, I want to say that the commentors on the blog post annoys me. :-) Thoughts on that usage? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ P.S. FWIW, here is the blog post: http://www.hawaiistreets.com/seoblog/?itemid=748catid=20 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] RDFa vs microformats
Thanks for the article. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Mabbett Sent: Saturday, November 25, 2006 10:39 AM To: Microformats Discuss Subject: [uf-discuss] RDFa vs microformats In case you missied my adding it to the 'wiki;', here's an article about RDFa vs microformats : http://evan.prodromou.name/RDFa_vs_microformats -- Andy Mabbett Say NO! to compulsory ID Cards: http://www.no2id.net/ Free Our Data: http://www.freeourdata.org.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] [citation] url field
On Dec 1, 2006, at 3:55 PM, Bruce D'Arcus wrote: Scott Reynen If you mean why not call it URI?, Yeah, that's what I mean, and worried about collapsing the notion of URI as a name, and URL as a location. I'm skeptical we can rely on parsing a URL fo extracting a DOI/ISBN/etc. Have you looked at the ISSN URN (RFC 3044)? http://www.ietf.org/rfc/rfc3044.txt -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] [citation] url field
A couple points on this subject. I have recently been doing a *lot* of research in the area of URLs/URIs and having discussions with numerous people on REST-discuss and www-TAG lists so I feel I'm pretty well-versed on this subject now. Although it is possible to infer an ISBN or maybe even a DOI from a URL, it is considered Bad Practice unless the URI Authority (i.e. owner of the website) specifically documented the structure of the URL and gave a reasonably trustworthy guarantee that it will not change. References: 1.) Architecture of the World Wide Web, Volume One section 2.5 on URI Opacity [1]: Good practice: URI opacity Agents making use of URIs SHOULD NOT attempt to infer properties of the referenced resource. 2.) The use of Metadata in URIs section 2.1 on Reliability of URI metadata [2] Constraint: Web software MUST NOT depend on the correctness of metadata inferred from a URI, except when the encoding of such metadata is documented by applicable standards and specifications. 3.) The use of Metadata in URIs section 2.1 on Reliability of URI metadata [2] The principle conclusions of this finding are: * Assignment authorities may publish specifications detailing the structure and semantics of the URIs they assign. Other users of those URIs may use such specifications to infer information about resources identified by URI assigned by that authority. * People and software using URIs assigned outside of their own authority should make as few inferences as possible about a resource based on its URI. The more dependencies a piece of software has on particular constraints and inferences, the more fragile it becomes to change and the lower its generic utility. In the case of Jon Udel's LibraryLookup which as been referenced as an example: Data point: ISBNs are already being reliably extracted from URLs: http://weblog.infoworld.com/udell/stories/2002/12/11/librarylookup.html Jon's work has been derided by purists as doing something it shouldn't i.e. peeking into URLs when they should remain opaque. Personally, I don't see what Jon did as such a bad thing. Jon's script interfaces with a human only, and if Amazon ever changes their URLs his script just won't work and the user will figure that out. In the mean time by breaking the rules he's offering pretty useful functionality that he couldn't get otherwise. And even Amazon does changes their URLs and his script breaks, which is highly unlikely given their affiliate program, Jon can just update his script and then anyone who has a broken script can search for Jon's new version (unless Amazon eliminates the ISBN from the URL, which I would highly doubt.) However, advocating the use of non-document metadata in a URL for a Microformat citation is a completely different matter. Rather than one author (Jon Udell) using it for one app (LibraryLookup) where it's users can later get updates if required, advocating it for a Microformat where authors will markup untold HTML content, much of which will never get updated for future revisions requires a very high bar for immutability. IOW, we should ensure that we have a *guarantee* that the format of the URL will *never* or we shouldn't use it. Yes we *could* still parse the old format, but we'd have to continue adding parsers some of which might eventually fail for ambiguity. At the moment, the only immutable reference for an ISBN is a URN from RFC 3187[4]. For example: URN:ISBN:0-395-36341-1 This doesn't deference in a browser, if used in IE7 for example, but one day it might. But we can be sure it is definitely immutable. As for resolving DOIs, they are new to me and I've not done enough research to determine if there is an immutable resolvable source for DOIs. This article[5] and these websites ([6] [7]) might be helpful there. As an aside, please don't take this as me being unsupportive. On the contrary, I am a strong advocate to get website owners to put metadata in their URLs and to document that metadata. However, until we have solid sources of URLs with documented metadata, we should probably all play smartly by the rules as specified by the W3C, at least IMO. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://www.w3.org/TR/webarch/#uri-opacity [2] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061107.html [3] http://www.w3.org/2001/tag/doc/metaDataInURI-31-20061107.html#N1023D [4] http://www.ietf.org/rfc/rfc3187.txt [5] http://www.dlib.org/dlib/june98/06powell.html [6] http://www.handle.net/ [7] http://www.doi.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] [citation] url field
Andy Mabbett wrote: What about: a class= tag isbn href=http://www.example.com/wibble/71194301X; which could be a URL on the same site as the citation, or on a trusted bibliographic website. Agreed, but is there the latter? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Comments from IBM/Lotus rep about Microformats
For those on this list who are not following [whatwg], here is an interesting thread about inability to use Microformats: http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-December/00 8462.html I wonder if his issues can be addressed? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
Bruce D'Arcus wrote: RDFa includes namespacing, the lack of which is already a problem in microformats (witness hCite and the serious awkwardness that title will be indicate using fn), and which will grow over time as more and more people want to mark up their content. Moreover, the need to write dedicate code for each new microformat will also present serious scalability problems. Finally, that there's no model at the heart of microformats with clear extension rules means that the vaunted social process here is a mess. It's all centralized, and people get frustrated when their pet property isn't included because they know what that means: the tools written for the blessed microformats won't see them. I agree with your comments. Whereas I think XML namespaces are too difficult for widespread adoption in HTML markup, I think the lack of any similar scope mechanism for Microformats and the resistance of some in the Microformat to prepare Microformats for scaling in usage and application mean that Microformats may end up being remembered as a good idea at the time but quite possibly not in use several years out. Scott Reynen wrote: I think it's just a limited goal of solving specific problems as simply as possible. If people want to solve general problems without the constraints of keeping it simple for publishers, I'd say they should do that somewhere else. I think you are creating a false dichotomy. I do agree that RDF is too difficult, but I don't think addressing the issues in another way would necessarily sacrifice ease of use. David Janes wrote: The best part about microformats (IMHO) is not the class and rel and abbr stuff, but the fact that it deliberately constrains itself to real problems that people are actually having. But only those real problems, as Bruce pointed out, that conform to some limited set of terms that only get agreed to through some tortuous process of which the vast majority of people couldn't be bothered. Benjamin West wrote: Talk of general microformats doesn't make sense. Talk of microformats as technique also does not make sense. If that is true, then having Microformat Design Patterns[1] doesn't make sense. Which is it? The core problem is no strategies have been adopted to avoid naming collisions, and to avoid having the whole concept self destruct from it's own weight of complexity. People who want to contribute but can't because the centralized Microformat community is not interested will go off and create their own and names start clashing, we'll just be left with one big mess. Most of the Microformat community seems to want to keep Microformats a tight knit club focused on a small number of use cases that reviews and approves everything, declining things they don't like, but I think there is really an obligation to the Internet at large to address how to scale the process because Microformats squat on a scare resource (names in classes.) With great power comes great responsibility; Microformats has a responsibility to the web at large to ensure Microformats can scale, but all I've seen is resistence to even consider that (which is one of the reason's I've been quiet lately.) -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ [1] http://microformats.org/wiki/Main_Page#Design_Patterns ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
S. Sriram wrote: This is not a scarce resource, people can (and are) naming classes as they choose. Any constraint happens at the parsing stage, since microformat-aware parsers look for specific class names etc. (see below) If it is not a scarce resource, please tell me what would happen if I decided to start marking up documents, as an example, using the class directory and license, for purposes other than rel-directory and re-license? How could my markup and those Microformats co-exist in the same HTML document? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
--- these values are not reserved across all of HTML. We have a mechanism to prevent this, it is called Profile URIs, if a parser comes across class=vcard then the best way to determine if this is a random CSS Style or a semantic value is to see if there is a Profile URI that matched the XMDP of hCard. Are you referring to this? http://www.w3.org/TR/html401/struct/global.html#profiles Is a Profile URI a well-known URI where I have to find semantics elsewhere or if not what format is returned by the URI? (just trying to understand) How can I disambiguate when two Microformats collide? Let me give a concrete example (one I will be working on in the future): Looking at ADR, here is an example: div class=adr div class=street-address665 3rd St./div div class=extended-addressSuite 207/div span class=localitySan Francisco/span, span class=regionCA/span span class=postal-code94107/span div class=country-nameU.S.A./div /div Now let's say I want to use something called RegionData where Regions are heirarchical: div class=region-data div class=region street title=child-of-city 665 3rd St.; Suite 207 /div span class=region city title=child-of-stateSan Francisco/span, span class=region state title=child-of-countryCA/span span class=post-code94107/span div class=region country title=child-of-continentU.S.A./div /div Now, someone needs to use both: div class=region-data vcard div class=region street title=child-of-city div class=street-address665 3rd St./div div class=extended-addressSuite 207/div /div span class=region city locality title=child-of-stateSan Francisco/span, span class=region state region title=child-of-countryCA/span span class=post-code postal-code94107/span div class=region country country-name title=child-of-continentU.S.A./div /div How do I disambiguate between region-data's region and vcard's region? Assume I created my RegionData with no knowledge that vcard existed, because unless there is a central clearing house to avoid name clashes, two different groups will end up creating conflicting microformats with clashing names. It is also only a hypothetical issue, so until this becomes a real issue, we're not going to worry too much about it, but we do have a system that solves this problem. So we aren't squatting on any values. Hypothetical issues sometimes have a way of biting people in the ass, using a phrase Mark Baker recently said on the REST-discuss forum on another topic. :) However, this is not a hypothetical issue. A project I'm working on that I'm not willing to go public with yet will make heavy use of microformats-like markup, and I've already seen a lot of potential for collision such as the one above, which is an example of a planned use. But maybe Profile URIs can solve this. Can you please explain how, using my example? -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: [uf-discuss] Comments from IBM/Lotus rep about Microformats
S. Sriram wrote: They would simply co-exist. Period My only response to your comments is that I strongly disagree with you, but as you appears you have a similar conviction it would be a waste of time to debate it further. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
RE: Re: RE: [uf-discuss] [citation] url field
Ironically, this sounds like another real-world (i.e. not hypothetical) example of the need to provide a way to differentiate microformats. -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael McCracken Sent: Thursday, December 07, 2006 6:05 PM To: Microformats Discuss Subject: Re: Re: RE: [uf-discuss] [citation] url field This seems to have been buried - so again, to anyone interested in hCite: I want to define a new field URL to denote an http URL that points to the location of a copy of the cited work. URIs that encode an identifier of the work can be combined with this field, but do not need to be. I understand that the name URL may overlap a bit with URI, and something like downloadlink, etc. might be more direct, but I argue that URL is the better choice because it is the most common name already in use in our examples from the web. Can we discuss this revised version of the proposal (or just vote on it?) Thanks, -mike ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
