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
[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] 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
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] 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] 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] 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] 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] 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
[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