OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [camp] PDP subcommittee and next meeting

Thank you Alex,


On the dropbox you can find the Seaclouds-Negotiation-Main-V0.2. with
the last changes suggested by Alex. I've re-shaped the Standardization
ppt as well. 
Please feel free to comment. 

The only slides missing at this moment are the slides from NURO.

See you in a couple of hours.

Thx and Regards

-----Original Message-----
From: camp@lists.oasis-open.org [mailto:camp@lists.oasis-open.org] On
Behalf Of Alex Heneveld
Sent: martes, 14 de mayo de 2013 12:29
To: Martin Chapman
Cc: camp@lists.oasis-open.org
Subject: Re: [camp] PDP subcommittee and next meeting

Only concern is that there are other P1 issues to discuss and at least
one proposal.
If there is a capable pro-tem chair volunteer that might be better?


On 13/05/2013 18:55, Martin Chapman wrote:
> Alex et al,
> I will probably not be able to make this Wednesday's TC call so I was
thinking of cancelling and handing over the time slot to a pdp call -
this would not be a formal call to maintain voting rights etc.
> Thoughts?
> Martin.
>> -----Original Message-----
>> From: Alex Heneveld [mailto:alex.heneveld@cloudsoftcorp.com]
>> Sent: 13 May 2013 18:17
>> To: camp@lists.oasis-open.org
>> Subject: [camp] PDP subcommittee and next meeting
>> Hi folks-
>> Thanks to all who joined the call just now.  Productive.  My notes 
>> and thoughts below.
>> I'll send an invite to the list for tomorrow's call at 4pm UK / 8am 
>> PDT, using GTM details (with Switzerland for Anish this time):
>>      https://www3.gotomeeting.com/join/759306270
>>      United States:  1 (646) 982-0002
>>      United Kingdom:  44 (0) 203 535 0624
>>      Switzerland:  41 (0) 435 0167 07
>>      Germany:  49 (0) 811 8899 6976
>>      Ireland:  353 (0) 14 845 975
>>      Access Code: 759-306-270
>> Best,
>> Alex
>> (Not intended as a transcript of the call, but my sense and my 
>> thoughts.  Please feel free to amend by email.)
>> DP component specs --
>>       typically become components, and often the platform will supply

>> more components;
>>      but the platform MAY NOT reflect a component in the DP spec with

>> a component in the platform
>>      (e.g. in a paas which e.g. uses a WAR as an input but doesn't 
>> model them as top-level ACT's)
>> There are valid reasons why people would want to represent a Platform

>> Component in the DP (e.g. providing a concrete topology, asking for a

>> server, asking for a git repo); but in general leaving it abstract, 
>> giving App Components (artifacts) and requirements, is likely to be 
>> more portable / better.
>> Requirements as explicit types (Alex's (1b) ) tentatively seems 
>> clearer now, vs
>> (1a) in Alex's note from Gil.
>> Requirements expressed in such a way provide abstraction independent 
>> of the component nodes -- more flexible than just components, and 
>> more formal and dependable than mixins (1c).
>> Traits as requirements (Alex's (2a) ) as a peer to "relationship"
>> requirements seems a reasonable
>> approach but need more time to process.  The line between a "provider

>> / supertype" requirement on a component and the "relationship" is
blurry -- e.g.
>> in case of a git repo, it might be part of a component (e.g. 
>> OpenShift) or it might be a separate component.
>> END
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that 
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.ph
>> p

To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

This e-mail and the documents attached are confidential and intended 
solely for the addressee; it may also be privileged. If you receive 
this e-mail in error, please notify the sender immediately and destroy it. 
As its integrity cannot be secured on the Internet, the Atos 
group liability cannot be triggered for the message content. Although 
the sender endeavours to maintain a computer virus-free network, 
the sender does not warrant that this transmission is virus-free and 
will not be liable for any damages resulting from any virus transmitted. 

Este mensaje y los ficheros adjuntos pueden contener informacion confidencial 
destinada solamente a la(s) persona(s) mencionadas anteriormente 
pueden estar protegidos por secreto profesional. 
Si usted recibe este correo electronico por error, gracias por informar 
inmediatamente al remitente y destruir el mensaje. 
Al no estar asegurada la integridad de este mensaje sobre la red, Atos 
no se hace responsable por su contenido. Su contenido no constituye ningun 
compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes. 
Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor 
no puede garantizar nada al respecto y no sera responsable de cualesquiera 
danos que puedan resultar de una transmision de virus. 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]