Re: [Specifications] Retracting operations (#246)

Thanks @asbjornu for detailed explanation. I'd love to deliberate more...

> One suggested way to deal with this is to not treat ApiDocumentation as a static resource, but instead re-request every time it changes.

It won't change anything - API documentation can be static resource that barely changes over time making a client effectively not re-requesting it. Also I don't see how re-requesting would help event if it changes - the operation in context may be unchanged at all.

> To treat out-of-bound metadata such as ApiDocumentation just as dynamic as the requested resource, however, is unintuitive. I don't think that's going to sit well with many developers.

I agree - I don't think we want to go this way.

> This means that auto-generated clients cannot make hydra:supportedOperation available on resource instances

I dare to disagree. As you've already noted, `hydra:supportedOperation` specifies an operation on the definition level - it's a way of extending a class with new features. If an instance of that very class, it must comply or it shouldn't be considered that class.

> instead, the operations are infrastructure that is used only when the hydra:operation in a response indicates that the operation should be available.

There would be no need for `hydra:supportedOperation` as inlined `hydra:operation` is fully sufficient. The `hydra:supportedOperation` was not mean to work like that and we won't change it in the spec - it would break everything in that matter that exists now.

@inf3rno, I was thinking about your statement:

> The upper is sort of query all except some. The other approach is query some. After adding NOT support, the next will be adding AND and OR support and more operators for comparison.

I don't think it has to do anything with querying. I'd stick to simple operations on sets (I believe set difference matches this case). Ok, matching operation may not be that simple (that's why I initially suggested direct operation IRI comparison), but it's doable event with simple clients.

Anyway, I seek for consensus on simple thing: do we need such a feature or shall we leave the clients with raw protocol responses - server will forbid an operation and the client will get to know about that sooner or later (later in this case)



-- 
GitHub Notification of comment by alien-mcl
Please view or discuss this issue at https://github.com/HydraCG/Specifications/pull/246#issuecomment-1370276047 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 3 January 2023 22:10:16 UTC