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


From: Harry Halpin <hhalpin@ibiblio.org>
Date: Mon, 25 Aug 2008 13:18:05 +0100
Message-ID: <48B2A2FD.7010503@ibiblio.org>
To: Ian Hickson <ian@hixie.ch>
Cc: Julian Reschke <julian.reschke@gmx.de>, 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>

Ian Hickson wrote:
> On Mon, 25 Aug 2008, Harry Halpin wrote:
>> 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.
We have a separate sort of link in GRDDL (rel="transformation") to 
directly connect a HTML page to a GRDDL transformation.

 People are not encouraged to make "custom" profiles for hCard, etc., 
that would be foolish. But you might want to make your own profile, say 
"microChemistry", and give it a profile page, and use that profile. 
Profiles are extensible.

The general idea behind using profiles was *not* as a substitute for a a 
link to a GRDDL transform, but that authors that use profiles could add 
a link to GRDDL transform to their profile page, and the GRDDL algorithm 
could look for a GRDDL transform there if one wasn't directly linked. 
Think of it as a short-cut for document authors - they just have to 
think about using particular profiles, rather than directly linking to a 
GRDDL transformation. That way the owner of the profile document can 
upgrade the GRDDL transformation once without modifying all instance 
data that uses that profile.

So, our "microChemistry" profile page could embed a GRDDL tranformation 
directly in that profile page, or require all instance data to both list 
the profile page and a rel="transformation" directly to the profile. The 
first seems easier.

Again, the use of profiles and direct linking to a GRDDL transform via 
rel="transformation" are two separate cases. I assume you are happy with 
rel="transformation" rather than rel="grddl-transformation".
> 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.
I hope this is clearer now what GRDDL does.
> 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.
rel="transform" works for me and is in the spec already.
>> 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.
See above.
Received on Monday, 25 August 2008 12:18:40 UTC

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