Re: Reviving HTTP Header Linking: Some code and use-cases

Harry Halpin wrote:
>> Understood. But wouldn't two different link relations have the same
>> semantics?
> Operational semantics, yes. But one would be authorized by the creator
> of the document while the other's wouldn't. I think that's a valid
> distinction. One could "link" to page containing a GRDDL transform and
> not want it run, because you do not trust it, it is still experimental,
> etc.

Yes, but you could define the two link relations to have exactly that 
semantics, couldn't you?

>>>> So, let's rephrase this: if a link relation could be a URI (or IRI),
>>>> would we need Profile?
>>> Explain precisely how this would work. I'm not sure what document I
>>> should be looking at to explain "link relations" to me. If there's
>>> another header that can do it, that might work.
>> No, I meant the link header...:
>>
>> Link: <http://example.com/grddl.xslt>;
>>   rel="http://www.w3.org/2003/g/data-view/transform"
> Yep, that would be another way to do it, but only *if* rel allows URIs.
> I thought it did not. Am I wrong?

That's up for discussion, I think.

> But if there is, still think there's an argument for profile, see below.
> 
>>> I can see how there might be conflict if HTML drops Profile and HTTP
>>> re-instates it. It would be better for it to be either re-instated
>>> uniformly or not. But I think Profile does have a pretty good URI-based
>>> extensibility case going for it.
>> Yes, I totally agree that URI based extensibility is good. I'm just
>> not sure it's good enough with Profile, given the fact it doesn't
>> solve the disambiguation problem.
> What profile does is provide a meta-data profile for the resource of the
> URI itself, not just the links, although it can be used to disambiguate
> the links (albeit imperfectly if lists of profiles and links are used).
> In this manner, it's still very useful. For example, it's usage in
> microformats in HTML allows microformats to have GRDDL transformations
> without a centralized repository. The same case can be made for HTTP.
> The only alternative is to "stick everything" in a centralized registry.

Profile does *help* with microformats name clashes, but it doesn't solve 
them; if you have class="title" in two different microformats, the 
profile attribute won't help you disambiguate.

On the other hand, for link relations we *may* have the option to ground 
them in URI space, so the problem simply would go away.

> So, we could imagine a case where someone wants to use a profile URI for
> their microformat-enabled page, and we want GRDDL to go to that profile
> and get the GRDDL transform. I guess one could try to do this.
> 
> Link: <http://example.com/mymicroprofile>;
>   rel="http://example.com/itsaprofile"
> 
> But it seems that Profile would work too:
> 
> Profile: <http://example.com/mymicroprofile>;
> 
> Again, I think I've already made a request for Link to be re-instated.
> If Link is re-instated, then we'd also like URIs to be allowed in rel
> fields. I think there's no argument here.
> 
> We'd also like Profile to be kept, but could probably live if an
> alternate mechanism was approved, i.e. URIs in rel fields.

OK, thanks for clarifying.

> However, this would break existing software and so we'd have to change

Which?

> it. I think the same would go for the microformat community if HTML 5
> got rid of profiles.

It's (imho) just a related problem that doesn't necessarily need the 
same solution.

BR, Julian

Received on Tuesday, 11 March 2008 14:31:18 UTC