- From: Karol Szczepański via GitHub <sysbot+gh@w3.org>
- Date: Fri, 06 Jan 2023 21:01:43 +0000
- To: public-hydra-logs@w3.org
Oh dear - so many comments I don't where to start. @tpluscode > Existing implementations which do not understand the "availability" will inevitably interpret as an inline operation. Fair point - maybe introducing `hydra:ForbiddenOperation` is better. I don't like the `hydra:target` approach - I'd prefer to stick the forbidden operation to the resource. We had some discussions about _actions_, but it died several years ago and I don't feel we want to dig it out now. @asbjornu > If we could fix it in ApiDocumentation instead, I think that would be much better. I don't feel like we want to change that part - it exists there as it is not for several years and fundamental changes in that matter introduced in the last feature I acknowledge a completion for the hydra would be a wrong move. >I think it's actually better to remove hydra:supportedOperation from the ApiDocumentation entirely than to make ApiDocumentation dynamic. ApiDocumentation being dynamic is just not something developers will expect. While API Documentation can change in time for obvious reasons (new features in the API, etc.), I don't feel like it should be considered a dynamic resource. Hydra does not mandate to stick to either API documentation or inlined hypermedia controls. I heard of implementations using purely API documentation approach as well as of implementations that were fully API documentation ignorant (pure inline hypermedia approach). The only the that hydra requires is an existence of the API Documentation that points to an entry point(s). -- GitHub Notification of comment by alien-mcl Please view or discuss this issue at https://github.com/HydraCG/Specifications/pull/246#issuecomment-1374126782 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 6 January 2023 21:01:44 UTC