- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Mon, 25 Aug 2008 11:53:20 +0200
- To: "Ian Hickson" <ian@hixie.ch>
- Cc: "Dan Connolly" <connolly@w3.org>, "Booth, David (HP Software - Boston)" <dbooth@hp.com>, "Julian Reschke" <julian.reschke@gmx.de>, "public-grddl-comments@w3.org" <public-grddl-comments@w3.org>
2008/8/25 Ian Hickson <ian@hixie.ch>: > On Mon, 25 Aug 2008, Danny Ayers wrote: >> 2008/8/22 Ian Hickson <ian@hixie.ch>: >> > On Fri, 22 Aug 2008, Dan Connolly wrote: >> >> >> >> But in GRDDL and HTML5, Ian Hickson, editor of HTML 5, advocates >> >> dropping the profile attribute of the HTML head element in favor of >> >> rel="profile" or some such. >> > >> > Actually my proposal is just to drop it altogether and just assume it >> > is present and lists all the values that you would otherwise have >> > recognised. >> >> Sorry Ian, I can't understand how that might work in practice. Without >> pre-awareness through registries or another predefined way of looking >> things up (like URIs + HTTP)...well how? Where is the list? > > The same place the list is with GRDDL used on pages that use the official > profile="" values. GRDDL relies on the target of the profile="" page > having a special reference to something that says how to process that > file, right? Near enough, though the notion of profiles comes from HTML 4ish. Well those pages rarely will have that information (e.g. the > XFN profile page doesn't), so whatever mechanism is used to work around > that should just always assume that all the profiles are available. To date microformats.org (and as far as I've seen the majority of microformat publishers) haven't exactly jumped on the notion of URI-based extensibility, but that doesn't necessarily mean it's a bad approach. Not hard to see it as a good approach compared to the workarounds (e.g. hard-coding things into the browser). > Or, you could use some GRDDL-specific link, e.g. <link > rel=transformation>, to do it, if you are willing to limit GRDDL's > usefulness to pages that are expecting GRDDL to be used on them. It's not an exclusive or. What troubles me though is the potential exclusion of the option for producers and/or consumers of the HTML markup to choose their own way of expressing data. Truth be known, I am attracted to Dan's attitude - "I'm content for the market to choose" [1], despite my having yet to see evidence of the wisdom of crowds (including software companies ;-) Cheers, Danny. [1] http://dig.csail.mit.edu/breadcrumbs/node/240 -- http://dannyayers.com ~ http://blogs.talis.com/nodalities/this_weeks_semantic_web/
Received on Monday, 25 August 2008 09:53:58 UTC