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

[David Booz <booz@us.ibm.com>]

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