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: RE: [sca-policy] SCA Policy RFC2119 Review Document [POLICY-62] F2F Actions


Please let me know what version I should use for proposals on rx and tx intents and the conformance section.


> -----Original Message-----
> From: ashok malhotra [mailto:ashok.malhotra@oracle.com]
> Sent: 31 January 2009 22:29
> To: eric.wells@hitachisoftware.com
> Cc: sca-policy@lists.oasis-open.org
> Subject: Re: [sca-policy] SCA Policy RFC2119 Review Document [POLICY-62] F2F Actions
> 
> Thanks, Eric!
> When you and Dave tell me you are done with the RFC 2119 stuff I want to
> apply a couple of issues.
> All the best, Ashok
> 
> 
> Eric Wells wrote:
> > All,
> >     a new draft of the SCA Policy spec with Action from the F2F completed is
> > at:
> >
> >
> > http://www.oasis-open.org/committees/download.php/30985/sca-policy-1.1-spec-
> > CD01-Rev13d.doc
> >
> > I have tried to apply all the "editorial" actions relating to issue
> > POLICY-62 the RFC2119 review and NO OTHERS.
> > My understanding is that we need a "base" document that is free of RFC2119
> > issues that we can vote on for a new CD before making any other changes (new
> > issues etc).
> > Note that "editorial" in this case does go a little beyond correcting
> > spelling mistakes so PLEASE REVIEW THE DOCUMENT CAREFULLY.
> >
> > I found it difficult to sort out some of the previous changes while
> > reviewing the document (in MS WORD) so I have added a comment to each
> > changed section that point to the AI in the F2F minutes. This should make it
> > easier to see why things were changed. (Also note that this was a joint
> > effort so please don't rely on the changes from one person).
> >
> > There are two items I did not do as I can't recall the details from the F2F
> > and they don't seem to make sense to me. It may be that they have already
> > been applied or I am just not getting it. Either way someone else should
> > take a look.
> >
> > 	Action 20090128-41: Remove the whole of the last paragraph of 4.10.1
> >
> > 	Action 20090128-64: Make [POL90021] non-normative
> >
> > The other actions that remain are either new issues or changes that I don't
> > know enough about the requirements to make a sensible attempt.
> >
> > Best Regards,
> >               Eric.
> >
> > Eric Wells.
> > Consulting Engineer.
> > Hitachi Computer Products (America) Inc.
> > San Francisco, CA. USA.
> > +1 (415) 656-4346
> > eric.wells@hitachisoftware.com
> >
> >
> >
> > COMPLETED
> > =========
> > Action 20090128-03: Move [POL20001] to the end of section 4.10.1
> >     [POL20001] is now [POL40025]
> > Action 20090128-05: Add a normative statement requiring the @name attribute
> > of an intent to be unique in the Domain (line 257)
> > Action 20090128-06: Remove [POL30014] (line 262 )
> > Action 20090128-07: Change [POL30004] to read "If an intent has more than
> > one qualifier, one and only one of the qualifiers MUST be declared as the
> > default qualifier.
> > Action 20090128-08: Change [POL30004] to read "One and only one of the
> > qualifiers MUST be declared as the default qualifier."
> > Action 20090128-10: Reword the "should" statements in the 3rd paragraph
> > following the example in 4.3
> >     Actually 3.4 not 4.3
> > Action 20090128-11: Reword the "should" statement in the 6th paragraph
> > following the example in 4.3
> >     Actually 3.4 not 4.3
> > Action 20090128-12: Remove the final paragraph of 3.4 (about normatively
> > defined PolicySets)
> > Action 20090128-13: change POL30020 to "If a policySet or intentMap
> > specifies " and then delete POL30009
> > Action 20090128-14: Change POL30010 For each qualifiable intent listed
> > Action 20090128-15: Remove conformance statement [POL30012]
> > Action 20090128-16: (Dave) Rework the wording of [POL30013] to deal with
> > what "compatible" means in this case
> > Action 20090128-17: Replace "should" with "ought" in the paragraph
> > immediately above the BasicAuthMsgProtSecurity example
> > Action 20090128-19: Remove [POL40002].
> > Action 20090128-21: Section 4.4.1 bullet 3, change parenthesis to read
> > "rather than to all uses of the composite"
> > Action 20090128-28: Add the word "Any" to the beginning of [POL40009]
> > Action 20090128-29: Change POL40009 and POL40014 as written in the minutes
> >     "Any two intents applied to a given element, qualified, MUST NOT be
> > mutually exclusive" [POL40009]"
> >     "The intents declared on elements lower in the implementation hierarchy
> > of a given element MUST be applied to the element [POL40014]"
> > Action 20090128-31: Make a new normative statement from the text following
> > POL40014:
> >     "A qualifiable intent expressed lower in the hierarchy can be qualified
> > further up the hierarchy in which case the qualified version of the intent
> > MUST apply to the higher level element [POL4xxxx]"
> > Action 20090128-32: Change Rule 2 in 4.5.2 to read:
> >     The intents declared on elements higher in the structural hierarchy of a
> > given element MUST be applied to the element EXCEPT
> >     o if any of the inherited elements is mutually exclusive with an intent
> > applied to the element, then the inherited intent is ignored
> >     o if any of the inherited elements is mutually exclusive with an intent
> > applied to the element, then the inherited intent MUST be ignored
> >     o if the overall set of intents from the element itself and from its
> > structural hierarchy contains both an unqualified version and a qualified
> > version of the same intent, the qualified version of the intent MUST be
> > used.
> > Action 20090128-33: Delete [POL40004] from Section 4.5.1
> > Action 20090128-35: Change [POL40006] to read:
> >     "If the policySet on a <componentType/> has a @provides list that
> > includes an intent that is listed in the @provides list of a policySet on
> > the <component/>, the componentType policySet MUST be ignored"
> > Action 20090128-36: Replace the words of [POL40016] with the words in the
> > minutes
> >     "When calculating the set of intents and set of policySets which apply
> > to either a service element or to a reference element of a component,
> > intents and policySets from the interface definition and from the interface
> > declaration(s) MUST be applied to the service or reference element and to
> > the binding element(s) belonging to that element. [POL40016]"
> > Action 20090128-37: Replace final paragraph of Section 4.8 with the text in
> > the minutes
> >     "The locations where interfaces are defined and where interfaces are
> > declared in the componentType and in a component MUST be treated as part of
> > the implementation hierarchy as defined in Section 4.5 Usage of @requires
> > attribute for specifying intents" [POL40xxx]
> > Action 20090128-39: Replace 2nd paragraph of 4.10.1 with the 2 normative
> > statements in the minutes
> >     "The SCA runtime MUST determine the compatibility of the policySets at
> > each end of a wire using the compatibility rules of the policy language used
> > for those policySets" [POL4xxxx]
> >     "The policySets at each end of a wire MUST be incompatible if they use
> > different policy languages" [POL4xxxx]
> > Action 20090128-40: Replace 2nd bullet and the numbered list with the
> > following normative statement:
> >     "Where the policy language in use for a wire is WS-Policy, strict
> > WS-Policy intersection MUST be used to determine policy compatibility."
> > Action 20090128-42: Remove 2nd paragraph of 4.11
> > Action 20090128-44: Replace [POL40008] with "An SCA runtime MUST use the
> > algorithm in section 4.12.1 to select concrete policies that apply to
> > various SCA artifacts"
> > Action 20090128-45: Add a section 4.12.1 for the "Algorithm for Matching
> > Intents and PolicySets"
> > Action 20090128-46: Include the Note: section within the "Algorithm" section
> > of 4.12 to make it normative
> > Action 20090128-47: Remove step A.5 from the algorithm in 4.12
> > Action 20090128-48: Change step A.1 in 4.12 to say "Start with the set of
> > intents specified in the elements' @requires attribute"
> > Action 20090128-49: Change step 8 in 4.12 A  to "If the set of intents
> > contains a mutually exclusive pair of intents the SCA runtime MUST raise an
> > error and must stop the algorithm"
> > Action 20090128-50: Replace step B in 4.12 with: "Remove all directly
> > supported intents from the required intent set - directly supported intents
> > are the sets of intents listed in the @alwaysProvides and @mayProvides
> > attributes of the bindingType/implementationType declaration  for a
> > binding/implementation element respectively."
> > Action 20090128-55: (Dave) Remove section 7.2.2
> > Action 20090128-58: Remove [POL90001] as it is a duplicate
> > Action 20090128-59: in definition of managedTransaction.local, add a
> > normative statement requiring that any propagated global transaction MUST
> > NOT be visible to the target component
> > Action 20090128-61: Remove [POL90018] -- it is a duplicate [POL90024]
> > Action 20090128-62: Add a normative statement for "The SCA runtime ignores
> > propagatesTransaction for OneWay methods." in 9.6.1
> > Action 20090128-63: Correct the table in Section 9.5.2 to provide a
> > normative statement for the "Error" described in Table 1 Section 9.6.2
> > Action 20090128-67: Delete section 9.7
> >     Note there is a section 9.8 in sca-policy-1.1-spec-CD01-Rev13c which is
> > now renumbered to 9.7
> > Action 20090128-69: (Chairs) Remove the Non-Normative Text appendix
> >
> >
> >
> >
> > NOT COMPLETED
> > =============
> > Action 20090128-04: (Dave) Create a normative statement in an appropriate
> > section which reflects the non normative words at the end of section 2.3
> >     Possibly done.
> > Action 20090128-09: (Ashok) Add a reference to the XPath specification for
> > the description of the @appliesTo attribute
> > Action 20090128-18: (Dave) Add a formal definition section for the
> > <policySetAttachment/> element
> > Action 20090128-20: Section 4.4 consider normative statements which are
> > needed to deal with the case of deploying (new) PolicySets to a Domain that
> > already contains deployed artifacts (such as Composites)
> > Action 20090128-22: Reconsider the wording of section 4.4.2 to remove
> > ambiguities and also to ensure that "ancestor inheritance" is properly
> > addressed
> > Action 20090128-30: (Eric) Check the meaning of "applies" and determine if
> > the spec needs a statement added relating to its meaning
> > Action 20090128-34: Mike E to raise an issue to change the normative meaning
> > of [POL40006]
> >     "If a component has any policySets applied to it, then any policySets
> > attached to the componentType are ignored"
> > Action 20090128-38: (Dave) Reexamine section 4.9 to determine if there need
> > to be normative statements
> > Action 20090128-41: Remove the whole of the last paragraph of 4.10.1
> >     Possibly done - Don't see why we want to delete the existing paragraph
> > in "sca-policy-1.1-spec-CD01-Rev13c" as posted.
> > Action 20090128-43: Replace 2nd paragraph of 4.12 with wording that captures
> > the concept of expansion of the profile intent
> > Action 20090128-51: Dave Booz & Mike Edwards to review and make proposals
> > for section 4.12.1
> > Action 20090128-52: (Mike E) Change section 5.1 into a normative definition
> > of implementationType
> > Action 20090128-53: (Mike) Create a normative statement requiring the
> > presence in any Domain of the <definitions/> file containing the intent
> > definitions - and decide on the appropriate location for this statement in
> > the spec
> > Action 20090128-54: (Mike) Add wording to the section about requiring the
> > <definitions/> file to be present encouraging the provision ("should") of
> > concrete policies which satisfy these intents
> > Action 20090128-56: (Dave) Raise an issue to require removal of the
> > Authorization section (7.3 and its subsections)
> > Action 20090128-57: (Martin) Create normative statements for the meaning of
> > each intent defined in the Policy specification
> > Action 20090128-60: Dave to query Assembly TC on the semantics of OneWay
> > messages
> > Action 20090128-64: Make [POL90021] non-normative
> >     *** Why? ***
> > Action 20090128-66: (Mike E) Raise an issue to change section 9.6.3 to be a
> > non-normative example
> > Action 20090128-65: (Ashok) Raise an issue that the Qualified intent
> > mechanism is broken and needs fixing
> > Action 20090128-68: (Chairs) To fill in the Acknowledgements appendix
> > Action 20090128-70: (Martin) Create appropriate words for Conformance
> > section
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
> 
> ---------------------------------------------------------------------
> 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]