200 OK with Content-Location might work: But maybe it can be simpler?

How about something that's totally independant from HEADER issues?

think normal people here. absolutely 0 interest to mess with headers
and http responses.. absolutely no business incentive to do it.

as a baseline think someone wanting to annotate with RDFa a hand
crafted, apached served html file.
really.. as simple as serving this people.

as simple as anyone who's using opengraph just copy pastes into their
HTML template.. as simple as this
really, please, its the only thing that can work?

Giovanni

On Fri, Nov 5, 2010 at 5:55 PM, Nathan <nathan@webr3.org> wrote:
> Mike Kelly wrote:
>>
>> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-12#page-14
>
> snipped and fuller version inserted:
>
>   4.  If the response has a Content-Location header field, and that URI
>       is not the same as the effective request URI, then the response
>       asserts that its payload is a representation of the resource
>       identified by the Content-Location URI.  However, such an
>       assertion cannot be trusted unless it can be verified by other
>       means (not defined by HTTP).
>
>> If a client wants to make a statement  about the specific document
>> then a response that includes a content-location is giving you the
>> information necessary to do that correctly. It's complemented and
>> further clarified in the entity body itself through something like
>> isDescribedBy.
>
> I stand corrected, think there's something in this, and it could maybe
> possibly provide the semantic indirection needed when Content-Location is
> there, and different to the effective request uri, and complimented by some
> statements (perhaps RDF in the body, or Link header, or html link element)
> to assert the same.
>
> Covers a few use-cases, might have legs (once HTTP-bis is a standard?).
>
> Nicely caught Mike!
>
> Best,
>
> Nathan
>
>

Received on Friday, 5 November 2010 17:25:40 UTC