Deleting an activity

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Deleting an activity

Werner Donné

Hi,

When an activity is deleted all references to it should be removed.
Versions that have the activity in their activity-set, for example,
should have their activity-set updated. Versions, which were created
on a branch represented by the activity, all of the sudden are not
on that branch anymore and in an implicit way. This seems rather
strange and dangerous. Would it be allowed to reject the deletion
of the activity in this case?

Regards,

Werner.
--
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Deleting an activity

Manfred Baedke

Hi Werner,

This is of course allowed, IMHO. More generally, a server is allowed to
reject the deletion of any resource for whatever reason.

Regards,
Manfred

Werner Donné wrote:

> Hi,
>
> When an activity is deleted all references to it should be removed.
> Versions that have the activity in their activity-set, for example,
> should have their activity-set updated. Versions, which were created
> on a branch represented by the activity, all of the sudden are not
> on that branch anymore and in an implicit way. This seems rather
> strange and dangerous. Would it be allowed to reject the deletion
> of the activity in this case?
>
> Regards,
>
> Werner.
>  

Reply | Threaded
Open this post in threaded view
|

Re: Deleting an activity

Werner Donné

Hi Manfred,

Shouldn't then a pre-condition be added in section 13.8 of RFC 3253,
analogous to the one in section 3.13?

Regards,

Werner.

Manfred Baedke wrote:

> Hi Werner,
>
> This is of course allowed, IMHO. More generally, a server is allowed to
> reject the deletion of any resource for whatever reason.
>
> Regards,
> Manfred
>
> Werner Donné wrote:
>> Hi,
>>
>> When an activity is deleted all references to it should be removed.
>> Versions that have the activity in their activity-set, for example,
>> should have their activity-set updated. Versions, which were created
>> on a branch represented by the activity, all of the sudden are not
>> on that branch anymore and in an implicit way. This seems rather
>> strange and dangerous. Would it be allowed to reject the deletion
>> of the activity in this case?
>>
>> Regards,
>>
>> Werner.
>>  
>
>

--
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Deleting an activity

Manfred Baedke
Hi Werner,

being a MAY requirement, the precondition definition in section 3.13 is nothing really normative. Maybe its only me, but I find the concept of a precondition containing only MAY requirements rather strange.

Regards,
Manfred

Werner Donné wrote:
Hi Manfred,

Shouldn't then a pre-condition be added in section 13.8 of RFC 3253,
analogous to the one in section 3.13?

Regards,

Werner.

Manfred Baedke wrote:
  
Hi Werner,

This is of course allowed, IMHO. More generally, a server is allowed to
reject the deletion of any resource for whatever reason.

Regards,
Manfred

Werner Donné wrote:
    
Hi,

When an activity is deleted all references to it should be removed.
Versions that have the activity in their activity-set, for example,
should have their activity-set updated. Versions, which were created
on a branch represented by the activity, all of the sudden are not
on that branch anymore and in an implicit way. This seems rather
strange and dangerous. Would it be allowed to reject the deletion
of the activity in this case?

Regards,

Werner.
  
      
    

  
Reply | Threaded
Open this post in threaded view
|

Re: Deleting an activity

Werner Donné

Hi Manfred,

Perhaps the pre-condition in section 3.13 could be replaced with a
final paragraph in the section saying that the operation may be
rejected. It is also formulated like that in other areas of the
specification, such as when the update of some property may be
rejected. Such a paragraph would in place for section 13.8 too.

Regards,

Werner.

Manfred Baedke wrote:

> Hi Werner,
>
> being a MAY requirement, the precondition definition in section 3.13 is
> nothing really normative. Maybe its only me, but I find the concept of a
> precondition containing only MAY requirements rather strange.
>
> Regards,
> Manfred
>
> Werner Donné wrote:
>> Hi Manfred,
>>
>> Shouldn't then a pre-condition be added in section 13.8 of RFC 3253,
>> analogous to the one in section 3.13?
>>
>> Regards,
>>
>> Werner.
>>
>> Manfred Baedke wrote:
>>  
>>> Hi Werner,
>>>
>>> This is of course allowed, IMHO. More generally, a server is allowed to
>>> reject the deletion of any resource for whatever reason.
>>>
>>> Regards,
>>> Manfred
>>>
>>> Werner Donné wrote:
>>>    
>>>> Hi,
>>>>
>>>> When an activity is deleted all references to it should be removed.
>>>> Versions that have the activity in their activity-set, for example,
>>>> should have their activity-set updated. Versions, which were created
>>>> on a branch represented by the activity, all of the sudden are not
>>>> on that branch anymore and in an implicit way. This seems rather
>>>> strange and dangerous. Would it be allowed to reject the deletion
>>>> of the activity in this case?
>>>>
>>>> Regards,
>>>>
>>>> Werner.
>>>>  
>>>>      
>>>    
>>
>>  

--
Werner Donné  --  Re
Engelbeekstraat 8
B-3300 Tienen
tel: (+32) 486 425803 e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Deleting an activity

Manfred Baedke
Hi Werner,

since the current wording of section 3.13 does not do any harm and there is no need to mention explicitly the possibility of rejecting a DELETE request on an activity resource, I do not think that this is really an issue. Again, a server may fail any request for whatever reason.

Regards,
Manfred

Werner Donné wrote:
Hi Manfred,

Perhaps the pre-condition in section 3.13 could be replaced with a
final paragraph in the section saying that the operation may be
rejected. It is also formulated like that in other areas of the
specification, such as when the update of some property may be
rejected. Such a paragraph would in place for section 13.8 too.

Regards,

Werner.

Manfred Baedke wrote:
  
Hi Werner,

being a MAY requirement, the precondition definition in section 3.13 is
nothing really normative. Maybe its only me, but I find the concept of a
precondition containing only MAY requirements rather strange.

Regards,
Manfred

Werner Donné wrote:
    
Hi Manfred,

Shouldn't then a pre-condition be added in section 13.8 of RFC 3253,
analogous to the one in section 3.13?

Regards,

Werner.

Manfred Baedke wrote:
  
      
Hi Werner,

This is of course allowed, IMHO. More generally, a server is allowed to
reject the deletion of any resource for whatever reason.

Regards,
Manfred

Werner Donné wrote:
    
        
Hi,

When an activity is deleted all references to it should be removed.
Versions that have the activity in their activity-set, for example,
should have their activity-set updated. Versions, which were created
on a branch represented by the activity, all of the sudden are not
on that branch anymore and in an implicit way. This seems rather
strange and dangerous. Would it be allowed to reject the deletion
of the activity in this case?

Regards,

Werner.
  
      
          
    
        
  
      

  
Reply | Threaded
Open this post in threaded view
|

Re: Deleting an activity

Geoffrey M Clemm

The main usage of MAY statements in 3253 was to highlight certain
allowed but not required behaviors that implementors at the time felt
were likely to occur (such as automatically putting resources under
version control when they were created, preventing the modification of
certain properties, and preventing the deletion of versions).

When a new revision of 3253 is created, at that time we would take a
poll on additional candidates for MAY statements, based on current
implementations.  So I would suggest deferring discussion on possible
additional candidates for MAY statements until we are in the end-game
of producing a new 3253 revision.

Cheers,
Geoff

Manfred wrote on 05/30/2006 05:53:03 AM:
> since the current wording of section 3.13 does not do any harm and
> there is no need to mention explicitly the possibility of rejecting
> a DELETE request on an activity resource, I do not think that this
> is really an issue. Again, a server may fail any request for whatever reason.

> Werner Donné wrote:

> Perhaps the pre-condition in section 3.13 could be replaced with a
> final paragraph in the section saying that the operation may be
> rejected. It is also formulated like that in other areas of the
> specification, such as when the update of some property may be
> rejected. Such a paragraph would in place for section 13.8 too.

> Manfred Baedke wrote:
> being a MAY requirement, the precondition definition in section 3.13 is
> nothing really normative. Maybe its only me, but I find the concept of a
> precondition containing only MAY requirements rather strange.

> Werner Donné wrote:
> Shouldn't then a pre-condition be added in section 13.8 of RFC 3253,
> analogous to the one in section 3.13?

> Manfred Baedke wrote:
> This is of course allowed, IMHO. More generally, a server is allowed to
> reject the deletion of any resource for whatever reason.

> Werner Donné wrote:
> When an activity is deleted all references to it should be removed.
> Versions that have the activity in their activity-set, for example,
> should have their activity-set updated. Versions, which were created
> on a branch represented by the activity, all of the sudden are not
> on that branch anymore and in an implicit way. This seems rather
> strange and dangerous. Would it be allowed to reject the deletion
> of the activity in this case?