- From: Tomasz Pluskiewicz via GitHub <sysbot+gh@w3.org>
- Date: Sat, 17 Mar 2018 21:14:57 +0000
- To: public-hydra-logs@w3.org
> i think pseudo code above doesn't need that templateVariables assignment and can just use value from the event client intends to create
I do not agree. With a URI template I don't think we should assume that the mappings are derived from the actual request representation. They could and the actual event would be used to fill in the template
``` js
var newEvent = {};
/* ... */
const operationWithTargetExpanded = operation.expandTarget(newEvent);
client.invoke(operationWithTargetExpanded, newEvent);
```
But from the client (library) perspective I think these should be kept separate.
---
Review status: all files reviewed at latest revision, 8 unresolved discussions.
---
*[drafts/use-cases/0.intro.md, line 61 at r3](https://reviewable.io:443/reviews/hydracg/specifications/154#-L7phzWK_cLAGjwnFap_:-L7phzWK_cLAGjwnFapa:b7f0c99) ([raw file](https://github.com/hydracg/specifications/blob/fa23516a0e71bf50633726d839217103245d7544/drafts/use-cases/0.intro.md#L61)):*
> ```Markdown
> },
> "target": {
> "@id": "hydra:target",
> ```
So we want this to be `"@reverse": "hydra:operation"`?
---
*[drafts/use-cases/1.1.security-considerations.md, line 35 at r3](https://reviewable.io:443/reviews/hydracg/specifications/154#-L5Fjs7pVaFH-CFN_F4A:-L7piYXPKKdVnnTqf-T9:b7lnxid) ([raw file](https://github.com/hydracg/specifications/blob/fa23516a0e71bf50633726d839217103245d7544/drafts/use-cases/1.1.security-considerations.md#L35)):*
> This just makes the benefits from action event less tempting
There is one good benefit. Instead of minting properties like `hydra:search`, the API can group all possible actions (:tada:) together. A client may not understand the semantics if they use something unexpected (aka not schema.org) but the implementation will be simpler to present the possible options to the client.
> BTW. How would you pick the operation matching a desired protocol?
I'd say this is outside of the scope of the API description.
---
*[drafts/use-cases/1.entry-point.md, line 94 at r3](https://reviewable.io:443/reviews/hydracg/specifications/154#-L6qKMefMi47gmHpdvUv:-L7pkg3Bl8adK8c1NgWL:bxhrcbk) ([raw file](https://github.com/hydracg/specifications/blob/fa23516a0e71bf50633726d839217103245d7544/drafts/use-cases/1.entry-point.md#L94)):*
<details><summary><i>Previously, lanthaler (Markus Lanthaler) wrote…</i></summary><blockquote>
For embedded actions/operations it is, yeah. But it may be fine as they would only be used rarely. @elf-pavlik could you please add an example illustrating how this would work in a `ApiDocumentation`? We would likely support two cases there: a) explicit target and b) implicit target that depends, e.g., on a resource's class
</blockquote></details>
Oh yeah, this was bugging me. In general we have symmetry between ApiDocumentation and inline affordances
* `operation` => `supportedOperation`
* `property` => `supportedProperty`
Actions looked to me like an inline-only feature...
---
*[drafts/use-cases/5.1.creating-event-with-put.md, line 67 at r1](https://reviewable.io:443/reviews/hydracg/specifications/154#-L2FGn5gasTIWY81_mpI:-L7pn15TETn7vUI4D8xF:b-djvsm8) ([raw file](https://github.com/hydracg/specifications/blob/aa28c5c639dde02c9aacfaf7f5d7121b0d7caa3b/drafts/use-cases/5.1.creating-event-with-put.md#L67)):*
<details><summary><i>Previously, lanthaler (Markus Lanthaler) wrote…</i></summary><blockquote>
Yes. Pavlik already replaced it's need for PUTs here. We could do the same for GETs by adding the following action
```
{
"@type": "schema:DiscoverAction",
"title": "Directly access a member of the collection (if it exists)",
"operation": {
"@type": "Operation",
"method": "GET",
"target": {
"@type": "IriTemplate",
"template": "http://example.com/api/event{/slug*}",
"variableRepresentation": "BasicRepresentation",
"mapping": [
{
"@type": "IriTemplateMapping",
"variable": "slug",
"property": "schema:name",
"required": true
}
]
}
}
}
```
</blockquote></details>
Good one! Another reason to like `actions` where they help us reduce the overall number of concepts (other being `hydra:search`)
---
*[drafts/use-cases/5.1.creating-event-with-put.md, line 28 at r3](https://reviewable.io:443/reviews/hydracg/specifications/154#-L6qL2xZ0izObS8VgEvs:-L7plQx51I_GOK-vU46v:b-z40661) ([raw file](https://github.com/hydracg/specifications/blob/fa23516a0e71bf50633726d839217103245d7544/drafts/use-cases/5.1.creating-event-with-put.md#L28)):*
> `getOperationsForAction()`
:+1:
---
*[drafts/use-cases/5.1.creating-event-with-put.md, line 33 at r3](https://reviewable.io:443/reviews/hydracg/specifications/154#-L6qLS1rPACGmw8J2dm2:-L7pl4ZoUwpgBObqJBnE:bt6qirt) ([raw file](https://github.com/hydracg/specifications/blob/fa23516a0e71bf50633726d839217103245d7544/drafts/use-cases/5.1.creating-event-with-put.md#L33)):*
<details><summary><i>Previously, lanthaler (Markus Lanthaler) wrote…</i></summary><blockquote>
I agree with Pavlik that the application using Heracles should provide the property and not know anything about the variable name as it is an implementation detail that may change at any time.
</blockquote></details>
Well, both can change :slightly_smiling_face:. But neither is out-of-bounds so there is not issue with allowing either. After all this information comes from the template mappings.
Still, I don't understand why two value concatenated into one string. What if one was to have spaces? :) And full URL should be used (or possibly proper JSON-LD)
``` json
{
"http://schema.org/name": [
{ "@value": "meeting" },[
{ "@value": "with will" }
]
}
```
---
*[drafts/use-cases/7.searching-events.md, line 19 at r1](https://reviewable.io:443/reviews/hydracg/specifications/154#-L2FHzTqp1okBeqnrpBL:-L7pnQF1AaLzZSi76bj0:b7t1ezl) ([raw file](https://github.com/hydracg/specifications/blob/aa28c5c639dde02c9aacfaf7f5d7121b0d7caa3b/drafts/use-cases/7.searching-events.md#L19)):*
<details><summary><i>Previously, tpluscode (Tomasz Pluskiewicz) wrote…</i></summary><blockquote>
Ah yes, what I commented above. Would see it more like
```
var operation = client.get(string).getActionOfType(string).operation
```
</blockquote></details>
Actually, I like Markus' suggestion above better.
---
*[drafts/use-cases/7.searching-events.md, line 72 at r3](https://reviewable.io:443/reviews/hydracg/specifications/154#-L7pnYSMDeJ6U5y0ECUB:-L7pnYSMDeJ6U5y0ECUC:bn03c3i) ([raw file](https://github.com/hydracg/specifications/blob/fa23516a0e71bf50633726d839217103245d7544/drafts/use-cases/7.searching-events.md#L72)):*
> ```Markdown
> }
> ],
> "action": {
> ```
Yes! Kill it, kill it :fire:
Why not just remove `search` and `memberTemplate` from the vocabulary with this very PR... (if it hasn't been done yet)
---
*Comments from [Reviewable](https://reviewable.io:443/reviews/hydracg/specifications/154#-:-L7ph9OB12E-05mZG4GC:b-f7vxwy)*
<!-- Sent from Reviewable.io -->
--
GitHub Notification of comment by tpluscode
Please view or discuss this issue at https://github.com/HydraCG/Specifications/pull/154#issuecomment-373953150 using your GitHub account
Received on Saturday, 17 March 2018 21:15:00 UTC