[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-policy] Issue 93 feedback on proposal
1)The original wording is correct and should be left alone. Your new wording omits the considerations of rule1, which actually result in a behavioral change, and is therefore not editorial. 2) Let's talk about this on the call. I don't understand what you are proposing. As things stand now, I don't like the idea of the appendix. It pulls an important concept out of the main line of the document. Perhaps this is stylistic and not substantitive, but I really don't like it. 3) ok 4) Discuss on the call. See (8) below, maybe there's a way to get this fixed. 5) My suggestion would be to make section 4.6.2 into section 4.8 (after Attaching intents to SCA Elements) and added some text to ensure that it was clear that the XPath functions could be used by both intent and policytSet @attachTo. 6) Right ok. This adjustment would have to be factored into my suggestion for (5). 7) I object to the one you added for intents, because, as I said, intents are different from policySets. Intents are constraints and as such MUST have different override rules than policySets do. The statement that's there for policySets is fine. 8) Ok, so then I think we need to add some text about this to the proposal. My suggestion would be to do this in section 4.3. The last normative statement (which is the subject of my comment (4)) could be reworded to indicate that not only does policySet attachment happen after intent ext. attachment, but ALSO re-evaluation of policySet attachment happens following the deployment of an intent. 9) You didn't answer my question. What happens to the already deployed components when something like this happens? 10) This is another case similar to 9. What happens? What does the runtime do? Should it fail the deployment of the intent or stop all the deployed components? I don't think we can leave this dangling. 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 |------------> | From: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |ashok malhotra <ashok.malhotra@oracle.com> | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | To: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |David Booz/Poughkeepsie/IBM@IBMUS | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Cc: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |sca-policy@lists.oasis-open.org | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Date: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |02/02/2010 06:17 PM | >--------------------------------------------------------------------------------------------------------------------------------------------------| |------------> | Subject: | |------------> >--------------------------------------------------------------------------------------------------------------------------------------------------| |Re: [sca-policy] Issue 93 feedback on proposal | >--------------------------------------------------------------------------------------------------------------------------------------------------| Dave: See inline All the best, Ashok David Booz wrote: > 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. > We had some internal discussions and I thought the wording could be improved/clarified. If you disagree we can change it back. This has nothing to do with Issue 93 but tries to make the spec clearer. > 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. > The only normative statement I found in the Appendix was The SCA runtime MUST raise an error if the @attachTo XPath expression resolves to an SCA <property> element, or any of its children. [POL40002] I think we could move this normative statement to the description of the @attachTo attribute for intents and for policySets. The Domain Composites Infoset is now used both by intents and policySets so I wanted to move it away from the policySet section. Looking at your later comment on 4.6.1, I think we should move these functions with the Domain Composite Infoset. > 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. > Yes, the third normative statement should read: · When External Attachment is used for both intents and policySets, intents MUST be attached before policySets [POL40xxx] > 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. > OK. I'm open to discussion/persuasion. > 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. > I think you mean the XPath functions in 4.6.1. Yes, it would be better to move them to clarify that they can be used with intents as well as policySets. Move them next to the Domain Composites Infoset? > 6) Section 4.6.2.2 - Can the IntentRefs XPath function be used to attach an > intent? > My thinking was that the intent-based XPath functions could not be used to attach intents. Nor could they be used in the @attachTo Xpath for intents. This needs to be said. > 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. > I just copied the normative statement just above the one you cited and changed it to apply to intents. I'm not sure what you are objecting to. Do you object to both the normative statements -- for policySets and intents or only the one that I added for intents? > 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? > Yes > 9) Could the deployment of a new intent into the Domain cause all already > deployed composites to become invalid? Only if the new intent has an @attachTo attribute or if the value of the @attachTo changes. There should be a parallel statement for policySets. > Suppose the new intent is attached > at a location which cause a MUX violation as per POL40017 in section 4.14. > Yes, this may happen. > 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? > Yes > > [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 > > > --------------------------------------------------------------------- > 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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]