[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Draft Minutes October 2013 F2F
Minutes of the CAMP F2F, 14 - 16th October 2013
Hosted by Fujitsu, UK
Meeting Attendees:
Oracle Mark Carlson Voting Member
Oracle Martin Chapman Chair
Fujitsu Limited Jacques Durand Voting Member
Cloudsoft Corporation Limited Alex Heneveld Voting Member
Oracle Anish Karmarkar Voting Member
Oracle Ashok Malhotra Voting Member
Rackspace Hosting, Inc. Adrian Otto Secretary
Vnomic Derek Palma Voting Member
Oracle Gilbert Pilz Voting Member
Fujitsu Limited Tom Rutt Voting Member
Intro:
Scribes: Adrian (Monday session), Jacques (Tuesday session), Anish (Wednesday session)
[Adrian Scribing]
Agenda: Three two hour sessions held over three days (15:30 - 17:30) .
GOAL of the F2F: Ensure we have directions/resolutions for all P1s and all PR comments
Agenda based on 1) the posted agenda and 2) proposals as a result of discussion during the informal parts of the gathering.
Under issues discussion lead with CAMP-145 https://tools.oasis-open.org/issues/browse/CAMP-145
No opposition raised to proposed Agenda
Roll: Attendees listed above, 10 of 14 voting members (71%) Meeting is quorate.
Minutes:
9th October 2013: https://www.oasis-open.org/apps/org/workgroup/camp/email/archives/201310/msg00069.html
Motion: m=Gil s=Anish
no objections, Minutes accepted
Action Items:
Jacques Durand: Coordinate Editing team meeting to discuss the challenges document referenced in CAMP-83.
TBD
Gilbert Pilz: Get input from Martin (email) on what publications he thinks we should release between our PRs.
CLOSED - Overtaken by events
Topic: Administrivia
Current open issues: 82 in total; 7 P1, 68 P2, 7 P3.
Topic: Editors Update
WD25 released: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51007/camp-spec-v1.1-wd25.doc
Topic: New Issues
no new issues from last week to process
Issue Discussion: CAMP-145 https://tools.oasis-open.org/issues/browse/CAMP-145
Gil presents a rewrite based on a discussion about simplification: removal of templates, collapsing app and platform components, and bringing the resource model in line with the pdp.
https://www.oasis-open.org/apps/org/workgroup/camp/download.php/51025/camp-spec-v1.1-RMR.doc
Platform Resource is changed
links from Platform are adjusted to URIs of collections of resources
rather than arrays of resources
assembliesUri, servicesUri, and plansUri are the key differences
Assemblies: Collection of Assembly Resources
Assembly Resources are mostly the same, but they refer to components rather than platformComponents
Services is a collection of Service Resources
Plans is a collection of Plan resources
A Plan resource is an optional expression of a DP, in JSON rather than YAML
If you POST a Plan to an Assemblies resource, an Assembly results
If you POST a Plan to a Plans resource, a Plan results
If you POST to a Plan, you get an Assembly
Components is a collection of Component resources
Component resources have a "relatedComponents" attribute so you can generate a hierarchy of components (parents, children, etc.)
artifact refers to an Artifact from a Plan
service refers to a Service (formerly known as PCT)
Issues 29, 23, 5, 22, 37, 64, 66, 74, 82 all addressed by this proposal.
Alignment of terminology is most of the proposed approach
Making the creation of an Assembly into a one step process is an additional feature of the contemplated Platform
Ashok: When do the components go away when the Assembly is acted upon by a DELETE request?
Martin: it would be possible to delete an Assembly and all related Components without impairing other Assemblies
Alex: Platform implementers can decide when Containers are shared, if at all
Alex: suggests that observing what implementations do should guide future spec work on this. Try not to over-specify this.
Alex Heneveld: (& this was an issue pre-refactoring, if anything this simplifies discussion on the issue)
Gil: Simplifying the spec to have fewer component types is a significant reduction in complexity
Gil: Section 4 does not change
Gil: Section 6 does not change
Gil: Extensions and metadata does not change. Only the resource model is adjusted.
Gil: Section 1.3 can be adjusted to show a more simple workflow to more closely track how today's PaaS systems work (go directly to a running Application in a one-step process)
Gil: The original two-step process is also possible by using a new feature (Plans)
Tom Rutt (Fujitsu): leave separate URI resources for each type of container
Additional discussion: Adrian, Alex, Gil, Martin, Tom
touched on backpointers
touched on types, and possible consolidation for collections
Justification for this work: Adoption >> Window of Opportunity >> Interop + Portability
helps us strike a balance of Adoption and WoO
Tom: text about DP generated comment(s), there may be some editorial work to address that.
words "node" and "type" may not be used consistently
we will address this during the F2F within the scope of issue triage.
Topic: Triage Issues, identifying each issue flagged for TC discussion
https://tools.oasis-open.org/issues/browse/CAMP-98 discuss -editorial
sections 2 and 3 could be merged.
Gil: Yes, we can merge them.
Alex: instance diagrams are not the same as the type diagrams
Tom: We do need two different diagrams, but we could decide to just describe them with words, and not use a diagram.
Martin: Suggests we revisit this after our resource refactoring effort
https://tools.oasis-open.org/issues/browse/CAMP-99 discuss (with 98 maybe merge section 2 and 3) - editorial
Martin: Gil's proposal for CAMP-83 would address this.
Gil: confirms, yes.
Looking at CAMP-83 proposal: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50879/camp-spec-v1.1-wd20-r1-NewNormTags-f3.doc
text in section 1.6 may resolve CAMP-99
+ a minor editorial adjustment to the sentence about 'These tables appear in Appendix C, "Normative Statements"'
Tom Rutt (Fujitsu): I agree with adding the sentenced "all examples are informative"
Tom: Perhaps the table of "Normative Statements" are actually "Conformance Statements"?
Jacques: They are Normative Statements, not Conformance Statements
we can add "Examples are all informative, not normative"
Martin is updating CAMP-99 with an excerpt from the proposal for CAMP-83 to address the normative statement concern.
Martin: "The statements that use these keywords have been highlighted as per this sentence, and each such statement has been given a unique tag in the following manner: [EX-00]
For convenience these statements have been tabulated and cross-indexed by their tags and appear in Appendix C, Normative Statements. All examples in this document are non-normative."
We will add "This section is informative." to the start of Sections 2 and 3.
MartinC1: mark section 2 and 3 as being informative.
Tom Rutt (Fujitsu): rfc 2119 is about marking "requirements" Key words for use in RFCs to Indicate Requirement Levels
CAMP-99 updated with Martin's proposal
MOTION: m=Adrian s=Gil to resolve CAMP-99 with a direction to the editors to make changes outlined by Martin's proposal added to CAMP-99 as a comment.
Proposal:
In section 1.6, terminology, add the following text after the 2nd para:
The normative statements that use these keywords have been highlighted as per this sentence, and each such statement has been given a unique tag in the following manner: [EX-00] [{note to editor highlight the sentence} For convenience these statements have been tabulated and cross-indexed by their tags and appear in Appendix C, Normative Statements. All examples and notes in this document are informative. Unless marked otherwise text in this specification is normative.
In addition add the following text as the first line of section 2 and section 3.
"This section is informative."
Editors discretion to mark other sections/appendices as informative.
No discussion.
No objections.
Motion passed.
https://tools.oasis-open.org/issues/browse/CAMP-102 discuss - technical
MOTION: m=Adrian s=Gil to close CAMP-100 with no action in accordance with resolution to CAMP-99.
No discussion.
No objections.
Motion passes.
https://tools.oasis-open.org/issues/browse/CAMP-101
Tom Rutt (Fujitsu): could close as accommodated by resolution to 99
https://tools.oasis-open.org/issues/browse/CAMP-109 discuss - editorial
https://tools.oasis-open.org/issues/browse/CAMP-113
The value of this node expresses the version of the CAMP specification to which the Deployment Plan conforms. This value SHALL be the Specification Version String of the CAMP specification to which this Deployment Plan conforms. The value of this node SHALL be "CAMP 1.1" as defined in Section XX [PDP-18]
The value of this node expresses the version of the CAMP specification to which the Deployment Plan conforms. This value SHALL be the Specification Version String of the
CAMP specification to which this Deployment Plan conforms. [PDP-18]
NOTE: The value of this node SHALL be "CAMP 1.1" as defined in Section XX
Tom Rutt (Fujitsu): we need to wait to see if 1.2 is backwards compatible to 1.1
Jacques (Fujitsu)1: just remove PDP-18
Tom Rutt (Fujitsu): perhaps this campVersion node should be a sequence node, that way a dp maker could state which versions they are compatible with. They may only use the
Cross-section of features from both versions
Tom Rutt (Fujitsu): futureproof the dp syntax
Tom Rutt (Fujitsu): the array has the versions that this dp conforms to. They would only be able to put two values in if they conform to both versions
meeting is in recess until tomorrow
[Jacques scribing]
Meeting restarts.
topic: triage of PR issues, recap
chair: for 3/4 we have proposed resolutions.
Adrian: we have 11 ready to close.
Adrian Otto (Rackspace): I will (in a moment) move to close CAMP-91, CAMP-95, CAMP-97, CAMP-101, CAMP-103, CAMP-104, CAMP-106, CAMP-107, CAMP=108, CAMP-129, and
CAMP-130 with no action, as each of these issues has been satisfied by the resolution of CAMP-99.
Adrian: need more time to review? all on this list are obviated by CAMP-99 discussed yesterday
MOTION: Adrian: to close all above issues: CAMP-91, CAMP-95, CAMP-97, CAMP-101, CAMP-103, CAMP-104, CAMP-106, CAMP-107, CAMP-108, CAMP-129, and CAMP-130 with no
action, Sec: Tom
... no discuss, no object. UNAN.
chair: we present proposal for CAMP-145
Issue 145: Gil has a more concrete proposal:
Gil: major refactoring of our resource model is in order (addressing number of issues and feedback)
Gil: section 1.3 illustrates key examples of main usage scenario
... proposed: to simplify the creation of an app - in 1 operation (if desired)
... use a generic "Component" resource, no AssemblyTemplate anymore.
... introduce Services (as replacement for PCTs)
... Plan (replaces AssemblyTemplate somehow)
... Artifacts are inert packages, migration-ready, as opposed to Components that are dynamically used
Mark: Fig 2-7 needs update (Assemblies missing)
Gil: need to harmonize diagrams. Alex has great ideas about this.
Gil: we are not trying to approve 145 today
Tom: this is simpler
chair: section 3 needs be rewritten
... at least partially
Gil: working with "Plans": the "resource" view of a Plan must have same data or less than the file content/view
... so Service ref (href) needs be in the Plan file
... we don't have Requirements anymore (nor capability)
... platform content consequently changed.
Anish: URI --> URL
Ashok: relationship Assembly and Plan?
Gil: relationship visible at instance level
... planURI in Assembly
Tom Rutt (Fujitsu): {
"uri": URI,
"name": String,
"type": "component",
"description": String ?,
"tags": String[] ?,
"representationSkew": String ?,
"assembly": Link,
"artifact": URI ?,
"service": URI ?,
"status": String,
"relatedComponents": Link[] ?,
"operationsUri": URI ?,
"sensorsUri": URI ?
}
Tom: Plan without common attributes? Gil: they are in YAML format.
Gil: we have lost some functionality in the process: can't get back the PDP anymore from Provider (no PDP URI in the Plan)
Alex: in favor of taking this as is. Just file a new issue for additional features like this linkage.
Gil: support for Plan is advertised in metadata (an extension resource "CAMP-Plans-Extension")
Adrian: many of CAMP systems have built-in features. Annoying. A singular interface (CAMP extensions) better for advertising this.
... Note: may exist alternatives to advertise Plan support
Gil: deploying an app not same as registering a Plan.
Another issue is: how to stop vs delete...
chair: comments?
Adrian: we should thank Gil. The proposal reduces size of spec, would help adoption.
... (others chime in)
Gil Pilz (Oracle): :-$
Alex: well done. Good we get such a consensus on this.
chair: needs still the blessing of the TC for that *direction*
MOTION: Adrian: that the TC recognizes the current proposal for 145 as directional, for the editors to work further on this issue.
second: Gil
... no discussion, no objection. Pass UNAN.
Back to triaging:
Adrian Otto (Rackspace): https://tools.oasis-open.org/issues/browse/CAMP-121 Proposal in Jira (close-no-action)
https://tools.oasis-open.org/issues/browse/CAMP-124 Proposal in Jira (close-no-action)
https://tools.oasis-open.org/issues/browse/CAMP-133 Proposal in Jira (close-no-action)
https://tools.oasis-open.org/issues/browse/CAMP-134 Proposal in Jira (close-no-action)
https://tools.oasis-open.org/issues/browse/CAMP-139 Proposal in Jira (close-no-action)
https://tools.oasis-open.org/issues/browse/CAMP-140 Proposal in Jira
https://tools.oasis-open.org/issues/browse/CAMP-138 Proposal in Jira
https://tools.oasis-open.org/issues/browse/CAMP-137 Proposal in Jira
https://tools.oasis-open.org/issues/browse/CAMP-136 Proposal in Jira
https://tools.oasis-open.org/issues/browse/CAMP-135 Proposal in Jira
https://tools.oasis-open.org/issues/browse/CAMP-131 Proposal in Jira
https://tools.oasis-open.org/issues/browse/CAMP-127 Proposal in Jira
https://tools.oasis-open.org/issues/browse/CAMP-125 Proposal in Jira
https://tools.oasis-open.org/issues/browse/CAMP-122 Proposal in Jira
https://tools.oasis-open.org/issues/browse/CAMP-120 Proposal in Jira
https://tools.oasis-open.org/issues/browse/CAMP-119 Proposal in Jira
Adrian: proposed resolutions for group ...
... first 6 close w no action, the remainder have proposals in JIRA
issue: 121 https://tools.oasis-open.org/issues/browse/CAMP-121
MOTION; Adrian: to clowse w proposal in JIRA. Tom 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-124 https://tools.oasis-open.org/issues/browse/CAMP-124
MOTION; Adrian: to close w proposal in JIRA. Anish 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-133 https://tools.oasis-open.org/issues/browse/CAMP-133
MOTION; Adrian: to close w proposal in JIRA. Jacques 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-134 https://tools.oasis-open.org/issues/browse/CAMP-134
MOTION; Adrian: to close w proposal in JIRA. Gil 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-139 https://tools.oasis-open.org/issues/browse/CAMP-139
MOTION; Adrian: to close w proposal in JIRA. Jacques 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-140 https://tools.oasis-open.org/issues/browse/CAMP-140
MOTION; Adrian: to close as subsumed by 145. Gil 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-138 https://tools.oasis-open.org/issues/browse/CAMP-138
MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-137 https://tools.oasis-open.org/issues/browse/CAMP-137
OTION; Adrian: to resolve w proposal in JIRA. Gil 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-136 https://tools.oasis-open.org/issues/browse/CAMP-136
MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-135 https://tools.oasis-open.org/issues/browse/CAMP-135
MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-131 https://tools.oasis-open.org/issues/browse/CAMP-131
MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-127 https://tools.oasis-open.org/issues/browse/CAMP-127
MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-125 https://tools.oasis-open.org/issues/browse/CAMP-125
MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-122 https://tools.oasis-open.org/issues/browse/CAMP-122
MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-120 https://tools.oasis-open.org/issues/browse/CAMP-120
MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd.
... no discuss, no object. Pass UNAN.
issue: CAMP-119 https://tools.oasis-open.org/issues/browse/CAMP-119
MOTION; Adrian: to resolve w proposal in JIRA. Gil 2nd.
... no discuss, no object. Pass UNAN.
chair: we have handled a 3rd of our PR issues so far!
Pro-temp chair for the wednesday session : Chair (martin) motions that Adrian chairs the remainder of the F2F , Gil 2nd.
... no discuss, no object. Pass UNAN.
chair: meeting recessed until Wed 3:30pm UK time
[Meeting restarts]
[Adrian charing]
[Anish Scribing]
Issue: CAMP-145 (again) https://tools.oasis-open.org/issues/browse/CAMP-145
Motion: m:Gil s:Alex resolve issue 145 with the proposal in Jira (v3)
tom: what happened to section 3?
gil: put it back in and removed references to resources that no longer exist
Gil talks about what is now in section 3
Need a new issue to figure out we still need section 3
tom: does the plan resource exist before the PDP is posted to the assembly?
gil: if the provider supports plans then posting a PDP to assemblies results in an assembly and a plan
MartinC not that im listening but we did have an issue to loook at merging 2 and 3 and now with the re-write the two could condense nicely into a single section
Adrian Otto (Rackspace): martin, do you know if that is a PR issue, or a spec issue?
MartinC: pr issue - one of patrick's - the one where he was confused between the uml class diagram and instance diagrams
adrian: safer to open a new issue, if the issue that martin points out is already there we can close it as dup
no more discussion on the motion
motion approved w/o
RESOLUTION: CAMP 145 is resolved with proposal in JIRA
<applause>
Topic: issues 5, 22, 23, 29, 64, 77, 82, 141, & 145
adrian reviews issue 5
proposals for all the issues are CNA with a reference to 145
adrian reviews issue 22
adrian reviews issue 23
adrian reviews issue 29
adrian reviews issue 64
adrian reviews issue 77
adrian reviews issue 82
adrian reviews issue 141
adrian reviews issue 145
adrian reviews issue 145
Motion: m:Gil s:Ashok Close issues CAMP-5, CAMP-22, CAMP-23, CAMP-29, CAMP-64, CAMP-77, CAMP-82, and CAMP-141 with no action as they are resolved by resolution of issue
CAMP-145
no discussion
motion approved w/o
RESOLUTION: Issues 5, 22, 23, 29, 64, 77, 82, and 141 are closed with no action (resolved by issue CAMP-145)
Topic: issues 85, 86, 87, 89, 90, 92, 93, 94, 96, 128, 123, 132, 141
Adrian discusses each issue and its proposal
Tom Rutt (Fujitsu): from YAML 1.1 spec
"Copyright 2001-2008 Oren Ben-Kiki, Clark Evans, Ingy dt Net
This document may be freely copied, provided it is not modified."
mark: need to worry about requirements of taking our spec to ISO
mark: adding it to our appendix would also be an option
mark: if we could enlist folks like Tim Bray/MarkN to move this to IETF
Gil Pilz (Oracle): Would adding it to our appendix make us responsible for it?
Gil Pilz (Oracle): If not, how does that help anyone?
ACTION: Mark to engage with Tim Bray/MarkN to see if YAML 1.1 can be moved to IETF
tom: note that the copyright stmt allows copying
... wrt ISO there are ways around this, such as reference explanatory note
AI: Mark to contact @tbray, @mnot to see if they can champion YAML in IETF
anish: taking the spec thru an org like IETF would result in the spec itself changing
ashok: do we really feel that strongly on YAML?
adrian: the move to use yaml is to help devs and human beings
... for example json doesn't allow comments
... we are trying to track implementers preferences
Mark Carlson:
https://www.tbray.org/tmp/draft-ietf-json-rfc4627bis-03.html - "This
revision does not change any of the rules of the specification; all
texts which were legal JSON remain so, and none which were not JSON
become JSON. The revision's goal is to fix the errata and highlight
practices which can lead to interoperability problems."
... if OASIS comes back saying no way we can host/copy it, we'll have to reconsider
Mark: example of JSON proposal by tim bray that does not want to change anything. Same will be true for YAML
anish: keep this issue out of the block motion, as we don't know what oasis' answer will be
Ashok Malhotra (Oracle): +1 to Anish
anish: add security consideration section to the spec
adrian walks thru proposal for issue 89
changed 'roles' to 'actors'
changed section 1.6 Terminology
included definition for CAMP provider and Consumer
Adrian walks thru proposal for issue 90
90 is addressed by issue 99
Adrian walks thru proposal for issue 92
editorial issue
Adrian walks thru proposal for issue 93
Adrian walks thru proposal for issue 94
Adrian walks thru proposal for issue 96 https://tools.oasis-open.org/issues/browse/CAMP-96
motion m:Gil s:Anish Move to close CAMP- 96 with no action as it is already resolved by issue CAMP-145 resolution
no discussion
motion approved w/o
RESOLUTION: Issue 96 closed with no action as it is already resolved by resolution of issue 145
Adrian discusses issue 128
adrian: this is not ready for resolution. we don't yet address the media types issue
Adrian walks thru proposal for issue 123
Adrian walks thru proposal for issue 132 https://tools.oasis-open.org/issues/browse/CAMP-132
Motion: m:Gil s:Anish close issue 132 to close it with no action
no discussion
motion approved w/o
RESOLUTION: issue 132 is CNA
Adrian Otto (Rackspace): Completed review of: CAMP-85, CAMP-87, CAMP-89, CAMP-90, CAMP-92, CAMP-93, CAMP-94, CAMP-123
motion: m:Gil s:Anish resolve CAMP-85, CAMP-87, CAMP-89, CAMP-90, CAMP-92, CAMP-93, CAMP-94, CAMP-123 with proposal in Jira
no discussion
motion approved w/o
RESOLUTION: CAMP-85, CAMP-87, CAMP-89, CAMP-90, CAMP-92, CAMP-93, CAMP-94, CAMP-123 resolved with proposals in Jira
Topic: Schedule https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50034/CAMP%20sched%202013-07-19.pdf
anish: we are already late by 2 weeks
... we have to let Jacques take the changes and accommodate the test suite
... we also have to deal with Jacques challenges
... no major issues left
... perhaps move it by 3 weeks
so 2nd PR end of 1st week of November; start of CS ballot end of 1st week of december
no one objects
Topic: raising the bar on new issues
Ashok Malhotra (Oracle): I thought it was 2/3
"Special Majority Vote" is a TC vote in which at least
2/3 (two thirds) of the Voting Members vote "yes" and no more than 1/4
(one fourth) of the Voting Members vote "no". These numbers are based on
the total number of Voting Members, regardless of the number of Voting
Members present in the meeting. Abstentions are not counted. For
example, in a TC in which there are 30 Voting Members, at least 20
Voting Members must vote "yes" for a motion to pass; but if 8 or more
vote "no" then the motion fails. All Special Majority Votes must be
conducted via electronic ballot by the OASIS TC Administrator.
Adrian Otto (Rackspace): 2/3 of voting members present
2/3 of voting members present & voting
Motion: m:Gil s:Alex Moves to create a standing rule to
require 2/3 majority of voting members present and voting to open new
issues against CAMP 1.1
anish: reminder that PR is an escape hatch
no discussion
motion approved w/o
RESOLUTION: new standing rule to require 2/3 majority of voting members present and voting to open new issues against CAMP 1.1
[Chair notes that we made the following motion on 2nd October 2013:
MOTION: GIl - after 16th October, we raise the bar that requires 2/3 of those on a call to vote in favor to open a new issue against V1.1
2nd: adrian
No obj. Motion carries. 16 october is bar raising date
]
Topic: new issue 146 https://tools.oasis-open.org/issues/browse/CAMP-146
deferred till next call
Topic: types, superclass, subclass, inheritance and substitutability
related to issue CAMP-44 https://tools.oasis-open.org/issues/browse/CAMP-44
Gil: https://www.oasis-open.org/apps/org/workgroup/camp/download.php/50959/camp-spec-v1.1-issue-44.doc
Alex argues for multiple-inheritance
issue of diamond inheritance
Gil argues for single-inheritance
Alex: if you have cowboy-artist then its draw operation must do what draw of cowboy *and* draw of artist says it does simultaneously. Otherwise it is lying
Derek: agree with Alex. There are ways to address the ambiguity problems
Tom: there has to be rules about common attributes. We could say that we disallow it if there are common attribute names with different types
... This is complicating this. We have to justify adding complicated rules
ashok: this is hard and complicated. We could spend hours on this. I have a thought about how we could do this quickly -- various
... programming languages/disciplines have worked this out. What we could do is -- we are going to do exactly like "so-and-so" which address all the
... difficult issues that come up. Fine a scheme that we are happy with which is well worked out and copy that.
Adrian: do you have any in mind?
Ashok: no. but can research this
Gil: we are making comparison to programming languages. But we don't have a compiler. All we got is a type definition.
... it is a definition of particular resource type
... the mechanisms to get multiple inheritance to work escapes me
... no existing implementations to worry about
... understand the usecases and desire.
... we should postpone this till the next version
Alex: it is actually pretty easy to implement
... i would be OK with leaving it as is
... but if we were going to have inheritance then it would drive me bonkers if multiple-inheritance did not exist
Derek: was thinking of proposing a syntax for this. An array might just do it.
Gil: our type definitions do not say anything about operation.
Alex: would be fine with it.
Adrian: would be an interesting extension
ashok: what happens if two attributes have the same name and they don't match
alex: in some cases it would be an error if it is not possible
Tom Rutt (Fujitsu): OMG CORBA has a set of rules for interface inheritance see clause 7.8.5 in http://www.omg.org/spec/CORBA/3.1.1/Interfaces/PDF/
Lots of freeform discussion between Alex and Gil
anish: what would happen if we don't say anything about inheritance. Would that make the spec inconsistent. Concerned about introducing such a feature so late
Alex Heneveld: @Tom - looking at that section. it seems quite simple.
Gil: it is going to result in something equally complex
Derek: we all have a meta-model in our mind. And these things result in bringing forward mismatches. The spec is not going to
... have a meta-model. We should perhaps just figure out what we want to express.
... would prefer to leave it out. But if we can't then just bite the bullet and do it
Alex: we got a lot of attributes and the only way we know it's there is thru the type system
... if we can find a simple solution quickly we should put it in. But if we can't we can just leave it out
Adrian: if we have an array for inheritance then implementations can decide whether to use inheritance
Tom Rutt (Fujitsu): @alex, the corba rules do not allow the directly inherited interfaces to have attributes with common names.
... so draw in cowboy and draw in artist would not be allowed to be multiple
... inherited in cowboy artist, but the diamond repeats of attributes are allowed because they are the same attribute
<Open ended discussion not scribed>
AOB:
Topic: straggler roll
Thanks to Fujitsu for hosting the f2f. Great network
Adrian: martin not available next week. Unless we hear from Martin I'll be your pro-tem chair next week
Meeting adjourned
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]