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

hello mark.

On 2013-06-05 15:02 , Mark Baker wrote:
> On Wed, Jun 5, 2013 at 3:20 PM, Erik Wilde <dret@berkeley.edu> wrote:
>> 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.

sure, you can try all possible interactions with all possible URIs all 
day long, but it's rather unlikely that you will get anything done this 
way, right? unless you're randomly trying to change state of random 
resources, but that's not the goal most clients have.

> 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.

it also governs your interactions with those. and that's the important 
part. if i send you the form/@action URI of an HTML form, it's pretty 
unlikely that you'll be able to do anything useful. you need two things 
to do something useful: you need the runtime info about what kind of 
inputs that form processor accepts. you also need the media type info 
given in the HTML spec that tells you how to encode those values to 
create a meaningful form dataset. you need to know the rules of the 
interaction to be able to successfully engage in a conversation.

>> 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.

no you didn't. if you have time, can you please try again? how does a 
client that does not know LDP know that it has to follow certain rules 
when it wants to use LDP services?

> 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.

if that were the case, the HTML spec would not need to say anything 
about how to encode form values. all you would need to say is which HTTP 
method to use for form/@action, and you should be good to go. HTTP is 
the foundation for interactions, but for any non-trivial interactions, 
you need to know how to use HTTP interactions in the context of the 
protocol defined by the media type. of course you can "interact" with an 
HTML form processor without knowing the HTML media type (send random 
requests to it), but in order to get your job done, you need to know the 
form, and you need to know HTML.

so i guess strictly speaking you're of course right, HTTP makes 
interactions possible. but in order to write meaningful clients that can 
successfully interact with the services they need to use to get their 
jobs done, you need to understand the rules under which they operate.

cheers,

dret.

Received on Thursday, 6 June 2013 00:34:21 UTC