Re: Proposal to close ISSUE-19: Adressing more error cases, as is

On Wed, Jun 5, 2013 at 3:20 PM, Erik Wilde <dret@berkeley.edu> wrote:
>> That's not the case. Any URL can be DELETEd a priori without knowledge
>> of Atom or what rel=edit means. The resource may not be deleted of
>> course, due to permissions (e.g. 401), capability (e.g. 501), or other
>> issues, but that doesn't change the fact that the message's meaning is
>> unambiguous and required no additional information beyond the URI
>> itself.
>
>
> c'mon mark, you're better than this. you cannot conveniently cherry-pick the
> one method that is hard-coded and requires no request body, and ignore all
> the much more interesting interactions you need in real-world applications
> where you need to know what you can and cannot PUT, POST, or PATCH, and what
> it actually means to do that.

I just used the method you chose, but the truth is it doesn't matter;
substitute any other HTTP method for "DELETE" and the answer would be
the same. For example, I can try to PUT an image at any URI. I can try
and POST a JSON document to any URI.

Nothing about the media type changes that. What the media type does is
- if required - help me pick the right URIs and media types (for
outbound bodies) I might actually want to use to Get Stuff Done.

>
>
>>>> what is the general mechanism that tells me how to go from "this is
>>>> text/turtle" to "I can interact with it as defined in the LDP spec">
>>
>> So to try to answer that again :) ... the mechanism is term grounding
>> via namespaces in RDF, but that only takes you to the tiny part of the
>> spec that defines that term; it cannot and should not inherit all the
>> conformance criteria of the totality of the referenced specification
>> (because there shouldn't be any there, as I've said before) or
>> anything else that would, in effect, change the (uniform) interface.
>
>
> that's basically kingsley's argument saying that "since RDF can describe
> anything and everything this will probably also work. somehow. i am just not
> telling you how." so, please treat alexandre and me to explaining how the
> general model you're referring to solves the concrete question of figuring
> out (at runtime!) how interactions based on methods such as PUT, POST, and
> PATCH work, without having any prior knowledge of the vocabulary that's
> being used.

Hopefully I did, above. I don't think you and I disagree about how
that looks from a well-designed media type POV, but we do seem to
disagree about what is possible in the presence of an unknown type.

Media types don't make interactions possible (HTTP does that). They
simply guide them.

Mark.

Received on Wednesday, 5 June 2013 22:02:54 UTC