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:]
>Sent: 13 May 2013 18:17
>To:
>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
>
