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] F2FActions - draft F



Folks,

I've just posted Rev F completing my actions from the F2F:

http://www.oasis-open.org/apps/org/workgroup/sca-policy/download.php/31089/sca-policy-1.1-spec-CD01-Rev13f.doc

This completes the following actions from the F2F:

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

These actions are also complete, but dont directly affect this version of the spec

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-66: (Mike E) Raise an issue to change section 9.6.3 to be a non-normative example


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com



From: David Booz <booz@us.ibm.com>
To: sca-policy@lists.oasis-open.org
Date: 04/02/2009 16:58
Subject: Re: [sca-policy] SCA Policy RFC2119 Review  Document [POLICY-62] F2F Actions - draft E





To review this document, you might want to review with changes turned off, it's getting quite messy.

http://www.oasis-open.org/committees/download.php/31039/sca-policy-1.1-spec-CD01-Rev13e.doc

Here's a log of what I've accomplished:

Verified actions applied by Eric/Dave previously:
Problems encountered:
a) 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."

these were not applied correctly so I fixed them in draft e

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

I adjusted Eric's wording slightly, changing the word client to reference.


c) Action 20090128-64: Make [POL90021] non-normative
Eric is questioning why we decided to make this stmt non-normative. IIRC, we decided that POL90021 was redundant with 90020, but that a factual assertion would still be useful. I made the change as directed by the AI.



===========================================================================================

Completed the following actions:
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
- Section 4.12.F already has normative words which I reflected non-normatively in section 2.3.
Action 20090128-09: (Ashok) Add a reference to the XPath specification
Action 20090128-18: (Dave) Add a formal definition section for the <policySetAttachment/> element
Action 20090128-22: Reconsider the wording of section 4.4.2 to remove ambiguities and also to ensure that "ancestor inheritance" is properly addressed
- Deleted POL40003 - it is in direct conflict with section 3.4 (1st paragraph below the example), moved some text from 4.3 into 3.4.
Action 20090128-43: Replace 2nd paragraph of 4.12 with wording that captures the concept of expansion of the profile intent
Action 20090128-38: (Dave) Reexamine section 4.9 to determine if there need to be normative statements
Action 20090128-41: I can confirm that was done during the F2F meeting and therefore was complete in draft c that I sent out.
Action 20090128-56: (Dave) Raise an issue to require removal of the Authorization section (7.3 and its subsections)
Action 20090128-60: Dave to query Assembly TC on the semantics of OneWay messages
- decided to delete the note at the end of 9.5.2 as the decision from assembly is irrelevant to tran semantics - trans don't flow on oneways.
Action 20090128-64: Make [POL90021] non-normative
Action 20090128-68: (Chairs) To fill in the Acknowledgements appendix
===========================================================================================

Remaining actions:


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-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-51: Dave Booz & Mike Edwards to review and make proposals for section 4.12.1
- I did a little work here, but Mike should also take a pass.
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-57: (Martin) Create normative statements for the meaning of each intent defined in the Policy specification
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-70: (Martin) Create appropriate words for Conformance section



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

Inactive hide details for "Eric Wells" ---01/31/2009 05:19:19 PM---All,     a new draft of the SCA Policy spec with Action from"Eric Wells" ---01/31/2009 05:19:19 PM---All, a new draft of the SCA Policy spec with Action from the F2F completed is

From:

"Eric Wells" <eric.wells@hitachisoftware.com>

To:

<sca-policy@lists.oasis-open.org>

Date:

01/31/2009 05:19 PM

Subject:

[sca-policy] SCA Policy RFC2119 Review Document [POLICY-62] F2F Actions





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










Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]