[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 93 feedback on proposal
Ashok, Here's the set of questions/issues I promised to provide as feedback for your proposal to resolve Issue 93 [1] 1) The changed text in section 3.1 under the @excludes description. Why did you change this text, I don't see what these changes have to do with the new feature of external attachment. 2) Appendix A that you created contains normative statements. IMHO, it is not appropriate for normative statements to be placed in an appendix. I think you should move that section back into the main body of the document. 3) Section 4.3 - Did you intent 2 or 3 normative statements at that point? Right now there are 2, but I think you intended to have 3. The 3rd needs a capital MUST. 4) Section 4.3 - I don't think the last normative statement (which is repeated in section 4.6) is helpful. This would be better stated in section 4.14 alone if it's even necessary. 5) Section 4.6.1 and 4.6.2 (and all subsections) are currently within the context of policySets. I think the proposal needs to re-adjust those sections to be applicable to external attachment of intents. You need this if you want the same external attachment capabilities for intents and policySets. 6) Section 4.6.2.2 - Can the IntentRefs XPath function be used to attach an intent? 7) Section 4.9 - you added a new normative statement: "Similarly, If a component has any intents attached to it (by any means), then any intents attached to the componentType MUST be ignored." I have a fundamental disagreement with this statement. Your statement is explicitly disallowing intent attachment by an implementation which renders the Java intent annotations to be completely useless. I don't think this is what we want. Direct attachment of intents can come from the implementation itself. Intents work differently that policySets in that they are constraints, not configuration. You cannot ignore the constraints of the implementation. There would be chaos if a component could declare that it ran under a global tran when the implementation was not prepared to deal with that, and had annotated for the use of a local tran. I'll note that similar new language appears in section 5 and needs to be removed. 8) What happens when I deploy a new intent into the Domain that uses the external attachment mechanism, do all externally attached policySets have to be re-evaluated in the Domain following the deployment of a new externally attached intent? 9) Could the deployment of a new intent into the Domain cause all already deployed composites to become invalid? Suppose the new intent is attached at a location which cause a MUX violation as per POL40017 in section 4.14. 10) What happens if none of the existing policySets @provide this new intent? When the new intent is deployed, if there is no @providing policySet, are all deployed composites invalid...as per POL40018? [1] http://lists.oasis-open.org/archives/sca-policy/201001/msg00023.html Dave Booz STSM, BPM and SCA Architecture Co-Chair OASIS SCA-Policy TC and SCA-J TC "Distributed objects first, then world hunger" Poughkeepsie, NY (845)-435-6093 or 8-295-6093 e-mail:booz@us.ibm.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]