Re: [camp] PDP subcommittee and next meeting

[Alex Heneveld <alex.heneveld@cloudsoftcorp.com>]

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?

--A


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
> >
> >
> > SELECTED NOTES/COMMENTS
> > (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.php