Re: [uf-discuss] FYI: Jeff Jarvis on microformats and Google Base
Jon Tan wrote: Searching for products, property and jobs could be revolutionised by MFs and immensely valuable for all users, whether they know what the blogosphere is or not. If it was ever seriously suggested that until current ones are in widespread use others should be on hold or not be discussed it would be unfortunate. Here's what I'd like to see: less talk of the hypothetical revolution microformats might usher in, and more actual implementations. There are currently so few sites with microformats that it's entirely feasible to list them all in the wiki. There's no need for a search engine like Google to get involved. I think we should create a large enough base of information that it requires a search engines before we waste too much time trying to pressure search engines to parse the data. In the meantime in regard to the GBase question my point was that they have their app now. Precisely. In one day, Google Base collected more structured information than they could in a month of parsing all existing microformatted data on the web. Google wants data to attract searchers. Real data. No amount of hypothetical data will attract a search engine, regardless of how well that hypothetical data is publicized. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] uF Discovery?
Brian Suda wrote: the advantage of saying what you have available will minumized the crawl space. I can get one file that tells me everything, or crawl the entire 40,000 Avon hCard pages to try to get the same thing. This seems counter to the DRY and/or users-first mantra of microformats. If Avon made all microformats available in a single file distinct from their existing user-focused navigation structure, why would they bother keeping the user-focused data microformatted? If they do keep it, it's repetition, and if they don't keep it, it's separating user data and machine data. And at the point, why would they use microformats at all? Look at Google Sitemaps, that is a single file that describes the pages on the site, along with last-update time. This helps to limit un-needed crawls, bandwidth, time, etc. But Google says [1] Please note that the Sitemap Protocol supplements, but does not replace, the crawl-based mechanisms that search engines already use to discover URLs. So it's not actually limiting un-needed crawls; it's only pointing to things that wouldn't be found by crawling the user-centric website, which in my understanding should not include microformats. Peace, Scott [1] http://www.google.com/webmasters/sitemaps/docs/en/protocol.html ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] draft blog post on rel vs. rev
Just a typo: It get used should be It gets used in 4th from last paragraph. Other than that, my only comment is on the end: Remember, it is only the relationship between the documents, not the documents themselves which are described. I suspect many people reading that will wonder: how does one describe the documents themselves? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-tag for hierarchical categories
Andreas Haugstrup wrote: Some parsers will still treat that as a single tag, but others will treat it as a hierarchy, and even in those systems treating it as a single tag, I think software.httpsubscription suggests a hierarchy to many humans. It won't be cool for those people who use system that don't see the hierarchy. I'm not sure what you mean by won't be cool. It doesn't break any functionality as far as I can tell, and successfully adds functionality for systems that support it (e.g. Foxylicious). People are already using parent.child syntax for tags [1] [2], and it seems to be working just fine. Why not use two links: a href=http://members.optusnet.com.au/benjamincarlyle/benjamin/ blog/softwaresoftware/a/a href=http://members.optusnet.com.au/ benjamincarlyle/benjamin/blog/software/ httpsubscriptionhttpsubscription/a You could, but that doesn't give leave any indication that httpsubscription is meant as a subset of software. Not particularly important in this case, but politics.green is quite different from construction.green or color.green. Peace, Scott [1] http://technorati.com/tag/food.cooking [2] http://del.icio.us/tag/music.pop ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Use title attribute in non-abbr tags?
I looked around on the wiki, and read Tantek's original explanation of using title in abbr tags [1], but I didn't find a clear answer to this. Should title attribute values be preferred to internal text values in non-abbr tags when parsing microformats? E.g. if a parser comes across something like span title=Bob Smith class=fnRobert Smith/span, should it take Bob Smith, or Robert Smith as the value of the fn, or should that only be done if the tag is abbr? Peace, Scott [1] http://tantek.com/log/2005/01.html#d26t0100 ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformat Base
Tantek Çelik wrote: Consider adding hReview as well! I did that. I also cleared out all the data and changed it so it doesn't follow links from sites with no microformats, in an attempt to limit the scope a bit. Turns out I don't have the storage space to catalog every URL on the web. Anything not connected to microformats.org via pages containing microformats can still be added manually, and I made a simple submission form for that [1]. Craig Ogg wrote: On 12/1/05, Scott Reynen [EMAIL PROTECTED] wrote: I thought I'd go ahead and play around with a microformat-based alternative to Google Base. So far, I have a basic spider that I set loose from microformats.org to slowly wander the web. When it finds any known microformat-associated class names, it records the data which can then be searched here: This is very cool, but I don't think it is really an alternative to Google Base. I don't think it's a viable alternative myself. I wrote in my weblog: One suggestion, popular - of course - among the microformats community, was that Google could use microformats to remove the need for submission to their base and leverage the distributed nature of the web. Personally, I suspect there's just not enough microformatted content out there yet to make it worth Google's cycles parsing it. [2]. But I thought it better to try and prove myself wrong with some code than to just speculate about it. Peace, Scott [1] http://www.randomchaos.com/microformats/base/ [2] http://weblog.randomchaos.com/archive/2005/11/30/Microformat_Base/___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Bases
Charles Iliya Krempeaux wrote: On 12/5/05, Chris Messina [EMAIL PROTECTED] wrote: On 12/4/05, Scott Reynen [EMAIL PROTECTED] wrote: Personally, I suspect there's just not enough microformatted content out there yet to make it worth Google's cycles parsing it. [2]. But I thought it better to try and prove myself wrong with some code than to just speculate about it. Um, why are we waiting for Google? I mean, besides technorati, aren't microformats kind of the next frontier for smart search engines? The web as distributed database sounds pretty damn appealing to me. If you want to search all of it, and want to do it in a reasonable amount of time, indexing helps. Right, that's the first problem I ran into. If you want to crawl the whole web, you have to index the whole web. And there's not enough microformatted data out there to be worth indexing the whole web to get at it. Even restricting the crawler to one node away from a found microformat, only 293 out of 5163 (5%) URLs currently contain microformats. Crawling the entire web, that percentage quickly approaches zero. Google Base, on the other hand, gets valuable structured data out of 100% of submissions. Advantage Google. David Janes -- BlogMatrix wrote: we have developed a crawler that collects FOAF profiles from the Web and uploads them into Google Base. I've been thinking about doing the same with the Microformat Base data, but I don't really care to deal with the potential copyright issues: If you want to be removed from Google Base, please send us a mail and we will remove you. If anyone else wants to be responsible for that, I'd be glad to make an Atom feed of hCards, which you could convert to a Google Base upload format. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats and When 2.0
David Janes -- BlogMatrix wrote: Was anyone holding up the uF flag for hCalendar at When 2.0 [1]? http://tantek.com/log/2005/12.html#d06t1551 Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] entry permalink in hatom
Tantek Çelik wrote: Copying it though violates the DRY principle and unnecessarily introduces a risk of introducing errors/changes from the spec. Are we really applying the DRY principle to documentation? Nobody uses rel-bookmark because nobody knows about it because nobody reads W3C specs in their entirety. I think the benefits of explaining the elements of meaningful XHTML [1] clearly outweigh the risks of straying from the spec. If we don't understand a section of the spec well enough to explain it to others, how can we expect to build microformats on top of XHTML? We should not duplicate things from other specs, we should reference them. False dichotomy. We can both reference them and further explain them within the contexts of microformats. Thus perhaps we need a required reading section where we at least list: Specifications: - HTML 4.01: http://w3.org/tr/html401 - XHTML 1.0: http://w3.org/tr/xhtml1 Those two specs are hundreds of pages long. That's a hefty prerequisite to impose on someone who just wants to make their weblog markup a bit more semantic. Alternatively, one might say that the use of rel=bookmark for blog permalinks is worthy of documenting as an explicit example, since the HTML 4.01 spec makes no reference to blogs or permalinks. I would lean this way, but I don't think this conversation is worth having until a rel-bookmark wiki page actually exists. Right now we're discussing whether or not a hypothetical explanation of rel- bookmark is better than the W3C explanation. Peace, Scott [1] http://tantek.com/presentations/2005/03/elementsofxhtml/ ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-bookmark [was entry permalink in hatom
Kevin Marks wrote: (also, as http://www.microformats.org/wiki/rel-bookmark is #3 on Google for a search for 'rel bookmark', putting something there is better than nothing). This is the third reason for me thinking it might be best to not link to wiki pages that don't yet exist. The other two: 1) blank pages are confusing to readers less familiar with wikis 2) blank pages lead to miscommunication here as we discuss a page's hypothetical contents (e.g. this thread) Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview feedback
Mark Nottingham wrote: For example, a review's author might be inferred from the Web site it's hosted on. What about doing something similar to hAtom: 'if an Entry has 0 Entry Author elements, the logical Entry Author is assumed to be the author of the XHTML page' [1] [1] http://microformats.org/wiki/hatom#Entry_Author Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview feedback
Benjamin Carlyle wrote: Reviews are often carried out in blog entries, so if hAtom sees widespread adoption it may also be useful to say is assumed to be the author of the containing hAtom entry. You could try and generalise by saying the containing microformat, but that is probably going too far. Why? That sounds like a good solution to me. Seems to follow DRY. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview feedback
John Panzer wrote: That is, if my review the content of a blog entry, and my entry's title is my blog entry's title, do I need to repeat it? Or can readers use headline for whatever they'd normally use summary for? Since summary is optional, this isn't as critical as author, but it would be nice to know what the best thing to do is where you really do want to supply it, but want to avoid duplication. In hAtom, we could just use multiple class names, e.g.: div class=hentry hreview h4 class=summary titleReview of Something/h4 But when that gets converted into Atom (or read directly by an aggregator), it will no longer be recognizable as an hReview, because it's not part of the content. To have it included in the content, it would need to be like: div class=hentry h4 class=titleReview of Something/h4 div class=content h5 class=summaryReview of Something/h4 So how would we use hAtom to syndicate microformatted data without such redundancy? Or is that a 20% case? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Fwd: Press release microformat
admin Yellowikis wrote: Would hAtom allow an embargo on a press release? Do you have an example of anyone publishing an embargoed press release on the web? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformat for linking to XML source (to replace the Structured Blogging plugin's embedding method)
Phillip Pearson wrote: The plan is to move the XML off to a separate URL and link to it from the post. Anyone know of any prior art? http://weblog.burningbird.net/2005/12/19/aint-no-cobwebs-here/ I could also use the embedded metadata approach behind SB. However, my preferred approach would be to generate RDF/XML metadata for the movie review, and then just add this to the other metadata associated with the page. To make this data accessible, I only need to add a META link in my header, pointing to an URL the same as the post URL, except with an ‘/rdf/’ attached to the end. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hReview feedback
Craig Ogg wrote: Why do people disagree on what the lower bound of a rating system is? I think Ryan says Amazon's lower bound is 1 because you can't enter a lower rating (you have to click on a star to set the rating). I also believes that this is why he made it the default. I think others disagree because the user may have wanted to give it less than one star but was constrained by the input mechanism -- IOW, the real lower bound is zero but Amazon just doesn't allow that to be chosen any more than they let 3.5 be chosen. Personally, I disagreed because it said 0 in the real world example page. And I didn't put much effort into verifying those numbers because the first few I tried to verify didn't actually publish lower bounds at all, so I could only discover them by registering and creating a review to test how low I could make the rating. As far as I know, none of the real world examples actually publish lower bounds; they're only implied. Am I wrong about that, or are we really discussing how to format data that no one is publishing? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] citation microformat encodings
Ross Singer wrote: In regards to your local (public) library not running one of these link resolver thingamabobs, that's hardly an excuse not find value in the technology. It's only a matter of time before all libraries have a link resolver of some sort. The rise of electronic resources has basically rendered the link resolver as important as the catalog. There are logical reasons that you find it currently at the academic level, rather than the public library level - the bread and butter of link resolvers (and, indeed, citations and scholarly research) is in journal articles. This is a much larger part of a university library budget than a public library's. However, the state of Georgia will be rolling out link resolving for all citizens (colleges, public libraries, K-12) this year, so the trend is certainly moving down the library food chain. I'm not clear on how the existence of link resolvers is relevant to an XHTML microformat adopting OpenURL's metadata labels. Is everyone talking about the same thing here, roughly what Tim and Ed pointed to [1,2]? [1] http://www.inkdroid.org/journal/2006/01/18/openurl-as-microformat/ [2] http://onebiglibrary.net/project/coins/openurl-microformat-for- journals Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats + Thunderbird
Dr. Ernie Prabhakar wrote: Hmm. I'm not sure if I understand your solution. To avoid corruption, I'm pretty sure AddressBook doesn't want people writing directly to its private data store (regardless of format), so there needs to be some API. There already is: http://developer.apple.com/releasenotes/AppleApplications/ AddressBook.html Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RSS/Atom to XHTML in Flock's Feed View
On Feb 1, 2006, at 10:00 AM, Chris Messina wrote: Are there examples in the wild of RSS/Atom conversions into hAtom? Luke Arno is working on it in XSLT, having already gone the other way: http://lukearno.com/projects/hAtom/ Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] chat microformat next steps
Joshua Kinberg wrote: Could be a fringe sort of case as I'd guess more chat logs are output in plain text. But I do believe that Apple outputs chat logs this way from iChat. Can anyone confirm? No need to speculate. There is an iChat example already on the chat- examples page: http://microformats.org/wiki/chat-examples You see screenshots because they are prettier and easier to produce than finding the logs, which many people don't even have turned on. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] chat microformat next steps
On Feb 1, 2006, at 1:13 PM, Joshua Kinberg wrote: Maybe this is a dumb question because I'm working on a PC right now... How does one export the visual transcript from Apple iChat like the example I sent. That's not a simple screen grab as it includes a lengthy chat session. Does iChat include a way to export a Chat session as an image or PDF? Yes, but not in the format you pointed to. It looks to me like that person took several screen shots and pasted them together. That doesn't appear to be a common practice [1], so I doubt it is worth considering, especially as the information in that image is not accessible. [1] http://images.google.com/images?q=ichat Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hatom parsing question
On Feb 6, 2006, at 10:25 AM, Chris Casciano wrote: h3a href=http://127.0.0.1/index.php?id=7; rel=bookmark class=headlineTest Post/a #183; abbr class=published title=2006-02-05T17:03:32-0800a few seconds ago/abbr by span class=authorChris/span/h3 When i run that though the the Almost Universal Parser[2] it seems to pick up both the published date as well as the author values, but the title it is outputting for the post is the full text of the h3 element: Test Post · a few seconds ago by Chris Is this parser error, some clash between the spec and markup used by this template? Is there a remedy that doesn't involve completely changing the semantics of the original template? The spec says an Entry Title element is identified by the class name headline - an Entry Title element may alternately be identified by the h# element in an Entry, which makes it sound as if class=headline takes precedence over h#, which would make that a parsing error. Either way, it appears precedence should be clarified in the spec. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Job posting microformat
On Feb 6, 2006, at 5:18 PM, Ryan King wrote: On Feb 6, 2006, at 2:56 PM, Mike Siekkinen wrote: Hey All, Welcome Mike! I wanted to start work on a micro format for job postings. Following the wiki advice on how to get started I have plenty of real world examples to illustrate a need. I’m pretty sure there’s not any other work being done on this. (Someone please correct me if I’m wrong). Well, there's been discussion of this before on the list. See http://microformats.org/wiki/job-listing-examples for the beginnings of collecting real world examples. Feel free to start adding your examples to that page (which some basic analysis). See also: http://microformats.org/wiki/job-listing-brainstorming Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Signalling use of microformats?
On Feb 9, 2006, at 9:24 AM, David Osolkowski wrote: Didn't someone already write a microformat spider/robot/crawler? http://randomchaos.com/microformats/base/ But that's not looking for profiles at all, just class names. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Microformats for scientific papers
On Feb 19, 2006, at 3:59 PM, Alf Eaton wrote: On 19 Feb 2006, at 15:54, Ryan Cannon wrote: I like your use of space-separated class names (e.g. citation reference book), but you do have a little bit of redundancy: - abbr implies an abbreviation, so class=journal-title-abbr could just be journal-title That's true, but it's going to be easier for parsers to use the class name to differentiate rather than having to look at the node name as well, so the redundancy might be worthwhile. Microformat parsers must treat titles as the full content of a abbr node regardless of what you name the class, so you're not actually saving any parsing time here. - li id=ref16a name=ref16 is redundant and may be (not sure) illegal. THe (X)HTML validator doesn't seem to complain, so I think it's ok. The thing is, the li surrounds the citation, so needs an identifier, but there also needs to be an anchor link in the page. I think you can ignore the internal anchor links as far as semantics go: they're only really useful for page navigation, as they don't wrap anything useful. See: http://www.w3.org/TR/xhtml1/#h-4.10 Particularly Both of these attributes are designed to be used as fragment identifiers. which means you can't use the same one twice in the same page even if one is name and the other id. Also XHTML 1.0 documents MUST use the id attribute when defining fragment identifiers on the elements listed above one of which is a, so name is deprecated there, even if the validator doesn't know this. You'll find when you remove the name=ref16 that the id=ref16 functions just as well as an internal anchor. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Microformats for scientific papers
On Feb 19, 2006, at 7:01 PM, Alf Eaton wrote: Great! I hadn't realised it worked that way, so you can just use #ref1 to link to the li id=ref1. Do all browsers handle that properly? Not all, but enough that there's little reason not to follow the spec: http://www.python.org/dev/doc/idtest.html Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hAtom Proxy
On Feb 28, 2006, at 1:14 PM, Luke Arno wrote: I just wanted to point out the proxy: http://lukearno.com/projects/hatom2atom Now that I know where to test it, I thought it might be worth metioning that my crawler is now returning hAtom-formatted search results: http://www.randomchaos.com/microformats/base/ So you can now subscribe to an Atom feed of microformat content, for example, with a region of California: http://lukearno.com/projects/hatom2atom?url=http%3A%2F% 2Fwww.randomchaos.com%2Fmicroformats%2Fbase%2F%3Fkey%3Dregion%26value% 3DCA Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformat Question
On Mar 8, 2006, at 6:24 PM, Tantek Çelik wrote: Also, I think some folks have at least discussed an FAQ microformat, you may want to look for that as well. I don't see this in the wiki nor the email archives. But apparently multiple people remember it, so perhaps someone could fill in the wiki with the relevant info? Peace, Scott___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plants Microformat
On Mar 23, 2006, at 7:20 AM, mark gibbons wrote: Hi, I am developing a microformat proposal for plants. Please take a look and join in if you wish. http://microformats.org/wiki/plant-examples I don't understand what problem this microformat would solve. The stated problem seems to be basically there's no microformat, which doesn't really explain why there should be. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plants Microformat
On Mar 23, 2006, at 8:12 AM, mark gibbons wrote: I would be the first to admit it is a niche, but here would be a few scenarios where I can see this as useful. - Collection of distributed plant information from the web into larger plant databases. - Plant catalogs can be published by retailers and the information about what can be bought where, can be easily aggregated. - Building up personal catalogs of plants, so I can have a customized view on my own plants that I grow, telling me more about them. Sounds good. This might have some overlap with the discussed product microformat, but it doesn't have the major problem of identification with the latin terms acting as unique IDs. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plants Microformat
On Mar 23, 2006, at 3:43 PM, Paul Bryson wrote: but it doesn't have the major problem of identification with the latin terms acting as unique IDs. Is there any page that discusses the potential issues of using IDs in microformats? Oh, I didn't mean ID attributes - just something to uniquely identify plants. All plants have a unique latin name, so if two people discuss the same plant, it's easy to identify that they're both the same. It's much more complicated with products, because different systems use different identifiers (bar codes, serial numbers, ISBN, VIN, etc.), which can overlap. It's clear what span class=latin- nameErysimum Cheiri/span means because there is only one Erysimum Cheiri in the plant world. It's less clear what span class=idQ7639R087/span means, because the meaning is very dependent on context. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plants Microformat
On Mar 23, 2006, at 8:31 PM, Breton Blake Slivka wrote: Brian, if you look at the wiki, it would seem that he already has done much of what you list. I'm with you so far as defining the simpler microformat first for the Latin classification system. My thought is that it's a very specific microformat, which sort of bucks the trend of very broadly applicable microformats thus far defined and set as official specifications on microformats.org. First two microformat principles: * solve a specific problem * start as simple as possible http://microformats.org/about/ This looks to me like a good candidate for a microformat, generally in line with both the principles and the process. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plants Microformat
On Mar 24, 2006, at 12:08 PM, Andy Mabbett wrote: What do you mean by plants? Garden plants? Plants as studied by botanists? Plant-material, such as cut flowers, or planks of timber? Is there really any ambiguity here? The former two are the same thing, no? Does a plant become something different depending on whether it is in a garden or being studied by a botanist? It still has the same latin name, water needs, sunlight needs, etc. And I think it's obvious from the wiki page that planks of timber are outside the scope here. Do we need to clarify that we're not talking about plastic plants or photos of plants also? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Enumerating Microformats on a Page
On Mar 24, 2006, at 12:17 PM, Phil Haack wrote: I can envision something similar with Microformats. Suppose I point my brand spanking new Microformats enabled RSS Bandit towards http://glazkov.com/ and it pops up a list of various Microformats on that page. Wonderful! The bummer is that I may miss out on your Down Home Alabama/Russian Fusion Cuisine Recipes which just happen to be on another page. Why deny the world a grits and salted herring dish? Because feed auto-discovery links are in the content, not the headers of HTTP responses, aggregators have to download the entire page, and most aggregators search first for link type=alternate ... tags, and second for something like a href=something.rssRSS/a. The link tag makes more sense here because people don't read feeds directly, so it doesn't make a lot of sense to provide human-readable a links to feeds. But people *do* read microformat content directly, so if it's related to the current page, it should be linked from the current page, and any human or machine looking site-wide for microformat content (or anything else) should follow links throughout the site. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Enumerating Microformats on a Page
On Mar 24, 2006, at 4:20 PM, Ryan King wrote: Hmm, this sounds to me like a theoretical argument. I'd like to hear what experience people have had here. Has anyone here worked on crawling to index microformats? If so, what challenges did you face? Yes. The two I know of are reevoo, which aggregates hreviews: http://www.reevoo.com/ and my own effort, which aggregates hcards, hcalendars, and hreviews: http://randomchaos.com/microformats/base/ My main challenges have been a lack of space to store the data (which has nothing to do with microformats) and the the lack of a parser that can read invalid X(HT)ML (which is only an issue because I haven't installed Tidy on my server). If microformat site maps existed, I would use them as starting points to know where to look, but I wouldn't trust them as any sort of accurate listing of what's on a domain just because I know I would likely forget to update my own if I had one. So I'd still be reading the same number of documents, just in a different order. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plants Microformat
On Mar 24, 2006, at 4:04 PM, Ryan King wrote: I've so far stayed out of the discussion about a plant microformat, mostly because I don't really care about talking about plants on the Web. Let's take a step back and think about whether a microformat for plants is worthwhile– We should probably step back a bit further and welcome Mark to the list before we go on telling him how much we don't care about what he's working on, and what he's doing wrong. Welcome to the list Mark! I don't personally care about plants, but I think you need more examples. I worry our efforts to point out problems on this list too often counter-act our efforts to promote interest in microformats elsewhere. My first response to Mark's idea what to point out a problem. I now regret that. Peace, Scott___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Enumerating Microformats on a Page
On Mar 26, 2006, at 7:48 PM, Antonio Touriño wrote: I'd want to take advantage of it to decide where to start, but not where to end. A search engine should seek to maximize the search area to improve results. I want to look at everything on your site, unless instructed otherwise. If there are cases in which you might not want to believe the sitemap. what are they? How are you going to distinguish them? If you are going to selectively chose when to rely on a sitemap then I don't see the point to it. I would always believe a site map as *a* source of links, but I would never believe a site map as *the* source of links. If there were microformat site maps, I would have my crawler look for them, and start spidering a site from the addresses listed in a site map, because that would likely lead to microformat content more quickly than just traversing every link (which is what it does now). When it was done with those addresses in the site map, I would have it go on to traverse all links. So if the site map was inaccurate, I still wouldn't be missing anything (so I'd say no harm done), and if it was accurate, the spidering would be slightly more efficient. I doubt that efficiency is worth the time and effort of developing site maps, but as it's not my time and effort, I have no reason to discourage anyone who thinks otherwise. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Citation format straw proposal on the wiki
On Mar 29, 2006, at 9:36 AM, Alf Eaton wrote: span class=editors span class=editorJohn Green/span and span class=editorSimon Brown/span (Eds); /span I guess there are some things in there that could become vcards, if you wanted. I think marking up all people and companies with hcard makes sense, but there's an issue with redundant role information. Unless the include pattern[1] is used here, the citation would read like John Green, editor; Simon Brown, editor, because each editor would need a separate editor role. But leaving editors around each editor means that any existing hcard parser would lose role information. [1] http://microformats.org/wiki/include-pattern Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] HTML Analytical Lexicon
After reading the recent discussion of a meta-microformat, I decided to play around with the idea. I've probably gone through 9000 revisions, but I think I have a usable tool now, which I'm calling HTML Analytical Lexicon. What it does is parse natural language queries and derive a semantic representation (internally stored as RDF) using Princeton's WordNet: http://wordnet.princeton.edu/ Then it searches an internal cache of microformatted HTML content (converted via XSLTs to RDF) collected from around the web, assigned meaning via XMDP if available, otherwise WordNet. It finally translates the RDF result back into natural language results. So far it seems to be working well. You can submit a query like Where is Tantek Çelik right now? and it will find Tantek's vcard info, match that against all the hcalendar data on the web, look for a vevent matching the current time, pull out the location, and return an answer like Tantek is at home. Because it uses WordNet to determine meaning of both content and class names, it doesn't require formal definitions of microformats, so it will work just as well for future microformats that haven't been created yet or even unstructured formats individuals use in their own markup. I'm still making changes and testing so things may break, but if you'd like to try it out, here are some example queries: http://randomchaos.com/microformats/hal/?q=Where+it+Tantek+Çelik+right +now? http://randomchaos.com/microformats/hal/?q=What+is+the+date+today? http://randomchaos.com/microformats/hal/?q=Open+the+pod+bay+doors Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Some hcard feedback from a vCard implementor
On Apr 4, 2006, at 12:25 PM, Sam Roberts wrote: Hi, I'm the author of Vpim (http://vpim.rubyforge.org), an implementation (in progress) of vCard and iCalendar encoding/decoding for ruby. Neat. but you can't go the other way, there is no way for the receiver to know the cultural conventions of the creator of the card: FN:given family or FN:family given and certainly can't know the creators personal preferences: FN:JD Bock N:Bock;John;Donald,Sebastian;; NICKNAME:JDS ORG:Big Company;Product Development;Microformats and Web Apps FN is what he wants on his card, how he customarily presents his name. There's no example for this on the wiki, but I believe it's possible to do this like so: div class=vcard span class=n span class=given-nameJohn/span span class=additional-nameDonald/span span class=additional-nameSebastian/span span class=family-nameBock/span /span, a.k.a. span class=fnJD Bock/span /div I trust I will be corrected if this is wrong. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Some hcard feedback from a vCard implementor
On Apr 4, 2006, at 3:19 PM, Ryan King wrote: There's no example for this on the wiki, Actually, there is: http://microformats.org/wiki/hcard-examples I still don't see anything in the wiki where FN and N exist as non- overlapping siblings in the hierarchy. Everything I see has either N containing FN, or the two being identical. I think it would be good to have one with N and FN completely distinct to make it clear that this is possible in hcard. On Apr 4, 2006, at 3:35 PM, Sam Roberts wrote: You have a description on the wiki of deriving N from FN, which assumes things about the format of FN that are culturally specific (first names before last, for example), But this assumption is only made in the limited context where the author doesn't provide an explicit N. So it makes it easier for (arguably) most authors, while not at all inhibiting the minority who prefer family, given order. when the very absence of N is a violation of the vCard spec. N exists in every valid hcard. It's value can be implied or explicitly stated, but N *always* has a value. It sure looked to me like the spec is describing how to do that which shouldn't be done. I still don't see why it shouldn't be done. Now remove the example from the spec. How would a reader be able to know from the specification that span elements are to be used in the XML? That's not in the spec because those span elements are entirely optional. Any valid XHTML tag will work there. The goal of simplicity is met by the spec if it can be used to implement. If your data is already in vcard format, implementation should be incredibly easy. Take every FN and wrap it in X class=fn tags. Take every ORG and wrap it in X class=org tags. And so on. the rules aren't in the spec Here's the main rule: The basic format of hCard is to use vCard object/property names in lower-case for class names, and to map the nesting of vCard objects directly into nested XHTML elements. http://microformats.org/wiki/hcard#In_General Specific example, the NOTE field. Its value type is TEXT. TEXT can have newlines, they are encoded as the two characters '\', and 'n'. The hcard spec doesn't say how to handle TEXT, doesn't even mention its existence, AFAICT, and I can't find an example where \n was used on /hcard-examples, so I'm not sure how newlines would get represented in hcard. That should probably be added to hcard. XHTML ignores newlines. I believe the most common conversion from text to XHTML is to replace newlines with br / tags. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Some hcard feedback from a vCard implementor
On Apr 4, 2006, at 7:14 PM, Ryan King wrote: I wouldn't even now how to begin encoding a vCard as an hCard, and it doesn't sound like there is any reason to. Would an hcard even exist, standalone? Huh? Would it exist on its own? There are plenty of hCards that exist on their own, sans-vCards. See http://microformats.org/wiki/ hcard#Examples_in_the_wild. I think maybe Sam meant as a separate document, outside of a larger XHTML document. This isn't common use of hcard, but it's possible. I do it in AJAX applications. Here's the main rule: The basic format of hCard is to use vCard object/property names in lower-case for class names, and to map the nesting of vCard objects directly into nested XHTML elements. All the structured types (ADR, GEO, ORG,..) have names assigned to what are ';' seperated fields. The above rule would give: JOE class=ORGCompany;Unit;Sub-Unit/JOE No, you would use the names for the sub-properties, and lower-case the class names. Right, those are listed here: http://microformats.org/wiki/hcard#Property_List And they are applied according to the general rule (as lower-case class names). Maybe we should have a Where's the rest of the spec? FAQ? I expect others coming from a background in XML formats rather than XHTML could easily experience the same confusion Sam had. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Live Clipboard and uF escaping (was Fwd: 0.91 Spec comment: escaped markup is harmful)
On Apr 6, 2006, at 5:25 AM, Danny Ayers wrote: I'm not sure I understand why Matt suggests XML data might have to be delivered as both XML and escaped as well, but he gets into browser/DOM territory, a place presumably well-known around this list - thoughts appreciated. I don't understand everything Matt says, but what I do know might help: browsers use different DOMs, with different functionality, for XML or HTML. The HTML DOM is generally easier to use, sometimes even for XML data. For example, if you treat XHTML as XML, you can't use most getElementsByClassName() functions on it, which makes parsing microformats much more difficult. But if you just dump the raw text of the same XML in the .innerHTML of some HTML node (even one that isn't in the document tree), you can use the full range of HTML DOM functions on it. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: Live Clipboard and uF escaping
On Apr 6, 2006, at 2:55 PM, Ryan Cannon wrote: Treating XHTML as HTML is losing all of the benefits of using XHTML, and theoretically opens you up to parsing errors. If you're going to use the HTML DOM, why not use HTML, instead of causing potential breakage and confusion in the future when browsers may (or may not) become more strict in their handling of these two different languages? I haven't had those problems. I have had the problems of not being able to find an implementation of getElementsByClassName() that worked on an XML node, and not being able to use the XML DOM on content retrieved as text/html (e.g. almost everything on the web) via XMLHttpRequest. That's why I personally use the HTML DOM for parsing microformats in JavaScript. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] What does draft mean? (was: Citation IRC Meet-up Time)
On Apr 10, 2006, at 10:09 AM, Tantek Çelik wrote: Alf, it is premature to be making recommendations when the necessary steps in the process have not yet been completed. More on the wiki page itself. I read the wiki page itself, and I don't see anything more descriptive than process not completed. Looking at the process, I'm not clear on which steps are considered incomplete. I also see a lot of drafts without much evidence of the process being followed at all. I'm confused about what the word draft means in relation to the microformats wiki. If this isn't a draft, what specifically is missing, and why was, for example, the include pattern labeled a draft prior to any real world examples or public discussion? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] What does draft mean? (was: Citation IRC Meet-up Time)
On Apr 10, 2006, at 11:20 AM, Tantek Çelik wrote: One poor job does not deserve another - this line of argument NEVER justifies poor behavior. I intentionally avoided making any line of argument, as I thought simply asking for clarification would be more productive. Apparently I was wrong about that, as the inferred line of argument (don't use the process) is pretty much the opposite of the one I avoided making (encourage use of the process through clarification). So here's my line of argument: Exceptions to the process should be clearly identified and explained to avoid confusion between the exception and the rule. It's nice to keep pointing people to the process page, but that's analogous to pointing people to the HTML spec. People imitate examples more than we follow rules. When someone looks at the hcard pages and sees no collection of real-world publishing of contact data nor discussion of the properties implied by such examples, I think it's far too easy to infer that microformats come from other formats more than actual behavior. There's nothing on the process nor the hcard pages explaining this discrepancy. I would argue that there should be an explanation, probably in both places. If design patterns don't follow the process, I would argue that this distinction should be clearly documented and explained. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Chat microformat/podcast transcript
On Apr 12, 2006, at 8:45 PM, Jude Robinson wrote: I agree entirely. Think it very odd and reckon cite and q/ blockquote more appropriate. Don't understand the dl suggestion at all. This is what I'm doing in an AJAX chat system I've been working on. But looking at the examples [1], there doesn't appear to be any consistency in tag usage, so I'm not sure it matters what we think is appropriate. If some people are putting their chat transcripts in TABLEs, some in OLs, DLs, SPANs, etc., the microformat will need to work in all of these tags to be adopted. [1] http://microformats.org/wiki/chat-examples Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Google at it again
On Apr 13, 2006, at 8:37 AM, Mark Pilgrim wrote: Anyway, I'd bet microformats were not a top priority for their initial release of Gcal, but that doesn't mean they can't add it later. Can't we add it ourselves? I'm assuming the events are being submitted via an AJAX call and authenticated via sessions (though I haven't yet been able to verify this in the 2000 lines of obfuscated JavaScript). If that's the case, it should be possible for a bookmarklet/Greasemonkey script/Google toolbar patch to parse vevents on a page and insert working 'Add to Google calendar' buttons near each found. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] Google hCalendar Greasemonkey script
On Apr 13, 2006, at 9:45 AM, Mark Pilgrim wrote: I will donate a free copy of Greasemonkey Hacks to the first person to write a Greasemonkey script that * adds a remind me with Google Calendar button ( http://www.google.com/googlecalendar/event_publisher_guide.html ) next to any event described in hCal, mapping the appropriate VEVENT parameters to GCal parameters; * works entirely on the client (i.e. doesn't require a call to a hosted X2V service); * is released under the GNU GPL or a GPL-compatible open source license. http://randomchaos.com/software/firefox/greasemonkey/googlehcalendar/ googlehcalendar.user.js It looks to me like almost everyone is doing timezones wrong, but I suspect it's actually just me. I'm hoping someone with more experience with timezones can explain where I'm going wrong here. I live in CST, which is UTC-6. When I look at this page for an event in my timezone: http://upcoming.org/event/69170/ Upcoming says the timezone is -07:00, which I believe is wrong. Then I have my Google calendar set to CST timezone, which again is UTC-6. When I send a time like 20060425T01Z I would think Google should adjust that 6 hours to 2006-04-24 7pm. But it only seems to adjust it 5 hours to 8pm. So between jumping ahead 7 hours on my parsing and then jumping back only 5 hours on Google's parsing, I end up 2 hours in the future. So am I wrong and/or are Google and Upcoming both wrong? And then some sites don't supply timezones at al, e.g.l: http://eventful.com/events/E0-001-000874028-2 http://suw.org.uk/archives/category/events/ I'm not clear on what to do with those. Aren't timezones required in ISO8601? I'm just treating them as if they end in Z right now, but that's clearly not the right time. Other than these time zone issues, it seems to be working fine in my Firefox 1.5.0.2 and Greasemonkey 0.6.4, though I'm sure there are a few dozen edge cases I haven't considered. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Google hCalendar Greasemonkey script
On Apr 15, 2006, at 2:31 PM, Alf Eaton wrote: Upcoming is wrong - timezones have been on their to-do list for ages. Looks like they've got things working now anyway... http://upcoming.org/news/archives/2006/04/14/fun_with/ I wouldn't call it working. They've made their own export to Google functionality, which ignores timezones completely, and their hcalendar timezones are still all wrong. Ignoring timezones means the export to Google only has the correct time for events within the same timezone as the Google calendar, so it's not working for anything that spans timezones. For example, if I add an Upcoming event in New York to my Google calendar, it will go in at the wrong time because 8pm in New York is not 8pm in Iowa. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: class names Was: [uf-discuss] hcard validation
On Apr 18, 2006, at 8:16 AM, Mark Wallace wrote:
I'm sorry for asking a really silly question, but doesn't it make
sense that any class should have a a space as either a dash or
underscore?
If memory serves, the url fn would break the standard css
formating...
Though most authors only ever use single class names, the class
attribute contains *multiple* space-separated class names. So url
fn is two class names, not one. You can do CSS formatting on
intersections of multiple class names like so:
.url.fn { color: #f00; }
Peace,
Scott
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hcard name/fn question
On Apr 19, 2006, at 12:49 AM, Rebecca Cox wrote: If a number of sub-properties are specified within n, do these all have to be included in fn? For example, if I had something like: - n: family-name: Cox given-name: Rebecca additional-name: Laura honorific-prefix: Ms Would I be able to specify fn as follows: Fn: Rebecca Cox -- You can do that, but unless the FN is an ordered subsection of the N, you'll need to repeat: p class=vcardMy name is span class=n span class=honorific-prefixMs/span span class=given-nameRebecca/span span class=additional-nameLaura/span span class=family-nameCox/span /span but you can just call me span class=fnRebecca Cox/span./p Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: life, death and address books (was Re: [uf-discuss] hCard and Life Dates?)
On Apr 19, 2006, at 10:52 AM, Tantek Çelik wrote: Rather than attempting to shoehorn this into hCard, perhaps citations are the right place to think about this? I think there is a large difference between what to do with contact data for an acquaintance who has recently passed away and how to mark up historical information on a stranger, and my first thought was that the two are probably distinct enough to belong in two separate formats. But my second thought was that this is all similar to genealogical data, and perhaps both the personal and the impersonal purposes could be served with such a format, as some people do genealogy for personal reasons, and others do it for historical reasons. I see the start of such a format here: http://microformats.org/wiki/genealogy-formats Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plazes Microformats
On Apr 19, 2006, at 2:23 PM, Ryan King wrote: That's right. The reason you can't collapse a 'vcard' class name and its 'fn' class name is that it makes putting a 'vcard' class name inside another one becomes ambiguous. I've seen this explanation a few times, and I've never personally found the separation of vcard and fn to be a problem, but I don't understand the explanation. Couldn't the spec prevent such ambiguity simply by stating that vcard and fn in the same node should be treated by parsers as an fn node within the vcard node. More generally, why doesn't nearest-in-parent [1] start with the current node rather than the parent node? [1] http://microformats.org/wiki/algorithm-nearest-in-parent Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Plazes Microformats
On Apr 19, 2006, at 4:32 PM, Ryan King wrote: div class=vcard span class=fnTantek Çelik/span span class=agent vcard !-- the order is actually irrelevant here class=vcard agent is synonymous -- span class=fnRyan King/span /span /div Which hcard does the 'agent' belong to? If we were determining belonging with a nearest-parent algorithm that started with self, We're *not* using nearest-parent here. We're parsing top down. Isn't that just the same thing with a different name? Whichever direction you're parsing, you know which vcard a property belongs to by looking at the closest vcard in the hierarchy. What I'm asking is: why isn't the self considered the closest? On Apr 19, 2006, at 4:17 PM, Tantek Çelik wrote: Things are working as-is, the risk of change is high, and the reward is low. Unless you have a serious objection, I'd like to consider this proposal rejected and move on. People continue to ask the same question over and over and the answer doesn't make any sense to me (nor, apparently, David). I'm not asking for a change in the spec. I'm asking for an explanation of the spec, so that I will know what to say when I'm suggesting someone use microformats and they ask me the same question. I can't honestly say it's ambiguous because it doesn't look ambiguous to me. I know very clearly which vcard that agent belongs to, and I know how to tell a machine which it belongs to. What I don't know is why I shouldn't be doing that. Peace, Scott___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: uid microformats? (was Re: [uf-discuss] ISBN mark-up)
On Apr 25, 2006, at 9:21 AM, Tantek Çelik wrote: The closest thing to UIDs that current publishers of hCards are publishing are their unique URLs within their sites (e.g. Upcoming and Eventful venues and events). I have a concern that using URLs as UIDs will prevent them from being globally identifiable, where using otherwise meaningless UIDs would not. When Eventful is adding an event already found on Upcoming, I would expect Eventful to be more likely to assign a UID of 123872138623 than http://upcoming.org/event/123872138623/ Both Upcoming and Eventful have event IDs that are part of event URLs, but don't associate the events with a particular domain. The domain association ensures the IDs are unique, but it seems to do so at the expense of identifying multiple copies of the same event, which I thought was the primary purpose of the UID. I expect URLs as UIDs would allow us to identify the same event from the same site, but not across multiple sites because each site will use its own URL as the UID. And in the case of book citations, aren't ISBNs the closest thing to UIDs currently published? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: uid microformats? (was Re: [uf-discuss] ISBN mark-up)
On Apr 25, 2006, Tantek Çelik wrote: We *want* resources that can be identified by network location and thus a system that shows a bias *for* that is a *good* thing. Is the proposal that UIDs SHOULD be URLs or UIDs MUST be URLs? If it's MUST, that would seem to discourage use of microformats to markup content that doesn't exist at a canonical URL. many well-established identifiers are not based on URL. e.g. In a typical library application, we really want to identify the books in Amazon and local catalog are referencing same thing, Ah, you just introduced a new requirement, and perhaps that is where the disconnect is. I assumed the same use case. This is all I've ever seen UIDs used for. What is the other use case? The requirement that we are looking at is: globally unique, that is, two *different* events/contacts don't end up using the same UID. That's it. Couldn't we more simply give each event an ID attribute and accomplish that? I have a concern that using URLs as UIDs will prevent them from being globally identifiable, This is a joke, right? Requesting feedback and then responding like this just seems mean- spirited to me. URLs are by design global. The opposite of your concern is actually true: URLs will tend to make UID *more* globally identifiable. URLs are inherently globally unique, but URLs are only globally identifiable if people use them like that, and I doubt people will. When Eventful is adding an event already found on Upcoming, I would expect Eventful to be more likely to assign a UID of 123872138623 than http://upcoming.org/event/123872138623/ In speaking with both the Upcoming developers and the Eventful developers this is not the case. It is *much* easier and more natural to publish and convey a notion of a permalink for an event or venue, and then mark that up as its UID, than to expose random gibberish UIDs to the user (whether numbers or some other opaque sequence). Right, but one involves pointing to a competitor and the other doesn't, and I think that difference has a real-world effect on people's behavior. Both Upcoming and Eventful have event IDs that are part of event URLs, but don't associate the events with a particular domain. The domain association ensures the IDs are unique, but it seems to do so at the expense of identifying multiple copies of the same event, Not a requirement. Identifying multiple copies of the same event can easily be done by implementations. E.g. event aggregators can keep track of *all* the URLs that an event has when it is found across different sources. RFC 2445 says UID MUST NOT occur more than once. Are we changing this in hcalendar? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar - every week event
On Apr 25, 2006, at 8:59 PM, Michael MD wrote: re: http://www.dgabcsolutions.com.br/preview/camarascs/cm_home.asp Is it actually allowed to have a hcalendar event without a date? If so that could be a problem .. I think in the parser I want to put together that will have to be a requirement. The RFC says of DTSTART: 'The property is REQUIRED in VEVENT calendar components.' Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: uid microformats? (was Re: [uf-discuss] ISBN mark-up)
On Apr 26, 2006, at 12:13 AM, Joe Andrieu wrote: if microformats are going to take off, shouldn't there be a way to disambiguate inevitable conflicts? There is. See profiles: http://microformats.org/wiki/profile-uris Alternatively, who is to say which version of hCoupon is valid? Mark Pilgrim. Rather, Mark is working on a validator, based on the specs at microformats.org. Who is the registrar? http://gmpg.org/ Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: uid microformats? (was Re: [uf-discuss] ISBN mark-up)
On Apr 26, 2006, at 10:44 AM, Tantek Çelik wrote: Ross, if the problem you're trying to solve doesn't involve common real world publishing cases on the *Web*, then yes, it should be dismissed as far as microformats are concerned. A large portion of what is published on the web references things that don't exist on the web, and thus don't have a canonical URL. As markup geeks, we all have our own URLs to represent ourselves. Normal people don't. That doesn't mean normal people don't publish on the web. This is the wrong place to solve problems that don't fit those constraints. Publishing on the web is a good constraint for microformats. Having a canonical URL on the web suitable for a UID is a bad constraint for a microformat. I think there has been ample room left for misunderstanding over which is being advocated as a constraint. Clearing up this ambiguity would be more productive than repeating the same truisms over and over again. If we didn't understand what you meant the first time you said something, putting asterisks around it won't help. Voices on a mailing list don't determine the 80 vs. 20. That's the point of the process. Documented real world publishing examples on the web determine the 80 vs. the 20. Right. I think saying 80% of people do X without pointing to the real world publishing examples that back up such a statement makes it look like voices on this mailing list are determining the 80 vs. 20. Until you can prove that URNs are nothing more than edge case on the Web, then this is not worth discussing any further. Until you can prove that such ultimatums are conducive to developing a common understanding of what these things mean, I think everyone should stop talking like lawyers here and start talking like people interested in developing a common understanding of what these things mean. Isn't that the whole point of microformats? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: uid microformats? (was Re: [uf-discuss] ISBN mark-up)
On Apr 26, 2006, at 11:44 AM, Tantek Çelik wrote: A large portion of what is published on the web references things that don't exist on the web, and thus don't have a canonical URL. Right, and to resolve whether it is a large portion or not, we ask that such things are documented in examples pages, and the citation- examples are a good example (so to speak) of this. Ok, here are a hundred thousand references to a cup of coffee: http://technorati.com/search/%22a%20cup%20of%20coffee%22 None of these cups have canonical URLs that allow me to uniquely reference the cup of coffee on the web. Having a canonical URL on the web suitable for a UID is a bad constraint for a microformat. This I am not sure about. It certainly seems like a *good thing* to provide incentive for more UIDs to become canonical URLs on the web. But I would agree that this shouldn't be a constraint/requirement per se, but rather should be a bias (i.e. SHOULD) so that we provide incentive or at least preference in the direction of more canonical URLs. And everyone else seems to be arguing that this shouldn't be a MUST. MUST is a constraint. SHOULD is a *good thing*. Where is the disagreement here? Let's not waste our time explaining why we disagree before making sure we really do. Right. I think saying 80% of people do X without pointing to the real world publishing examples that back up such a statement makes it look like voices on this mailing list are determining the 80 vs. 20. Right. Hopefully we only do so in obvious cases (e.g. things on the Web have URLs :) That's what I thought, but I apparently illustrated my own point with my large portion comment. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: uid microformats? (was Re: [uf-discuss] ISBN mark-up)
On Apr 26, 2006, at 11:54 AM, Bruce D'Arcus wrote: I'm glad there's some progress in this discussion, but you're still trying to come up with a general rule for disparate things. Nope, we're trying to come up with a general recommendation, not a rule. So there's no need to explain why URL shouldn't be a rule, because it's not being proposed as a rule. So I'd say that URLs should only be preferred where one is referring to a particular item whose canonical location is in fact on the web. Which I believe is exactly what Tantek is saying. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats vs XML
On Apr 27, 2006, at 8:06 AM, Dimitri Glazkov wrote: Scott, I wouldn't be so sure. http://msdn.microsoft.com/workshop/author/behaviors/library/ calendar/calendar.asp Take a look at the example at the bottom. In my pre-semantic markup days, I've used CSS to style xml (namespaces and all) tags quite a bit. My mistake. Apparently it's just namedspaced attributes that IE doesn't support. At least that's what I see when I try this test in IE6: http://lyceum.open.ac.uk/temp/cssns.html Or is there a workaround for this too? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats for everyone!
On Apr 27, 2006, at 8:36 AM, Christopher St John wrote: Do you see this as being related to the uf zen garden effort? (which seems to have stalled a bit) Here's a working implementation that applies CSS and/or JS to sample microformat template pages: http://randomchaos.com/microformats/zen/ I made this a long time ago, and was at the time expecting that someone else more experienced with the formats would want to be in charge of administering this, reviewing submissions, setting up templates, etc. but that never happened. If no one is interested in maintaining a zen garden, I'll do it, but right now it looks to me like something people like to discuss in the abstract, but wouldn't actually use in practice. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: question about client-side xslt rendering (was Re: [uf-discuss] Microformats vs XML, redundancy)
On Apr 27, 2006, at 12:03 PM, Xiaoming Liu wrote: This file can be rendered in IE and Firefox, because they do xslt client-side rendering, so the display is correct, but when I check page source, it's still the raw xml file. And when writing a script to fetch Microformats fragments, I have to do XSLT rendering first to get HTML back. So I am wondering if the above scenario is a good practice You might want to look at this site: http://w3future.com/ I vaguely recall Sjoerd tried to run his entire site as you've described and it lasted a few weeks before he ran into enough problems that he now does server-side XSLT to HTML 4 unless you click the Try XHTML 2.0 button, which turns off the server-side XSLT. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Disambiguation [was RE: uid microformats? (was Re: [uf-discuss] ISBN mark-up)]
On Apr 29, 2006, at 5:32 PM, Benjamin Carlyle wrote: It is not clear to me at this time that microformats need profiles. hcard seems to have several profiles: http://microformats.org/wiki/hcard-profile http://www.w3.org/2006/03/hcard hcalendar seems to have none. Has this harmed adoption or made tooling more difficult? I don't think so, at least not so far. I think the likelihood of someone using a class name like hcalendar to mean anything other than the microformat is incredibly small. However, I have run into many people for whom such a formal indication is a prerequisite for using a markup format, so in my experience, the lack of profiles is harming adoption. Microformat terms act like profiles in identifying how to process the content, so what else would using a profile add: 1) The ability to skip parsing of a html document (or parts thereof) becase we don't see the profile elements we recognise. 2) To provide additional disambiguation: To tell a parser which vcard specification or version to use. 3) To identify the fact that some microformats are in use, ie use http://microformats.org/; instead of a profile for a specific microformat. I think that (1) is based on a false premise. You have to at least start parsing the html document in order to know which profiles are used. Chances are that profiles will be frequently missing or incorrect given the current tooling situation. I think parsers will look for microformats they know about no matter what the profiles attribute says. Agreed. (2) and (3) also seem like a bad ideas. They would be technical measures to allow the established microformat community base to splinter. While we all live within one namespace we are force to interact with each other to resolve conflict. Outside of that space confrontation is avoided and we end up with mymicroformats:vcard and yourmicroformats:vcard class names. Publishers would be forced to choose between the two. I don't really understand 3. I don't think 2 is a bad idea; I just don't think it's necessary. It's not really mymicroformats:vcard and yourmicroformats:vcard we might see on the web. It's gmpg.org/ vcard (or even w3.org/vcard) and mydomain.com/vcard. One is clearly more authoritative than the other (which is so far entirely hypothetical), so I don't think this is a worthwhile concern. I don't think ambiguity is a worthwhile concern either, but I do think it will be less trouble to create profiles to satisfy those who have this concern than to convince them that it's not worth worrying about. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Microformats vs XML
On Apr 30, 2006, at 9:56 PM, Karl Dubost wrote: *Remember* that I concluded the mail by ying-yang. Nothing is all good or all bad. It's yin-yang (no 'g' on 'yin'), and that's not really what it means. Yin-yang is the balance of opposing forces, e.g. human- readability and machine-readability. When these are balanced properly, it's all good. When one has too much influence over the other, e.g. tag soup on the one end, or binary formats on the other, it's all bad. See Wikipedia: http://en.wikipedia.org/wiki/Yin-yang Yin and yang are equally important, unlike the typical dualism of good and evil. So yin-yang might actually be a good symbol for microformats, just not in the way suggested above. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Language Maps [was RE: [uf-discuss] Microformats vs XML]
On May 1, 2006, at 3:33 AM, Joe Andrieu wrote: All without any requirement of seeing or using English except the one reference to hCard in the title of the profile. And all the HTML. The problem is that we need a shared language in order to communicate, and machines are bad at translation. At some point before parsing, all multi-lingual class names would need to be translated to a lingua franca that can be understood by all machines. There is no good place to do this after the server outputs a document, but there's no reason it can' t be done before that point and work with all existing microformat parsers. If you want to write your microformats in French, write them in French. You just need to translate them into English before presenting them to a machine expecting you to speak English. This translation could be a relatively simple server-side XSLT. But expecting every parser to translate every document before parsing it would require a distributed translation system accessible by any programming language. If we had that, I expect we'd find better uses for it. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Disambiguation [was RE: aid microformats? (was Re: [uf-discuss]ISBN mark-up)]
On May 1, 2006, at 2:29 AM, Joe Andrieu wrote: You have to at least start parsing the html document in order to know which profiles are used. Agreed. The presumption here is that processing is cheap and undirected. There's no way to download only the DOCTYPE or the head of a document, and processing is cheaper than bandwidth. Once you've already downloaded a whole document, you might as well parse it all because the head might be wrong about what's in the body. See Kaboodle[1] or Backpack[2] or Scrapbook[3] for examples where realtime, directed parsing is useful. [A] http://www.kaboodle.com [B] http://www.backpackit.com [C] http://amb.vis.ne.jp/mozilla/scrapbook/ Basically, all of these could be seen as variants on Live Clipboard. Right, but these all work client-side, where the document is already completely loaded. Many microformat parsers work server-side. If there are only a handful of Microformats and they are all well- known, (and we have effectively hijacked the class default namespace), then the processing should be manageable. It is manageable. It's just not worth doing because: 1) the whole document is already downloaded, which is the largest burden 2) heads lie. But if there are thousands or tens of thousands of Microformats-- and yes, I know this presumption is at odds with some of the expectations behind a socially moderated namespace--in that scenario, it is easy to calculate the difference of running a single attribute check for microformat instead of checking against the entire Microformats space. This was what I meant when I asked How do Microformats scale? Microformats scale by re-use. Thousands or tens of thousands of microformats is an anti-goal. I don't believe we are in the latter situation where we need tight coordination as in a protocol. We need tight coordination as in a dictionary. A formal definition of a shared lexicon is what allows us to communicate with new symbols. You can use whatever class names you want, but if I don't know what they mean, I can't parse them, and a profile doesn't tell me what they mean, it just tells me whether they follow a certain syntactic structure. Profiles are like a grammar check, but we still need a dictionary. Instead, what we need is a simple way for human authors to say This is what I mean. Profiles don't do that. No technology does that. That's an incredibly complex problem that no one has yet solved. When they do, we'll have usable machine translation, artificial intelligence, and microformats will be the least of our worries. There is value in forging a tight class of well understood, easily human authored, semantic tags. However, Allowing rich variation on the existing classes doesn't split the community--the community is the social network, not the semantic space. In practice, social networks require shared understanding of what things mean. The lack of this shared understanding leads to civil war in the real world, and unused specs in the tech world. Instead, it allows exploration and differentiation, which ultimately can be incorporated back into the foundation classes. More importantly, it allows user-driven innovation. You can already explore and develop your own specs. But if you want someone else to understand them, you have to explain to them what the spec means in clear human language. Machines don't understand. People understand. Clear human language is easier to accomplish in community than in isolation. I think it is hubris to expect that the first adopted version of a microformat is the orthodox way to do it and that variations are heresy. It would be if microformats, or dictionaries, did much more than document and formalize existing use. Do you find hubris in dictionaries as well? Who is this Webster to tell us what dog means? He's someone who documented how a lot of people use the word dog and wrote it down in a dictionary, just like we're documenting how a bunch of people mark up citations, and writing it down in a wiki. If our mantra includes basing our developments on real-world examples, then how does the spec evolve if we don't have real-world examples of derivative implementations? We have a web full of real-world data publishing examples. Without variations, we risk stagnation. No one is preventing anyone from using whatever class names they want. No one is preventing anyone from telling others what their class names mean. But no one has invented a technology to automate shared meaning. We can't use it because it doesn't exist. I think the type of disambiguation I am talking about can be addressed with a simple microformat=profile attribute. Have you looked at profile URIs? http://microformats.org/wiki/profile-uris That accomplishes exactly what your microformat=profile would, except it's valid XHTML. But neither accomplish shared meaning,
Re: [uf-discuss] meeting minutes: microformats needed?
On May 3, 2006, at 6:31 AM, Edward Summers wrote: On May 3, 2006, at 5:29 AM, brush wrote: *new microformat?: hparticipants (multiple hcards plus class=role) -- could be useful in many other circumstances If a role could somehow be assigned to an hCard it would be very useful in the citation microformat for authors, editors, translators, etc... Doesn't the ROLE property already serve this purpose? Type name: ROLE Type purpose: To specify information concerning the role, occupation, or business category of the object the vCard represents. See: http://www.faqs.org/rfcs/rfc2426.html http://microformats.org/wiki/hcard#Property_List Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] meeting minutes: microformats needed?
On May 3, 2006, at 1:43 PM, brush wrote: one thought about role: is it appropriate to re-engineer the category from what is apparently originally intended as a relatively static feature (ie. sales engineer for a person or green construction for an organization) to something relevant only in the immediate context (ie. notetaker for a specific meeting, or abstain for a vote)? It looks to me like role in vCard and hCard means what role in English means. I would say notetaker is a role, but abstain is not. Maybe abstainer could be a role, but it would need to be defined within a very specific context, unless you're describing someone who just goes around abstaining all day. I think roles need to be nouns, not verbs. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
[uf-discuss] hcalendar timezone, DST examples
I believe the most common flaw in vevents is currently missing or incorrect timezones. I was just looking at how timezones are shown in the examples, and discovered that they aren't. Every single example is marked as Z. On the live web, I don't see many actually converting their times to UTC, so I think the examples should probably reflect the more common use of offsets to encourage better timezone markup. I started by changing the first event to CST under DST. I also changed the timezone question in the FAQ to focus more on what people are more often doing (offsets): http://microformats.org/wiki/hcalendar-examples http://microformats.org/wiki/hcalendar-faq I'm still not entirely sure I understand timezones and DST correctly, so it would be good for others working with this issue to review. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hcalendar timezone, DST examples
On May 12, 2006, at 2:02 PM, Scott Reynen wrote: I believe the most common flaw in vevents is currently missing or incorrect timezones. I was just looking at how timezones are shown in the examples, and discovered that they aren't. Every single example is marked as Z. On the live web, I don't see many actually converting their times to UTC, so I think the examples should probably reflect the more common use of offsets to encourage better timezone markup. I started by changing the first event to CST under DST. I also changed the timezone question in the FAQ to focus more on what people are more often doing (offsets): http://microformats.org/wiki/hcalendar-examples http://microformats.org/wiki/hcalendar-faq I'm still not entirely sure I understand timezones and DST correctly, so it would be good for others working with this issue to review. Nevermind, none of that is there now. Ryan, why are you reverting my changes? Is the complete lack of offset timezone examples a feature? Looks like a bug to me. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hcalendar timezone, DST examples
On May 12, 2006, at 3:56 PM, Ryan King wrote: Certainly, we need more educational material on how people should use timezones. Deleting attempts to create such material without notice strikes me as a funny way to get it created. I'm not sure what you mean by discussion. I reversed the edit you made because... Here's how you could help instead... This is assuming such help is desired. Without such discussion, I'd tend towards the opposite assumption. On May 12, 2006, at 4:50 PM, Tantek Çelik wrote: One thing that often helps is to be on irc (#microformats on irc.freenode.net) *while* you are editing the pages. This significantly increases the time required for someone to try to improve the wiki. It also suggests to me that some sort of back- channel pre-approval is required for editing the wiki. Do I have any other other options if I want to help and not just waste my (and Ryan's) time? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
On May 25, 2006, at 3:04 AM, Chris Messina wrote: how do we create URIs for partial bits of data like a word or hcard in the middle of a paragraph? http://www.eekim.com/blog/tech/hyperscope/hyperscopeuri.html I'm not sure that's really the question being asked by Eugene. It sounds like the addressing of HyperScope goes beyond specific fragments: It can do path expressions, similar in spirit to XPath, which allows you to reference some subset of nodes in a document. This sounds to me like, e.g., a URI that references all the TEL elements in a document, and only those elements, so the client can read the URI, load the document, and strip it down to the specified nodes. So the question being asked is whether this would be better as http://domain.org/?hyperscope=class:tel or http://domain.org/ #hyperscope:class-tel or something else. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Addressing bits of information
On May 25, 2006, at 10:52 AM, Tantek Çelik wrote: What problem is this solving? What human readable content is this marking up? This is sounding off-topic for microformats. Am I missing something? I don't think it's about publishing microformats, but rather parsing microformats. That may be off-topic for this list, but it might be good to discuss on the microformats-dev list or somewhere, as a simple re-usable tool for pulling microformats out of documents would be useful for anyone building parsers. And more parsers makes the benefits of microformats more obvious to publishers. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] RDFa and microformats
On May 30, 2006, at 3:53 PM, Elias Torres wrote: I'm missing your point Scott. If what you refer to as real-world implementation is (vcard, vcalendar, etc), then RDFa draws from them just as well uF does. I wasn't comparing microformats and RDFa. I was comparing RDFa and vcard. There were thousands, maybe millions, of real-world vcards to look at when developing the hcard microformat. Where is the existing RDFa data you would like incorporated into future microformat development? Can you provide some URLs where RDFa is being published currently? If so, you should add them to the relevant *-examples pages on the wiki. If not, RDFa is not yet a real-world publishing concern, making it beyond the scope of microformats. See: http://microformats.org/about/ Specifically: adapted to current behaviors. As far as I can tell, RDFa is not a current behavior so what you're suggesting is that microformats should be adapted to future behaviors. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] microformats search and pinging
On Jun 1, 2006, at 5:50 PM, Tantek Çelik wrote: Mea Culpa. Okay. On Jun 1, 2006, at 7:08 PM, Kevin Marks wrote: Scott, I'm trying to relay pings to you byt they don't seem to eb working: It currently fails on anything that's not well-formed X(HT)ML, so it's probably not worth auto-pinging until I get to installing Tidy. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hCalendar for events in tables (real world examples)
On Jun 2, 2006, at 5:51 PM, Andy Mabbett wrote: It seems clear to me that, since its talking about markup that its for authors. You asked me to let you know if they lack clarity in any way; not whether they were clear to you. Yeah, what's up with asking if it's clear and then arguing with the response? And you really think the section that starts with when parsing is clearly for authors? Is this opposite day or something? On Jun 2, 2006, at 6:01 PM, Andy Mabbett wrote: I'm troubled by the (ab)use of the object tag - what object is being embedded, in such cases? The referenced node. But it's not being embedded, is it? It's merely referenced. The object tag isn't itself an object. It's a reference to an object, just like the img tag is a reference to an image, by URI. The user agent is supposed to do the inclusion if it understands the referenced object, and ignore it if it doesn't. That's all in the HTML spec. The only thing microformats seem to be adding is the stipulation that objects referencing fragment URLs should only include the specific node the fragment identifies, and not the entire document as Safari does. I don't see that in the HTML spec. Safari doesn't handle object elements correctly. what would be correct? The spec says correct behavior is including the referenced object if it's understood, and ignoring it if it's not. Most browsers ignore what Safari includes, but on my reading, that doesn't make Safari's behavior incorrect. Is there something else, or is it just that Safari's inclusion is a visual mess? Right, you should certainly apply the above styling to all browsers, as they each have their own difficulties with object elements. And what about agents with no CSS capability? You should be able to use the height and width attributes for such user agents. The method smacks of being a kludge. Inclusion seems to be following the intent of the object tag, but it doesn't seem like any browsers really implement the object tag well. We can't change what's valid XHTML, so the alternatives seem to be object tags or nothing. And nothing is a perfectly viable option. Inclusion is not a requirement, just an option. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: DOM scripting as an alternative to include-pattern?
On Jun 3, 2006, at 3:19 PM, Michael Leikam wrote: I brought up client side parsing not to imply that sever-side parsing is irrelevant, but to say that there's already a well-known and robust way to copy precise parts of the DOM and insert them in precide locations. You can already implement inclusion with DOM manipulation with the current inclusion pattern. There's no reason all parsers need to implement it the same way. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Re: DOM scripting as an alternative to include-pattern?
On Jun 5, 2006, at 12:27 PM, Michael Leikam wrote: could you (or anybody else really) explain a little more about the differences you see between supporting DOM manipulation during the parsing, as I've suggested, and supporting include-patterns? The include pattern describes simple behavior (include the referenced fragment). DOM manipulation is one specific implementation of that behavior, and much more beyond it. What is the difference between defining a data format and defining what people do with that data format (i.e., what that data format is used for)? I think the important difference is that the former makes communication easier and the latter makes communication more difficult. But in order for the parser to generate the target format, you've defined this procedure: - if class is include, grab the referenced node including descendants and replace the current node with the referenced one. - I think the HTML spec pretty much defines this procedure: http://www.w3.org/TR/html4/struct/objects.html#adef-data This attribute may be used to specify the location of the object's data ... a serialized form of an object which can be used to recreate it. Maybe this is a good example of why specs shouldn't be repeated. The sort of markup I had in mind was something like this: - div id=company div class=hcard h1 class=fn orgMichael's Webby Widgets/h1 div class=adr span class=localityLos Angeles/span /div /div /div div class=hcard onUFparseEvent=add_org_and_city() div class=fnMichael Leikam/fn a class=email href=mailto:[EMAIL PROTECTED] /div - This is invalid XHTML. There is no onUFparseEvent attribute for div tags. We can't just add arbitrary attributes to XHTML, and especially not if we expect anyone else to understand what we're trying to communicate. Adding an ID to span.locality, which I think is how include-pattern wants to handle this, isn't appealing because I'd want to use a generic hcard generator for any contact information. I don't think that's what the include pattern is for. You might want to look at microtemplates, as it seems to be more what you're after: http://microtemplates.org/ But from the replies I've gotten, it sounds like this is the beginning of a discussion and not something that is already ongoing. The inclusion pattern is a relatively new introduction to microformats. The object tag is older than microformats. The principle of separating markup from functionality is older than microformats. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] mf-dev
On Jun 7, 2006, at 9:52 AM, Tantek Çelik wrote: Perhaps this should be an FAQ with more explanation, but the microformats-dev list is open for subscription to only those with a public implementation. FYI, I have two microformat parsers. I've read multiple suggestions that I should join the microformats-dev list to discuss issues with these parsers. But I haven't joined because I've seen no explanation of how to do this. I have the key, but I don't see the door. I continue to be surprised at how such basic information about this community, which is built around the goal of making information more accessible on the web, is inaccessible on the web. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] mf-dev
On Jun 7, 2006, at 11:09 AM, Drew McLellan wrote: The link to the signup page is here: http://microformats.org/discuss/ That's the Discuss page of microformats.org - it's on every page as part of the main navigation bar. I'd like to be able to suggest ways to make it easier to find, but I'm struggling to think of any. Yeah, I've read that page several times. It is very easy to find. But it's also misleading. On the actual signup page, it says This is a closed list, which means your subscription will be held for approval. That's descriptive. On the discuss page, it says closed subscription (only those with a implementation). That's misleading. There's a difference between subscriptions being held for approval and subscriptions being closed. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] include pattern question
On Jun 11, 2006, at 1:03 PM, Michael Leikam wrote: As I understand it, well-formed XHTML is required when authoring content because it needs to be rendered by user agents (e.g., browsers) in a human-friendly way *and* parsable by XML tools (like Brians X2V parser, which uses XSLT to reformat the content). If these conditions were not required, we could author content in HTML or XML. Why does your parser need to have valid XHTML input instead of working with valid XML? If you loosen your input requirement for the parser, you can do your inclusions first and pass valid XML (but invalid XHTML) to your parser. Oops. I was mixing up two different tools I'm working on. My current parser does only require valid XML, so disregard my question. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] LinkedIn and Microformats
On Jun 13, 2006, at 4:18 PM, David Janes -- BlogMatrix wrote: I was going to report the happy news that LinkedIn [1] is using hCards, as my little Greasemonkey script was showing an icon on the page. Alas, it's not to be -- here's what they're doing: p class=vcarda href=/addressBookExport?exportMemberVCard=memberID=6172221 name=_exportVCardDownload vCard/a/p D'oh -- they're using vcard to mark that there's, umm, a vcard at the other end of the link. If anyone knows anyone at LinkedIn, you may want to give them a nudge. Ideally, they'd be using microformats, but they're not doing anything wrong here. Microformats don't own class attributes, and that's a perfectly descriptive use of the class attribute. I think this is a good reminder that those of us writing parsers shouldn't be assuming valid microformat data based only on class attributes. At the very least, the above hcard doesn't have any N property, so parsers shouldn't be treating it as parse-able data. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] LinkedIn and Microformats
On Jun 13, 2006, at 5:10 PM, Tantek Çelik wrote: Ideally, they'd be using microformats, but they're not doing anything wrong here. Microformats don't own class attributes, and that's a perfectly descriptive use of the class attribute. I think this is a good reminder that those of us writing parsers shouldn't be assuming valid microformat data based only on class attributes. At the very least, the above hcard doesn't have any N property, so parsers shouldn't be treating it as parse-able data. Actually, I see less harm in treating Linkedin's use of class=vcard as an error and ignoring it than making a lot of extra work for every implementer for one degenerate case. But it's not just one degenerate case. It's every degenerate case. This is just the most obvious case of an invalid hcard. Any hcard invalid in ways that make it impossible to parse (e.g. missing FN, unclosed tags, etc.) has the same problem. Unparseable hcards with class=vcard show up on this list regularly. Isn't it safe to assume they show up in the wild even more often? But even without that, it is not unreasonable to assume that class=vcard is an hCard. Just as it is not unreasonable (as in they all do it) for a browser to assume that html is an HTML document even if there is no DOCTYPE that points to a DTD URL which defines the element html as such. It's not unreasonable for a browser to assume anything with a .jpg extension is a JPEG, but I'm glad my browser checks for valid data before presenting it to me. It's just bad user interface to suggest something can be parsed when it can't. Parsers are able to parse the data already. It's not any extra work to do this before indicating the data is parse-able. I'm not suggesting this should be part of any spec, but I don't see any advantage to making the assumption that everything with class=vcard is a valid hcard. And I say that having written parsers that make this very assumption. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Spam and Microformats Search
On Jun 19, 2006, at 9:56 AM, Patrick Crowley wrote: Great job on MF search, guys. My hCard is showing up nicely now, but I noticed my email is sitting out in the open. Any chance you can add spam protection to search results? Isn't it already sitting out in the open for the search to have picked it up? Publishing-side spam protection is generally a placebo. If a single person with a vulnerable machine has your email address, it's available to any persistent spammer even if it's not on the web anywhere. And once one spammer has it, they'll sell it to other spammers. I don't think microformats have much to offer as far as spam-fighting. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hKit parsing library for PHP5
On Jun 19, 2006, at 5:10 PM, Drew McLellan wrote: I poked around looking at stuff that's already out there, including Microformats Base, but I couldn't find anything that fitted the model I was after - namely chuck in a string or URL, and get out an array structure of, say, hCards. So in the principal of release early, release often, here's what I'm calling hKit for PHP5 version 0.1. http://allinthehead.com/code/hkit/hkit-v0.1.tgz Neat. The first issue I see in a quick skim is that you seem to be assuming values for date classes should be in the title attribute, but deference to the title attribute is based on the abbr tag, not the class name. It depends on SimpleXML in PHP5, and really needs either the PHP Tidy functions or tidy on the local system (a configurable setting), otherwise you're depending on the page being valid. You could run the URL through a public Tidy proxy before parsing. That makes it reliant on a server you can't control, but it also makes it reliant on a service you don't need to control. Here's an edited version demonstrating how this would work: http://microformat.makedatamakesense.com/hkit.zip Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hKit parsing library for PHP5
On Jun 19, 2006, at 5:10 PM, Drew McLellan wrote: I poked around looking at stuff that's already out there, including Microformats Base, but I couldn't find anything that fitted the model I was after - namely chuck in a string or URL, and get out an array structure of, say, hCards. I just noticed this on the wiki, and it seems very similar: http://www.oliverbrown.me.uk/2005/09/03/a-working-microformats- extension-to-simplexml/ Looks like you're both in the UK too. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] hKit parsing library for PHP5
On Jun 20, 2006, at 12:04 PM, Drew McLellan wrote: I'll not keep clogging up this list with updates, but I thought this one was worth it as I've fixed a large number of problems since the initial release last night. I'd be interested in hearing about such updates, though I agree they probably aren't appropriate for this list. Can you sign up for the dev list and post these there? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] More Microformats Browser UI
On Jun 21, 2006, at 8:29 PM, Chris Messina wrote: So, here's a challenge: what kind of solutions can we come up with that are single click only? I just made this Greasemonkey script yesterday: http://greasemonkey.makedatamakesense.com/callto_tel/ It wraps TEL numbers in hcards with callto: links, which can be used to open phone calls in VOIP applications like Skype or Vonage (I've only tested with Skype on OSX). It has several known bugs, including merging multiple VALs within the same TEL, being totally ignorant of non-American phone number formats (because I don't know much about non-US phone number formats, nor how VOIP applications handle them), and not checking to see what tag the TEL is in and potentially wrapping a link around something it can't go around in valid XHTML. But it is, nonetheless, a one-click interface for hcards, as requested above. And as far as my searching found, VOIP is a previously unexplored interface for hcards. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Very basic question that is not in the FAQ
On Jun 22, 2006, at 8:32 AM, Tantek Çelik wrote: Sam points out that I am employed by Technorati and implies that poses some sort of conflict or corporate bias. I'll challenge you on that Sam, because the (by design deliberate) policies of having open email/IRC/wiki with archives actually serve to make microformats.org *more* transparent and accountable than *any* other standards effort (I challenge you to find one with more open policies) no matter *who* is involved or what connections they may have, and second, enable *anyone* with email/IRC/web access to participate without having to pay *thousands* of dollars per year to join a consortium or committee. In that latter sense, microformats.org is actually *less* corporate (despite your implication) than other standards bodies which require paid membership to take part in (very often secret) discussions which actually write the standards, and in some cases, even just the *test suites*. Nonetheless, people maintain a mistrust of large corporations, and Technorati's ties to microformats.org are more obvious than the various corporate connections to the W3C. It may not be a valid concern, but it is definitely a real concern that continues to hamper microformat adoption. I'd suggest that challenging such people to validate their concern is not the best way to address this issue. Sure, Technorati should be presumed benign until there is evidence to the contrary, but unfortunately that's not how such perceptions work in the real world. The point here is that microformats.org, as a community was designed to be open and accessible to independent designers and developers, and puts them on equal footing with small and large companies alike. And it has largely succeeded in being all of those things, but that doesn't have much effect on how people unfamiliar with the history perceive the relationship between Technorati, the microformats community, and also the GMPG. I think it would be helpful to unambiguously clarify these relationships up front as people begin to learn about microformats. And to correct Sam's implications further, Technorati does not own microformats.org Who does? Can we get that information on the about page and address these concerns before they develop? As a side note, does anyone know anything about wwwmicroformats.org? Is that just typo domain squatting? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Very basic question that is not in the FAQ
On Jun 22, 2006, at 9:46 AM, Tantek Çelik wrote: Hamper compared to what? When I'm telling someone about microformats and they express concern that Technorati might try to control microformats as Microsoft or Google has been feared trying to control the web, or Apple trying to control podcasting, or UserLand trying to control RSS, I believe the answer influences people's interest in microformats. I try to point to the CC license. I avoid a curt that's just FUD (even if it is) because I find that insulting. I find clarifying ownership works well in one-on-one discussion and I think it would work well on the website too. If you disagree, fine. I don't think it's going to make a big difference in the long run, and I didn't mean to suggest it would. But I continue to believe clarifying ownership in advance would be an improvement. With all due respect Scott, if you consider the current adoption rate of microformats to be hampered, I would be curious to know what your expectations are. Frankly, I don't think that's all due respect. This appears to be a rhetorical question implying that my expectations are wildly unrealistic. I made concrete suggestions about what I think would improve adoption of microformats. I think I made it clear that I don't think corporate ownership is a valid concern, but I think it should be addressed nonetheless because it exists in the real world. And your response appears to me a defensive dismissal that does little to address my suggestion to clarify ownership before it becomes a concern. Maybe people don't express this concern to you, but they express it to me, so I'm passing that along. Don't shoot the messenger. Here's an alternative suggestion: if the sponsorship isn't something that needs to be disclaimed, perhaps it shouldn't be on the disclaimers page: http://microformats.org/wiki/Microformats:General_disclaimer Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Very basic question that is not in the FAQ
On Jun 22, 2006, at 1:20 PM, Kevin Marks wrote: The point of microformats is to give up control. Technorati genuinely believes that distributed open formats are more valuable than centralised closed ones, and that is a big reason why Tantek and I work here. I know all this. My point is that someone reading microformats.org for the first time does not, and they should. The problem may be that 'clarifying ownership' involves a digression into Open Source theory rather than a simple disclaimer. If you have a good way of explaining this do please share it. On http://microformats.org/about I'd suggest something like: microformats are: ... open data format standards that a diverse community of individual and organizations are actively developing ... microformats are not: Controlled by any individual or organization On http://microformats.org/wiki/faq I'd suggest something like: Q: Who controls microformats? A: An open community. Microformats are open standards licensed under Creative Commons Attribution. Work on microformats began at Technorati, who later divested control of microformats to an open community The microformats.org domain is registered to CommerceNet, but CommerceNet claims no control over microformat standards... I'd like to be able to point people to words like these. I can say these things myself, but my words don't carry as much weight as microformats.org. In my experience, fearful, uncertain, and distracted people prefer weighty words. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] permalinks for microformat chunks of pages: use the 'id' attribute on root microformat elements
On Jun 22, 2006, at 1:54 PM, Tantek Çelik wrote: The microformat chunks (e.g. hCards, hCalendar events, hReviews etc.) that have an id attribute are much easier to automatically reference (and thus link to and browser/scroll to from search results) than those without. In the past, I've added ID attributes to pages with multiple hCards thinking this would be useful for taking actions on specific contacts, but then discovered that most tools didn't recognize fragment URLs. Last I checked, I believe X2V wasn't recognizing fragment URLs, so it wasn't possible to export a single vcard from a document containing multiple hCards. To work around this, I made a proxy service to strip documents down to single fragments: http://makedatamakesense.com/fraggle/ For example, Tantek has 26 hCards on his home page, but you can pull out just his own by running the page through this proxy: http://makedatamakesense.com/fraggle/?url=http%3A%2F%2Ftantek.com%2F% 23hcard And then I went back and looked at X2V again, and now it seems to be recognizing fragment URLs. Technorati's vcard export still ignored the fragment in URLs, so I thought this might still be useful there. But it seems to be doing some odd conversion of URLs that makes this impossible. This: http://feeds.technorati.com/contacts/http://makedatamakesense.com/ fraggle/?url=http%3A%2F%2Ftantek.com%2F%23hcard Becomes this: http://feeds.technorati.com/contacts/http://tantek.com/#hcard And it converts all 26 hCards. So it looks like I wasted a little time on that proxy. But if there is some service out there that doesn't recognize fragment URLs, and anyone wants to take advantage of ID attributes on microformats, you can use it. On a side note: as I was going through the hCard examples looking for pages with multiple hCards to see if any of them had ID attributes already, I noticed a lot of pages in that list don't actually have hCards at all. For example, I remember Neil Dunn once had a nicely styled hCard on this page, but now it's gone: http://www.ndunn.com/2005/10/7/hCard So what's the protocol here? Should such links be removed from the wiki? Moved to a formerly had hCards section? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: Include fragments [was RE: [uf-discuss] a.include mimetype]
On Jul 10, 2006, at 1:06 PM, Joe Andrieu wrote: Including references to fragments on other pages creates the problems Chris brought up: that the fragment, which may be from some other author and may be arbitrarily formed or invalid or impermanent. Tantek wrote on IRC today that it is not allowed across pages, so we don't need to worry about those problems right now. Before identifying fragments by IDs became common, authors would often create addressable fragments with empty anchors, e.g.: a name=fragment href=/a So I don't expect doing the opposite would be a difficult concept for authors. Of course, people don't do this much anymore because it's ugly, but we seem to be lacking any prettier alternative. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] rel-tag: Sorry, I'm confused as to what it means
On Jul 11, 2006, at 10:34 AM, Lee Amosslee wrote: I've read all the FAQ pages, and maybe I'm just being dense, but can someone explain to me the difference between a hyperlink that should include rel-tag and one that *shouldn't* include one? The microformats wiki states: By adding |rel=tag| to a hyperlink, a page indicates that the destination of that hyperlink is an author-designated tag (or keyword/subject) of the current page. and rel=tag is specifically designed for tagging content, typically web pages (or portions thereof, like blog posts). rel=tag is NOT designed for tagging arbitrary URLs or external content. So, if I apply rel-tag, am I saying that this is an important link? Not exactly. If you just want to mark a link as important, you could wrap it with em/em. When you mark it with rel=tag, you're saying the destination link has a relationship of tag to the current content (which may or may not make it important). Not every link has that relationship, so you should only use rel=tag when the link actually has a tag relationship. Further, you should only use it when linking to URLs that end with the text of the intended tag. Regardless of how related it might be to your post on umbrellas, you shouldn't link to http://www.umbrellas.com/archives/ with rel=tag unless you want to tag your content with the term archives, which you probably don't want to do, although it appears to be a somewhat popular tag: http://technorati.com/tag/archives/ Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] More responses to slashdot comments
On Jul 13, 2006, at 3:17 PM, Sho Kuwamoto wrote: Depending on the look I wanted to achieve, I might find myself needing to surround, say, the first three divs by another div (let's call it leftColumn because there is no semantic relationship between these three sections). Why isn't leftColumn a semantic relationship? It means something, doesn't it? There's no reason a bunch of designers couldn't get together and agree on what leftColumn means just like the W3C agreed on what h1 means, and the microformats community agreed on what vevent means. Until someone find a babblefish, that shared meaning is all we have to communicate. That's as semantic as it gets. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Currency microformat
On Jul 18, 2006, at 9:54 AM, Ciaran McNulty wrote: It'd be pretty neat to have a browser widget that converted all the USD prices on an American site into their equivalent GBP on mouseover, or something along those lines. It already is pretty neat: http://viewmycurrency.wordpress.com/about/ In addition to that FireFox extension, here are two Greasemonkey scripts that manage to do currency conversion with no microformats: http://nybblelabs.org.uk/projects/exchequer http://6v8.gamboni.org/Greasemonkey-Yahoo-Finance.html Which prompts the question: what exactly is the problem we're trying to solve here? Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
Re: [uf-discuss] Developing a strategy for deployment of microformats
On Jul 18, 2006, at 2:03 PM, Ryan King wrote: Another problem - going to, for example, http://www.bath.ac.uk/whats-on/getevent.php?event_id=3010catIds=ALL Tails use the correct date (17 July) whereas the Google hCalendar Greeasemonkey script uses a date of 16 July. I'm not familiar that greasemonkey script. You may want to talk to its author. I know of two such scripts, and I am the author of one. I'm not currently able to load that URL, so I can't see the problem right now. There are three places where this can go wrong: 1) in the markup, 2) in the Greasemonkey script, and 3) at Google Calendar. For 1), in my limited testing, almost no one is publishing time zones correctly, which is only an obvious problem when you try to use an event across time zones. For 2), if there is a bug, I'll need to see the URL in question to track it down. For 3), I vaguely recall Google Calendar doesn't always correctly convert times to the time zone set in your preferences. Most problems are in 1) and/or 3), which makes it difficult to track down problems in 2). Garbage in, garbage out, as they say. Peace, Scott ___ microformats-discuss mailing list microformats-discuss@microformats.org http://microformats.org/mailman/listinfo/microformats-discuss
