Hydra W3C Community Group Telecon
Minutes for 2018-03-19
- Agenda
- n/a
- Topics
- Action Items
- Scribe
- Karol Szczepański
- Present
- Karol Szczepański, elf Pavlik, Tomasz Pluskiewicz
- Audio Log
Karol Szczepański is scribing.
Topic: PR-154
Tomasz Pluskiewicz: https://reviewable.io/reviews/hydracg/specifications/154
elf Pavlik: there is a comment related to which part of parameters should go into the body and which into the IRI template
Tomasz Pluskiewicz: Question is wether template variables should be extracted from solely body of the resource or there are other sources
All: we agree on the fact that the resource cannot be the only source of arguments/parameters
elf Pavlik: idea was to make the API operation agnostic - the difference in the example was only in the HTTP verb, no other differences related to filling the 'slug' parameter should be rellevant
Tomasz Pluskiewicz: how about switching both UC5 and UC5.1 to use new id so the resulting event ends up with same URL
elf Pavlik: lets focus on Markus's example and use some UUID parameter
Tomasz Pluskiewicz: We shouldn't assume that all the resource's property are good fit for URL parameters
elf Pavlik: maybe we should multiply examples with slugs and UUId (either augogenerated by client or server)
Tomasz Pluskiewicz: the slug is not the issue, UUID generation is not the purpose of the client (i.e. some custom form for UUID generation) and then we should provide two objects to the request, one with target resource, another with additional parameters
elf Pavlik: IRI variables are only mappings for properties
elf Pavlik: question is what is a subject in the variable mappings (i.e. payload is the subject), which is unknown here
elf Pavlik: same with UUID, we don't know whether it should be a value of the payload or it should be taken from other place
Tomasz Pluskiewicz: I've started somehow related questions in #152
elf Pavlik: take the snipped from Markus's example and based on this modify UC5.1 to rely on client not undestanding an UUID property
Karol Szczepański: how the PR154 for actions is related to that issue we're discussing
elf Pavlik: Actions are defining how the resource is related to the request/operation as it works on one request, and the operation may be related on other resource
Karol Szczepański: I've got a gut feeling that the issue related to resource/template interpretation is big enough to have a separate PR and is a tool to achieve the PR154 for actions
elf Pavlik: I could modify the use case to put an explicit UUID so the variable mapping is not a concern in the PR154
Karol Szczepański: this way we could focus on the actions in PR154 and introduce a separate Heracles.ts PR related to IRI template and the operation invocation API
elf Pavlik: my another effort would be to have some 'like' example so the actions could come in handy and provide more details on the PR154
Tomasz Pluskiewicz: one more thing I wanted to understand about actions and the API documentation relation
elf Pavlik: you couldn't define an operation that uses PUT on another operation in the API documentation, Actions would allow you to do it
Tomasz Pluskiewicz: supported operations of a supported property allows that
Karol Szczepański: also IRI template used as a parent of the operation could allow that
Tomasz Pluskiewicz: these are possibilites, but these are not communicated properties
elf Pavlik: how UC5.1 could be described in the API documentation? Can you look at it with existing possibilities?
Tomasz Pluskiewicz: let's start a new issue: How to perform UC5.1 in API documentation
ACTION: Pavlik modify UC5 and UC5.1 to use UUID instead of slug
ACTION: Pavlik actions and operations in API documentation (PR154 in API documentation)
ACTION: Karol introduce API changes in the Heracles.ts for IRI templates
ACTION: Tomasz will start issue: How to perform UC5.1 in API documentation