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


Erik, 

A web browser which doesn't know the form elements of HTML would be operational for viewing and navigation between documents. It would just miss out on a number of interaction possibilities. 

So, I don't quite understand why we can't just use 'text/turtle' (?) If the client is a read-only LD client, it can navigate the data in the usual (readable) way and make no special case for ldp: vocab. However, for a generic LDP client, it can interpret it in the special (for writing) way. We need forms for RDF before we get to this generic LDP client.
  
Roger