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

On Wed, Jun 5, 2013 at 8:33 PM, Erik Wilde <dret@berkeley.edu> wrote:
> 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.

Sure, but my point there was that media type knowledge is not a priori
required in order to form meaningful HTTP messages. It seems like we
agree on that.

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

Maybe we could make this concrete with an example, because I'm quite
certain I've answered that question already. Can you provide an
example of some LDP RDF and the rules that are required to be known by
clients?

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

That's true, but the devil's in the details regarding "rules"; some
are fine (like the application/x-www-form-urlencoded knowledge for
HTML), but many are not, particularly those that attempt to change the
uniform interface (which is surprisingly easy to do, without intending
to). Time for that example, I think.

Mark.

Received on Thursday, 6 June 2013 19:26:28 UTC