[GRAAP-WG] Time Constraints Profile

[Alexander Papaspyrou]

Dominic, Costas, all,

Am 10.12.2009 um 19:13 schrieb Dominic Battre <mailinglists at battre.de>:

> 1) Positive: compact representation
> 2) Negative: difficult to model, negotiate and evaluate adherence

Actually, I don't really agree on this. Whether the agreement  
initiator or responder expands the intensional representation (and at  
which time) does not matter at all.

> 3) Positive: can be used to model infinite number of repetitions  
> (every
> day until the end of the world)
>
> I think that 3) has no real usecase as contracts should contain a well
> defined end.

Well, this might or might not be the case, since this is up to the  
contractors. I could think of examples where you want to have  
perpetual contracts but, from time to time, renegotiate a certain term  
(such as the price). A savings account would be an example for this,  
and one can think of many similar contract types.


> I think the extensional description has the same expressiveness (as
> mentioned, I don't see 3) as a usecase for us) but is easier to handle
> and creates a leaner specification.

As said, I don't really agree on the former, but have to admit that  
the specification simplicity is a valid point, too. Personally,  
however, I would give more power to the expressiveness to ensure a  
broad set of possible agreements while sacrificing simplicity a bit,  
since humans are not supposed to ever see the electronic agreement in  
its bare, naked form anyway.

Best
Alexander

>
> Best regards,
>
> Dominic
>
> On 12/07/2009 05:17 PM, Constantinos (Costas) Kotsokalis wrote:
>> Hi Dominic,
>>
>> Recurring patterns for service usage is something that is needed in  
>> many
>> cases, even if not allowed by current technology/service providers.  
>> In
>> an example scenario where someone rents VMs to execute enterprise
>> operations s/w on them, (s)he would certainly prefer to load-balance
>> over a number of them available during working hours, and half or  
>> less
>> that number outside working hours, to save money. I know this is not
>> something that current cloud providers offer (to the extent I'm aware
>> of, at least) but I believe it's a realistic need, and fits with  
>> fully
>> dynamic scaling scenarios.
>>
>> On the same time, I do agree that it increases complexity,  
>> especially if
>> one is willing to include constructs such as "on the first Monday of
>> every month" etc.
>>
>> Just my E0.02.
>>
>> Best regards,
>>
>> Costas
>>
>>
>> On 7 Dec 2009, at 14:39, Dominic Battre wrote:
>>
>>> Hello Costas,
>>>
>>> it would certainly be a possible extension.
>>>
>>> The question is do we want it? If we end up translating ical to  
>>> XML we
>>> come to a specification that is extremely powerful but very  
>>> difficult
>>> to implement.
>>>
>>> Our idea was to use the simplest language that would be useful.
>>> Therefore, I would like to ask you and the others: Do you need
>>> something like "every day, 9am-5pm"?
>>>
>>> Best regards,
>>>
>>> Dominic
>>>
>>> Constantinos (Costas) Kotsokalis wrote:
>>>> Hi Dominic,
>>>> Would you see fit to augment this also with some construct for
>>>> defining periodic durations? E.g. to be able to say "every day,
>>>> 9am-5pm", or things like that.
>>>> Best regards,
>>>> Costas
>>>> On 7 Dec 2009, at 13:43, Dominic Battre wrote:
>>>>> Dear GRAAP members,
>>>>>
>>>>> we have seen in various discussions that there seems to be a  
>>>>> frequent
>>>>> desire for a standardized term language to express when a  
>>>>> service shall
>>>>> be delivered.
>>>>>
>>>>> Examples are:
>>>>>
>>>>> - Making a hardware reservation of a cluster for interactive use
>>>>>
>>>>> - Co-allocation of resources of various types (hardware, network,
>>>>> licenses, ...)
>>>>>
>>>>> - Defining a deadline for the completion of a job
>>>>>
>>>>> We have had a discussion about this in Banff after which Oliver  
>>>>> and I
>>>>> have prepared a proposal for a Time Constraints Profile for
>>>>> WS-Agreement. This proposal has been uploaded here:
>>>>>
>>>>> https://forge.gridforum.org/sf/go/doc15832?nav=1
>>>>>
>>>>> We would be eager to hear your comments.
>>>>>
>>>>> - Is the proposal clear?
>>>>>
>>>>> - Is the proposal complete?
>>>>>
>>>>> - Does the proposal satisfy your needs?
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Dominic
>>>>> -- 
>>>>> graap-wg mailing list
>>>>> graap-wg at ogf.org
>>>>> http://www.ogf.org/mailman/listinfo/graap-wg
>>>
>>
>>
>
> --
>  graap-wg mailing list
>  graap-wg at ogf.org
>  http://www.ogf.org/mailman/listinfo/graap-wg