OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-policy message

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