RE: Specifying operations for instances

> -----Original Message-----
> From: Markus Lanthaler [mailto:markus.lanthaler@gmx.net]
> Sent: Wednesday, June 18, 2014 9:51 PM
> To: public-hydra@w3.org
> Cc: McBennett, Pat
> Subject: RE: Specifying operations for instances
> 
> On 18 Jun 2014 at 09:53, McBennett, Pat wrote:
> > Markus Lanthaler wrote on June 15, 2014 8:09 PM:
> >> On 14 Jun 2014 at 23:27, Tomasz Pluskiewicz wrote:
> >>> I understand that the resource still supports the DELETE because it
> >>> is an instance of the ForumPost class. But in very practical terms,
> >>> would you consider the absence of the DELETE operation in the
> >>> instance's representation a good enough clue for the client not to
> >>> render a delete button?
> >>
> >> Yes, with the caveat that the ApiDocumentation doesn't tell me
> otherwise.
> >
> > Ok, I totally agree here, but this seems to be contradicted below at [1]...
> 
> a)
> 
> [...]
> 
> >>> I meant the guidelines would be more appropriate than rules.
> >>>
> >>> I think what's missing is or vague is:
> >>> 1. what clients should assume if a resource representation has some
> >>> but not all of the supported operations defined by it's class
> >>
> >> The operations associated to the resource itself and the ones
> >> associated to its class are merged. After that, they are
> >> indistinguishable. Again, it doesn't matter where the operations are
> asserted.
> 
> b)
> 
> > [1]... but if this is the correct assumption, then won't the client
> > always have to render the DELETE button in the example above? There
> seems to be a clear inconsistency here...
> 
> No. Example a) might looks like this:
>   ApiDocumentation: ForumPost supportedOperation x, y, does *not* include
> DELETE
>   /posts/a operation z, *not* a DELETE
> 
> No DELETE in the representation of /posts/a and the ApiDocumentation also
> "doesn't tell me otherwise", i.e., also doesn't include a DELETE.
> 
> Example b) might look like this
>   ApiDocumentation: ForumPost supportedOperation x, y, does *not* include
> DELETE
>   /posts/b operation x (again, *not* a DELETE)
> 
> The representation of /posts/b includes some (x) but not all (y is missing)
> operations know to be supported by instance of the class ForumPost.
> 
> Thus,
>    /posts/a has the following operations: x, y, z
>    /posts/b has the following operations: x, y
> 
> Where do you see "the clear inconsistency" Pat?

(Sorry for the delay in replying - work and travel getting in the way!)  So yes, I still see an inconsistency. Let me try to illustrate reusing your examples.

From the original a) above '...would you consider the absence of the DELETE operation in the instance's representation a good enough clue for the client not to render a delete button?' - Markus: 'Yes...'

So I interpreted Tomasz's original description as saying that the following scenario existed:

c)
ApiDocumentation: ForumPost supportedOperation x, y, *does* include DELETE
/posts/a operation z, *not* a DELETE

...in which case Tomasz's UI would probably render a DELETE button for '/posts/a' (since the DELETE operation *is* present in the API documentation), *but* that button would be grayed out and disabled (since the DELETE operation *is not* present in the instance's representation). That's what I was agreeing with, and I thought you were saying 'Yes' to too.

But in b), you then stated that the '...the operations associated to the resource itself and the ones associated to its class are merged. After that, they are indistinguishable', which seemed to imply that we must always 'merge' the operations from the API documentation and the resource instance, which from my c) above would mean:

/posts/a operation z, x, y, DELETE (i.e. I must 'merge' all operations from the API doc and the resource instance.)

And therefore Tomasz's UI should now render the DELETE button as *enabled* (as well as enabling operations for z, x and y of course, when in fact the only operation '/posts/a' actually supports right now is 'z').

I'm pretty sure that wasn't your intended meaning. I think you probably meant 'additional operations appearing in the resource instance at runtime should be included (or considered 'enabled') by the client, even if they never appeared in the API documentation, whereas operations declared in the API documentation, but missing from the resource instance can be considered 'Unavailable (or 'disabled') at this time''. But anyway that's where I was seeing the inconsistency.

I think we were just seeing Tomasz's original formulation differently (i.e. I was seeing it as c) above, whereas you thought of it as 'No. Example a) might looks like this:' above?). Is that clearer...?

Pat.

> 
> 
> --
> Markus Lanthaler
> @markuslanthaler

Received on Thursday, 3 July 2014 21:40:46 UTC