- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Fri, 09 Feb 2007 09:40:09 +0000
- To: Ian Davis <ian.davis@talis.com>
- CC: Dan Connolly <connolly@w3.org>, public-grddl-wg@w3.org, "Carroll, Jeremy John" <jeremy.carroll@hp.com>
Agreed. I was unaware of that draft. It adds the clarity that I was after. A further issue from that draft is: The Link field is semantically equivalent to the <LINK> element in HTML. and The Profile field is semantically equivalent to the profile attribute of the HEAD element in HTML [W3C.REC-html401-19991224]. If the code were to treat the Profile field identically to that in the HEAD, then I would dereference profiles other than the GRDDL one, to see whether they had a profileTransformation. Also, a LINK header, could be used with a profile attribute inside the document, and vice-versa. I was thinking, and have currently implemented, that the HTTP header mechanism and the mechanisms triggered by document content were independent and do not interact. I hope the final document will clarify. I will see if I can produce tests on the points above. (Depends a bit - I have to interact with a system admin at sourceforge) Jeremy Ian Davis wrote: > On 08/02/2007 11:08, Jeremy Carroll wrote: >> >> >> I thought a bit about the spec for this (the earlier e-mail in the >> thread) and felt it could be improved. >> It was a little unclear what I need to be looking for in the values. >> >> Suggestions: >> 1) drop the "<" and ">" quoting the URIs; not used elsewhere in HTTP >> Headers (I think) >> 2) Use transformation as a token, rather than "transformation" a >> quoted string, as the value of rel. >> 3) provide grammar, extensibility, etc for these headers e.g. >> > My preference is to retain compatibility with the header as specified in > RFC2068 and continued in draft-nottingham-http-link-header-00 > > Ian
Received on Friday, 9 February 2007 09:40:58 UTC