Dominic, Costas, all, Am 10.12.2009 um 19:13 schrieb Dominic Battre <mailinglists@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@ogf.org http://www.ogf.org/mailman/listinfo/graap-wg
-- graap-wg mailing list graap-wg@ogf.org http://www.ogf.org/mailman/listinfo/graap-wg