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
Re: Reorganizing the Wiki is Fun for Everyone (Was: [uf-discuss] hCalendar spec- no specification included!)
On 10/16/06, Scott Reynen [EMAIL PROTECTED] wrote: I'd love to see Andy, Phae, Scott, Tantek, and anyone else interested in improving the wiki start to use the to-do list so I can align my organizational thoughts with everyone. Perhaps we can even run some kind of virtual card sort to help establish how things should be organized. Anyone have any ideas on how to do this? Thanks Ben for taking this initiative in organizing our wiki-cleaning labor around our shared goals. I will try to add my own thoughts to this as soon as I have some spare time, and I look forward to seeing a wide variety of thoughts on wiki reorganization to reflect the wide variety of use cases for the wiki. Seconded. Spread the load a little between those of us that want to help out, and it should get done in a way that'll suit the majority. -- Frances Berriman http://www.fberriman.com ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Know your stuff: (Was: [uf-discuss] hCard-o-matic toplevel div not address?)
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/13.html http://microformats.org/discuss/mail/microformats-discuss/2005-November/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
[uf-discuss] Lightweight Data Access Services and Well Designed Urls
Karl: 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. 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. Since you commented, did you read this first? http://www.mikeschinkel.com/blog/welldesignedurlsarebeautiful.aspx Do you see recommendations there that you think will cause problems? (Be aware that it's been 16 months since I wrote that and am really ready to revise it.) What I do want to do is shine a light on the cons of various choices for web site developers as well as platform developers (Microsoft is one in need of hearing this message.) As an aside, I think limiting choice can be good (if you have ever eaten at TGI Fridays, I'm sure you will relate to that comment!) Too much choice creates chaos and allows inexperienced people to make really sub-optimal choices for no other reason than happenstance. Best practices call out where the pitfalls are, and how best to avoid them. If all choice was good all the time there would never be any use for Best Practices for anything, right? As an example Link Ranking Systems have increased spam on the Web and nofollow didn't solve it at all. I think the things I'm thinking about as best practices are not of the same as the types you are talking about. I planning to codify those things that will make it easier for users to work with URLs; I'm not trying to create a new layer on the web or any new standards, only patterns. And nothing like Link Ranking Systems or nofollow. For example: * Once published, don't move the content to another URL * But if you move it, always leave a 301 or 302 redirect when you move a URL * Don't change the meaning of content at a published URL (with caveats, to be later discussed) * Ideally don't use extensions for (X)HTML content. * If you must use an extension for (X)HTML content, use either .HTM or .HTML * Extensions on URLs should define the content, not the technology that was used to create the content (i.e. .HTML not .ASPX, .JPG not .PHP, etc.) * When you peel off a subdirectory from a URL it should return a valid and appropriate .HTML page * Avoid using magic numbers in URLs whenever possible (i.e. use www.mysite.com/cars/ not www.mysite.com/5/) * A URL with a trailing slash should equal a URL w/o a trailing slash. (i.e. www.mysite.com/foo should be the same as www.mysite.com/foo/) * Organize major site divisions by subdomain (I need to put a lot more thought into this one about when and when not to) * Sitemaps and Website URL structures should have a very tight coorelation. * For new websites and website redesign, design your URL structure as one of the first steps. * Plus a *LOT* more... Also, please let's not debate these specific examples HERE (unless they are of the *type* that you caution me about); that's what the blog, list, and wiki are for, and besides I'm writing these on the fly and have not fully fleshed them out yet. I don't want to impose too much more on this list. BTW, some of the above it is VERY DIFFICULT to do in Microsoft IIS (until version 7.0) and many commercial web applications and content management systems) do a horrific job related to providing clean URLs (i.e. Vignette, DotNetNuke, etc.). However to date there's been no set best practices so the platform developers are like Alfred E. Newman and they say What, me worry? ;-) I want to give them something that says What you are doing when you are not considering your URL structure is creating all kind of problems for all kinds of people and here is why you need to think about your URL design and not consider the URLs your apps create to be just your own private Idaho. I also want to give Windows-centric hosting companies more reasons empower users to clean up their apps URLs. And more. (I hope you undersood my two potentially American-centric puns above. :) This is much more about shining a light into a problem area / area of opportunity than it is specifying some new set of standards. Think of it as similar to Jesse Jame Garrett and his declaration of AJAX (though I could only wish to be that influencial.) Jesse didn't defined any new standard with AJAX, he just applied a name to an existing set of technologies and recommend a set of patterns for how they can be used. So like Jesse, I'm more proposing *PATTERNS*and not *STANDARDS*. Make sense? 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.) I'm not seeing how this relates to URL design per se. Also, are you considering Microformats only valuable for
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
[uf-discuss] include-pattern semantics
When the include-pattern[1] is used, the spec says that 'include' on the object element to indicate that that object refers to a subtree which should be included in its place' [2]. What I'm interested in is what happens to any additional classes that are applied to the inclusion element (i.e. the A or OBJECT). My instinct when marking up an entry in hAtom, for example, would be to use something like the following: a class=include author href=#vcard-elsewhere / The spec and examples don't make it clear whether the included element will 'inherit' the @class=author from the A, or whether it would be ignored. Does anyone with an existing implementation or parser have an opinion about whether this sort of markup is correct? If not, what would be the correct markup, or what would be the behaviour of existing parsers when presented with something like the above? Whatever the answer, I think it'd be a good idea to update / add to the examples to cover this case - I'd be happy to do so myself once I know what the correct answer is. Cheers, -Ciaran McNulty [1] http://microformats.org/wiki/include-pattern [2] http://microformats.org/wiki/include-pattern#class_name_.22include.22 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] include-pattern semantics
This is/has been an outstanding issue for some time. There are a few examples in the Test suite, but no one is sure if the tests are correct. Both Tails and X2V interpert the spec differently (so far no one has really complianed and made it an issue). I'm CC'ing the -dev list because in the archives there, there have been a few discussions on the points[1] [1] - http://microformats.org/discuss/mail/microformats-dev/2006-September/000143.html On 10/17/06, Ciaran McNulty [EMAIL PROTECTED] wrote: When the include-pattern[1] is used, the spec says that 'include' on the object element to indicate that that object refers to a subtree which should be included in its place' [2]. What I'm interested in is what happens to any additional classes that are applied to the inclusion element (i.e. the A or OBJECT). My instinct when marking up an entry in hAtom, for example, would be to use something like the following: a class=include author href=#vcard-elsewhere / The spec and examples don't make it clear whether the included element will 'inherit' the @class=author from the A, or whether it would be ignored. Does anyone with an existing implementation or parser have an opinion about whether this sort of markup is correct? If not, what would be the correct markup, or what would be the behaviour of existing parsers when presented with something like the above? Whatever the answer, I think it'd be a good idea to update / add to the examples to cover this case - I'd be happy to do so myself once I know what the correct answer is. Cheers, -Ciaran McNulty [1] http://microformats.org/wiki/include-pattern [2] http://microformats.org/wiki/include-pattern#class_name_.22include.22 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss -- brian suda http://suda.co.uk ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
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
Re: title attribute and abbreviated class names(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 and crafted this regex which I think identifies 100% of the special case to which I referred: ^([^0-9,\. ]*)([0-9]+[\.,]?[0-9]*)([^0-9,\. ]*)$ In that regex, if $2 has a value, that's the amount. If $1 OR $3 has a value, then it's the symbol. If it doesn't match, you *must* use the complex form. (btw, this would also be really easy to write a recursive descent and/or a looping parser in javascript or other languages to parse this and we could publish those reference implementations.) We publish the regex (or a better written one) and the recursive descent parsers and say if it matches, you can use the simple form, otherwise the complex So the following could use the simple form: The book is span class=money title=USD$5.99/span. In Brazil, the book would be span class=money title=BRLR $12.84/span. In Denmark, the price would be span class=money title=DKK35.66kr/span. BTW, it wouldn't be hard to include spaces in the regex and it might be a good idea to go ahead and do that. If so, you can use the javascript replace() string function (or similar in other languages) to first normalize the string to containing only real spaces and no nbsp; like so: s.replace(/nbsp;/, ) where s is the innertext for the span and then use this regex on the result: ^([^0-9,\. ]*)[ ]?([0-9]+[\.,]?[0-9]*)[ ]?([^0-9,\. ]*)$ Where again $1 OR $3 will be the symbol and $2 will be the amount. That would make these possible. The book is span class=money title=USD$nbsp;5.99/span. In Brazil, the book would be span class=money title=BRLR$ 12.84/span. In Denmark, the price would be span class=money title=DKK35.66 kr/span. Yes is it a little more difficult for the person
Re: [uf-discuss] currency quickpoll results and suggested next step
Mike Schinkel wrote: My opinion is this sounds like a great idea! Will you be doing the edit on the current proposal? yes, I intend to do before the end of this week. 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. I think that you can change your vote (assuming your re-vote from the same machine and cookies are one and haven't been erased). Let me know. Otherwise, I think the simplest is that I remove your vote from the final results. 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? I suggest the current spec focuses on the top 3. The future will be moved to a 2.0 page. Any concern that some aspects of the 1.0 spec are not be forward-compatible with 2.0 is relevant for 1.0. Guillaume ___ 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
Joe Andrieu wrote: 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. Sorry for this. You're welcome to change your vote, if you want to. See earlier post. Guillaume ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar spec- no specification included!
In message [EMAIL PROTECTED], Benjamin West [EMAIL PROTECTED] writes Thanks for the prompt response; apologies if my own aren't so prompt. None needed. Such is e-mail! There also seems to be a presumption that newbies will initially be interested in authoring, that is almost certainly fallacious, and at best unsupported by evidence. Ah, that's interesting. Mind if I quote you on this in my to-do list? Of course not. What are newbies interested in? I can only speak for myself, and imagine what others want, but I would have thought a mixture of general information and information on ho to read uFs on pages which already have them (and thus what tools, FF extensions, etc. to use). IIRC, Jacob Neilsen's recent works suggests a 90-9-1 percentage mix of readers publishers and developers. How are they finding our content? Mostly, I suspect, by following links on pages/ sites which use, or discuss, uFs for example, respectively: http://en.wikipedia.org/wiki/Microformats http://www.westmidlandbirdclub.com/site/index.htm#Microformats I like how http://simile.mit.edu/solvent/ and friends do this. The big questions are right out front to help guide you to the information you are interested in. I happen to think that they are What is this? What can I do here? How can I learn more? Are there examples? Is this what you envision as well? Pretty much. 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
Re: [uf-discuss] hCalendar spec- no specification included!
In message [EMAIL PROTECTED], Benjamin West [EMAIL PROTECTED] writes * Show me a demo. * Create an hCard Between those two should come the formal specification. -- 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
Re: [uf-discuss] hCalendar spec- no specification included!
In message [EMAIL PROTECTED], Mike Schinkel [EMAIL PROTECTED] writes others have said that they (think newbies would be) interested in authoring, not the specification and I concur. 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) At the very least they should be given the option of reading the spec before they begin authoring - as is NOT the case with hCalendar, at present. 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. Reasonable, but it needs some content, so as not to appear dry and unwelcoming. For example, is a list of potential sub pages: [...] * Brainstorming (might be combined w/Discussion) Once they standard is set, the brainstorming (and related examples) is only of archival interest. I note that your list does not include an explanation of Semantic XHTML... -- 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
Re: [uf-discuss] currency quickpoll results and suggested next step
In message [EMAIL PROTECTED], Guillaume Lebleu [EMAIL PROTECTED] writes I suggest the current spec focuses on the top 3. I see no need to be so restrictive. -- 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
[uf-discuss] there appears to be a calm in the species/currency/mars storm
In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes Can anyone tell me what is meant by there appears to be a calm in the species/currency/mars storm ? Surely someone must know? -- 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
Re: [uf-discuss] Use-check: rel=enclosure attribute
In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes I have marked up the link to a PDF on: http://www.westmidlandbirdclub.com/ladywalk/maps.htm with the attribute rel=enlcosure Is that use correct? I'm specifically asking about my usage - is it relevant, and does it serve any purpose? Anyone? -- 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
Re: [uf-discuss] Use-check: rel=enclosure attribute
Hello Andy, On 10/17/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes I have marked up the link to a PDF on: http://www.westmidlandbirdclub.com/ladywalk/maps.htm with the attribute rel=enlcosure Is that use correct? I'm specifically asking about my usage - is it relevant, and does it serve any purpose? Anyone? I remember someone putting PDF's in RSS enclosures and comparing it to faxing. http://blog.forret.com/2006/04/pdf-podcasts-proof-of-concept/ This is the closest thing I can think of to what you are doing. It's not really software support... but it's related. See ya -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ ___ Make Televisionhttp://maketelevision.com/ ___ Cars, Motorcycles, Trucks, and Racing... http://tirebiterz.com/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] there appears to be a calm in the species/currency/mars storm
Andy, it's hard to say for sure.. I assume you are referring to the irc logs from yesterday[1]? I remember being in the channel at the time, so let me add some context to the quote: -- # # [18:32:56] kingryan re the mailing list proposals... # [18:33:01] tantek maybe a diagram would help ;) # [18:33:05] kingryan why don't we try fixing uf-dev first and see if that helps? # [18:33:11] Phae No, it's not that complicated :P # [18:33:16] tantek uf-dev is the wrong place for *new* microformats # [18:33:18] tantek two problems # [18:33:20] kingryan I know # [18:33:24] kingryan I know # [18:33:28] tantek uf-dev should be focused on code # [18:33:28] kingryan but why don't we fix it? # [18:33:32] Phae uf-dev is just mostly unused isn't it? I glance at the archives sometimes and they seem short # [18:33:38] tantek see uf-dev thread on that kingryan # [18:33:48] kingryan it's unused because we don't let people join # [18:33:52] Phae heh # [18:33:53] kingryan I've read that tantek # [18:34:02] tantek then reply to it # [18:34:04] kingryan I'm just sayin', let's just change one variable at a time # [18:34:08] tantek if no-one objects within a day or so # [18:34:12] tantek then we can make that change first # [18:34:27] tantek we'll give the new list name discussion a bit more time # [18:34:43] tantek since there appears to be a calm in the species/currency/mars storm # [18:34:46] tantek ;) # [18:34:47] kingryan that's exactly what I'm proposing # [18:34:52] tantek excellent # [18:35:13] kingryan the Martian currency birdstorm of 2006 # [18:35:16] Phae heh # [18:36:13] kingryan we'll be telling our grandkids about this someday -- I think that's enough context. A discussion about what to do about the mailing list starts up. A suggestion is given to continue deliberating. Then there are some comments, one of which you inquired about. I'll try to explain, if I can. This is an exciting time for microformats. Many exciting implementations are being created and millions of microformats are being published on the web. In the midst of this is a lot of energy and activity on the mailing list. You might say, a storm of activity or a flurry of activity. This is just word play, and a common idiom in the USA. I think the implication is that since there appears to be a brief lull in activity, they can afford to take a bit more time on the problem at hand. After the comment in question, the word play and associated idioms continue: it is common for news shows to try and dramatize certain happenings, especially storms and such. You'll hear things like Storm of '98 or Blizzard of '05 or whatnot all the time on local news shows. It's so common that I believe even comedy shows have done many parodies, involving situations like Bee attack of '05. To me, this is all just word play; a brief moment of levity to help the work go more smoothly. Some day, these technologies may be so common that youngsters will have a hard time believing that it took hard work and many dedicated people to triumph with the accomplishments we are all working towards. Tantek, Ryan, and friends, employ a vocabulary rich with all kinds of word play and alusions. Here are some other brief examples: * Boiling the oceans * 80/20 * Tower of babel * fidelity of data I also frequently make up words; the technology we are discussing has simply never been done before, and I sometimes find (and enjoy) the need to make up new terms. Some of my examples include: * virtual card sort * ORM over the web And more generally many people have started using terms like web application and web api. I hope that clears things up, it can be hard to explain subtlety. If anyone has alternative interpretations, I'm open to correction. Ben [1] http://rbach.priv.at/Microformats-IRC/2006-10-16 On 10/17/06, Andy Mabbett [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes Can anyone tell me what is meant by there appears to be a calm in the species/currency/mars storm ? Surely someone must know? -- 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] Use-check: rel=enclosure attribute
On Oct 17, 2006, at 1:56 PM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes I'm specifically asking about my usage - is it relevant, and does it serve any purpose? Anyone? relevant? Yes, I think so. useful? Yes and no. I'm not sure of who supports rel-enclosure and I'm not aware of any tools that would make use of the enclosure in this case. If there were tools (like a browser that supported enclosures), however, this could be very useful. Either way, I say use it, but that's just my opinion. -ryan ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Use-check: rel=enclosure attribute
I concur with Ryan's opinion. You never know what application may be discovered for it in the future (which is the beautiful thing about powerful ideas). Regards, etc... David On 10/17/06, Ryan King [EMAIL PROTECTED] wrote: On Oct 17, 2006, at 1:56 PM, Andy Mabbett wrote: In message [EMAIL PROTECTED], Andy Mabbett [EMAIL PROTECTED] writes I'm specifically asking about my usage - is it relevant, and does it serve any purpose? Anyone? relevant? Yes, I think so. useful? Yes and no. I'm not sure of who supports rel-enclosure and I'm not aware of any tools that would make use of the enclosure in this case. If there were tools (like a browser that supported enclosures), however, this could be very useful. Either way, I say use it, but that's just my opinion. ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Lightweight Data Access Services and Well Designed Urls
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 Yes I did :) It is mostly what - Cool URIs don't change http://www.w3.org/Provider/Style/URI - CHIPs - Common HTTP Implementation Problems http://www.w3.org/TR/chips/ - Web Architecture http://www.w3.org/TR/webarch/ - Managing URIs http://www.w3.org/QA/Tips/uri-manage - Choose URIs wisely http://www.w3.org/QA/Tips/uri-choose As an aside, I think limiting choice can be good (if you have ever eaten at TGI Fridays, I'm sure you will relate to that comment!) Limiting choices in a service might be good, limiting choices in my ability of cooking is bad. Too much choice creates chaos and allows inexperienced people to make really sub- optimal choices for no other reason than happenstance. Best practices call out where the pitfalls are, and how best to avoid them. If all choice was good all the time there would never be any use for Best Practices for anything, right? Best practices are good. I think the things I'm thinking about as best practices are not of the same as the types you are talking about. I planning to codify those things that will make it easier for users to work with URLs; What do you mean by easier for users to work with URLs btw not sure the discussion belongs here but more on public- [EMAIL PROTECTED] * Once published, don't move the content to another URL web architecture * But if you move it, always leave a 301 or 302 redirect when you move a URL web architecture * Don't change the meaning of content at a published URL (with caveats, to be later discussed) web architecture * Ideally don't use extensions for (X)HTML content. cool uris CHIPs * If you must use an extension for (X)HTML content, use either .HTM or .HTML or .xhtml for XHTML it can help for mime-type management for example. * Extensions on URLs should define the content, not the technology that was used to create the content (i.e. .HTML not .ASPX, .JPG not .PHP, etc.) cool URIs * When you peel off a subdirectory from a URL it should return a valid and appropriate .HTML page Why? Here you make the confusion between a URL (resource) and a file (HTML document, image, etc.) * Avoid using magic numbers in URLs whenever possible (i.e. use www.mysite.com/cars/ not www.mysite.com/5/) Why? * A URL with a trailing slash should equal a URL w/o a trailing slash. (i.e. www.mysite.com/foo should be the same as www.mysite.com/foo/) Why? And opposite to what you said about extension and not extension http://example.org/toto http://example.org/toto.html http://example.org/toto.html.fr http://example.org/toto/ http://example.org/toto.svg * Organize major site divisions by subdomain (I need to put a lot more thought into this one about when and when not to) why? and I would say no. A website is an information space not buildings. It moves in terms of information structure. if you tie the organization of your information to the logical structure of a path, you make it difficult to manage on a long term. Date spaces are one way of organizing data. Here there's a misunderstanding between the navigation of information paradigm and the information space paradigm. * Sitemaps and Website URL structures should have a very tight coorelation. Could you explain a bit more? * For new websites and website redesign, design your URL structure as one of the first steps. contradictory with what is said just above. in
