From danny.ayers at gmail.com Thu Mar 1 02:47:42 2007 From: danny.ayers at gmail.com (Danny Ayers) Date: Thu Mar 1 02:47:49 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: <1172713107.5424.98.camel@localhost.localdomain> References: <1f2ed5cd0702280444w12203983h472f7e32d211da4@mail.gmail.com> <1172713107.5424.98.camel@localhost.localdomain> Message-ID: <1f2ed5cd0703010247o4eae5d9bn4651051ddbc3878c@mail.gmail.com> On 01/03/07, Mike Linksvayer wrote: > > On Wed, 2007-02-28 at 13:44 +0100, Danny Ayers wrote: > > XMDP profiles have already been drafted for many of the microformats > > (e.g. there's one for hCalendar at [4]). > > Possibly stupid question: why profile_s_? (Or perhaps rather, why > profile URI_s_.) > > Microformats are specified centrally at microformats.org, why not take > advantage of that? Adding a profile attribute to will be hard > enough for some webmasters, why make them think about which one(s) to > include? > > This would also comport with microformat parsers tending to be > "universal", parsing all microformats. Imaginary grokMicroformats.xsl > should be just another one. Yep, a combined profile would certainly be useful. There is still value in having multiple profiles in that it allows independent development (and deployment), microformats at different levels of maturity can comfortably coexist. Just as an aside (and I'm open to accusations of "architecture astronautics" here), if adding a profile attribute is hard for webmasters, the right answer is to make it easier rather than working around its absence. The of a HTML document is an important part of the chain of authoritative metadata [1]. As an analogy, XML-RPC in itself works because there are solid foundations underneath (HTTP/REST). The fact that it takes rather a warped view of those foundations means that anything built on top will be fragile. (Not following the RPC paradigm was a very early design choice for HTTP [2]). To ensure we can build solid things on top of microformats, they need to maximimally respect the layers below (HTML, HTTP, URIs etc). I believe that's the case in principle, only the practice is lagging a little. > Finally, consider the single most informative page on the microformats > wiki -- http://microformats.org/wiki/existing-classes. Not in anything > like a profile-style definition list format, but it could be (probably > as multiple lists). Thanks - that is a most excellent resource. Cheers, Danny. [1] http://www.w3.org/2001/tag/doc/mime-respect.html [2] http://www.w3.org/Protocols/DesignIssues.html -- http://dannyayers.com From robertc at gmail.com Thu Mar 1 09:15:37 2007 From: robertc at gmail.com (Rob Crowther) Date: Thu Mar 1 09:15:41 2007 Subject: [uf-discuss] Training events in hResume In-Reply-To: References: <3ce2ebd20702111849x5d80ffa0w44320ef7030c564d@mail.gmail.com> <83a2ad2f0702120631j2778e773x6b12afe8f5af66a2@mail.gmail.com> <3ce2ebd20702130323n28897ca9h33521323803dcccc@mail.gmail.com> <939B8B59-029E-4063-9AFC-835DFD1FC36A@technorati.com> <45D4DC9E.1010300@skynet.ie> <3ce2ebd20702160532p53d4a921l8270b10dbcc48a64@mail.gmail.com> <83a2ad2f0702160658h2be775aaoc1172b6c2ec6415c@mail.gmail.com> <3ce2ebd20702160915k739c27b0vceac01428b998764@mail.gmail.com> Message-ID: <3ce2ebd20703010915n332be6f5w71033327b8114d51@mail.gmail.com> On 28/02/07, Ryan King wrote: > > The title attribute is hidden metadata, which we try to avoid as much > as possible. > But the class education is also hidden metadata, so if the "informal" isn't hidden then you can't see what it applies to. > Why not just use tags? > > ... ... > Wandering slightly off topic - after attending a few accessibility related talks recently I'm starting to think that littering pages with tags is perhaps a bad idea, as you end up with a load of links obstructing screen reader users. I was going to have a go at the construction the next time I updated my CV. Rob From mdagn at spraci.com Fri Mar 2 12:40:11 2007 From: mdagn at spraci.com (Michael MD) Date: Thu Mar 1 17:39:41 2007 Subject: [uf-discuss] Scraping or parsing? References: <1f2ed5cd0702280444w12203983h472f7e32d211da4@mail.gmail.com><1172713107.5424.98.camel@localhost.localdomain> <1f2ed5cd0703010247o4eae5d9bn4651051ddbc3878c@mail.gmail.com> Message-ID: <003a01c75d0a$fce39d60$116bacca@COMCEN> > Yep, a combined profile would certainly be useful. There is still > value in having multiple profiles in that it allows independent > development (and deployment), microformats at different levels of > maturity can comfortably coexist. I've been experimenting with trying to parse such profiles into perl hashes to use for parsing microformats but have come accoss some problems. I don't see how special cases where something has to be extracted in a different way are expressed in the profiles. (eg for rel-tag it needs to split the url in the href attribute and get the last part) >> Finally, consider the single most informative page on the microformats >> wiki -- http://microformats.org/wiki/existing-classes. Not in anything >> like a profile-style definition list format, but it could be (probably >> as multiple lists). yes I even tried using a html parser to parse the table on that page into a perl hash so that I could have some kind of data structure to experiment with! From scott at randomchaos.com Thu Mar 1 18:22:57 2007 From: scott at randomchaos.com (Scott Reynen) Date: Thu Mar 1 18:22:56 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: <003a01c75d0a$fce39d60$116bacca@COMCEN> References: <1f2ed5cd0702280444w12203983h472f7e32d211da4@mail.gmail.com><1172713107.5424.98.camel@localhost.localdomain> <1f2ed5cd0703010247o4eae5d9bn4651051ddbc3878c@mail.gmail.com> <003a01c75d0a$fce39d60$116bacca@COMCEN> Message-ID: <6F943852-6685-4B69-BD1E-AC7D87542203@randomchaos.com> On Mar 2, 2007, at 2:40 PM, Michael MD wrote: >> Yep, a combined profile would certainly be useful. There is still >> value in having multiple profiles in that it allows independent >> development (and deployment), microformats at different levels of >> maturity can comfortably coexist. > > I've been experimenting with trying to parse such profiles into > perl hashes to use for parsing microformats but have come accoss > some problems. > I don't see how special cases where something has to be extracted > in a different way are expressed in the profiles. > (eg for rel-tag it needs to split the url in the href attribute and > get the last part) Profiles are not intended to work as parsing templates. They just identify the type of data so parsers can figure out whether or not it's something they know how to parse. Peace, Scott From joe at andrieu.net Thu Mar 1 18:25:42 2007 From: joe at andrieu.net (Joe Andrieu) Date: Thu Mar 1 18:25:40 2007 Subject: [uf-discuss] Identity-related hCards? In-Reply-To: <254445A5-2894-47E9-84D6-7DF7CC5EE6E4@technorati.com> Message-ID: <004501c75c72$14334540$0301a8c0@andrieuhome> Ryan King wrote: > On Feb 20, 2007, at 12:23 PM, Scott Reynen wrote: > > And maybe that's because what you're describing is actually more > > specific that "related hCards" implies. It seems here you're just > > talking about a single relationship: identity. > > Yes. You're exactly right. I'm afraid I haven't been that > clear. When > I say "related hCards" I mean related in that they represent > the same > person or organization. I've been using "related hCards" as > shorthand > for "hCards that represent the same person or organization", which I > now realize must be confusing. (but it seemed so clear in my head! :D) Ryan, That made me laugh out loud. I was definitely responding to uid+url as non-identity relations earlier and it seemed perfectly clear in my head as well. =) So, don't equal UIDs already imply identitical hCards? In other words, what I think we've really been discussing is how to discover hCards for identical entities, using either URL or SOURCE (or "via", although I think SOURCE is much better). Frankly, it seems like it would work if it SHOULD be expected that consume apps MAY use URL and/or SOURCE to look for identical hCards. I believe this approach allows both uid+url and uid+source to link to "related" and/or "sourcing" hCards without any of further restrictions on the UID. -j -- Joe Andrieu joe@andrieu.net +1 (805) 705-8651 "An inconvenience is an adventure wrongly considered. An adventure is only an inconvenience rightly considered." --G. K. Chesterton From brian.suda at gmail.com Sat Mar 3 06:46:48 2007 From: brian.suda at gmail.com (Brian Suda) Date: Sat Mar 3 06:46:50 2007 Subject: [uf-discuss] Last Call: GRDDL Links Microformats and Semantic Web Message-ID: <21e770780703030646i6809f904mc8e0286f121a0af8@mail.gmail.com> 2007-03-02: The GRDDL Working Group has released a Last Call Working Draft of GRDDL. Comments are welcome through 30 March. With important applications such as connecting microformats to the Semantic Web, GRDDL is a mechanism to extract RDF statements from suitable XHTML and XML content using programs such as XSLT transformations. GRDDL allows powerful mash-ups at very low cost. http://www.w3.org/News/2007#item38 If anyone has questions about GRDDL please let me know, there are lots of resource available to help further explain and demonstrate the uses. GRDDL Spec: http://www.w3.org/TR/2007/WD-grddl-20070302/ GRDDL Primer: http://www.w3.org/TR/2006/WD-grddl-primer-20061002/ GRDDL Use-cases: http://www.w3.org/TR/2006/WD-grddl-scenarios-20061002/ More information about GRDDL and the Working Group: http://www.w3.org/2001/sw/grddl-wg/ Any and all feed-back is welcome. The mailing list has a public archive of messages to the working-group: http://lists.w3.org/Archives/Public/public-grddl-comments/ Thanks, -brian -- brian suda http://suda.co.uk From costello at mitre.org Sat Mar 3 13:56:43 2007 From: costello at mitre.org (Costello, Roger L.) Date: Sat Mar 3 13:56:48 2007 Subject: [uf-discuss] No luck with getting Technorati to index my microformat-containing Web pages - help! Message-ID: Hi Folks, I don't seem to have any luck in getting Technorati to index any of my Web pages that contain Microformats. For example, about a month ago I entered this URL at Pingerati [1] of a Web page that has an hReview of the book An Introduction to Mathematics: http://www.xfront.com/microformats/examples/hReview/example01/revised-r eview-Introduction-to-mathematics.html When I enter this search - An Introduction to Mathematics - at the Technorati search page [2] my Web page does not appear. What am I doing wrong? Thanks. /Roger [1] http://pingerati.net/ [2] http://kitchen.technorati.com/review/search/ From supercanadian at gmail.com Sat Mar 3 17:56:41 2007 From: supercanadian at gmail.com (Charles Iliya Krempeaux) Date: Sat Mar 3 17:56:44 2007 Subject: [uf-discuss] No luck with getting Technorati to index my microformat-containing Web pages - help! In-Reply-To: References: Message-ID: <84ce626f0703031756u126d9815u35266d385ba2787@mail.gmail.com> Hasn't worked for me for a while either. (It's been a little while since I tried though.) Some of the Technorati guys hang out on this list... so one of the will likely reply soon. See ya On 3/3/07, Costello, Roger L. wrote: > Hi Folks, > > I don't seem to have any luck in getting Technorati to index any of my > Web pages that contain Microformats. > > For example, about a month ago I entered this URL at Pingerati [1] of a > Web page that has an hReview of the book An Introduction to > Mathematics: > > http://www.xfront.com/microformats/examples/hReview/example01/revised-r > eview-Introduction-to-mathematics.html > > When I enter this search - An Introduction to Mathematics - at the > Technorati search page [2] my Web page does not appear. > > What am I doing wrong? > > Thanks. > > /Roger > > [1] http://pingerati.net/ > > [2] http://kitchen.technorati.com/review/search/ -- Charles Iliya Krempeaux, B.Sc. charles @ reptile.ca supercanadian @ gmail.com developer weblog: http://ChangeLog.ca/ From mikeschinkel at gmail.com Sat Mar 3 21:10:45 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sat Mar 3 21:10:48 2007 Subject: [uf-discuss] "authoritative hCards", a simpler proposl In-Reply-To: References: Message-ID: <022d01c75e1b$771a78e0$0702a8c0@Guides.local> Ryan King wrote: > Catching up in the last few days, I find that there are some > probelems with the "authoritative hcards" proposals. I' > > > > My proposal is that we use UID+URL to hint that there's an > hCard on the other end of that URL which represents the same > entity. Also, multiple hCards with the same UID may be > considered as representing the same entity. In reviewing this I can't help but feel that I don't understand the use-case or the desired outcome. Will someone kindly explain? Is it that there could be hundreds of hCards on the web for Ryan King (the one for the guy who has the email address of [ryan@technorati.com]) but only one should be considered 'authoritative?" Also, is the proposal is just throw some unique cruft onto the end of some URL for it to stake it's claim as the authoritative one? Sorry, but I've read the proposal and related emails several times and I'm still confused. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." From mikeschinkel at gmail.com Sat Mar 3 23:32:10 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sat Mar 3 23:32:14 2007 Subject: [uf-discuss] Re: "Well-known" URLs In-Reply-To: <861wkxwlt5.fsf@rakim.cfhp.org> References: <861wkxwlt5.fsf@rakim.cfhp.org> Message-ID: <024c01c75e2f$389dad80$0702a8c0@Guides.local> Edward O'Connor wrote: > If the intent is simply to document the existing, legacy > technologies that rely on such URLs (such as robots.txt), > that seems reasonable to me. I'd be interested in documenting [1] them . Does anyone of any other initiatives to define Well Known Names besides these:? http://mysite.foo/robots.txt http://mysite.foo/favicon.ico http://mysite.foo/w3c/p3p.xml http://mysite.foo/sitemap.xml http://mysite.foo/crossdomain.xml http://mysite.foo/smbmeta.xml -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." [1] http://wiki.welldesignedurls.org/Well-Known_Names From mikeschinkel at gmail.com Sun Mar 4 00:14:33 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 00:14:36 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: <1f2ed5cd0703010247o4eae5d9bn4651051ddbc3878c@mail.gmail.com> References: <1f2ed5cd0702280444w12203983h472f7e32d211da4@mail.gmail.com><1172713107.5424.98.camel@localhost.localdomain> <1f2ed5cd0703010247o4eae5d9bn4651051ddbc3878c@mail.gmail.com> Message-ID: <000101c75e35$248b3910$2102fea9@Guides.local> Danny Ayers wrote: > Just as an aside (and I'm open to accusations of > "architecture astronautics" here), if adding a profile > attribute is hard for webmasters, the right answer is to > make it easier rather than working around its absence. > The of a HTML document is an important part of the > chain of authoritative metadata [1]. My pedantic side wants to yell "Yea! Right on!" but my pragmatic side tells me that taking such a position is completely impractical because of the proliferation of blogs, wikis, and cms that empower users to publish content with no access to the . Access may be denyed because the content publisher is using software on servers they have no access to or because they can't change the source code of their web app as they are are not technical enough/don't have admin access to the servers/don't want to fork the source/have company policies that disallow mods/don't have the source/etc. You could say "Well the answer then is to get all the developers of all those apps to provide the content publishers access to the and then get all the existing apps in the field replaced with the new versions!" However, I think you'll agree that requiring such an approach is impractical when it is possible to craft a workaround. Even if we could someone dicate the above, it would likely take a decade before most content publishers had access to . After all, look how long it took to get the major browsers to add (some) support for certain standards, and they numbered far less then 10. There are hundreds of web apps for content publishing with tens of millions of server installations; I don't see them being 'fixed' any time soon. :-( FWIW. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." From mikeschinkel at gmail.com Sun Mar 4 00:45:45 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 00:45:50 2007 Subject: [uf-discuss] Tutorial on AHAH (such a cool technology!) In-Reply-To: References: Message-ID: <000901c75e39$80650780$2102fea9@Guides.local> > Costello, Roger L. wrote: Hi Folks, > > I have created a tutorial on AHAH (Asynchronous HTML and > HTTP) > > http://www.xfront.com/microformats/AHAH.html > > Comments welcome. Printable version please! Ane that doesn't take 12 pages to print... (He also grumbles about lack of back button in presentation but glad the presentation was not 96 pages...) > The purpose of AHAH is to enable an HTML document to > dynamically fetch HTML from other documents, thus > creating one document that is an assembly of information > from many HTML documents. I assume you got AHAH from the efforts documented here[1]? > Provide a placeholder in your HTML document where you > want the fetched HTML data to be inserted. Identify that > placeholder using the id attribute, e.g., Shades of ASP.NET! Now we've got client-side "placeholders" too! ;-P > The target HTML document (the HTML that you are fetching) > must not be a whole HTML document; it must just be an HTML > fragment. How does that work with content types? If it is a fragment then it is not a valid text/html, right? Is there a content type of "HTML Fragment?" If not, shouldn't there be and it be used instead of what you are using? Alternately, shouldn't you include the full HTML and trimmings but then extract the innerText from before inserting? I think this is actually something that could potentially even be discussed by W3C TAG for a finding on best practices (i.e. inclusion of HTML fragments.) Lastly, photo hides the content from search engines, which is not good. Christian Heilmann wrote: > This example does that (except for the templating part): > http://beginningjavascript.com/Chapter8/exampleXHR.html This approach is definitely better because it lets the search engines see the link: Perfect Day Another alternative that seems cleaner to me would be to code it like this and let your ahah.js annotate the link for you: photo Oh course this last suggestion will probably run me afoul of the microformat police since rel="ahah" hasn't even been officially proposed yet and I didn't bring it up on [uf-new]... ;-P -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." [1] http://en.wikipedia.org/wiki/AHAH From paul.kinlan at gmail.com Sun Mar 4 01:35:34 2007 From: paul.kinlan at gmail.com (Paul Kinlan) Date: Sun Mar 4 01:35:39 2007 Subject: [uf-discuss] No luck with getting Technorati to index my microformat-containing Web pages - help! In-Reply-To: <84ce626f0703031756u126d9815u35266d385ba2787@mail.gmail.com> References: <84ce626f0703031756u126d9815u35266d385ba2787@mail.gmail.com> Message-ID: <1f8270600703040135n3d707abal74812f72131dac33@mail.gmail.com> Hi. I have completly removed my Technorati entry and stopped using Technorati because it never kept up to date with my site (i.e it was months out) and the support people at Technorati never got back to me. Funnily enough, my blog http://www.kinlan.co.uk/ has some hAtom support in it (although it might be broken), I think it conincieds with Technorati no longer updating their index's with my changes. Just thought I would share a similar experience. Kind Regards, Paul Kinlan On 04/03/07, Charles Iliya Krempeaux wrote: > Hasn't worked for me for a while either. (It's been a little while > since I tried though.) > > Some of the Technorati guys hang out on this list... so one of the > will likely reply soon. > > > See ya > > On 3/3/07, Costello, Roger L. wrote: > > Hi Folks, > > > > I don't seem to have any luck in getting Technorati to index any of my > > Web pages that contain Microformats. > > > > For example, about a month ago I entered this URL at Pingerati [1] of a > > Web page that has an hReview of the book An Introduction to > > Mathematics: > > > > http://www.xfront.com/microformats/examples/hReview/example01/revised-r > > eview-Introduction-to-mathematics.html > > > > When I enter this search - An Introduction to Mathematics - at the > > Technorati search page [2] my Web page does not appear. > > > > What am I doing wrong? > > > > Thanks. > > > > /Roger > > > > [1] http://pingerati.net/ > > > > [2] http://kitchen.technorati.com/review/search/ > > > -- > Charles Iliya Krempeaux, B.Sc. > > charles @ reptile.ca > supercanadian @ gmail.com > > developer weblog: http://ChangeLog.ca/ > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > From angus at pobox.com Sun Mar 4 05:34:13 2007 From: angus at pobox.com (Angus McIntyre) Date: Sun Mar 4 05:34:19 2007 Subject: [uf-discuss] Re: "Well-known" URLs In-Reply-To: <024c01c75e2f$389dad80$0702a8c0@Guides.local> References: <861wkxwlt5.fsf@rakim.cfhp.org> <024c01c75e2f$389dad80$0702a8c0@Guides.local> Message-ID: At 02:32 -0500 04.03.2007, Mike Schinkel wrote: >Edward O'Connor wrote: >> If the intent is simply to document the existing, legacy >> technologies that rely on such URLs (such as robots.txt), >> that seems reasonable to me. > >I'd be interested in documenting [1] them . > >Does anyone of any other initiatives to define Well Known Names besides >these:? > > http://mysite.foo/robots.txt > http://mysite.foo/favicon.ico > http://mysite.foo/w3c/p3p.xml > http://mysite.foo/sitemap.xml > http://mysite.foo/crossdomain.xml > http://mysite.foo/smbmeta.xml You could add: http://mysite.foo/siteinfo.xml although whether that's "well-known" is a matter of terminology, given that few people have actually heard of it. It seems that the SiteInfo 'standard' as proposed at: http://a9.com/-/company/help/siteinfo/ is quietly dying, and the A9 SiteInfo plug-in is no longer maintained. Which may or may not be regrettable: I quite like the idea, but it can be seen as just one more piece of clutter in your root directory. Angus From brian.suda at gmail.com Sun Mar 4 08:11:41 2007 From: brian.suda at gmail.com (Brian Suda) Date: Sun Mar 4 08:11:44 2007 Subject: [uf-discuss] Re: "Well-known" URLs In-Reply-To: <024c01c75e2f$389dad80$0702a8c0@Guides.local> References: <861wkxwlt5.fsf@rakim.cfhp.org> <024c01c75e2f$389dad80$0702a8c0@Guides.local> Message-ID: <21e770780703040811q5593fc34n2f821f47b6e84aed@mail.gmail.com> On 3/4/07, Mike Schinkel wrote: > Does anyone of any other initiatives to define Well Known Names besides > these:? > > .... > http://mysite.foo/sitemap.xml According to the sitemap.org site i found this reference: http://www.sitemaps.org/faq.html#faq_sitemap_location It doesn't really say that the filename HAS to be sitemap.org, search engines (may or maynot be crawling for a specific filename), but it looks like you submit the URL to your sitemap.xml file. http://www.sitemaps.org/faq.html#faq_after_submission i'm not sure if you are documenting practices or specifications? The favicon path and name can be overwritten by the LINK element: http://en.wikipedia.org/wiki/Favicon but versions of IE do not honor this and look for favicon.ico. Infact it doesn't need to be .ico format at all. -brian -- brian suda http://suda.co.uk From ryan at ryancannon.com Sun Mar 4 13:06:58 2007 From: ryan at ryancannon.com (Ryan Cannon) Date: Sun Mar 4 13:07:05 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: <200703040814.l248Emd2011779@microformats.org> References: <200703040814.l248Emd2011779@microformats.org> Message-ID: <0BFB19BB-396C-4877-B4A2-0705B7DBD2C2@ryancannon.com> On Mar 4, 2007, at 3:14 AM, Mike Schinkel wrote: > Danny Ayers wrote: >> if adding a profile >> attribute is hard for webmasters, the right answer is to >> make it easier rather than working around its absence. >> The of a HTML document is an important part of the >> chain of authoritative metadata [1]. > > ... Taking such a position is completely impractical because of the > proliferation of blogs, wikis, and cms that empower users to > publish content > with no access to the . Access may be denyed because the > content > publisher [for a number of legitimate reasons]. > > You could say "Well the answer then is to get all the developers of > all > those apps to provide the content publishers access to the > and then > get all the existing apps in the field replaced with the new > versions!" > However, I think you'll agree that requiring such an approach is > impractical > when it is possible to craft a workaround. Adding an @profile attribute to he element is far less technically demanding than, say, creating a tag space, which we also require. Especially as the addition also has no performance or usability impact. I also think that authoring microformats with the intent that they be usable to the CMS-using/WYSIWG masses is a pipe dream. Users should *not* be encouraged to publish HTML markup they cannot read. Robust microformatted content will always require either an understanding of how to hand-code HTML or a tool to help generate it--is it unreasonable to think that the meeting of either condition implies the ability to add an @profile as well for 80% of cases? -- Ryan Cannon Interactive Developer MSI Student, School of Information University of Michigan http://RyanCannon.com From andy at pigsonthewing.org.uk Sun Mar 4 02:49:49 2007 From: andy at pigsonthewing.org.uk (Andy Mabbett) Date: Sun Mar 4 13:36:05 2007 Subject: [uf-discuss] Re: "Well-known" URLs In-Reply-To: <024c01c75e2f$389dad80$0702a8c0@Guides.local> References: <861wkxwlt5.fsf@rakim.cfhp.org> <024c01c75e2f$389dad80$0702a8c0@Guides.local> Message-ID: In message <024c01c75e2f$389dad80$0702a8c0@Guides.local>, Mike Schinkel writes >Does anyone of any other initiatives to define Well Known Names http://exmaple.com/delorie.htm (see ) http://exmaple.com/opensearch.xml http://exmaple.com/siteinfo.xml http://exmaple.com/sitemap.xml all the above in use on . >http://mysite.foo/ Please use "http://example.com" for example URLs - it's specifically reserved for that purpose. -- Andy Mabbett Welcome to the world's longest week! From ml at creativecommons.org Sun Mar 4 13:56:33 2007 From: ml at creativecommons.org (Mike Linksvayer) Date: Sun Mar 4 13:56:37 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: <0BFB19BB-396C-4877-B4A2-0705B7DBD2C2@ryancannon.com> References: <200703040814.l248Emd2011779@microformats.org> <0BFB19BB-396C-4877-B4A2-0705B7DBD2C2@ryancannon.com> Message-ID: <1173045393.6467.206.camel@localhost.localdomain> On Sun, 2007-03-04 at 16:06 -0500, Ryan Cannon wrote: > Adding an @profile attribute to he element is far less > technically > demanding than, say, creating a tag space, which we also require. > Especially as > the addition also has no performance or usability impact. But one doesn't need to create a tag space to use rel-tag; it isn't even a best practice. > I also think that authoring microformats with the intent that they be > usable > to the CMS-using/WYSIWG masses is a pipe dream. Users should *not* be > encouraged > to publish HTML markup they cannot read. Robust microformatted content > will always require either an understanding of how to hand-code HTML > or a tool > to help generate it-- Though hand-coding elemental microformats is within reach of many of the CMS-using masses. > is it unreasonable to think that the meeting of > either > condition implies the ability to add an @profile as well for 80% of > cases? Perhaps the ability to add a single @profile URL. If I were a CMS developer I would not want to introspect the page, possibly assembled by various modules, before outputting the head, though if there were some tangible benefit to doing so I would add a profile-used(profile-uri) callback. -- http://wiki.creativecommons.org/User:Mike_Linksvayer From john at westciv.com Sun Mar 4 15:13:53 2007 From: john at westciv.com (John Allsopp) Date: Sun Mar 4 15:14:15 2007 Subject: [uf-discuss] "authoritative hCards", a simpler proposl In-Reply-To: <022d01c75e1b$771a78e0$0702a8c0@Guides.local> References: <022d01c75e1b$771a78e0$0702a8c0@Guides.local> Message-ID: <6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> Hi all, Mike Schinkel wrote: > Ryan King wrote: >> Catching up in the last few days, I find that there are some >> probelems with the "authoritative hcards" proposals. I' >> >> >> >> My proposal is that we use UID+URL to hint that there's an >> hCard on the other end of that URL which represents the same >> entity. Also, multiple hCards with the same UID may be >> considered as representing the same entity. > > In reviewing this I can't help but feel that I don't understand the > use-case > or the desired outcome. Will someone kindly explain? Is it that > there > could be hundreds of hCards on the web for Ryan King (the one for > the guy > who has the email address of [ryan@technorati.com]) but only one > should be > considered 'authoritative?" A number of somewhat overlapping suggestions seem to be floating around regarding this. There is definitely a strong use case, IMO, for somehow indicating that some hCard over there is a more detailed version of this one. For example, at the various conference sites I am involved wiht, we mark up all speakers using hCard. Ofen it's simply John Allsopp Now, if this could point at an hCard with more information about the speaker so marked up, to me that would be potentially very useful for something like Tails or Operator to pull in that additional information, or for aggregating references to the same person and on. As to definitiveness or authoriativeness, I think that's a tougher nut to crack. j From mdagn at spraci.com Mon Mar 5 11:53:40 2007 From: mdagn at spraci.com (Michael MD) Date: Sun Mar 4 16:53:12 2007 Subject: [uf-discuss] Scraping or parsing? References: <200703040814.l248Emd2011779@microformats.org> <0BFB19BB-396C-4877-B4A2-0705B7DBD2C2@ryancannon.com> Message-ID: <001201c75f5f$fe041240$116bacca@COMCEN> >Users should *not* be > encouraged > to publish HTML markup they cannot read. That been happening out there in the real world with html for years with wysiwyg editors! ... and the fact that some of them generate bad or bloated markup is not going to stop the masses from using them. Personally I think it would be nice to see authoring tools for microformats built into wysiwyg editors .... I'm sure its coming soon... - I even had a go last year at modifying a javascript-based html editor to auto-detect hcards and vevents and allow authoring and editing of them with simple forms but decided I needed to learn to optimize javascript better first (it was way too slow!) ... anything designed for "the masses" to use must be fast enough to for an impatient person on an old slow machine! From mikeschinkel at gmail.com Sun Mar 4 17:08:12 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 17:08:16 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: <0BFB19BB-396C-4877-B4A2-0705B7DBD2C2@ryancannon.com> References: <200703040814.l248Emd2011779@microformats.org> <0BFB19BB-396C-4877-B4A2-0705B7DBD2C2@ryancannon.com> Message-ID: <008501c75ec2$bf8be030$2102fea9@Guides.local> Ryan Cannon wrote: > Adding an @profile attribute to he element is far > less technically demanding than, say, creating a tag > space, which we also require. Especially as the addition > also has no performance or usability impact. It may be less technically demanding, but the latter is needed. > I also think that authoring microformats with the intent > that they be usable to the CMS-using/WYSIWG masses is a > pipe dream. Users should *not* be encouraged to publish > HTML markup they cannot read. Robust microformatted > content will always require either an understanding of > how to hand-code HTML or a tool to help generate it--is > it unreasonable to think that the meeting of either > condition implies the ability to add an @profile as well > for 80% of cases? I cannot overemphasis how strongly I disagree with that last paragraph from a philosophical standpoint, for two reasons: 1.) There are two schools of thinking, one of which I believe to be severely flawed: A.) Don't worry about the syntax or how it is implemented, the tools will take care of make it easy. B.) Don't even think about tools until it can be done and easily understood by a human. Only then should tools be created. Of course I strongly believe that "A" is the flaw perspective although I know there are many people in that camp, you (it appears) included. I plan to write a paper in the future on this issue after I've done enough research and gathered actual evidence but for now let's look at the technologies that have gained quick and *widespread* usage (a), and those that haven't (b): (a) HTML, RSS, CSS, XML, some microformats, shell scripts/batch files, languages using text for source, and so on. (b) XHTML, XML Namespaces, XSLT, RDF, other microformats, Visual programming languages, and so on. Yes, through some Herculean efforts some of the technologies in (b) have seen adoption, but not without tons of promotion by some entity with vested interests. The technologies that work are the ones that are designed for humans first, with humans with tools second. If it can't be done in Notepad or VIM, it's probably a bad idea. 2.) I also believe strongly that we should not dichotomize the population and split them into the haves and the have-nots; the party members and the proles, the Alphas and the Epsilons. Believing that there is or should be a difference between "users" and "content authors" is either simply ignorant or actively arrogant. The web with its recent social media component has empowered EVERYONE to become content authors, and I don't honestly see this abating. My expectation is that soon every kid from a first world country (and soon every kid in the world, if OLPC succeeds) will be as comfortable coding in HTML as today's office worker is comfortable using Microsoft Word. And if you'll forgive the tinge of melodrama, by you seeking to repress people's ability to richly author content you are in a small way working to put limits on "users" freedom of speech. I personally will fight anyone whose world view attempts to separate those who are anointed as being "better" and mere "users" where the "better" ones are the only ones who are going to get to publish rich content on the Internet, everyone else be damned. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." From karl at w3.org Sun Mar 4 18:12:16 2007 From: karl at w3.org (Karl Dubost) Date: Sun Mar 4 18:13:00 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: <008501c75ec2$bf8be030$2102fea9@Guides.local> References: <200703040814.l248Emd2011779@microformats.org> <0BFB19BB-396C-4877-B4A2-0705B7DBD2C2@ryancannon.com> <008501c75ec2$bf8be030$2102fea9@Guides.local> Message-ID: Le 5 mars 2007 ? 10:08, Mike Schinkel a ?crit : > 1.) There are two schools of thinking, one of which I believe to be > severely > flawed: IMHO, more than that. :) as there are nuances in between. > A.) Don't worry about the syntax or how it is implemented, the tools > will take care of make it easy. > B.) Don't even think about tools until it can be done and easily > understood by a human. Only then should tools be created. > Of course I strongly believe that "A" is the flaw perspective > although I > know there are many people in that camp, you (it appears) included. still, it depends on the context. All is a question of context. > The technologies that work are the ones that are designed for > humans first, > with humans with tools second. If it can't be done in Notepad or > VIM, it's > probably a bad idea. png, jpeg, gif, illustrator files, pdf, videos format? But you might say that they are difficult formats, so what about email, usenet, chat messenging, irc. How many of us are editing the simple headers of emails by hand? :) It doesn't make your point invalid, it is just that it is not black and white :) It depends on the context and the way the technology has been developed, and its level of maturity. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** From mikeschinkel at gmail.com Sun Mar 4 18:31:51 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 18:32:08 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: References: <200703040814.l248Emd2011779@microformats.org><0BFB19BB-396C-4877-B4A2-0705B7DBD2C2@ryancannon.com><008501c75ec2$bf8be030$2102fea9@Guides.local> Message-ID: <008c01c75ece$7722c5f0$2102fea9@Guides.local> Karl Dubost wrote: > There are two schools of thinking, one of which I believe > to be severely flawed: > > IMHO, more than that. :) as there are nuances in between. True. > > A.) Don't worry about the syntax or how it is > > implemented, the tools will take care of make it easy. > > B.) Don't even think about tools until it can be done > > and easily understood by a human. Only then should > > tools be created. > > > > Of course I strongly believe that "A" is the flaw > > perspective although I know there are many people in > > that camp, you (it appears) included. > > > still, it depends on the context. All is a question of > context. I'll reserve my opinion for each context until its use-case is presented to me. :) > > The technologies that work are the ones that are > > designed for humans first, with humans with tools > > second. If it can't be done in Notepad or VIM, it's > > probably a bad idea. > > > png, jpeg, gif, illustrator files, pdf, videos format? I'll give you those, but there is something fundamentally different about them, i.e. they are for visual presentation not logic and data encoding. And there is SVG. Still, I have to ponder why tools have worked there but not elsewhere. It could be simply because their level of complexity in text would be far beyond what a human could comprehend. > But you might say that they are difficult formats, so > what about email, usenet, chat messenging, irc. How many > of us are editing the simple headers of emails by hand? > :) Ah, but I would argue they were *first* a format that did not require tools for humans easily to understand, and later tools were added. I don't complain about tools, on the contrary I like them. I just think the underlying format should not be forgiven its complexity because of a faint hope that future tools that will make everything alright. > It doesn't make your point invalid, it is just that it is > not black and white :) heh. For someone who generally never sees anything but shades of grey, I certainly would be a hypocrite if I were to disagree with you there! :) > It depends on the context and the > way the technology has been developed, and its level of > maturity. But wouldn't you agree, people tend to use the promise of a tool as a crutch when they should instead strive to make things in the raw grokable by humans first? -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." From mikeschinkel at gmail.com Sun Mar 4 18:36:52 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 18:36:56 2007 Subject: [uf-discuss] Re: "Well-known" URLs In-Reply-To: <21e770780703040811q5593fc34n2f821f47b6e84aed@mail.gmail.com> References: <861wkxwlt5.fsf@rakim.cfhp.org><024c01c75e2f$389dad80$0702a8c0@Guides.local> <21e770780703040811q5593fc34n2f821f47b6e84aed@mail.gmail.com> Message-ID: <008d01c75ecf$220395d0$2102fea9@Guides.local> Brian Suda wrote: > It doesn't really say that the filename HAS to be > sitemap.org, search engines (may or maynot be crawling > for a specific filename), but it looks like you submit > the URL to your sitemap.xml file. > > http://www.sitemaps.org/faq.html#faq_after_submission > > i'm not sure if you are documenting practices or > specifications? Er, I was just creating a list of known "well-known names", but I wasn't being all that exacting about it. I could segment the page or set up a table to indicate the difference which I might do in the future but not now. OTOH, it *is* on a wiki so you are more than welcome to help and update it! :-) :-) :-) > The favicon path and name can be overwritten by the LINK > element: http://en.wikipedia.org/wiki/Favicon > > but versions of IE do not honor this and look for > favicon.ico. Infact it doesn't need to be .ico format at > all. Hehe. Gotta love ya, MS! ;-P -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." From mikeschinkel at gmail.com Sun Mar 4 18:52:39 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 18:52:45 2007 Subject: [uf-discuss] Re: "Well-known" URLs In-Reply-To: References: <861wkxwlt5.fsf@rakim.cfhp.org><024c01c75e2f$389dad80$0702a8c0@Guides.local> Message-ID: <008f01c75ed1$569af480$2102fea9@Guides.local> Angus McIntyre wrote: > You could add: > > http://mysite.foo/siteinfo.xml > > although whether that's "well-known" is a matter of > terminology, given that few people have actually heard of > it. It seems that the SiteInfo 'standard' as proposed at: > > http://a9.com/-/company/help/siteinfo/ > > is quietly dying, and the A9 SiteInfo plug-in is no > longer maintained. Which may or may not be regrettable: I > quite like the idea, but it can be seen as just one more > piece of clutter in your root directory. Thanks. Don't know why that didn't cross my mind. I just first read about it last week! -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." From mikeschinkel at gmail.com Sun Mar 4 20:05:40 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 20:05:45 2007 Subject: [uf-discuss] "authoritative hCards", a simpler proposl In-Reply-To: <6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> References: <022d01c75e1b$771a78e0$0702a8c0@Guides.local> <6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> Message-ID: <00c801c75edb$8a0aa270$2102fea9@Guides.local> John Allsopp wrote: > A number of somewhat overlapping suggestions seem to be > floating around regarding this. > > There is definitely a strong use case, IMO, for somehow > indicating that some hCard over there is a more detailed > version of this one. > > For example, at the various conference sites I am > involved wiht, we mark up all speakers using hCard. Ofen > it's simply > > class="url fn">John Allsopp > > Now, if this could point at an hCard with more > information about the speaker so marked up, to me that > would be potentially very useful for something like Tails > or Operator to pull in that additional information, or > for aggregating references to the same person and on. > > As to definitiveness or authoriativeness, I think that's > a tougher nut to crack. Thanks for the clarification. In reading the threads I didn't get the part about including a URL in an hCard to point to another hCard. That is helpful. OTOH I think (as you imply) this discussion might be attempting to use a pickaxe to resolve a problem that requires a bulldozer. Or said another way, trying to resolve a problem whose proper solution lies in a different domain. I've actually recently been thinking about a related question. i.e. what is a person's canonical URL? Google "Roy T. Fielding", "Bill Gates", "Linus Torvalds", or even "John Allsopp" or "Mike Schinkel" and tell me which URL is the canonical URL? I've been planning to blog about this for weeks. Do you, or anyone, have a proposed solution to this dillema? Basically the problem is simplified as "What URL identifies a person, and more importantly, how does someone who doesn't know that person or can't reach that person to ask be able to find it?" And, being an advocate for "Well Designed URLs", I do not think the right solution is to simply tag a random and undiscoverable and unmemorizable UID onto the end of a URL. But I'd have to understand the problem domain and use-cases to be better able to make an alternate proposal. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." From mikeschinkel at gmail.com Sun Mar 4 20:26:25 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 20:26:30 2007 Subject: [uf-discuss] Re: "Well-known" URLs In-Reply-To: References: <861wkxwlt5.fsf@rakim.cfhp.org><024c01c75e2f$389dad80$0702a8c0@Guides.local> Message-ID: <00c901c75ede$70304230$2102fea9@Guides.local> Andy Mabbett wrote: > http://exmaple.com/delorie.htm > (see > ) I read the info about it I found while googling but I'm not sure I'm clear. Is it saying that Opera will look for a page called "/delorie.htm" on the current domain? > http://exmaple.com/opensearch.xml Thanks. I knew about that one too. Not sure why I didn't think of it earlier. > >http://mysite.foo/ > > Please use "http://example.com" for example URLs - it's > specifically reserved for that purpose. I was not aware of [1], as evidenced by my proactive use of mysite.foo [2]. Still, one problem with using example.{tld} is it makes it confusing when your example uses two sites, i.e. mysite.foo vs yoursite.foo is clearer than example.com vs. example.net. BTW, is http://exmaple.com also reserved too? ;-) -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." [1] http://en.wikipedia.org/wiki/Example.com [2] http://blog.welldesignedurls.org/2007/03/01/urlquiz-2-url-equivalence-and-ca chability/#footnotes-20070301 From karl at w3.org Sun Mar 4 20:40:28 2007 From: karl at w3.org (Karl Dubost) Date: Sun Mar 4 20:41:08 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: <008c01c75ece$7722c5f0$2102fea9@Guides.local> References: <200703040814.l248Emd2011779@microformats.org><0BFB19BB-396C-4877-B4A2-0705B7DBD2C2@ryancannon.com><008501c75ec2$bf8be030$2102fea9@Guides.local> <008c01c75ece$7722c5f0$2102fea9@Guides.local> Message-ID: Le 5 mars 2007 ? 11:31, Mike Schinkel a ?crit : >> png, jpeg, gif, illustrator files, pdf, videos format? > > I'll give you those, but there is something fundamentally different > about > them, i.e. they are for visual presentation not logic and data > encoding. And > there is SVG. Still, I have to ponder why tools have worked there > but not > elsewhere. It could be simply because their level of complexity in > text > would be far beyond what a human could comprehend. and *pdf* (given in the list) I could have added, vcard, vcalendar, vectorial illustrator. All of those, I do NOT want edit by hands, even if I had the possibility ;) > Ah, but I would argue they were *first* a format that did not > require tools > for humans easily to understand, and later tools were added. I don't > complain about tools, on the contrary I like them. I just think the > underlying format should not be forgiven its complexity because of > a faint > hope that future tools that will make everything alright. >> It depends on the context and the >> way the technology has been developed, and its level of >> maturity. > > But wouldn't you agree, people tend to use the promise of a tool as > a crutch > when they should instead strive to make things in the raw grokable > by humans > first? That is a different issue :) Human is too broad to be meaningful. The goal is really to make a technology which is easy to use depending on the ecosystem. then using the argument that: 1. complexity of the technology is NOT important because there are/ will be tools. 2. simplicity of the technology is a MUST because of "hand authoring". are both flawed, IMHO. I'm really happy penballs exist even if I could use ink with a feather. I'm really happy to have light measurement on my camera, even if I could use my own lightmeter (which I do on a 6x6) I'm really I have not to teach HTML to my parents, and just give them a wysiwyg editor ;) but yes I think we agree. :) -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool *** From scott at randomchaos.com Sun Mar 4 21:25:23 2007 From: scott at randomchaos.com (Scott Reynen) Date: Sun Mar 4 21:25:21 2007 Subject: [uf-discuss] "authoritative hCards", a simpler proposl In-Reply-To: <00c801c75edb$8a0aa270$2102fea9@Guides.local> References: <022d01c75e1b$771a78e0$0702a8c0@Guides.local> <6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> <00c801c75edb$8a0aa270$2102fea9@Guides.local> Message-ID: <52866CCA-A18F-4366-ADA2-23C6421107CC@randomchaos.com> On Mar 4, 2007, at 10:05 PM, Mike Schinkel wrote: > And, being an advocate for "Well Designed URLs", I do not think the > right > solution is to simply tag a random and undiscoverable and > unmemorizable UID > onto the end of a URL. But I'd have to understand the problem > domain and > use-cases to be better able to make an alternate proposal. I think you're still a bit confused about what was suggested. Every URL is already a potential UID, so there's no need to add anything onto the end. URLs are unique, and some of them (e.g. http:// theryanking.com/blog/contact/#vcard) identify people. That's all a UID needs to be: unique and identifying. Many UIDs happen to be random strings of numbers and/or letters, but that's not at all a requirement for UIDs. So the proposal was just to add the UID class name to the URL class name, e.g. Ryan King, not to add anything to the actual URL. Peace, Scott From ara.pehlivanian at gmail.com Sun Mar 4 21:33:15 2007 From: ara.pehlivanian at gmail.com (Ara Pehlivanian) Date: Sun Mar 4 21:33:18 2007 Subject: [uf-discuss] "authoritative hCards", a simpler proposl In-Reply-To: <6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> References: <022d01c75e1b$771a78e0$0702a8c0@Guides.local> <6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> Message-ID: <923a87360703042133t73dc7675keee520f2ced6b823@mail.gmail.com> On 3/4/07, John Allsopp wrote: > Hi all, > > Mike Schinkel wrote: > > > Ryan King wrote: > >> Catching up in the last few days, I find that there are some > >> probelems with the "authoritative hcards" proposals. I' > >> > >> > >> > >> My proposal is that we use UID+URL to hint that there's an > >> hCard on the other end of that URL which represents the same > >> entity. Also, multiple hCards with the same UID may be > >> considered as representing the same entity. > > > > In reviewing this I can't help but feel that I don't understand the > > use-case > > or the desired outcome. Will someone kindly explain? Is it that > > there > > could be hundreds of hCards on the web for Ryan King (the one for > > the guy > > who has the email address of [ryan@technorati.com]) but only one > > should be > > considered 'authoritative?" > > A number of somewhat overlapping suggestions seem to be floating > around regarding this. > > There is definitely a strong use case, IMO, for somehow indicating > that some hCard over there is a more detailed version of this one. > > For example, at the various conference sites I am involved wiht, we > mark up all speakers using hCard. Ofen it's simply > > John Allsopp > > Now, if this could point at an hCard with more information about the > speaker so marked up, to me that would be potentially very useful for > something like Tails or Operator to pull in that additional > information, or for aggregating references to the same person and on. > > As to definitiveness or authoriativeness, I think that's a tougher > nut to crack. > > j > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-discuss > Maybe the problem is that we're trying to point to an authoratative hCard when in reality what we want to do is simply (like you just said) point to a more detailed hCard. That way, if you have a professional hCard set up on your work site you might want to point to that from your conference listing page, but if you have a personal one set up as well you might want to point to IT from a personal site somewhere. Managing "authoritative" relationships between cards seems to be more hassle than it's worth. Simply pointing to a more detailed card could be the solution. So for example, the rule could simply be that the anchor with class="url" found inside the hCard will point to a more detailed hCard should it have a direct reference to an ID. In other words the following example would be pointing to a more detailed hCard: John Allsopp The moment the ID is provided, it indicates that the link isn't just pointing to any old resource on the web, but that it is in fact pointing to a more detailed hCard. The only problem that I can see with this model is that you might not want your hyperlink dropping to the hCard's location when it's clicked. A. From mikeschinkel at gmail.com Sun Mar 4 21:54:58 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 21:55:14 2007 Subject: [uf-discuss] Scraping or parsing? References: <200703040814.l248Emd2011779@microformats.org> <0BFB19BB-396C-4877-B4A2-0705B7DBD2C2@ryancannon.com> Message-ID: <00d501c75eea$ced1c280$2102fea9@Guides.local> Karl Dubost wrote: > > I'll give you those, but there is something > > fundamentally different about them, i.e. they are for > > visual presentation not logic and data encoding. And > > there is SVG. Still, I have to ponder why tools have > > worked there but not elsewhere. It could be simply > > because their level of complexity in text would be far > > beyond what a human could comprehend. > > > and *pdf* (given in the list) I could have added, vcard, > vcalendar, vectorial illustrator. All of those, I do NOT > want edit by hands, even if I had the possibility ;) It's not about wanting to or not wanting to, it's about being able to. And just because some people want to use tools not all want to, so being able to is very important. vcard is easy to edit by hand, if need be. Same with vcalendar. What's more, both of those are generallyfgenerator or exported as opposed to authored. Also, being able to comprehend when reading and also being able to author by hand makes it is much easier for people to write code that generates the format. The easier that is, the more conforming implementations there will be. So I come back to my central thesis; design for humans first (even if those humans are programmers), build tools second. > > But wouldn't you agree, people tend to use the promise > > of a tool as a crutch when they should instead strive > > to make things in the raw grokable by humans first? > > > That is a different issue :) Human is too broad to be > meaningful. Is it a different issue? At least not closely interlinked? > Human is too broad to be meaningful. I think Wikipedia does a pretty good job [1]. ;-) > The goal is really to make a technology which is easy > to use depending on the ecosystem. > then using the argument that: 1. complexity of the > technology is NOT important because there are/ will be > tools. 2. simplicity of the technology is a MUST because > of "hand authoring". are both flawed, IMHO. But you are twisting my words. I said: B.) Don't even think about tools until it can be done and easily understood by a human. Only then should tools be created. So I didn't say 'a MUST because of "hand authoring"'; I said it needs to be understandable by humans. :) Of course I did imply handauthoring be accessible, and stand behind that. But unless you are just picking nits, I don't think that is flawed. > I'm really happy penballs exist even if I could use ink > with a feather. I'm really happy to have light > measurement on my camera, even if I could use my own > lightmeter (which I do on a 6x6) Different domains. Apples and oranges. I'm talking in the domain where instructions for computer processing are given. > I'm really I have not to teach HTML to > my parents, and just give them a wysiwyg > editor ;) Frankly, I'd rather teach a man to fish instead of having to fish for them all the time. I *did* teach my dad HTML so he'd quit asking me why the damn WYSIWYG editor kept screwing up his preferred layout and wouldn't let him fix it. But maybe that's just the former programming instructor in me... And 15 years later, I've yet to see an HTML editor that will allow me the same level of control of *output* (I'm not even talking control of markup) that I can get with a simple notepad (Even MS Word is infuriating in that respect albeit only someone ignorant of its excesses would use it to generate HTML for web publishing.) Yes, I'd rather have the WYSIWYG, but only if it comes w/o the frustrating limitations. Which is why I still do most of my editing on Notepad (well, Notepad2 that is.) > but yes I think we agree. :) You do enjoy being pedantic, don't you? ;-) -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." [1] http://en.wikipedia.org/wiki/Human From mikeschinkel at gmail.com Sun Mar 4 22:20:52 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 22:20:56 2007 Subject: [uf-discuss] "authoritative hCards", a simpler proposl In-Reply-To: <52866CCA-A18F-4366-ADA2-23C6421107CC@randomchaos.com> References: <022d01c75e1b$771a78e0$0702a8c0@Guides.local><6574D3E7-04B0-4824-A035-F450140B394B@westciv.com><00c801c75edb$8a0aa270$2102fea9@Guides.local> <52866CCA-A18F-4366-ADA2-23C6421107CC@randomchaos.com> Message-ID: <00da01c75eee$6cea72c0$2102fea9@Guides.local> Scott Reynen wrote: > I think you're still a bit confused about what was > suggested. Indeed I was confused. I could have sworn I saw some kind of usage that tagged a GUID on the end of a URL, which is what confused me, but I can't seem to find that email in my folders so, not important. Thanks for the clarification. > Many UIDs happen to be random strings of numbers and/or > letters, but that's not at all a requirement for UIDs. And I hope, something that would be frowned on! > So the proposal was just to add the UID class name to the > URL class name, e.g. Ryan King, not > to add anything to the actual URL. Cool! -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." From mikeschinkel at gmail.com Sun Mar 4 22:25:52 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 22:25:55 2007 Subject: [uf-discuss] "authoritative hCards", a simpler proposl In-Reply-To: <923a87360703042133t73dc7675keee520f2ced6b823@mail.gmail.com> References: <022d01c75e1b$771a78e0$0702a8c0@Guides.local><6574D3E7-04B0-4824-A035-F450140B394B@westciv.com> <923a87360703042133t73dc7675keee520f2ced6b823@mail.gmail.com> Message-ID: <00db01c75eef$1feba4c0$2102fea9@Guides.local> Ara Pehlivanian wrote: > Maybe the problem is that we're trying to point to an > authoratative hCard when in reality what we want to do is > simply (like you just said) point to a more detailed > hCard. > > > > The moment the ID is provided, it indicates that the link > isn't just pointing to any old resource on the web, but > that it is in fact pointing to a more detailed hCard. I think that makes a huge amount of sense. Determining authoritativeness is hard, leave it to another initiative and get almost everything else needed w/o it. Great suggestion. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." From mikeschinkel at gmail.com Sun Mar 4 23:22:47 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Sun Mar 4 23:22:50 2007 Subject: [uf-discuss] Re: "Well-known" URLs In-Reply-To: References: <861wkxwlt5.fsf@rakim.cfhp.org><024c01c75e2f$389dad80$0702a8c0@Guides.local> Message-ID: <00e301c75ef7$13223350$2102fea9@Guides.local> Andy Mabbett wrote: > http://exmaple.com/opensearch.xml I just researched this and it appears that Amazon/A9 are *not* using Well-Known Names but instead using autodiscovery on a element[1]. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." [1] http://www.opensearch.org/Specifications/OpenSearch/1.1#Autodiscovery From danny.ayers at gmail.com Mon Mar 5 03:31:26 2007 From: danny.ayers at gmail.com (Danny Ayers) Date: Mon Mar 5 03:31:40 2007 Subject: [uf-discuss] Microformat tools bogosity test Message-ID: <1f2ed5cd0703050331u7fb90da0g2f2f3fbc2a9afd@mail.gmail.com> Thought this might be useful: http://dannyayers.com/misc/microformats/soupdragon Cheers, Danny. -- http://dannyayers.com From ryan at technorati.com Mon Mar 5 10:29:46 2007 From: ryan at technorati.com (Ryan King) Date: Mon Mar 5 10:29:52 2007 Subject: [uf-discuss] Identity-related hCards? In-Reply-To: <004501c75c72$14334540$0301a8c0@andrieuhome> References: <004501c75c72$14334540$0301a8c0@andrieuhome> Message-ID: <771E2C3C-1F2A-4F30-ABB6-ECB3DFA98BAC@technorati.com> On Mar 1, 2007, at 6:25 PM, Joe Andrieu wrote: > Ryan King wrote: >> On Feb 20, 2007, at 12:23 PM, Scott Reynen wrote: >>> And maybe that's because what you're describing is actually more >>> specific that "related hCards" implies. It seems here you're just >>> talking about a single relationship: identity. >> >> Yes. You're exactly right. I'm afraid I haven't been that >> clear. When >> I say "related hCards" I mean related in that they represent >> the same >> person or organization. I've been using "related hCards" as >> shorthand >> for "hCards that represent the same person or organization", which I >> now realize must be confusing. (but it seemed so clear in my >> head! :D) > > Ryan, > > That made me laugh out loud. I was definitely responding to uid > +url as non-identity relations earlier and it seemed perfectly clear > in my head as well. =) > > So, don't equal UIDs already imply identitical hCards? No. Per the RFC, UID identifies the entity represented by the vCard or hCard [1]. > In other words, what I think we've really been discussing is how to > discover hCards for identical entities, using either URL or > SOURCE (or "via", although I think SOURCE is much better). Exactly. > Frankly, it seems like it would work if it SHOULD be expected that > consume apps MAY use URL and/or SOURCE to look for identical > hCards. > > I believe this approach allows both uid+url and uid+source to link > to "related" and/or "sourcing" hCards without any of further > restrictions on the UID. I don't see any reason why source can't be used as well as url+uid. They signify different semantics, but are both already a part of the format. They only thing we need to figure out with SOURCE is what consuming applications that convert to vCard (like X2V) should do. Should they take the SOURCE value from the hCard or should they use the URL of the hCard (as X2V currently does). -ryan 1. From section 3.6.7 of RFC 2426 (http://www.ietf.org/rfc/rfc2426.txt): Type purpose: To specify a value that represents a globally unique identifier corresponding to the individual or resource associated with the vCard. ... Type special notes: The type is used to uniquely identify the object that the vCard represents. -- Ryan King ryan@technorati.com From ryan at technorati.com Mon Mar 5 11:26:25 2007 From: ryan at technorati.com (Ryan King) Date: Mon Mar 5 11:26:30 2007 Subject: [uf-discuss] "related" hcards [was VIA or VIA SELF to indicateauthoritativehCard[was:UID URL to indicate (relatively)moreauthoritativehCard...]] In-Reply-To: <003901c7572f$2fd535d0$0301a8c0@andrieuhome> References: <003901c7572f$2fd535d0$0301a8c0@andrieuhome> Message-ID: <071BF304-F819-4E71-8016-B18924DA73A9@technorati.com> On Feb 23, 2007, at 1:44 AM, Joe Andrieu wrote: > Ryan King wrote: >> I understand this. I agree that this is a desirable goal. I would >> personally like to see it happen. However, the simpler >> problem of two >> hcards representing the same person (or organization) should be >> solved first, because it is a simpler problem, with a simpler >> solution (which may not require adding any properties to hCard). > > If all you want to do is have two hCards represent the same entity, > why not just use the same UID? > > I think I understand that it is to traverse the network to discover > multiple, "synonymous" hCards for the same entity? That what you > want is not just synonymity, but discoverable synonymity. Is that > correct? Yes. The nice thing about URLs is that you can dereference them and consume the resource returned. > RFC2426 [1] (the vCard spec incorporated by reference into hCard) > specifies the URL type use as: > To specify a uniform resource locator associated with > the object that the vCard refers to. > > Your algorithm was: >> 1. if no uid or uid == the uid from the previous >> iteration/recursion => you're done >> >> 2. if url == uid and there's an hCard at that url, >> recurse with the new hCard > > In that case, what you are saying is that if the UID is the same as > the URL, one should expect to be able to assume a common > relationship between this hCard and any hCard with either no UID or > a matching UID at the URL for this hCard. > > Here's what seems to fail in this usage: > 1. Referrees without UID match any referring hCard > 2. Ambiguous relation when multiple hCards are present at URL > 3. UIDs that are XRIs and not URLs > 4. UIDs that are not URLs, generally. > > 1. Referrees without UID match any referring hCard > If the referred to hCard has no UID, the algorithm assumes > "relatedness", but that seems dubious at best without a confirming > UID. I agree. It is a bit dubious. This might be something that's left to consuming applications to decide. > 2. Ambiguous relation when multiple hCards are present at URL > If the referred to URL has multiple hCards, each with no UID, there > is no way to disambiguate which one(s) should be "related." > > So... Refering card: > > Mr. Andrieu > http://www.andrieu.net > > > While on Andrieu.net we might have multiple hCards > > Joe Andrieu > > > Julia Andrieu > > > Mike Andrieu > > > Maureen Andrieu > > > Who is "Mr. Andrieu"? > > This is even more likely to occur when we accept the dynamic nature > of the web and the inevitable consistency errors of > less-than-perfect data maintenance. It seems to me that relating > only cards with common UIDs makes a lot of sense. One option here would be to only take hCards in an

. Of course that doesn't apply in your example, but it would work in some real world examples (like http://theryanking.com/blog/). > 3. UIDs that are XRIs and not URLs > > With the use of OpenID as UID, do we extend the field URL to > include XRIs? This may or may not make sense, but stuffing an XRI > into > a URL/URI is out of spec unless the spec changes to allow it. XRIs > are designed to replace URIs, but plenty of consuming > applications break today if you try that. > > 4. UIDs that are not URLs > I stand by the argument that UIDs that are not URLs should be > viable in any mainstream use of any microformat. Your bias towards > URLs as UIDs shouldn't limit people's use of UIDs with alternate > formats, such as XRIs. If we feel strongly about such a bias, as a > community, we should change the hCard spec to require UIDs as > URLs. XRIs as UIDs is just /one/ example where I think the evidence > is overwhelmingly clear that there is technical acceptance and > solid reasoning for UIDs that are not URLs. Now, we could change the > definition of "URL" to include "XRIs", but I think we are better > off accepting that we cannot predict the future, nor should we > presume that URLs are the only good UID unless we are willing to > make that a requirement in the spec. And frankly, that would put > our definition of URL at odds with RFC for URLs.[2] The spec uses > "should" for good reason. It is because of that *should* that XRI > UIDs are 100% compliant with hCard /today/ without redefining the > spec. That's a good thing. Making URL UIDs a requirement for > discovering synonymous hCards seems arbitrarily limiting with > minimal payoff. > > Items 1 & 2 could be trivially addressed by simply modifying your > algorithm to require that the UID of the /referred to/ hCard match > the UID of the referring hCard for anything to work. So they aren't > major issues. (And it is clear that in the brevity of your > algorithm, you didn't say termination assumed "relatedness", so 1&2 > aren't all that important.) > > However, non-URL UIDs, as exemplified by XRIs as UIDs is a > fundamental problem that you have not satisfactorily addressed > other than > by asserting >> What better UID is there than a URL? > > You also stated: >> Indeed, in vcard UID is just a string, but my proposal is that we >> make it by default a URL. It's a simple change (which may already be >> implemented in X2V). You're right, I think UIDs should be URIs, but they don't have to be. I think the hCard spec should specify that UIDs be parsed as URLs, but that doesn't mean you *must* use a URI. For example, this would work just fine: this is not a URI Just don't put the XRI in an a@href, img@src, object@data or area@href. > Your disposition is clearly yours, not what the spec reflects, and > you have yet to make a solid case for it, much less secured > community support for changing to that default. I referred to your > disposition as a religious belief not to insult you, but to > clarify that is an assertion of your presumptive belief. From your > arguments, I have nothing but your faith in URLs as UIDs, no > evidentiary arguments have been presented. If the core of your > argument is that UIDs are supposed to be URLs, that is a completely > different proposal than both this thread and the originating thread > (canonical hCards) is talking about. > > You later stated: >> Also I'm not saying that UID-as-URI is the "right" way to do things. >> I'm just saying that it's the most useful way to do things." > > For many applications, XRIs are arguably more useful. In fact, I > think XRIs answer your initial question adequately. They are a > better UID than a URL. Your simple assertion of your opinion is a > statement of belief, rather than a compelling argument. My > assertion that XRIs are better is also a statement of belief. > However, there are a lot of other smart people that also disagree on > this topic (in both directions). Debating it here would be off- > topic to say the least. However, the acceptance of the viability of > XRI by a significant community is itself sufficient challenge to > your blanket assertion of the "most usefulness" of URLs as UIDs. > Other UID schemes can be just as useful, perhaps more so. XRIs may be theoretically more useful, but URIs work today in existing implementations. Microformats in general are built upon already-deployed technologies. That's why URIs (especially dereferencable ones) are useful. > Because of that, I strongly feel that requiring UID=URL as the only > vehicle for discovering synonymous hCards is a huge mistake. > More importantly, requiring that UIDs be URLs is a proposal/debate > in, and of itself. It is currently sidetracking this discussion > of how we might relate (potentially authoritative) hCards to each > other. I'm not saying UIDs must be URLs, I'm saying that they should be parsed as such, which included fallback to non-url values. > Instead, I would like to propose that "source" be traversed to > discover synonymous hCards, relying on UIDs for association, without > requiring that source == UID prior to traversal. > > [my apologies if my shifting position seems to undermine my case. I > have learned much discussing this topic and can see why > "via"/"via self" has problems and find "source" to be both in the > vCard spec and suitable for the usage.) > > Again from the vCard RFC: >> If the SOURCE type is present, then its value provides information >> how to find the source for the vCard. > > That seems like what we are looking for. It is not required to be > a URL, but it can be. If a consuming application does not know > how to resolve the source, then it has no way to continue the path > of discovery. That's both reasonable and expected. > > Previously, you objected: >> SOURCE is already used by X2V to indicate the URL at which the >> current hCard is available. I don't think we'd be able to override >> that at this point. > > I respect the work done by Brian Suda and others on X2V, but this > argument doesn't pass the smell test. > > First, I think "the URL at which the current hCard is available" is > exactly what we mean. If a consuming application sets the > source of the contact to where it found it, we have the "authority" > or "relatedness" we are talking about. If the consuming > application is savvy enough, it can follow any "source" it might > find on the page to discover additional information from other, > synonymous hCards. I agree. > Second, I have a hard time believing that modifying the X2V XSLTs > to handle the clarified semantic is an unsolvable problem > /technically/. It may be hard for political reasons I don't > understand, but that is a different issue and I would argue that > shaping specifications based on politics is bad technology > development. I didn't mean to suggest that it was a unsolvable technical problem, but merely a problem of figuring out what the application should do and make sure any changes don't break existing content. > Third, on principle, it seems incredibly arbitrary to make a case > for the spec based on any particular implementation. Just because > the and tags were implemented in Netscape and IE, > respectively, didn't mean that HTML should adopt those > "innovations." Nor should HTML have been limited to table-based > layout just because no browsers had CSS before there was CSS. The > spec should evolve to provide the most coherent, consistent, and > usable foundation for the most compelling applications, it should > not arbitrarily be limited based on existing technology. X2V can be changed. I'm not suggesting that we *don't* change things because existing applications deal with them a certain way, but we need to be very careful not to break existing applications. Perhaps no one depends on the SOURCE returned by X2V. In that case, we can change it rather freely, but, if people depend on it we need to be careful. > And indeed, both of us are suggesting an incredibly minor change to > the extended semantics of a single field to support a particular > use case. URL and SOURCE will still mean basically the same thing > as always. However, an additional implied semantic would enable > discovery of synonymous cards. This seems like an odd item to limit > based on existing XSLT files. > > So, I think uid+url could address problems 1&2 with a modified > algorithm (or perhaps just a clarified one: your algorithm terminated > on no uid, but you didn't say if that implied relatedness). > However, it does not seem capable of addressing non-URL UIDs such as > XRIs, which are acceptable forms of OpenIDs, which are now being > supported as widely by both AOL and Microsoft, two gorrillas who > are making their own cowpaths in this area. As discussed elsewhere > OpenIDs /are/ UIDs. I understand that Microsoft and AOL will be supporting XRIs, however we build microformats based on existing practice on the web. If their support leads to people using XRIs, then it will be useful for us to support. (also, yes, we need to clarify my algorithm. I'm not sure what the answer should be yet, let me think about it.) > In contrast, uid+source, without a requirement that source==uid > addresses all of the above shortcomings of uid+url, including all of > the use cases that uid+url supports, with no new fields added to > hCard. > > So, could you outline in a concise form the fundamental problems > you have with uid+source for related hCards? I don't see any problems other than figuring out what consuming applications who convert to vCard should do with SOURCE. -ryan -- Ryan King ryan@technorati.com From tdrake at yahoo-inc.com Mon Mar 5 13:23:18 2007 From: tdrake at yahoo-inc.com (Ted Drake) Date: Mon Mar 5 13:23:27 2007 Subject: [uf-discuss] hrecipe prototype Message-ID: <00e801c75f6c$7e5f4cf0$a7dd15ac@ds.corp.yahoo.com> Hi All I created a mockup of a Yahoo! Food page with a prototype of an hrecipe format for last quarter?s Yahoo Hack Day. Is there a group working on the hrecipe microformat? I?d like to pass the coding on to the group for consideration. P.S.? Yahoo! Tech is hiring a good Front End Engineer. If you are looking for a new job and know CSS, JS, PHP, XML, and Microformats, send me an email off list to tdrake@yahoo-inc.com. Sorry for the spam. Ted Drake Yahoo! Tech? - Tech Made Easy Member of the Yahoo! Accessibility Stakeholders?Group ? Enable Your Audience Are you serving the 55 millon kids and adults with disabilities in the United States? How about the 550 million around the world? From pmw57 at xtra.co.nz Mon Mar 5 13:45:29 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Mar 5 13:45:33 2007 Subject: [uf-discuss] Tutorial on AHAH (such a cool technology!) Message-ID: <003801c75f6f$97b30950$bc08a8c0@nzto22> Mike Schinkel wrote: > Printable version please! Ane that doesn't take 12 pages to print... (He > also grumbles about lack of back button in presentation but glad the > presentation was not 96 pages...) The slideshow was built using S5, A Simple Standards-Based Slide Show System from Eric Meyer. http://meyerweb.com/eric/tools/s5/ Eric built S5 to scratch an itch, and now many others have taken to using it too. There are several ways to go back, arrow keys, page up, or mouse down to the info back and click on the arrows. Keyboard controls for it can be found at http://meyerweb.com/eric/tools/s5/features.html#controlchart The keyboard controls aren't easily discoverable, especially for people viewing the slideshows and perhaps that's an improvement that can be suggested. You're right about the printing issue. a page per screen is too much. I wonder if there's a way to print on a virtual a5, and have two of those a5's appear on a single a4 page. > Lastly, href="javascript:ahah('Waldorf-Astoria-Photo.html','Photo');">photo > hides the content from search engines, which is not good. > Another alternative that seems cleaner to me would be to code it like this > and let your ahah.js annotate the link for you: > > photo > Oh course this last suggestion will probably run me afoul of the > microformat > police since rel="ahah" hasn't even been officially proposed yet and I > didn't bring it up on [uf-new]... ;-P Give it an id and the script can be robust while you're at it. I don't like the idea of javascript scraping the page for class names. Dustin Diaz covers this particular issue very well in http://www.dustindiaz.com/class-name-widget-philosophy/ While it's convenient, it's slow, demanding, and at high risk of breaking. If we're going to try to not use the class tag as an identifier for javascript functions, the trouble comes in making it easy for people to add the script to their page and use it. The following seems to do the trick. photo

Then the script can get only what it needs, like the anchors, filter through them much more rapidly, perhaps with the wonderful forEach technique from http://dean.edwards.name/weblog/2006/07/enum/ and add the behavior to those elements with something like addEvent from http://www.dustindiaz.com/rock-solid-addevent/ (Yeah, more Dustin, he does great stuff) And if the script uses object notation, like the searchplay object at http://www.dustindiaz.com/javascript-searchplay/ then there won't have to be a lot of functions like ahahinit, ahahdoit, ahahdone. It might start to look something like this // beware, untested code, dragons may be lurking ahah = { init : function() { var els = document.getElementsByTagName('a'); Array.forEach(els, function(el) { if ('ahah' == el.getAttribute('rel')) { var href = el.getAttribute('href'); var id = 'ahah-' + el.getAttribute('id'); addEvent(el, 'click', 'function(){ahah.get("'+href)+'", "'+id+'")}'); } } }, get : function(url, target, delay) { // code as per normal } }; How close would something like this get to cleaning things up? -- Paul Wilkins From pmw57 at xtra.co.nz Mon Mar 5 14:00:01 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Mar 5 14:00:16 2007 Subject: [uf-discuss] Tutorial on AHAH (such a cool technology!) References: <003801c75f6f$97b30950$bc08a8c0@nzto22> Message-ID: <004101c75f71$9f9f7840$bc08a8c0@nzto22> From: "Paul Wilkins" > It might start to look something like this // beware, untested code, dragons may be lurking ahah = { init : function() { var els = document.getElementsByTagName('a'); Array.forEach(els, function(el) { var href = el.getAttribute('href'); var id = 'ahah-' + el.getAttribute('id'); addEvent(el, 'click', ''); }); }, get : function(url, target, delay) { // code as per normal } }; > How close would something like this get to cleaning things up? -- Paul Wilkins From pmw57 at xtra.co.nz Mon Mar 5 14:07:22 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Mar 5 14:07:34 2007 Subject: [uf-discuss] Tutorial on AHAH (such a cool technology!) References: <003801c75f6f$97b30950$bc08a8c0@nzto22> <004101c75f71$9f9f7840$bc08a8c0@nzto22> Message-ID: <004a01c75f72$a64d4220$bc08a8c0@nzto22> From: "Paul Wilkins" > It might start to look something like this Note to self, don't post when rushed for time. // beware, untested code, dragons may be lurking ahah = { init : function() { var els = document.getElementsByTagName('a'); Array.forEach(els, function(el) { var href = el.getAttribute('href'); var id = 'ahah-' + el.getAttribute('id'); addEvent(el, 'click', 'function(){ahah.get("'+href+'", "'+id+'")'); }); }, get : function(url, target, delay) { // code as per normal } }; > How close would something like this get to cleaning things up? -- Paul Wilkins From fberriman at gmail.com Mon Mar 5 14:11:05 2007 From: fberriman at gmail.com (Frances Berriman) Date: Mon Mar 5 14:11:16 2007 Subject: [uf-discuss] hrecipe prototype In-Reply-To: <00e801c75f6c$7e5f4cf0$a7dd15ac@ds.corp.yahoo.com> References: <00e801c75f6c$7e5f4cf0$a7dd15ac@ds.corp.yahoo.com> Message-ID: On 05/03/07, Ted Drake wrote: > Hi All > > I created a mockup of a Yahoo! Food page with a prototype of an hrecipe > format for last quarter's Yahoo Hack Day. > Is there a group working on the hrecipe microformat? I'd like to pass the > coding on to the group for consideration. Hey Ted, I assume you've seen the recipe work on the wiki[1]? The appropriate step to interact with interested parties would probably be to look over that, add your relevant information to the wiki pages (like your examples) and if you want to discuss it with people, send something up to the microformats-new mailing list[2], rather than this -discuss list. F [1]http://microformats.org/wiki/recipe-examples [2]http://microformats.org/wiki/mailing-list#microformats-new -- Frances Berriman http://fberriman.com From pmw57 at xtra.co.nz Mon Mar 5 14:26:53 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Mar 5 14:26:56 2007 Subject: [uf-discuss] Tutorial on AHAH (such a cool technology!) References: <003801c75f6f$97b30950$bc08a8c0@nzto22><004101c75f71$9f9f7840$bc08a8c0@nzto22> <004a01c75f72$a64d4220$bc08a8c0@nzto22> Message-ID: <005901c75f75$60590e90$bc08a8c0@nzto22> From: "Paul Wilkins" If I have some time I'll get a fully tested version of this fleshed out. // beware, untested code, dragons may be lurking ahah = { init : function() { var els = document.getElementsByTagName('a'); Array.forEach(els, function(el) { if ('ahah' == el.getAttribute('rel')) { var href = el.getAttribute('href'); var id = 'ahah-' + el.getAttribute('id'); addEvent(el, 'click', 'function(){ahah.get("'+href+'", "'+'ahah-'+id+'")'); } }); }, get : function(url, target, delay) { // code as per normal } }; How close would something like this get to cleaning things up? From mikeschinkel at gmail.com Mon Mar 5 17:13:38 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Mon Mar 5 17:13:41 2007 Subject: [uf-discuss] Tutorial on AHAH (such a cool technology!) In-Reply-To: <003801c75f6f$97b30950$bc08a8c0@nzto22> References: <003801c75f6f$97b30950$bc08a8c0@nzto22> Message-ID: <001b01c75f8c$abf8d4e0$0702a8c0@Guides.local> Paul Wilkins wrote: > Mike Schinkel wrote: Printable version please! Ane that > doesn't take 12 pages to print... (He also grumbles about > lack of back button in presentation but glad the > presentation was not 96 pages...) > > The slideshow was built using S5, A Simple > Standards-Based Slide Show System from Eric Meyer. > http://meyerweb.com/eric/tools/s5/ > > Eric built S5 to scratch an itch, and now many others > have taken to using it too. > > There are several ways to go back, arrow keys, page up, > or mouse down to the info back and click on the arrows. > > Keyboard controls for it can be found at > http://meyerweb.com/eric/tools/s5/features.html#controlcha > t > > The keyboard controls aren't easily discoverable, > especially for people viewing the slideshows and perhaps > that's an improvement that can be suggested. Thanks for the link. I had seen various HTML slideshows used from evidently different sources, some with and some without visible controls, but didn't know Eric Meyer was the source of this one of them. I may be old school, but to me if there is no visible indicators of a control, or at least a link to a help file, they doesn't exist. As least not from a usability perspective. What's incredibly ironic is someone such as Eric Meyer who focuses on visual presentation would make such an error. Heck, his example presentation does not have visible controls; at least he could have included a "help" link to his keyboard shortcuts! > You're right about the printing issue. a page per screen > is too much. I wonder if there's a way to print on a > virtual a5, and have two of those a5's appear on a single > a4 page. BTW, it seems one can press "T" to toggle and get a printable view. If he added visible controls it would sure be the heck out of Powerpoint for the web! > > Another alternative that seems cleaner to me would be > > to code it like this and let your ahah.js annotate the > > link for you: > > > > > rel="ahah">photoOh course this last suggestion will > > probably run me afoul of the microformat police since > > rel="ahah" hasn't even been officially proposed yet and > > I didn't bring it up on [uf-new]... ;-P > > > Give it an id and the script can be robust while you're > at it. > > I don't like the idea of javascript scraping the page for > class names. Dustin Diaz covers this particular issue > very well in Did I say "class"? No, I said "rel" ;-) Interestingly reading Diaz' article there were a lot of people with good points that disagreed with his suggestion. But whatever, I was more discussing an overall concept, not a specific implementation of Javascript or how to optimize it. Seems like I accidentially hit on one of your hotbuttons, though? :-) > While it's convenient, it's slow, demanding, > and at high > risk of breaking. And microformats, as currently envisioned, are *not* at a high risk for breaking? As an aside, rel="ahah" wouldn't be at a high risk of breaking because the author using the technique would author it so it didn't break (or can you see potentials where his authoring would break that are not abstract hypotheticals?) Also, how would Diaz' article apply if these AHAH links were littered throughout the document? His article addressed what seemed like typically a single widget, not multiple instances of the same widget scattered throughout a document. I think it would be a heavy burden to place on a content author to require them to write the Javascript code he talks about if they had to tag 10 different segments rather than just scan for . I think these may well be two different use-cases that might deserve two different approaches. On a similar note, one a partner of mine is would on, how do you feel about scraping a document to find heading tags (H1..H3) so as to build a table of contents? > How close would something like this get to cleaning > things up? Anyway, I'm fundamentally not really a Javascript guy, I'm a URL guy. So my comments were focused on ensuring the URLs were treated right. If you are a Javascript guy that can optimize that stuff so it is still usable for the content author, it's all yours! -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." > If we're going to try to not use the class tag as an > identifier for javascript functions, the trouble comes in > making it easy for people to add the script to their page > and use it. > > The following seems to do the trick. > > id="waldorf">photo > >

> > Then the script can get only what it needs, like the > anchors, filter through them much more rapidly, perhaps > with the wonderful forEach technique from > http://dean.edwards.name/weblog/2006/07/enum/ and add the > behavior to those elements with something like addEvent > from http://www.dustindiaz.com/rock-solid-addevent/ > (Yeah, more Dustin, he does great stuff) > > And if the script uses object notation, like the > searchplay object at > http://www.dustindiaz.com/javascript-searchplay/ then > there won't have to be a lot of functions like ahahinit, > ahahdoit, ahahdone. > > It might start to look something like this > > // beware, untested code, dragons may be lurking ahah = { > init : function() { var els = > document.getElementsByTagName('a'); Array.forEach(els, > function(el) { if ('ahah' == el.getAttribute('rel')) { > var href = el.getAttribute('href'); var id = 'ahah-' + > el.getAttribute('id'); addEvent(el, 'click', > 'function(){ahah.get("'+href)+'", "'+id+'")}'); } } }, > get : function(url, target, delay) { // code as per > normal } }; > > -- Paul Wilkins > > _______________________________________________ > microformats-discuss mailing list > microformats-discuss@microformats.org > http://microformats.org/mailman/listinfo/microformats-disc > ss From pmw57 at xtra.co.nz Mon Mar 5 18:18:47 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Mar 5 18:18:51 2007 Subject: [uf-discuss] Tutorial on AHAH (such a cool technology!) Message-ID: <008901c75f95$c5da6aa0$bc08a8c0@nzto22> From: "Mike Schinkel" > What's incredibly ironic is someone such as Eric Meyer who focuses on > visual > presentation would make such an error. Heck, his example presentation > does > not have visible controls; at least he could have included a "help" link > to > his keyboard shortcuts! If you mouse to the bottom right of the presentation (or press C) you'll find there are some minor controls, but you've got to either stumble upon them or know about them beforehand. What's really needed is for someone to take the S5 system and built upon it an easily discoverable system for nagivation and control, but that would mean finding someone with the time to put together the interface. > BTW, it seems one can press "T" to toggle and get a printable view. > If he added visible controls it would sure be the heck out of Powerpoint > for > the web! Unfortunately T only switches the view from slideshow to content. The printout isn't affected from either view. Perhaps there needs to be two print stylesheets, and have them switched to match the view. >> I don't like the idea of javascript scraping the page for >> class names. Dustin Diaz covers this particular issue >> very well in > > Did I say "class"? No, I said "rel" ;-) Class or rel, they're both handled the same, where some code typically has to go through every single element on the page and scrape up the wanted attributes. ID attributes are different because the computer creates a list of them beforehand. The significance is that having several scripts scrape over the page after it's loaded can be troublesome. For example, if a hot finger clicks on an anchor before it's had time for the event to be attached. In this case finding them via the id attributes isn't viable, so the next best thing to do it limit the number of elements that need to be searched through, to help the computer do its thing more quickly than if it were using some generic getElementsByClassName function. At least some of them allow you to supply extra info to help narrow down and pleed up the search, like http://www.dustindiaz.com/getelementsbyclass > Interestingly reading Diaz' article there were a lot of people with good > points that disagreed with his suggestion. But whatever, I was more > discussing an overall concept, not a specific implementation of Javascript > or how to optimize it. Seems like I accidentially hit on one of your > hotbuttons, though? :-) Code performance is one of those, that's for sure. I'm glad we're using the rel attribute here though, for I perceive some trouble down the road with class names. With the growth in class names being used for purposes other than styling, there will be in a few years more and more trouble with them clashing together. Looking at the list of class names for microformats alone, http://microformats.org/wiki/existing-classes I can see names that have been used in previous created stylesheets. In light of this, my own development is going to feature a slow down in class names for attaching javascript events, and instead focus on methods that should prove to be more compatible with less troubles in the future. >> While it's convenient, it's slow, demanding, >> and at high >> risk of breaking. > > And microformats, as currently envisioned, are *not* at a high risk for > breaking? They *are*are at more of a risk of breaking, but it's the best solution we have at the moment. > As an aside, rel="ahah" wouldn't be at a high risk of breaking > because the author using the technique would author it so it didn't break > (or can you see potentials where his authoring would break that are not > abstract hypotheticals?) Sure thing. Take for example the case where some webmaster decides to specify the relevance of outgoing links. He may have a script that goes through adding rel tags to certain known links and domains, and leave empty those that it doesn't know about. That example is the problem I eventually tracked down, to help someone who's attributes weren't sticking, because another script that nobody had looked much at was playing around where it shouldn't have. The good thing about the rel is that "The rel attribute specifies the relationship of the linked document with the current document." So rel="ahah" is perfect to state that the link goes out to some AHAH content. > Also, how would Diaz' article apply if these AHAH links were littered > throughout the document? His article addressed what seemed like typically > a > single widget, not multiple instances of the same widget scattered > throughout a document. The dilemma is when there are several types of widgets scattered throughout a document. Then each widget is going to be lining up behind each other, waiting for the chance to scan through and find the bits it needs. > I think it would be a heavy burden to place on a > content author to require them to write the Javascript code he talks about > if they had to tag 10 different segments rather than just scan for rel="ahah">. I think these may well be two different use-cases that might > deserve two different approaches. It would be a heavy burden, so I'm suggesting that the javascript code he talks about is moved into the function itself, so that the content author just has to bring in the code and apply a rel attribute and a few id attributes. > On a similar note, one a partner of mine is would on, how do you feel > about > scraping a document to find heading tags (H1..H3) so as to build a table > of > contents? I know what you're on about because Web Developer already has a View Document Outline http://chrispederick.com/work/webdeveloper/ The biggest issue at hand is if this stuff is happening after the page finished loading, that the user received feedback on when these things have finished and the page is ready for use. When a page appears on the screen people expect to be able to use it immediately. If there is some 5 seconds of waiting required (without feedback of some kind) before everything is ready, that's where the trouble lies. > Anyway, I'm fundamentally not really a Javascript guy, I'm a URL guy. So > my > comments were focused on ensuring the URLs were treated right. If you are > a > Javascript guy that can optimize that stuff so it is still usable for the > content author, it's all yours! Dead right, for URLs to work properly the href must link to to a usable document. If javascript isn't enabled it'll then still work. If javascript is enabled then it can fiddle around and perform its magic, just so long as it works and doesn't take too long. -- Paul Wilkins From bjonkman at sobac.com Mon Mar 5 20:46:05 2007 From: bjonkman at sobac.com (Bob Jonkman) Date: Mon Mar 5 20:46:42 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar Message-ID: <45ECABBD.3865.380950@bjonkman.sobac.com> Hi all: Today I had the urge to mark up an arbitrary date, not one that is part of an hCalendar event, eg. Use version 7.0.2 from 5 March 2007 This is to provide some standarization in presenting dates, but keep them human- readable in arbitrary format. dtstart and dtend aren't appropriate semantic classes in this example. Is there a proper microformat for arbitrary dates? --Bob. -- -- -- -- Bob Jonkman http://sobac.com/sobac/ SOBAC Microcomputer Services Voice: +1-519-669-0388 6 James Street, Elmira ON Canada N3B 1L5 Cel: +1-519-635-9413 Networking -- Office & Business Automation -- Consulting PGP:0xAE33E989 Fingrprnt:9FAF A6AC B567 BC10 8973 7CF0 CB27 0317 From pmw57 at xtra.co.nz Mon Mar 5 21:21:08 2007 From: pmw57 at xtra.co.nz (Paul Wilkins) Date: Mon Mar 5 21:21:18 2007 Subject: [uf-discuss] Formatting arbitrary dates, not part of hCalendar In-Reply-To: <45ECABBD.3865.380950@bjonkman.sobac.com> References: <45ECABBD.3865.380950@bjonkman.sobac.com> Message-ID: <45ECFA44.3060804@xtra.co.nz> Bob Jonkman wrote: > Hi all: Today I had the urge to mark up an arbitrary date, not one that is part of > an hCalendar event, eg. > > Use version 7.0.2 from 5 March 2007 > > This is to provide some standarization in presenting dates, but keep them human- > readable in arbitrary format. > > dtstart and dtend aren't appropriate semantic classes in this example. Is there a > proper microformat for arbitrary dates? No, there isn't a proper microformat, it's more of a design pattern. Datetime Design Pattern http://microformats.org/wiki/date -- Paul Wilkins From ryan at ryancannon.com Mon Mar 5 21:23:37 2007 From: ryan at ryancannon.com (Ryan Cannon) Date: Mon Mar 5 21:23:41 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: <200703050406.l25467hD009893@microformats.org> References: <200703050406.l25467hD009893@microformats.org> Message-ID: <7C47CE4D-B2B5-4D8F-A8F3-6121E6625652@ryancannon.com> On Mar 4, 2007, at 11:06 PM, Mike Schinkel wrote: > Ryan Cannon wrote: >> Adding an @profile attribute to he element is far >> less technically demanding than, say, creating a tag >> space, which we also require. Especially as the addition >> also has no performance or usability impact. > > It may be less technically demanding, but the latter is needed. Creating a tag space allows a user of rel-tag to discover precisely what the author means by the text of the tag. Profile URIs help authors discover precisely what an attribute value means. In light of your later point about grokability, I think both are needed. >> I also think that authoring microformats with the intent >> that they be usable to the CMS-using/WYSIWG masses is a >> pipe dream. Users should *not* be encouraged to publish >> HTML markup they cannot read. Robust microformatted >> content will always require either an understanding of >> how to hand-code HTML or a tool to help generate it--is >> it unreasonable to think that the meeting of either >> condition implies the ability to add an @profile as well >> for 80% of cases? > > I cannot overemphasis how strongly I disagree with that last > paragraph from > a philosophical standpoint, for two reasons: > > 1.) There are two schools of thinking, one of which I believe to be > severely > flawed: > > A.) Don't worry about the syntax or how it is implemented, the tools > will take care of make it easy. > B.) Don't even think about tools until it can be done and easily > understood by a human. Only then should tools be created. > > Of course I strongly believe that "A" is the flaw perspective > although I > know there are many people in that camp, you (it appears) included. > I plan > to write a paper in the future on this issue after I've done enough > research > and gathered actual evidence but for now let's look at the > technologies that > have gained quick and *widespread* usage (a), and those that > haven't (b): > > (a) HTML, RSS, CSS, XML, some microformats, shell scripts/batch > files, languages using text for source, and so on. > (b) XHTML, XML Namespaces, XSLT, RDF, other microformats, Visual > programming languages, and so on. > > > > The technologies that work are the ones that are designed for > humans first, > with humans with tools second. Although I'm not sure about the others, I know that RSS, CSS and XML were designed not simply for humans, but for humans with a specific set of skills in place. People with these skills built tools that then fueled (or are fueling) wide-spread adoption. Perhaps I'm wrong, but I see microformats in the same vein. I think your concept of "quick" and "widespread" are interesting as well--CSS 2 (Recommended 1998) and XML Namespaces (Recommended 2006) have roughly similar penetration in Web browsers (imperfect in most, quite poor in a major one). > Believing that there is or should be a > difference between "users" and "content authors" is either simply > ignorant > or actively arrogant. To quote Andy Mabbett, this is a straw man. I never said this, nor did I intend it. What I said was: WYSIWYG-only users can't read code. Microformats without tools are code. In my experience, WYSIWYG users who post code they cannot read rarely get the outcome they desire. Authoring Microformats with the intention that they be usable *as code* to content authors *who cannot read code* is a pipe dream. > The web with its recent social media component has > empowered EVERYONE to become content authors, and I don't honestly > see this > abating. My expectation is that soon every kid from a first world > country > (and soon every kid in the world, if OLPC succeeds) will be as > comfortable > coding in HTML as today's office worker is comfortable using > Microsoft Word. And? Once this occurs adding a single attribute to a single element will be easy for everyone. > And if you'll forgive the tinge of melodrama I don't think it's appropriate, warranted or necessary. This thread is about the necessity of profile URIs. I think the problems started with Scott Reynen's assertion[1] that: > Profiles are not intended to work as parsing templates. They just > identify the type of data so parsers can figure out whether or not > it's something they know how to parse. Profiles are intended for machines *and humans*[2]. Providing profile URIs adds important disambiguation for the definitions of terms and helps content authors better understand the code they are writing. For example, say an author unfamiliar with hCard attempted to duplicate the following code:

Ryan Cannon is a Scorpio.

What is necessary? What is significant? Why banana? Instead of having to wade through the vCard or hCard spec, the profile provides an easy-to-read description of the format and its included terms. By allowing microformat publishers to omit profile URIs, you also eliminate important clues as to what microformats mean, what is important, and what is not. *That* is a good way to keep content authors from becoming anointed. [1]: http://microformats.org/discuss/mail/microformats-discuss/2007- March/008892.html [2]: http://www.gmpg.org/xmdp/ From scott at randomchaos.com Mon Mar 5 23:10:52 2007 From: scott at randomchaos.com (Scott Reynen) Date: Mon Mar 5 23:10:44 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: <7C47CE4D-B2B5-4D8F-A8F3-6121E6625652@ryancannon.com> References: <200703050406.l25467hD009893@microformats.org> <7C47CE4D-B2B5-4D8F-A8F3-6121E6625652@ryancannon.com> Message-ID: On Mar 5, 2007, at 11:23 PM, Ryan Cannon wrote: > This thread is about the necessity of profile URIs. I think the > problems > started with Scott Reynen's assertion[1] that: > > > Profiles are not intended to work as parsing templates. They just > > identify the type of data so parsers can figure out whether or not > > it's something they know how to parse. That was not a statement about the necessity of profile URIs. It was only a statement of a simple fact: profile URIs provide disambiguation, not parsing instructions. I wrote that in direct response to this: On Mar 2, 2007, at 2:40 PM, Michael MD wrote: > I don't see how special cases where something has to be extracted > in a different way are expressed in the profiles. Michael didn't see how that was expressed in profiles because it's *not* expressed in the profiles. That doesn't mean profile URIs aren't useful, just that they don't solve the problem of communicating parsing instructions. Peace, Scott From joe at andrieu.net Tue Mar 6 00:18:33 2007 From: joe at andrieu.net (Joe Andrieu) Date: Tue Mar 6 00:18:34 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: Message-ID: <006101c75fc8$08d5dd80$0301a8c0@andrieuhome> Scott Reynen wrote: > On Mar 2, 2007, at 2:40 PM, Michael MD wrote: > > > I don't see how special cases where something has to be extracted > > in a different way are expressed in the profiles. > > Michael didn't see how that was expressed in profiles because it's > *not* expressed in the profiles. That doesn't mean profile URIs > aren't useful, just that they don't solve the problem of > communicating parsing instructions. Scott, I think different profile URIs do express "where something has to be extracted in a different way." Different profile URIs can mean different extraction rules. The rules are not actually in the profiles themselves, but the use of profile URIs does what Michael was asking about. As I understand it, the profile itself need not even be dereferenced by consuming applications. In that way, it is more of an identifier than a locator. And in fact, profile URIs are the only mechanism we have for version control. So if parsing rules change with a new version, the only way a consuming app would know to apply the new/old parsing is because of the profile URI. For context, Michael's original question in the archive is at http://microformats.org/discuss/mail/microformats-discuss/2007-March/008891.html -j -- Joe Andrieu joe@andrieu.net +1 (805) 705-8651 "An inconvenience is an adventure wrongly considered. An adventure is only an inconvenience rightly considered." --G. K. Chesterton From mikeschinkel at gmail.com Tue Mar 6 01:33:16 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Tue Mar 6 01:33:22 2007 Subject: [uf-discuss] Tutorial on AHAH (such a cool technology!) In-Reply-To: <008901c75f95$c5da6aa0$bc08a8c0@nzto22> References: <008901c75f95$c5da6aa0$bc08a8c0@nzto22> Message-ID: <00a601c75fd2$7861ba70$0702a8c0@Guides.local> Paul Wilkins wrote: > If you mouse to the bottom right of the presentation (or > press C) you'll find there are some minor controls, but > you've got to either stumble upon them or know about them > beforehand. > > What's really needed is for someone to take the S5 system > and built upon it an easily discoverable system for > nagivation and control, but that would mean finding > someone with the time to put together the interface. heh. If I didn't have so many other projects, I'd jump on it (would be a good way to learn JS.) Maybe after I finish all my other projects... :) > > BTW, it seems one can press "T" to toggle and get a > > printable view. If he added visible controls it would > > sure be the heck out of Powerpoint for the web! > > > Unfortunately T only switches the view from slideshow to > content. The printout isn't affected from either view. > Perhaps there needs to be two print stylesheets, and have > them switched to match the view. Strange; S5's intro[1] DOES print correctly in outline mode, but Roger's AHAH slideshow does not. > In this case finding them via the id attributes isn't > viable, so the next best thing to do it limit the number > of elements that need to be searched through, to help the > computer do its thing more quickly than if it were using > some generic getElementsByClassName function. > > At least some of them allow you to supply extra info to > help narrow down and pleed up the search, like > http://www.dustindiaz.com/getelementsbyclass That looks like a good middle ground. > With the growth in class names being used for purposes > other than styling, there will be in a few years more and > more trouble with them clashing together. Looking at the > list of class names for microformats alone, > http://microformats.org/wiki/existing-classes I can see > names that have been used in previous created > stylesheets. I don't know if you are aware, but I made a big deal about that issue on this list several months ago but it seemed that most people didn't feel like my concerns were going to be an issue. So rather than beat a dead horse, I moved on to work in other areas. I still monitor this list occassionally, but not in real time. > In light of this, my own development is going to feature > a slow down in class names for attaching javascript > events, and instead focus on methods that should prove to > be more compatible with less troubles in the future. > > > > While it's convenient, it's slow, demanding, and at > > > high risk of breaking. > > > > > And microformats, as currently envisioned, are *not* at > > a high risk for breaking? > > > They *are*are at more of a risk of breaking, but it's the > best solution we have at the moment. Actually, there are solutions I've proposed I think are better, but they fell on deaf ears on this list. I can dredge them up again if you like. > > As an aside, rel="ahah" wouldn't be at a high risk of > > breaking because the author using the technique would > > author it so it didn't break (or can you see potentials > > where his authoring would break that are not abstract > > hypotheticals?) > > Sure thing. Take for example the case where some > webmaster decides to specify the relevance of outgoing > links. He may have a script that goes through adding rel > tags to certain known links and domains, and leave empty > those that it doesn't know about. > > That example is the problem I eventually tracked down, to > help someone who's attributes weren't sticking, because > another script that nobody had looked much at was playing > around where it shouldn't have. Well, that would break all of Microformats and sounds like the problem is the rogue webmaster not realizing that existing rel tags need to be maintained. I can see a potential for such a problem, but in the same context I can see that webmaster creating far greater problems than just upseting rel="ahah." > > Also, how would Diaz' article apply if these AHAH links > > were littered throughout the document? His article > > addressed what seemed like typically a single widget, > > not multiple instances of the same widget scattered > > throughout a document. > > > The dilemma is when there are several types of widgets > scattered throughout a document. Then each widget is > going to be lining up behind each other, waiting for the > chance to scan through and find the bits it needs. Here's a thought (more of a Javascript issue than a microformat issue; we can take offline is anyone objects): would it be possible to pipeline in a common file with a single scanner that any such widgets could attach to? (I don't know Javascript well enough to know the answer to that.) > > I think it would be a heavy burden to place on a > > content author to require them to write the Javascript > > code he talks about if they had to tag 10 different > > segments rather than just scan for . I > > think these may well be two different use-cases that > > might deserve two different approaches. > > > It would be a heavy burden, so I'm suggesting that the > javascript code he talks about is moved into the function > itself, so that the content author just has to bring in > the code and apply a rel attribute and a few id > attributes. I don't see it. Can you give code examples? > > On a similar note, one a partner of mine is would on, > > how do you feel about scraping a document to find > > heading tags (H1..H3) so as to build a table of > > contents? > > > I know what you're on about because Web Developer already > has a View Document Outline > http://chrispederick.com/work/webdeveloper/ Interesting. > The biggest issue at hand is if this stuff is happening > after the page finished loading, that the user received > feedback on when these things have finished and the page > is ready for use. When a page appears on the screen > people expect to be able to use it immediately. If there > is some 5 seconds of waiting required (without feedback > of some kind) before everything is ready, that's where > the trouble lies. 5 seconds is a lot! Maybe there are better techniques, like having the links be inactive and greyed-out until available? -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." From mikeschinkel at gmail.com Tue Mar 6 01:43:25 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Tue Mar 6 01:43:29 2007 Subject: OFFLIST: Re: [uf-discuss] Tutorial on AHAH (such a cool technology!) In-Reply-To: <008901c75f95$c5da6aa0$bc08a8c0@nzto22> References: <008901c75f95$c5da6aa0$bc08a8c0@nzto22> Message-ID: <00a801c75fd3$e3578390$0702a8c0@Guides.local> Paul: OFFLIST I really enjoyed your discussion, and you seem to be very knowledgable about Javascript issues. I have started a project with a partner in the UK (I am in the USA) that we hope to see grow to be used by most websites and most webusers. One thing we think is missing are visible reasons for people to use semantic markup where they can see an immediate and obvious tangible benefit. That's why we decided to pursue this project. We've got pure intentions, and our goal is to be a catalyst to make the web better. The project is called Toolicious (http://t.oolicio.us) Minimally all I'm asking is for you to read the small amount of info on the website and then give me your feedback. Beyond that I'd hope you'd just the mailing list[1] and participate in the discussions. We want to ensure that there is no reason people wouldn't want to use it on their website, but I'll let the website try to finish explaining to you as it eventually needs to speak for itself. Thanks in advance for your consideration. -- -Mike Schinkel http://www.mikeschinkel.com/blogs/ http://www.welldesignedurls.org http://atlanta-web.org - http://t.oolicio.us "It never ceases to amaze how many people will proactively debate away attempts to improve the web..." [1] http://lists.t.oolicio.us/toolicious-discuss/ From mikeschinkel at gmail.com Tue Mar 6 02:35:10 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Tue Mar 6 02:35:19 2007 Subject: OFFLIST: Re: [uf-discuss] Tutorial on AHAH (such a cool technology!) References: <008901c75f95$c5da6aa0$bc08a8c0@nzto22> Message-ID: <00f201c75fdb$1e138220$0702a8c0@Guides.local> Oops! Oh well, nothing said that I wasn't going to present to the Microformat community eventually! -Mike > -----Original Message----- > From: Mike Schinkel [mailto:mikeschinkel@gmail.com] > Sent: Tuesday, March 06, 2007 4:43 AM > To: 'Microformats Discuss' > Subject: OFFLIST: Re: [uf-discuss] Tutorial on AHAH (such a > cool technology!) > > Paul: > > OFFLIST > > I really enjoyed your discussion, and you seem to be very > knowledgable about Javascript issues. I have started a > project with a partner in the UK (I am in the USA) that we > hope to see grow to be used by most websites and most > webusers. One thing we think is missing are visible reasons > for people to use semantic markup where they can see an > immediate and obvious tangible benefit. That's why we decided > to pursue this project. We've got pure intentions, and our > goal is to be a catalyst to make the web better. > > The project is called Toolicious (http://t.oolicio.us) > Minimally all I'm asking is for you to read the small amount > of info on the website and then give me your feedback. Beyond > that I'd hope you'd just the mailing list[1] and participate > in the discussions. We want to ensure that there is no reason > people wouldn't want to use it on their website, but I'll let > the website try to finish explaining to you as it eventually > needs to speak for itself. > > Thanks in advance for your consideration. > > -- > -Mike Schinkel > http://www.mikeschinkel.com/blogs/ > http://www.welldesignedurls.org > http://atlanta-web.org - http://t.oolicio.us "It never ceases > to amaze how many people will proactively debate away > attempts to improve the web..." > > [1] http://lists.t.oolicio.us/toolicious-discuss/ > > From mikeschinkel at gmail.com Tue Mar 6 03:16:27 2007 From: mikeschinkel at gmail.com (Mike Schinkel) Date: Tue Mar 6 03:16:33 2007 Subject: [uf-discuss] Scraping or parsing? In-Reply-To: <7C47CE4D-B2B5-4D8F-A8F3-6121E6625652@ryancannon.com> References: <200703050406.l25467hD009893@microformats.org> <7C47CE4D-B2B5-4D8F-A8F3-6121E6625652@ryancannon.com> Message-ID: <00f901c75fe0$e2e6d480$0702a8c0@Guides.local> Ryan Cannon wrote: > > Ryan Cannon wrote: Adding an @profile attribute to he > > element is far less technically demanding than, > > say, creating a tag space, which we also require. > > Especially as the addition also has no performance or > > usability impact. > > > > It may be less technically demanding, but the latter is > > needed. > > > Creating a tag space allows a user of rel-tag to discover > precisely what the author means by the text of the tag. > Profile URIs help authors discover precisely what an > attribute value means. In light of your later point about > grokability, I think both are needed. I'm not sure I follow. And reading your whole email, you may be talking things different from what I'm talking about anyway. > Although I'm not sure about the others, I know that RSS, > CSS and XML were designed not simply for humans, but for > humans with a specific set of skills in place. > People with these skills built tools that then fueled (or are > fueling) wide-spread adoption. Perhaps I'm wrong, but I > see microformats in the same vein. And fundamental to my arguments are that skills can be learned. > I think your concept of "quick" and "widespread" are > interesting as well--CSS 2 (Recommended 1998) and XML > Namespaces (Recommended 2006) have roughly similar > penetration in Web browsers (imperfect in most, quite > poor in a major one). I have a book in my hands "Definitive XML Schema" written in 2001, published in 2002 and it discussed Namespaces in depth. The recommendation may have been last year, but it was not last year that the technology was available for people to use. And the fact that the major browsers can incorporate technology is an example of the Herculean effort from vested interests that I discussed. I don't know any mere mortal content author who can get the logic of XML Namespaces (after studying them on and off for six months, I gave up on them, and I'll challenge anyone on this list to be able to author a valid XML document that contains complex schema right without having to run through validation to debug it first.) > > Believing that there is or should be a difference > > between "users" and "content authors" is either simply > > ignorant or actively arrogant. > > > To quote Andy Mabbett, this is a straw man. I never said > this, nor did I intend it. I misunderstood, I thought you did. My apologizes if I got it wrong. > What I said was: WYSIWYG-only > users can't read code. Microformats without tools are > code. In my experience, WYSIWYG users who post code they > cannot read rarely get the outcome they desire. Authoring > Microformats with the intention that they be usable *as > code* to content authors *who cannot read code* is a pipe > dream. Help me with this... How do I recognized these "WYSIWYG-only users?" Are they a certain color? Height? Or maybe they have barcodes on the back of their necks? Or can I just give them IQ tests to determine who they are? Clearly my sarcasm drips... The point I'm making is that "WYSIWYG-only users" exist because technologist think it is okay to implement technology that is complex and *requires* tools as opposed to first implementing technologies that humans can deal with and THEN designing the tools. > > And if you'll forgive the tinge of melodrama > > > I don't think it's appropriate, warranted or necessary. But I did. > This thread is about the necessity of profile URIs. I > think the problems started with Scott Reynen's > assertion[1] that: > > > Profiles are not intended to work as parsing templates. > > They just identify the type of data so parsers can > > figure out whether or not it's something they know > > how to parse. > > > Profiles are intended for machines *and humans*[2]. > Providing profile URIs adds important disambiguation for > the definitions of terms and helps content authors better > understand the code they are writing. For exam