Re: Section 4: LDPR/non-LDPR formal definitions

hello richard.

> What's an LDP client supposed to do when it sees, say, a document that professes to be an ldp:Container, but is served using text/turtle? I suppose it would have to treat it as an opaque document, and not treat it as an LDP container?

same as a text/plain that contains HTML but is served as text/plain: 
it's a plain view of layered semantics not exposed by the resource.

> And what's an LDP server supposed to do when clients ask for text/turtle? Given that content negotiation is optional in LDP (and should remain so, to keep minimalistic servers possible), I suppose that many LDP server would have to refuse the request?

same as a server getting a request for text/plain even though it is 
serving web pages: "sorry, i don't have the plain text view you want to 
get. i am speaking HTML."

> The result would be that you're bifurcating the RDF world into a part that only handles text/ldp+turtle, and another part that only handles text/turtle, for no good reason.

it's like bifurcating the text world into generic text viewers, and HTML 
clients. it's a good reason to be explicit.

> I don't see how anybody wins in this scenario.

LDP wins, because now LDP clients don't have to (pretend to be) generic 
RDF clients (and the same is true for servers). they speak LDP and 
nothing else. they can make this explicit in HTTP conversations. how is 
that not a win for a protocol that explicitly intends to bridge RDF and 
non-RDF worlds?

cheers,

dret.

Received on Monday, 25 March 2013 20:07:38 UTC