Re: [Specifications] Add Use Case: Creating events indirectly (ie. with PUT)

I connected your W3C account to your GitHub account for you.

---

Review status: 0 of 1 files reviewed at latest revision, 15 unresolved discussions.

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 1 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcUoXZ9CSirPrVMr3o:-KxcUoXZ9CSirPrVMr3p:b-4cfvoz) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L1)):*
> ```Markdown
> ## Creating new event indirectly
> ```

Why do you call it "indirectly"? What's indirect about it?

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 6 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcUwM4IbV44gBrIv6X:-KxcUwM4IbV44gBrIv6Y:b52fpwe) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L6)):*
> ```Markdown
> 
> As an API publisher
> I want allow consumers to construct event's identifier
> ```

`event's identifier` -> event identifiers?

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 7 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcV-ElopVA4z9XGxI0:-KxcV-ElopVA4z9XGxI1:b29n2rp) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L7)):*
> ```Markdown
> As an API publisher
> I want allow consumers to construct event's identifier
> So that they can control the .
> ```

control what? The identifier? The URL?

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 10 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcV7lBobudR-WyuFut:-KxcV7lBobudR-WyuFuu:b-pmdzrc) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L10)):*
> ```Markdown
> 
> As an API consumer
> I want to be able to create new resources of a given type
> ```

... controlling parts of the URL (I think that's the point here, isn't it)?

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 34 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxZXSL5Owpv1cqTG5AR:-KxcUXmW9XbwsWsih1s8:b-227oga) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L34)):*
<details><summary><i>Previously, tpluscode (Tomasz Pluskiewicz) wrote…</i></summary><blockquote>

@alien-mcl See how I added the second `recursive` parameter. The indention is to search of operations in any linked resources. 

Also, is the native `filter` something you would do? Also, I realised now that it would return an Array. Should add indexer here...
</blockquote></details>

Hmm... that recursive parameter seems to open a can of worms. When should a client stop searching for the operation? It's easy to come up with an example that would crawl all of Wiki-/DBpedia

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 36 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxZY9gJ8iisuB-N2HfY:-KxcVNlmB9zgo7GNRLPI:b2cjisw) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L36)):*
<details><summary><i>Previously, tpluscode (Tomasz Pluskiewicz) wrote…</i></summary><blockquote>

@alien-mcl Here you see the second change where I added an optional parameter with template variables. Initially I was considering to have only one model - event and template var merged but I concluded it would break Single Responsibility in a way.
</blockquote></details>

An alternative that might be cleaner would be to first resolve the target of the operation to transform an abstract operation into a concrete one. [Expand is the name the URL Template spec uses for that process](https://tools.ietf.org/html/rfc6570#section-3).

```js
operation.expandTarget(templateVariables);
client.invoke(operation, event);
```

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 42 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcW88cm2en7sVc9HI0:-KxcW88cm2en7sVc9HI1:bhdobft) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L42)):*
> ```Markdown
> 
> To create an `Event` using `PUT`, the collection resource has to be linked to the actual target of the operation.
> This linked object can be a concrete resource or an `IriTemplate` as presented in the above snippet. In this case 
> ```

If it would be a concrete resource, it wouldn't create an Event, but replace that resource.

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 58 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxY28Opn5nMlgaMrFGV-r1-58:-KxcWQj80g_EQaYFgZxW:b-xfy893) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L58)):*
<details><summary><i>Previously, elf-pavlik (elf Pavlik) wrote…</i></summary><blockquote>

I agree that this PR does NOT introduce `manages` block here, I added it via https://github.com/HydraCG/Specifications/pull/132 and if we want to change it we should start dedicated Issue or PR for it
</blockquote></details>

+1.. but to answer the question: `manages` as currently defined only says that all members of the collection in this case are of type Event (nothing more and nothing less). I agree that we should find a better name for this.

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 64 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxYcL7VkgLlvZsRJlA4:-KxchO9K2joh3N6uUxFr:bs6z76y) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L64)):*
<details><summary><i>Previously, elf-pavlik (elf Pavlik) wrote…</i></summary><blockquote>

If you have some other specific Use Case, maybe you could describe it in depth, either in this PR, one of the open Issues or new PR. As I understand this Use Case we want to *create* a new resource of type *schema:Event* and have it appear as a member in this collection.
</blockquote></details>

What are the semantics that you want to express here? Can the client expect the created resource to be added to the collection? In other words, what's the relationship of the collection to the IriTemplate and the Operation? If the resource will become a member, something like a `hydra:memberTemplate` might be preferable (see also https://github.com/HydraCG/Specifications/issues/16)

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 72 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxchCDgCDQQ4nzkMnf4:-KxchCDgCDQQ4nzkMnf5:b-5cv5ab) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L72)):*
> ```Markdown
>                 "@type": "hydra:IriTemplateMapping",
>                 "variable": "slug",
>                 "property": "xsd:String",
> ```

This is a datatype, not a property. It should be something like `schema:name` or `example:slug`

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 97 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxciNXcDOyiU5-EUn3l:-KxciNXcDOyiU5-EUn3m:b34po0z) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L97)):*
> ```Markdown
> ``` json
> {
>     "@context": "/api/context.jsonld",
> ```

This is problematic. What is this URL relative to? How should the server receiving it interpret it (and thus the rest of the document)?

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 116 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcirKWssEpfkdjX8eA:-KxcirKWssEpfkdjX8eB:b-7rktc9) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L116)):*
Not this specification but it would be a violation of the [HTTP specification](https://tools.ietf.org/html/rfc7231#section-4.3.4):

>   The PUT method requests that the state of the target resource be
>   created or replaced with the state defined by the representation
>   enclosed in the request message payload.  A successful PUT of a given
>   representation would suggest that a subsequent GET on that same
>   target resource will result in an equivalent representation being
>   sent in a 200 (OK) response.  However, there is no guarantee that
>   such a state change will be observable, since the target resource
>   might be acted upon by other user agents in parallel, or might be
>   subject to dynamic processing by the origin server, before any
>   subsequent GET is received.  A successful response only implies that
>   the user agent's intent was achieved at the time of its processing by
>   the origin server.
>   [...]
>   The fundamental difference between the POST and PUT methods is
>   highlighted by the different intent for the enclosed representation.
>   The target resource in a POST request is intended to handle the
>   enclosed representation according to the resource's own semantics,
>   whereas the enclosed representation in a PUT request is defined as
>   replacing the state of the target resource.  Hence, the intent of PUT
>   is idempotent and visible to intermediaries, even though the exact
>   effect is only known by the origin server.

---

*[drafts/use-cases/5.1.creating-new-event-indirectly.md, line 124 at r1](https://reviewable.io:443/reviews/hydracg/specifications/143#-KxcjZT6dVJharDWu_oJ:-KxcjZT6dVJharDWu_oK:b-r96uzq) ([raw file](https://github.com/hydracg/specifications/blob/f03e3028e6417adf2767a44c0c854b4af3b5fb4d/drafts/use-cases/5.1.creating-new-event-indirectly.md#L124)):*
> ```Markdown
> 
> Even though the `schema:CreateAction` operation exists within the collection's representation it is not right to assume that
> the newly created event will become part of the collection, ie. it's `"hydra:member"` property. What's more, a single
> ```

So, why is it then associated to the Collection at all?

---


*Comments from [Reviewable](https://reviewable.io:443/reviews/hydracg/specifications/143#-:-KxcU9AESLztEOJKLf_H:b-bvaml4)*
<!-- Sent from Reviewable.io -->


-- 
GitHub Notification of comment by lanthaler
Please view or discuss this issue at https://github.com/HydraCG/Specifications/pull/143#issuecomment-340270420 using your GitHub account

Received on Sunday, 29 October 2017 15:27:29 UTC