W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Tue, 11 Mar 2008 09:02:44 +0100
Message-ID: <47D63CA4.3000106@gmx.de>
To: Harry Halpin <hhalpin@ibiblio.org>
CC: ietf-http-wg@w3.org

Harry Halpin wrote:
>> We were sort of stuck with the naming of link relations; is this a
>> single space for HTML link elements, Atom link elements, and HTTP Link
>> headers? If yes, what's the syntax, and where does the registry go?
> I think Profile would answer that, by allowing the Link's to be typed on
> the HTTP level as regards "naming link relations."

Are we talking about the link relation name? Would it be problematic to 
just use "transformation"? (assuming there would be a registry)

> I tend to think of all the link relations being one single space, with
> serializations in HTML/Atom/HTTP Link. I believe Mark's last draft says
> re Profile "The Profile field is semantically equivalent to the profile
> attribute of the HEAD element in HTML [W3C.REC-html401-19991224].  Note,
> however, that its use is not limited to HTML entities" and for Link "
> The Link field is semantically equivalent to the <LINK> element in
> HTML." Is there any argument why this should not be so?

No, I think this is fine.

The problem I see is that the definition of the Profile attribute in 
HTML 4 is sort of weak. It allows multiple profiles, but if you do 
multiple profiles (such as for multiple microformats), it can't be used 
for disambiguation (ha! missing prefixes :-).

So when defining new link relations, I think it's wise to do so in a way 
that doesn't rely on profiles.

> It would be good to have a centralized registry of well-known Link
> types, with URIs to go along. But it's not necessary I think, and
> certainly not mandatory. W3.org space could easily be used for this. In
> general, the mechanism is totally decentralized.


>> I think the last discussion is around
>> <http://lists.w3.org/Archives/Public/ietf-http-wg/2007OctDec/thread.html#msg46>.
> The use of "rel" values should be considered, but are orthogonal to this
> discussion at this moment, since we need a HTTP method.


>>> We'd like to see this as an IETF-approved part of HTTP. Reviving
>>> Nottingham's draft would solve a big problem for us. In order for
>>> authors of documents on the Web to tell agents that there is a transform
>>> to get data out of their data, they need a link to the transform and the
>>> ability for the agent to tell that link is actually not just an ordinary
>>> link, but the link of a GRDDL transform. This is absolutely needed for
>>> the cases where the document owner may want to authorize to the
>>> transformation, but may not want to add the information to the header of
>>> *every* document in the collection or have access to the document. A
>>> use-case given by Ian Davis of Talis has been written in more detail
>>> [2].
>> I totally agree that it would be good to make progress, but I'm not
>> sure it's required for your work to proceed.
>> After all, the Link header *is* defined by RFC2068, so if you stick to
>> that definition and do stick to a simple link relation name, I
>> wouldn't expect any problems.
> I think it's the combo of Link and Profile that would make us truly
> happy, and it's what our code uses. Profile is not in that RFC.
>> Q: do you really need "Profile"?
> Profile is in general needed to type the Links. Otherwise, it might not
> be a GRDDL Link, it could be a Link to anything. Does that make sense?

Maybe I'm missing something, but 
<http://www.w3.org/TR/2007/WD-grddl-20070302/#grddlvocab> seems to 
indicate that there is a single link relation -- "transform". Are there 
other kinds of GRDDL link relations?

And if there are, exactly what problem does "Profile" use for you? Can 
you provide an example?

BR, Julian

PS: I'm really trying to understand whether Profile is going to help here.
Received on Tuesday, 11 March 2008 08:03:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:45 UTC