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

Julian Reschke wrote:
>
> Harry Halpin wrote:
>> Hi, I'm Harry Halpin, and I'm working on GRDDL (Gleaning Resource
>> Descriptions from Dialects of Language) with the W3C, a rather neat
>> technology that helps us get uniform metadata from diverse XML, (X)HTML,
>> microformats, and (hopefully soon) HTML documents using a simple mix of
>> widely deployed technologies.
>
> Looking forward to the HTML binding :-)
Ah, that hasn't yet been truly decided  yet either. I think the same
people and code that want URIs in HTTP have also sent a few messages to
HTML 5 saying we'd like something like that kept.
>> I'd just like to send a e-mail to see if we can revive Mark Nottingham's
>> "HTTP Header Linking Draft", from which we in particular would like to
>> see the Link and Profile headers revived [1]. What's the current status
>> of this idea?
>
> 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."

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?

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?
>> ...
>
> BR, Julian
>


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Monday, 10 March 2008 22:52:30 UTC