Re: ldp-ISSUE-30 (bugtrack): Hierarchical bugtracking service [Use Cases and Requirements]

On 07/11/12 22:23, Richard Cyganiak wrote:
> On 7 Nov 2012, at 22:08, Andy Seaborne wrote:
>
>>
>>
>> On 07/11/12 22:00, Richard Cyganiak wrote:
>>>
>>> On 7 Nov 2012, at 16:31, Andy Seaborne wrote:
>>>
>>>>
>>>>
>>>> On 05/11/12 15:39, Linked Data Platform (LDP) Working Group Issue Tracker wrote:
>>>>>   POST /SomeProduct { <> a :Bug } yields { /Bugz/bug2 a :Bug }
>>>>
>>>> I read that as a response of 201/"Location: /Bugz/bug2" and
>>>> content { /Bugz/bug2 a :Bug } at /Bugz/bug2.
>>>>
>>>> Presumably POSTing { <> a :FeatureRequest } causes a different template for the URI allocated:
>>>>
>>>> Location: /Feature/request2331
>>>
>>> I'm not sure that would work with the current design. If bugs and features have different URI templates, then probably you also want different membership properties:
>>
>> not sure that I understand what "current design" means
>
> I mean what's in the ED. In this regard it's still the same as the FPWD.

OK - but should it work?

There is a case for specing something relatively unambitious fully 
expecting a follow-on WG in a few years time when more experience is 
available.

But if it's too simple, all the real work is beyond the spec and you 
have several sub-communities doing various things and it is hard to 
reconcile in a v2 WG.

It is import in scoping to decide what is not covered as an explicit 
decision.  That's UC&R (?).  Doing everything isn't necessary but too 
narrow a focus will block future standards work (it will be an 
incompatible v2 with all the problems of getting community acceptance 
that brings).

	Andy

>
>> nor where "URI templates" come from - pointer?
>
> Not a pointer but a quote:
>
>>> On 7 Nov 2012, at 16:31, Andy Seaborne wrote:
>
>>>> Presumably POSTing { <> a :FeatureRequest } causes a different template for the URI allocated:
>
>
> Best,
> Richard
>
>
>
>>>    </SomeProduct>
>>>      :bug </Bugz/bug2>;
>>>      :feature </Feature/request2331>.
>>>
>>> To get different properties, you need to POST to different containers. So the client needs to decide what container to POST to, and that decision will determine the URI pattern and the property to be used, and not information in the payload. Which seems mostly fine to me.
>>>
>>>> This is a great example - the data has driven the server's decisions on the response.
>>>
>>> Right, and if it works this way, then the client doesn't need to know that :Bugs go into the one container and :Features into the other; the server can sort this out by looking at the request. That's an advantage.
>>>
>>> On the other hand, the more of this logic is in the server, and kept out of the client-server protocol, the less the server is able to communicate to the client what it's going to do with the payload.
>>>
>>> Best,
>>> Richard
>>>
>>>
>>>
>>>>
>>>> 	Andy
>>>>
>>>
>>>
>>
>
>

Received on Thursday, 8 November 2012 11:12:06 UTC