W3C home > Mailing lists > Public > public-grddl-comments@w3.org > July to September 2008

Re: GRDDL and HTML5

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 25 Aug 2008 11:44:59 +0000 (UTC)
To: Harry Halpin <hhalpin@ibiblio.org>, Julian Reschke <julian.reschke@gmx.de>
Cc: Danny Ayers <danny.ayers@gmail.com>, Dan Connolly <connolly@w3.org>, "Booth, David (HP Software - Boston)" <dbooth@hp.com>, "public-grddl-comments@w3.org" <public-grddl-comments@w3.org>
Message-ID: <Pine.LNX.4.62.0808251138030.7044@hixie.dreamhostps.com>

On Mon, 25 Aug 2008, Harry Halpin wrote:
> 
> 1) We want pages without profiles to work. Even if the microformat 
> community settles on @rel="profile" (which would be a minor delta to 
> GRDDL), there are still lots of pages with perfectly good data in the 
> wild that won't use @rel="profile" either.

Agreed.


> 2) Yet we want users to be able to specify their own profiles with their 
> own GRDDL transformations in order to explictly license the extracted 
> RDF and not force anyone to use any "default" transformations.

This isn't what profile="" in HTML4 is for -- at least, not if they are 
using formats that do have their own defined profiles. For example, say 
you are using hCard. You can give the official hCard profile, or, you can 
give your own custom profile that happens to define a transformation that 
is exactly like hCard's. But if you do the latter, you're not technically 
using hCard, and people who are looking for profile="" declarations and 
are _not_ using GRDDL will not be able to use your pages' hCard data.

Thus, I posit that 2) is a mis-use of profile="". Certainly, even if HTML5 
had profile="", it wouldn't license the use of the attribute in this way.


> 1) Have a user-specified (i.e. user can turn it off and on) mode that as 
> a matter of local policy can be pointed to a namespace document (a URI 
> for a "list of default GRDDL transformations" for HTML, like hCard, 
> etc., perhaps maintained by the W3C) that contains a list of default 
> GRDDL transformations for popular microformats and vocabularies, and 
> apply these even if @rel="profile" is missing. Therefore, if the user 
> wants to be a bit unsafe, they can use this mode, but they can also turn 
> it off if they don't trust it, and point it to different "trusted" lists 
> of GRDDL transformations.

Right, that is what I have suggested in the past.


> 2) For users who use @rel="profile", get the GRDDL transformation and 
> then run it over the HTML5 DOM of the page. Minor change.
> 
> What we need to know from *both* the HTML5 community is simple: is 
> @rel="profile" in the spec, and does the community have consensus?

On Mon, 25 Aug 2008, Julian Reschke wrote:
> 
> That touches another issue: who owns the namespace of rel values? (for 
> which there is not HTNL5 WG consensus either, as far as I can tell).

Nobody owns the namespace; you can invent your own value, and then 
register it on the wiki:

   http://wiki.whatwg.org/wiki/RelExtensions

I see rel=profile is already on the list. Personally if you want to use a 
value to mean "it's a GRDDL transform", I'd use another keyword, e.g. 
rel=grddl-transform.


> Unrelated to that: in case we could agree that head/@profile could be 
> substituted by link/@rel=profile with the same meaning, why on earth 
> would we then remove head/@profile in the first place? Why break it, 
> when its functionality is actually used?

As Harry said, many people don't declare their profiles. So it shouldn't 
be needed. The only case where something might be needed is where you want 
an explicit link to a GRDDL transform, just like one might link to a CSS 
sheet. But this isn't a profile="" or rel=profile in the traditional 
sense, and a custom value for GRDDL would be more appropriate.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 25 August 2008 11:45:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:03 UTC