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 - draft G
- From: "Eric Wells" <eric.wells@hitachisoftware.com>
- To: <sca-policy@lists.oasis-open.org>
- Date: Mon, 9 Feb 2009 09:56:41 -0800
All,
just for the
record...
I
reviewed the spec and didn't find any glaring inconsistencies in the usage of
"applied" and "attached".
I
would still like to add some terminology to indicate "attached" is "syntax"
related and "applied" implies some sort of processing (inheritance, etc).
However I could not think of appropriate wording.
It
also occurred to me that this sort of terminology really belongs in a glossary,
but we can't just have these two items. I think at this late stage it would be
too much work to add a full glossary.
Consequently, I don't propose any changes at the
moment.
Best
Regards,
Eric.
Eric Wells.
Consulting Engineer.
Hitachi Computer Products
(America) Inc.
San Francisco, CA. USA.
+1 (415)
656-4346
eric.wells@hitachisoftware.com
Here is the link to the final proposal for RFC2119 text (Issue 62):
http://www.oasis-open.org/committees/download.php/31104/sca-policy-1.1-spec-CD01-Rev13g.doc
By
my count, the following action remains:
Action 20090128-30:
(Eric) Check the meaning of "applies" and determine if the spec needs a
statement added relating to its meaning
thanks
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
Mike
Edwards ---02/06/2009 09:44:33 AM---Folks, I've just posted Rev F completing my
actions from the F2F:
From: |
Mike Edwards
<mike_edwards@uk.ibm.com> |
To: |
sca-policy@lists.oasis-open.org |
Date: |
02/06/2009 09:44 AM |
Subject: |
Re: [sca-policy] SCA Policy RFC2119
Review Document [POLICY-62] F2F Actions - 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
"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]