Re: [sca-policy] Issue 93 feedback on proposal

[ashok malhotra <ashok.malhotra@oracle.com>]

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 
>
>